Happy New Year!
Last year, I wrote a blog with my predictions for what would happen in the world of Java in 2017. Now that 2017 has ended and we’re starting 2018, I thought it would be interesting to look back at what I had predicted and make some new predictions for this year.
I’ll use the same format as last year, looking at the major areas of Java individually
The Core Java Platform (JDK)
My prediction in this area was that JDK 9 would be released (that didn’t exactly require a sixth sense), although I did feel that the scheduled release date might slip (which it did). What I didn’t see was the rejection by the JCP EC of the initial Public Review of the Java Platform Module System (Jigsaw) component JSR. That demonstrated that the JCP EC could make Oracle aware that changes to the spec were required and that Oracle was responsive in making changes necessary to get the JSR approved at the reconsideration ballot.
What I don’t think anyone could have seen, including those making the decisions at Oracle, were the changes to the way the OpenJDK will be released. These announcements came shortly before JavaOne and will have a significant impact on what happens to the JDK in 2018. I don’t think I need to class this as a prediction, but we will have two releases of the JDK this year, JDK 10 and JDK 11. The contents of JDK 10 have now been finalised (I’ll be writing another blog on this shortly) but the contents of JDK 11 still need to be discussed and decided. Looking at the JEPs, we already have the Epsilon GC and dynamic class-file constants, but I predict we’ll also get JEP 323, Local-Variable Syntax for Lambda Parameters. I also predict that the Java EE and CORBA modules will be removed from the JDK. These have been deprecated so won’t require any real engineering effort to remove. I’ll even go further and predict that some other things will be removed in JDK 11: the CMS collector has already been suggested for removal and the browser plugin and even WebStart could be the end of applets entirely. If that does happen, then the previously deprecated applet package and contents will also likely disappear from the java.desktop module.
Java EE
Again, my prediction, if you can call it that, was the release of Java EE 8, which duly happened in September. I also don’t think anyone would have predicted the move of the specifications from Oracle to the Eclipse Foundation.
I know that there is a lot of work going on behind the scenes to get all the required administration work finished. My prediction is that we won’t see a new version of the umbrella EE4J (or whatever the new name is) specification this year. Given enterprise Java’s maturity and the speed at which most users like to upgrade I don’t think this will be an issue.
Java ME
I correctly predicted that there would be no Java ME 9 specification to accompany the launch of Java SE 9. There is some activity currently going on in the JCP to take the most useful parts of Java ME and make them available as separate libraries for use with Java SE. However, I don’t see much demand for this and suspect we won’t see anything substantial in this area again this year. The realities and economics of Moore’s law combined with the Java Platform Module System have made Java ME somewhat irrelevant in this day and age.
Embedded Java
I didn’t predict anything here, other than the continued popularity of Java for developing these types of application.
It, therefore, came as a bit of a surprise that Oracle decided to discontinue distributing binaries for ARM-based processors, starting with JDK 9.
For developers working in this space, Azul will continue to produce and make available JDK binaries for embedded platforms. In addition to ARM, we can also provide PowerPC-based ones. Just let us know if this is something you’re interested in.
Performance
One last thing that’s not a specific Java platform but very important.
Having seen the recent news about potential security issues related to speculative execution in Intel CPUs, it seems that the fixes in the Linux and Windows operating systems are likely to have significant adverse impact on performance. This will mean people will be looking to extract as much performance as possible from their JVMs to offset reductions in performance at the operating system level.
Azul’s Zing JVM is designed to do just that. If you need more performance from your JVM, why not try it free for 30 days?
