Should you adopt Java 12 or stick on Java 11 for the next 3 years? Seems like an innocuous question, but it is one of the most important decisions out there for those running on the JVM. I'll try to cover the key aspects of the decision, with the assumption that you care about running with the latest set of security patches in production.
TL;DR, It is vital to fully understand and accept the risks before adopting Java 12.
The Java release train
There is now a new release of Java every six months, so Java 12 is less than five months away despite Java 11 having just been released. As part of the process of moving to more frequent releases, certain releases are designated to be LTS (long term support) and as such will have security patches available for four years or more. This makes them "major" releases, not because they have a bigger feature set but because they have multi year support.
It is expected that Java 11 patches (11.0.1, 11.0.2, 11.0.3, etc.) will be smaller and simpler than Java 8 updates (8u20, 8u40, 8u60, etc.) - Java 11 updates will be more focused on security patches, without the internal enhancements of Java 8 updates. Instead, Oracle want us to think of Java 12, 13, 14 etc. as small upgrades, similar to an imaginary Java 11u20, 11u40 etc. To be blunt, I find this nonsensical.
Senior Oracle employees have repeatedly argued that updates such as 8u20 and 8u40 often broke code.
This was not my experience. In fact my experience was that update releases primarily contained bug fixes.
The only break I can remember was the addition of --allow-script-in-comments to Javadoc, which isn't a core part of Java.
As a result, I have never feared picking up the latest update release - and this has been a core benefit of the Java platform.
Drilling down into why update releases tend to cause no problems, lets examine the differences between release types:
| Model | Old model | New model | ||
|---|---|---|---|---|
| Upgrade | Java major releases | Java update releases | Java release train | Java patches |
| Frequency | Every 3 years or so | Every 6 months | Every 6 months | Every 3 months |
| Versions | 6 -> 7 -> 8 | 8 -> 8u20 -> 8u40 | 11 -> 12 -> 13 | 11 -> 11.0.1 -> 11.0.2 |
| Language changes | ✅ | ✘ | ✅ | ✘ |
| JVM changes | ✅ | ✘ | ✅ | ✘ |
| Major enhancements | ✅ | ✘ | ✅ | ✘ |
| Added classes/methods | ✅ | ✘ | ✅ | ✘ |
| Removed classes/methods | ✘ | ✘ | ✅ | ✘ |
| New deprecations | ✅ | ✘ | ✅ | ✘ |
| Internal enhancements | ✅ | ✅ | ✅ | ✘ |
| JDK tool changes | ✅ | ✅ | ✅ | ✘ |
| Bug fixes | ✅ | ✅ | ✅ | ✅ |
| Security patches | ✅ | ✅ | ✅ | ✅ |
Given the table above, I find it amazing that anyone would claim moving from 11 to 12 to 13 is anything like moving from 8u20 to 8u40. But that is the official Oracle viewpoint:
Going from Java 9->10->11 is closer to going from 8->8u20->8u40 than from 7->8->9.
Oracle FAQ
As the table clearly shows, each version in the Java release train can contain any change traditionally associated with a full major version. These include language changes and JVM changes, both of which have major impacts on IDEs, bytecode libraries and frameworks. In addition, there will not only be additional APIs, but also API removals (something that did not happen prior to 8).
Oracle's claim is that because each release is only 6 months after the previous one, there won't be as much "stuff" in it, thus it won't be as hard to upgrade. While true, it is also irrelevant. What matters is whether the upgrade has the potential to damage your code stack or not. And clearly, going from 11 -> 12 -> 13 has much greater potential for damage than 8 -> 8u20 -> 8u40 ever did.
The key difference compared to updates like 8u20 -> 8u40 are the changes to the bytecode version, and the changes to the specification. Changes to the bytecode version tend to be particularly disruptive, with most frameworks making heavy use of libraries like ASM or ByteBuddy that are intimately linked to each bytecode version. And moving from 8u20 -> 8u40 still had the same Java SE specification, with all the same classes and methods, something that cannot be relied on moving from 12 to 13. I simply do not accept Oracle's argument that the "amount of stuff" in a release is more significant than the "type of stuff".
Note however that another one of Oracle's claims really does matter. They point out that if you stick with Java 11 and plan to move to the next LTS version when it is released (ie. Java 17) that you might find your code doesn't compile. Remember that the Java development rules now state that an API method can be deprecated in one version and removed in the next one. Rules that do not take LTS releases into account. So, a method could be deprecated in 13 and removed in 15. Someone upgrading from 11 to 17 would simply find a deleted API having having never seen the deprecation. Lets not panic too much about removal though - the only APIs likely to be removed are specialist ones, not those in widespread use by application code.
Considerations before adopting the release train
In this section, I try to outline some of the considerations/risks that must be considered before adopting the release train.
Locked in to the train
If you adopt Java 12 and use a new language feature or new API, then you are effectively locking your project in to the release train.
You have to adopt Java 13, 14, 15, 16 and 17.
And you have to adopt each new release within one month of the next release coming out.
Remember that with the new release train, each release has a lifetime of six months, and is obsolete just seven months after release. That is because there will be only six months of security patches for each release, the first patch 1 month after release and the second 4 months after release. After 7 months, the next set of security patches come out but the older release will not get them.
Do your processes allow for a Java upgrade, any necessary bug fixing, testing and release within that narrow 1 month time window? Or are you willing to run in production on a Java version below the security baseline?
Upgrade blockers
There are many possible things that can block an upgrade of Java. Lets make a list of some of the common ones.
Insufficient development resources: Your team may get busy, or be downsized, or the project may go to production and the team disbanded. Can you guarantee that development time will be available to do the upgrade from Java 15 to 16 in two years time?
Build tools and IDEs: Will your IDE support each new version on the day of release? Will Maven? Gradle? Do you have a backup plan if they don't? Remember, you only have 1 month to complete the upgrade, test it and get it released to production. Under this section other tools include Checkstyle, JaCoCo, PMD, SpotBugs and many more.
Dependencies: Will your dependencies all be ready for each new version? Quickly enough for you to meet the 1 month deadline? Remember, it is not just your direct dependencies, but everything in your stack. Bytecode manipulation libraries are particularly affected for example, such as ByteBuddy and ASM.
Frameworks: Another kind of dependency, but a large and important one. Will Spring produce a new version every six months, within the narrow one month time window? Will Jakarta EE (formerly Java EE)? What happens if they don't?
Now the traditional approach to any of these blockers was to wait. With versions of Java up to 8, a common approach was to wait 6 to 12 months before starting the upgrade to give tools, libraries and frameworks the chance to fix any bugs. But of course the waiting approach is incompatible with the release train.
Cloud / Hosting / Deployment
Do you have control of where and how your code runs in production? For example, if you run your code in AWS Lambda you do not have control.
AWS Lambda has not adopted Java 9 or 10, and they don't even have Java 11 even though it is over a month after release.
Unless AWS give a public guarantee to support each new Java version, then you simply can't adopt Java 12.
(My working assumption is that AWS Lambda will only support major LTS versions, supported by the Amazon Corretto JDK announcement.)
What about hosting of your CI system? Will Jenkins, Travis, Circle, Shippable, GitLab be updated quickly? What do you do if they are not?
Predicting the future
Perhaps you have read through the list above and are happy your code and processes today can cope. Great! But it is critical to understand that you are also restricting your ability to change in the future.
For example, maybe your code doesn't run on AWS Lambda today. But are you willing to say you can't do so for the next three years?
Planning for the release train
If you are considering adopting the release train, I recommend preparing a list of all the things you depend on now, or might depend on in the next 3 years. You need to be confident that everything on that list will work correctly and be upgraded along with the release train, or have a plan if that dependency is not upgraded. The list for my day job is something like this:
- Amazon AWS
- Eclipse
- IntelliJ
- Travis CI
- Shippable CI
- Maven
- Maven plugins (compile, jar, source, javadoc, etc)
- Checkstyle, & associated IDE plugins and maven plugin
- JaCoCo, & associated IDE plugins and maven plugin
- PMD, & associated maven plugin
- SpotBugs, & associated maven plugin
- OSGi bundle metadata tool
- Bytecode tools (Byte buddy / ASM etc)
- Over 100 jar file dependencies
And I've probably forgotten something.
Don't get me wrong. I think it is perfectly possible to make a choice to say that you are willing to take the risk. That the benefits of new language features, and probable enhanced performance, make the effort worthwhile. But I strongly believe it is more risky than remaining on Java 11.
A middle ground?
One possible middle ground is to develop your application for Java 12, but run it in production on Java 13, 14, 15 etc. as soon as they come out. Sadly, this approach is less viable than it should be.
The removal of APIs and changes to the bytecode version add uncertainty to the stack. Even if your code doesn't use one of the removed APIs, one of your libraries might. Or a bytecode manipulation library might need upgrading, with knock on effects. So while the middle ground is a possible fallback if you get stuck, it is far from a no-risk solution.
Some additional links
Spring framework has expressed its policy wrt Java 12 in a video. The key sections are:
Jaba 8 and 11 as the LTS branches officially supported from our end. Best efforts support for the releases inbetween. ... if you intend to upgrade to 12 ... we are very willing to work with you ... but they are not officially production supported. ... The long term support releases are what we are primarily focussed on. Java 12 and higher will be best effort from our side.
As an example of a typical software vendor, Liferay states:
Liferay has decided we will not certify every single major release of the JDK. We will instead choose to follow Oracle's lead and certify only those marked for LTS.
Liferay blog
Oracle's official "misconceptions" slide about the new release model.
Summary
I'm sure some development teams will adopt the Java release train. My hope is that they do so with their eyes wide open. I know we won't be adopting the release train at my day job any time soon, a key blocker being our use of AWS Lambda, but I'd be concerned about all the other points too.
Feel free to leave a comment, especially if you think I've missed any points that should be on the considerations list.
