Since the release of Java 9 in 2017, new Java platform releases have been published using a new and much better defined release train. Unfortunately, the statements about the various changes and improvements to the Release Train were often very vague and there were even false rumors in the community. Oracle, in particular, did poor press work here and did not describe the new release train as transparently and cleanly as it should have been. Since the release of Java 17 brought changes to the release train again, I would like to use this post to describe the specific process.
Hendrik Ebbers (@hendrikEbbers) is Java Champion, JCP Expert Group Member and has been awarded several times as Rockstar Speaker of JavaOne. With his own company Open Elements, Hendrik is currently helping to design the Hedera Hashgraph and make its services available to the public. Hendrik is a co-founder of JUG Dortmund and Cyberland and gives lectures and workshops on Java all over the world. His book “Mastering JavaFX 8 Controls” was published by Oracle Press in 2014. Hendrik is actively involved in open source projects such as JakartaEE or Eclipse Adoptium. Hendrik is a member of the AdoptOpenJDK TSC and the Eclipse Adoptium WG.
beautiful old world
But before we look at the new release train, it makes sense to look at the releases of old Java versions. The following diagram shows the release date and life cycle of Java 6, 7 and 8. The life cycle of the versions is defined by the availability of free security updates for the respective version. As soon as there were no more free updates for one of the versions, its lifespan ends in the diagram.
Different points can be seen in the diagram. First of all, it is important that there is always a period in which at least two releases with security updates are still supported. This time serves users of the platform as a period of time to migrate their applications to the newer Java version. In addition, the intervals between the releases of new versions are different. This is because these Java versions were released as soon as all the features defined for each version were implemented.
For each of these old Java versions, the features to be implemented were defined within a Java Specification Request (JSR) in the Java Community Process (JCP). For Java 8, for example, see JSR 337 in section 3 for a list of features. These are in turn also specified as JSRs, with the introduction of lambda expressions in Java being defined in JSR 335 and the Date & Time API in JSR 310.
Since it was firmly defined in advance which JSRs should be implemented in a new Java version, the release date could never be firmly defined. This has sometimes led to long periods of time between the release of the versions.
Throughout the process, it’s important to note that these releases are not versions specific to, say, the Oracle JDK. All these versions are built in the OpenJDK. This means that every Java vendor can offer a build of their runtime with the current version without there being any differences in functionality.
More dynamic through faster releases
With Java 9, however, this procedure has changed significantly. Instead of long-lived releases with an indefinite publication date and life cycle, a new major release of the Java platform is now appearing every six months. This happens as before in the OpenJDK, but the sources of the OpenJDK have been completely migrated to GitHub since Java 17, where you can understand the exact workflows much better. Since the publication date of a release is firmly defined, the features can no longer be determined in advance. Much more, a new Java version includes all features completed at this time. These features are defined as JDK Enhancement Proposals (JEP) and can all be viewed on the OpenJDK website. These JEPs can be thought of as similar to Epic Issues. As of Java 10, you can also see the list of JEPs included in the release on the respective release pages (see example for Java 11).
Feature Previews
Because some of these features take longer to develop and have a strong impact on the Java platform, Preview and Incubator statuses were introduced for JEPs. The latter allows new APIs to end up in Java versions for testing before they become a final part of the Java class library in a future version. Such APIs are in a special incubator package and will only be moved to their correct package with their final release. The preview status can be used to make new language features of the Java platform available in advance. Such features must be activated via a command line parameter:
$ javac HelloWorld.java
$ javac --release 14 --enable-preview HelloWorld.java
$ java --enable-preview HelloWorldLong-Term Support und Critical Patch Updates
With a new release every six months, the lifespan of Java versions has changed significantly. A distinction is now made between Long-Term Support (LTS) and normal (non LTS) versions. The latter have a lifespan of exactly six months until the release of the next version. For example, Java 14 had a life span from March 2020 to September 2020. Versions marked as LTS are maintained longer in the OpenJDK and receive security updates over a longer period of time.
According to current knowledge, there will be updates for the LTS release Java 17 by 2027. Eclipse Adoptium offers a good overview of the LTS versions in the support overview. Even if LTS updates do not contain any new features, they do fix all known security vulnerabilities. Therefore, such releases are also called Critical Patch Update (CPU). For Java versions that are not defined as LTS versions, two planned CPU releases appear. For Java 16, after the first release in March 2021, version 16.0.1 was released as CPU in April 2021 and 16.0.2 in July 2021. With the release of Java 17, it was determined that there would be a new LTS release of Java every two years. This will make Java 21 the next LTS release in September 2023.
Based on these definitions, the release graph of Java versions since Java 9 looks like this:
Since all work is done in the OpenJDK, the release date of individual Java distributions may differ slightly. As soon as the release is approved in OpenJDK, work begins on creating distributions such as Eclipse Temurin, Oracle JDK or Azul Zulu. Each manufacturer is free to expand the sources of the OpenJDK with additional functions in order to stand out with a unique selling point. For example, some like Azul or Bellsoft bundle JavaFX in their builds.
In earlier versions, Oracle in particular tried to stand out from other OpenJDK builds with tools such as WebStart or Mission Control. However, this has led to compatibility problems in the community and is fortunately no longer practiced today.
(rme)