Bruno Borges recently tweeted a question about long-term support (LTS) of OpenJDK, which shows that there is still some confusion over what this really means. In this blog post, I’ll explain how the different parts fit together.
To start with, we need to clarify what we mean by OpenJDK, which has become a somewhat overloaded term. OpenJDK is the open source project, hosted on what’s left of the java.net website. Quoting directly from the home page, it’s “The place to collaborate on an open-source implementation of the Java Platform, Standard Edition, and related projects”. Related projects include JavaFX (under the OpenJFX sub-project), as well as future features such as Valhalla, Panama and Loom.
It’s also important (apparently) to use OpenJDK as an adjective, not a noun.
OpenJDK is where the development of the Java Platform, Standard Edition happens, primarily with contributions from Oracle engineers but with many other organizations and individuals providing input. Java SE is specified through a number of Java Specification Requests (JSRs) produced by expert groups organized by the Java Community Process (JCP). OpenJDK is the reference implementation of the Java SE specification.
In 2007, Sun Microsystems announced they would release the Sun implementation of the JDK under an open-source license, which is how OpenJDK started. Initially, this was JDK 7, but a project was also created that provided the source code for JDK 6. Each subsequent release of the JDK has had its own project.
To use OpenJDK to run applications requires the source code to be built for a specific platform, which is how we get OpenJDK binary distributions. Because these are often referred to as OpenJDK, it leads to confusion about what applies to OpenJDK, the source code, and OpenJDK, the binary distribution.
Just before the release of JDK 9, Oracle made a number of announcements about how the development, distribution and updating of Java would work moving forward. Rather than the multi-year, feature-driven release cycle, there are now two releases of Java each year. The dates of these are fixed (March and September) and include only the features that are ready at that time.
This faster release cadence would rapidly make providing extended support impractical, so Oracle said they would designate specific releases of the Oracle JDK binary as having long-term support (LTS). JDK 8 was designated with LTS to get things started, with JDK 11 being the first LTS release under the new model. LTS releases would then occur every three years (so every sixth JDK release).
There is a separate OpenJDK project for each release. Mark Reinhold, who works for Oracle as the Chief OpenJDK Architect, leads each project when it is created. It is an important, yet subtle distinction that Mark is the Project Lead, not Oracle.
In the past, Oracle has provided updates to its JDK until some time after the next release. This has varied from just over a year to just under three years. During this time, Oracle has continued to contribute source code changes for the updates to the relevant OpenJDK project. When Oracle stopped providing public updates for a JDK, it also stopped contributing the source code changes to the OpenJDK project.
With the termination in source code updates from Oracle, Mark resigns as project lead and, under the rules, another contributing member of the OpenJDK can take over. For JDKs 6, 7, 8 and 11, Andrew Haley (who works for Red Hat) has assumed the lead role. Again, it is important to stress that this is not Red Hat taking leadership of the project, but Andrew. Subsequently, Andrew has resigned as project lead of OpenJDK 6 and Andrew Brygin (who works for Azul) has taken over.
With the new release cadence since JDK 9, Oracle engineers only contribute code to an OpenJDK project for six months. When a new version is released, they switch their work to the new version.
By default then, OpenJDK projects do not have a formal LTS strategy for any release. Subsequently, other members of the Java community have stepped up to ensure that users will still have access to extended support for specific versions of the JDK. For long-term support, the community has adopted the same approach as Oracle. Other JDK providers (Azul, AdoptOpenJDK, Red Hat, Amazon, etc.) are also treating JDK 8 and 11 as LTS releases (and will most likely do the same for JDK 17 when it is released).
How long long-term support is depends on the length of time members of the OpenJDK project are prepared to continue to backport updates from the current release and upstream those changes.
At Azul, we have published our support plans, which will provide updates for nine years for LTS releases, plus a further two years of passive support (bugs can be reported, and we will generate a fix with new binary if required). In addition, Azul has also decided to offer what we are calling medium-term support (MTS). Since there are three years between LTS releases, there may well be features that people would like to use in the five intermediate releases. To address this requirement, Azul will offer extended support of two of those releases. Between JDK 11 and JDK 17, these will be JDK 13 and 15. For both these releases, we will provide commercial support until 18-months after the release of JDK 17.
Other providers have their own plans for how long an LTS release will be supported for and could offer different options like Azul’s MTS.
As you can see, the OpenJDK itself does not have any formal concept of long-term support. What is essential is that Java users now have a more extensive choice of provider for their JDK and can be confident of maintaining extended access to bug fixes and security patches, either with or without commercial support.
