Maksim Kabakou - Fotolia

Manage Learn to apply best practices and optimize your operations.

Don't ever put a non-Java LTS release into production

Development teams should avoid non-long-term support releases at all costs. Pay attention to the Java release cycle to make sure your updates are supported.

With new JDK releases scheduled to arrive every six months, organizations will quickly find themselves two or three versions behind the latest build. For example, any organization that upgraded to Java 11 shortly after its release in September of 2018 will be three versions behind when Java 14 comes out in March 2020. But teams should not allow this new version numbers game to make them anxious, because it makes no sense to even contemplate a production move to a non-long-term support (LTS) Java release.

Every so often, Oracle drops an LTS JDK release. Java 8, which was first released in March 2014, was an LTS release. Oracle provided Java 8 support for commercial users until January 2019 and will provide public updates throughout 2020.

Version 11 is the current Java LTS release, and organizations that use this version in production will continue to enjoy vendor support for years to come. As for all the non-Java LTS versions released into the ecosystem, while they are interesting to explore, they aren't production worthy.

Ongoing Java LTS releases

Updates aren't feature enhancements. For the most part, they're fixes. Sometimes an update addresses a security bug, other times a performance enhancement, or maybe the update wants to reduce the startup time. The updates are always minimally invasive, tested to be backwards compatible and are always highly recommended to be installed. There are plenty of updates, too. By October 15, 2019 there were 231 LTS updates for JDK 8.

Now let's compare Java 8 with Java 9. Java 8 was released in September 2017. Java 9 support ended in January 2018, with only four major updates in its very short lifespan. If any new bugs were found in the Java 9 software, the only fix is to move to Java 10 or 11.

Play with them on your laptop, but don't use a single feature, and wait for the LTS.
Gil TeneCTO, Azul Systems

Java 8 was an LTS release. Java 11, which was released in September 2018, is a currently supported LTS release. And version 17, which will be released in 2021, will be a Java LTS release.

All of this harkens back to my original point. Only currently supported Java LTS releases should ever be used in a production environment.

Feature releases vs. LTS releases

So, what about Java 12 or 13?

"Play with them on your laptop, but don't use a single feature, and wait for the LTS," said Gil Tene, CTO of Azul Systems. "Java 12.02 was the last update to 12. What would you do if you were running 12 and there was a security issue that wasn't fixed until the 13.01 release? Would you want to run a new release that was only a few months old? Would you even be allowed to?"

Or worse yet, in a situation such as the one Tene describes, you might find yourself back-porting to an older version of Java that does have ongoing support. It's not particularly likely that this would happen, but it is possible, so why would an organization even take the risk?

When a new version of the JDK gets released, read up on the feature sets, familiarize yourself with the language updates and maybe even run your current applications through some backwards compatibility tests to see if any issues arise.

But don't ever put a non-Java LTS release into production. It's foolhardy to say the least.

Dig Deeper on JSRs and APIs

Join the conversation

3 comments

Send me notifications when other members comment.

Please create a username to comment.

Was there ever a preview feature on a new JDK release that was so important to you that you ran that version in production?
Cancel
These articles written by authors who have not spent time trying to understand what they're writing about really hurt the java ecosystem.
Cancel
That sure is a generic, worthless statement.  Care to elaborate specifically or add value to your comment?  As someone who supports JRE in a corporate environment, what the author is saying is spot on.
Cancel

SearchAppArchitecture

SearchSoftwareQuality

SearchCloudComputing

SearchSecurity

SearchAWS

Close