Any takers?

Who will use JDK 9?

Simon Ritter
© Shutterstock / Seventy Three  

What are your plans for moving to JDK 9? Are you already in production or are we all just “thinking” about it? Simon Ritter believes that there are a few key reasons why JDK 9 will have little adoption in production.

Recently, I ran a webinar on “Migrating Applications to JDK 9”. To develop this, I used some of the material I had researched for an earlier blog post along with new material gleaned from different sources. Rather than looking at the details of moving an application from the classpath to a set of modules, I focused on changes in JDK 9 that might cause existing applications to stop working. It turns out there are quite a few small changes that may result in an application not starting on JDK 9, even if it does not use any of the internal APIs, like the infamous sun.misc.Unsafe class.

During the webinar, I conducted a poll of the audience to find out what stage they had reached in moving their applications to JDK 9. Given the title of the webinar, I assumed this would be a good group to ask. The results were both revealing and interesting. I ran the webinar twice: once for developers in EMEA and once for developers in the Americas.

SEE MORE: JDK 9: Pitfalls for the unwary

The question I asked was “What are your plans for moving to JDK 9?” The results are shown in the graphs below as percentages.

Results from the EMEA audience:


Results from the Americas audience:


Combined results:


Now, I know that there are “Lies, damn lies and statistics” and it’s true the sample size was less than 150, but I think this gives a reasonable indication of JDK 9 adoption. As an additional data point, during my keynote presentation at the Java Days Kiev this weekend I asked the 800 developers in the audience who was using JDK 9. Not a single person raised their hand.

SEE MORE: “JDK 9 does not have big features for developers, it’s about changing the runtime with modularity”

I believe there are several reasons that JDK 9 will have little adoption in production:

  • The number of incompatible changes when moving applications from JDK 8 or earlier. Although the six methods that have been removed from the standard API won’t affect many people, things like the number of command line options that will stop the JVM starting will be a hindrance.
  • The effect of encapsulation of internal JDK APIs. Again, the number of developers directly affected by this will not be significant but those affected indirectly will be. What I mean by this is that most developers use third-party libraries and frameworks when developing applications. There are plenty of these libraries and frameworks that do use encapsulated APIs. Although plenty have tested and made specific JDK 9 versions available, there are still plenty that have not yet done so. For libraries that are not actively maintained this can be an issue that will undoubtedly hold back moving to JDK 9
  • Longevity of support. The recent announcement of a new six-month JDK release cadence means the issue of support, through public updates, is something that developers need to keep in mind when deciding which version of Java to deploy on. JDK 8 has been classified as what is called a Long-Term Support (LTS) release. An LTS release will have three years of public updates, although in the case of JDK 8 this will be more like four and a half years. JDK 9 is not an LTS release, meaning it will only have public updates until the next release in March 2018.

SEE MORE: JavaOne 2017 afterglow

Most of the developers I’ve spoken to recently have said they will continue to use JDK 8 in production until at least the next LTS release, which will be in September 2018. The consensus seems to be that JDK 9 and 10 (at least that’s what it’s called this week) will be used to figure out how to move to JDK 11 when it arrives.

Oracle’s stated plan will make the transition between LTS releases quite challenging for developers. The problem is that there will be no overlap for public updates. When JDK 11 is released, it will contain new features that may well affect application compatibility. Since JDK 8 will no longer have public updates users are faced with two choices, either pay for a commercial support contract or jump to the next LTS release and hope that their applications don’t break or need substantial changes to make them work correctly.


This post was originally published on the Azul Systems blog.


Simon Ritter

Simon Ritter is the Deputy CTO of Azul Systems. Simon has been in the IT business since 1984 and holds a Bachelor of Science degree in Physics from Brunel University in the U.K.

Simon joined Sun Microsystems in 1996 and spent time working in both Java development and consultancy. He has been presenting Java technologies to developers since 1999 focusing on the core Java platform as well as client and embedded applications. Now at Azul Systems he continues to help people understand Java and Azul’s JVM products. Follow him on Twitter @speakjava.

comments powered by Disqus