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.
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.
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.
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.
If you’re looking for an alternative, cheaper provider of Java SE and OpenJDK support why not look at what Azul can offer with our (free to download) Zulu OpenJDK binaries?
