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.
more of the specifics about Azul’s support plans…
