As the Azul alternate representative on the JCP Executive Committee (EC), I get to attend all the EC meetings and take part in the various discussions. One topic that the EC has been devoting a lot of energy to recently is the adoption of the Java platform, post-JDK 8.
Ordinarily, this would be a discussion about the best ways to encourage people to migrate their applications to using JDK 9. However, this is not so in the new Java world order.
Several reasons are making people’s decision about which JDK to move to from JDK 8 harder than usual:
- One of the biggest is the new, faster, release cadence for the JDK. We now have a new JDK every six months, which means that JDK 9 is no longer the most recent version. That’s currently JDK 10, and JDK 11 will be released in less than two months. Which JDK to migrate to has become much more of a moving target.
- JDK updates. With the faster release cadence, a new strategy was required for delivering updates. Oracle now produce two JDK binaries: the traditional Oracle JDK and one built purely from OpenJDK source. By JDK 11 these will be functionally equivalent but not so from the perspective of updates. Each OpenJDK binary will only have updates (security patches and bug fixes) for six months, until the release of the next JDK. The Oracle JDK will have a long-term support (LTS) release every three years. JDK 8 is currently an LTS; the next will be JDK 11. Many people had assumed that they would move from JDK 8 to JDK 11 because it’s an LTS. However, the Oracle JDK 11 binary, the one with LTS, is not going to be free for use in production. If people want to use Oracle JDK 11 in production and get updates, they will need a commercial support contract. This is a significant change for most users.
- The issues related to modularisation. The Java Platform Module System (JPMS) not only separates the previously monolithic core libraries into a set of discrete modules, but also encapsulates most of the internal APIs. This encapsulation renders the APIs inaccessible to applications as well as frameworks and third-party libraries. Some APIs (like the infamous sun.misc.Unsafe) have been left accessible through JEP 260 and the jdk.unsupported module, but others need additional command line flags, especially for reflective access. With the difficulties associated with moving to the module system the option to stay on JDK 8 for the time being is an attractive one.
The JCP EC members attend plenty of conferences and developer events, so we have plenty of anecdotal evidence of which version of the JDK people are planning to use in the future. To get a more definitive assessment, a survey was run and promoted to gather hard data. The results of this can be found here.
The results reveal a lot, not just about which versions of the JDK people are or are not considering. One of the key underlying pieces of data that can be extracted from this is that there is still considerable confusion about how the new system of JDK binary distribution and updates works.
The fact that 13% of the respondents are planning to deploy JDK 9 and 12% are considering deploying it is quite remarkable considering that JDK 9 is no longer supported and has already been superseded by JDK 10. Even more people are planning (18%) or considering deployment (18%) of JDK 10, which will quickly be superseded by JDK 11 in September. It appears that a lot of people are planning to continue to use JDK 8 and not make the move to using modules. For those who are using JDK 9 and later the majority appear to be leaving everything on the classpath and not making the move to automatic or full modules. Many of the comments reveal that the move to full modularity is not always easy in practice.
As a follow up to this, our CTO, Gil Tene, ran a poll on Twitter. The question was chosen deliberately to assess people’s understanding of how the Java release process is changing. “If you run Java applications, when are you planning to start using JDK 9 or 10 in production?”
The available answers are:
- Already in production
- In the next six months
- In the next 1-2 years
- Never
At the time of writing, over half those who answered selected options 2 or 3. By leaving out the possibility of using JDK 11, the results again show confusion about the availability of updates for different releases of the JDK.
Clearly, there is work to be done in helping the Java community to fully understand the implications of the new JDK release cadence, delivery of binaries and updates.
In my earlier blog post, I tried to provide a concise summary of all the changes and their impact. With Azul’s Zulu JDK, we can help provide a different choice of JDK for your deployments.
What version of the JDK are you planning for future deployments?
