1. Introduction
In this article, we’ll discuss the new time-based releases of Java and the impact on all types of developers.
Changes to the release schedule include updating the feature delivery and support levels for versions of Java. Overall, these changes are distinctly different from the Java that has been supported by Oracle since 2010.
2. Why Six-Month Releases?
For those of us used to Java’s historically slow release cadence, this is a pretty significant departure. Why such a dramatic change?
Originally, Java defined its major releases around the introduction of large features. This had a tendency to create delays, like those we all experienced with Java 8 and 9. It also slowed language innovation while other languages with tighter feedback cycles evolved.
Simply put, shorter release periods lead to smaller, more manageable steps forward. And smaller features are easier to adopt.
Such a pattern pairs well in current conditions and allows JDK development to work in agile methodologies akin to the community it supports. Also, it makes Java more competitive with runtimes like NodeJS and Python.
Of course, the slower pace also has its benefits, and so the six-month release cycle also plays a role in a larger Long Term Support framework, which we take a look at in Section 4.
3. Version Number Change
A mechanical aspect of this change is a new version-number scheme.
3.1. JEP 223 Version-String Scheme
We’re all familiar with the old one, codified in JEP 223. This scheme made version numbers incremental and relayed extra information.
Actual Hypothetical Release Type long short ------------ ------------------------ Security 2013/06 1.7.0_25-b15 7u25 Minor 2013/09 1.7.0_40-b43 7u40 Security 2013/10 1.7.0_45-b18 7u45 Security 2014/01 1.7.0_51-b13 7u51 Minor 2014/05 1.7.0_60-b19 7u60
If we run java -version on a JVM for version 8 or older, we’ll see something like:
>java -version java version "1.6.0_27" Java(TM) 2 Runtime Environment, Standard Edition (build 1.6.0_27-b07) Java HotSpot(TM) Client VM (build 1.6.0_27-b13, mixed mode, sharing)
In this case, we might guess this is for Java 6, which is correct, and the 27th update, which is wrong. The numbering scheme isn’t as intuitive as it appears.
Minor releases were multiples of 10, and security releases filled everything else. Typically, we would see the short string appended onto our local installations, such as JDK 1.8u174. The next release may be JDK 1.8u180, which would be a minor release with new fixes.
3.2. New Version-String Scheme
The new version-string scheme will “recast version numbers to encode not compatibility and significance but, rather, the passage of time, in terms of release cycles,” according to Mark Reinhold in the JEP.
Let’s take a look at some:
9.0.4 11.0.2 10.0.1
At a quick glance this appears to be semantic versioning; however, this is not the case.
With semantic versioning, the typical structure is $MAJOR.$MINOR.$PATCH, but Java’s new version structure is:
$FEATURE.$INTERIM.$UPDATE.$PATCH
$FEATURE is what we might think of as the major version, but will increment every six months regardless of compatibility guarantees. And $PATCH is for maintenance releases. But, this is where the similarities stop.
First, $INTERIM is a placeholder, reserved by Oracle for future needs. For the time being, it will always be zero.
And second, $UPDATE is time-based like $FEATURE, updating monthly after the latest feature release.
And finally, trailing zeros are truncated.
This means that 11 is the release number for Java 11, released in September 2018, 11.0.1 is its first monthly update release in October, and 11.0.1.3 would be a hypothetical third patch release from October’s version.
4. Multiple Version Distributions
Next, let’s look at how to pick the right version.
4.1. Stability
Simply put, Java now has a fast channel, every six months, and a slow channel, every three years. Each third-year release is called an LTS release.
On the fast channel, the language releases features in incubation. These language features stabilize in the LTS release.
So, for companies that can embrace volatility in exchange for using new features, they can use the fast channel. For enterprises that appreciate stability and can wait to upgrade, they can upgrade at each LTS release.
Experimentation with JDK versions enables developers to find the best fit.
4.2. Support
There’s also, of course, the matter of support. Now that Java 8 support has sunset, what do we do?
And as discussed earlier, the answer comes in LTS versions, Java 11 being the most recent LTS release and 17 being the next. Updates will be available and supported by vendors such as Oracle and Azul.
If we can trust the support of the community, then Redhat, IBM, and others have stated their support for applying bug fixes for OpenJDK.
4.3. Licensing
One area of confusion for some is the difference between OpenJDK and Oracle JDK.
Actually, they are nearly identical, differing only in which bug fixes and security patches have been picked up, according to Brain Goetz.
OpenJDK acts as the source of most derived JDKs and remains free. Starting with Java 11, Oracle will charge commercial license fees for the Oracle JDK with additional support and services included.
4.4. Fragmentation
With more frequent releases, fragmentation may become an issue. Hypothetically, everyone could be running on different versions of Java with different features even more so than now.
Of course, containerization could help address this. From Docker and CoreOS to Red Hat’s OpenShift, containerization provides the needed isolation and no longer forces one installation location for Java to be used across the server.
5. Conclusion
In conclusion, we can expect a lot more from the Java team at Oracle with a regular release of Java every six months. As a Java developer, the prospect of new language features every six months is exciting.
Let’s keep in mind some of the implications as we decide what our upgrade channel is if we need support and licensing, and how to cope with fragmentation.