How to Encourage Upgrades Past Java 8

To understand the current and future state of the Java Ecosystem, we reached out to our community for their insights. Unlike other topics like containers and security, there are far fewer people willing to share their thoughts on the current and future state of Java. This appears to be a function of its maturity relative to other technologies.

We are grateful to our three contributors who all have significant experience with Java:

• Anders Wallgren, CTO, Electric Cloud
• Erik Costlow, Principal Product Evangelist, Contrast Security
• Mark Little, V.P. Middleware Engineering, Red Hat

We asked them, "What can Oracle, or the community, do to encourage organizations to upgrade past Java 8?" Here's what they told us:

• Look at what we are doing with AdoptOpenJDK providing a one-stop shop for developers can get access to different JDK builds from different vendors. We have more efforts to help people who are having problems moving from Version 8 to later versions. A lot of people have done this work and people are willing to share knowledge in the community. It's more about driving the knowledge, giving people access, and letting them know the knowledge exists. This effort has been kicked-off by several of the largest user groups in the world – London Java User Group and the SouJava Users Group based in Brazil.
• Keep coming out with huge improvements. Don’t throw the licensing thing at users right now. Having to change from the JRE hurts the adoption cycle. This requires the adoption of the frameworks themselves for all the various functionality and compatibility. IntelliJ has done a good job of staying ahead of the language changes. They understand the importance of getting support for those kinds of things, so people have the ability to adopt them. It is not just a question of the language, also the tooling and the frameworks that are in use. In the case of Hibernate or Spring, there is a little bit of diving under the covers into the JRE to get something done and those things are done differently. Now, you are a little more coupled to something that changes in the next version and you have to account for that. We see that as we switch over testing. We’ve run into subtle differences between the Oracle JRE and the other we are testing. That subtly is not covered by the Java spec. It takes time to figure out and adjust for the differences. It slows you down and sometimes it stops you.
• Java users need a compelling reason to change beyond Oracle changing the public version. Amazon Corretto’s Java 8 is now publicly supported for four years beyond Oracle’s Java 8 and AWS is the most popular cloud provider, opting people into Java 8 by default. Code built with JDK 11 APIs or bytecode won’t work. The issue I have seen is with compatibility, which I cited as the most important element in the ecosystem. Java 9 introduced modularity requirements, which broke compatibility with certain older code. There’s a campaign now about “works like heaven on jdk11” but the issue is figuring out if some part of your application is in purgatory. I think the strongest encouragement here will come from the cloud providers, not Oracle. When Java X becomes the default in major cloud providers, people will choose X. This means those providers did an analysis on compatibility, cost, and identified that X is better. They aren’t doing that now with JDK 11.