Happy New Year! As we enter the new decade, I decided it was time to write my now annual blog post giving my thoughts on what this year might hold for Java. I’ll also look back on my predictions in the last post to see how accurate (or not) I was.
Obviously, the most significant thing this year will be the celebration of a whole quarter of a century since Java was launched. I plan to write a lengthy missive about the last 25 years of Java closer to the time.
This year I’m going to focus just on the core Java platform. There are a number of reasons for this:
- Java ME really is now well and truly dead. There may be a few people still working with it, but there is absolutely no activity to develop it further in any areas like the JCP.
- Embedded Java. Although there are still plenty of people using this and developing applications, there isn’t anything significant going on that separates it from the core platform. Azul provides free builds of Zulu Embedded for the ARM architecture of either JDK 8 or JDK 11, so you can continue to use this on your Raspberry Pi and similar devices. Commercial support is availble as well, if you’re looking for things like custom builds.
- Jakarta EE. Now the standardisation work has fully moved to the Eclipse Foundation, rather than the JCP, I don’t have any significant interaction with Enterprise Java, so I’ll avoid making wild and (most likely erroneous) predictions about future developments.
JCP
Without the Java EE work, the JCP finds itself in a somewhat challenging place. There are currently 13 JSRs listed as active, but six of these are for recent Java SE releases. The last non-Java SE related JSR to be initiated (Units of Measurement API 2.0) was at the end of 2017. I attend the JCP Executive Committee meetings, and I think some hard decisions will need to be made this year on the direction and organisation of the JCP. Having JSRs is still vitally important to Java SE because it is this that provides a way for the platform to be unencumbered by issues of intellectual property rights.
Java SE
We are now over two years into the change to a six-month release cadence, and it is clear that this is working well. I correctly predicted that last year we would have two releases of Java and (not surprisingly) JDK 12 and JDK 13 were duly delivered on time. (Note, that when I say “prediction”, I’m being rather sarcastic). What we’re now seeing is a faster rate of change for Java than we’ve ever had in its history. This year will bring us JDK 14 and JDK 15 (which even now has early access versions available).
JDK 14 certainly looks like it will be one that has several advantageous developer-related features: Records, pattern matching for instanceof and helpful NullPointerExceptions. There’s also non-volatile mapped memory buffers and a new packaging tool.
One thing that will be interesting is to see user’s reaction to the removal of the CMS collector. It’s been deprecated since JDK 9 but will no longer be included in JDK 14. The G1 collector is mature, very stable and offers superior performance to CMS in most situations. I know some people have grumbled about the loss of CMS, but the reality is that it’s unfair to expect Oracle to maintain it when there is a better replacement available.
This leads me to another prediction for this year, which is that we will see other features in the JDK deprecated. Maybe, the Nashorn JavaScript engine will be removed from JDK 15?
JDK 14 is also notable, as I discussed in my last blog, for having two incubator APIs and three preview features. This ability to include fully formed features in the JDK without making them part of the standard is proving very useful. I predict we will see more of this in JDK 15.
OpenJDK Distributions
Another significant change for Java last year was the end of public updates for Oracle JDK 8. This combined with the move to the license used for Oracle JDK 11 onwards has led to many users needing to evaluate there deployment and update strategies.
Users now have more options than ever before for alternative builds of OpenJDK, both free and with commercial support. For either of those options, please have a look at the Zulu JDK from us at Azul.
Although all these distributions are based on the same source code base (the OpenJDK), there are small differences in terms of testing (such as use of the TCK), backported updates and features (Zulu, for instance, has both Flight Recorder and TLS 1.3 backported from JDK 11 to JDK 8). It’s worth spending some time evaluating the differences before making a decision on which distribution to use.
Conclusions
We’ve now all had time to adjust to the changes in JDK development and distribution. My overall prediction, then, is for another good year for Java. Those users who want stability will continue to use an LTS (or MTS) release, whilst those who can move more quickly will find JDK 14 provides plenty to keep Java fresh.
UPDATE: Based on some feedback from Reddit, there is another conclusion that can be drawn. This is that the Java platform is now more predictable than ever before and a crystal ball is not really required to see into Java’s future. With the six-month release cadence, it is easier to see which features will be added in the next six months and the timing of each release is fixed so doesn’t require any prediction. As such, I predict Java will continue to be the most popular development platform on the planet.
What do you think?
