Azul Introduces Code Inventory The Solution That Identifies Unused and Dead Code for Removal in Production, Saving Developer Time and Money 
Support
Blog chevron_right Java

Tall, Grande or Venti Support For Your JDK

Tall Grande Vente Coffee Duke

It’s now been a little over two years since Oracle announced it was making some significant changes to the way the Java platform is developed, distributed and updated. This was just before the release of JDK 9 and the fact that the current release is JDK 13 shows how quickly Java is now changing.

The switch to a time-based rather than feature-based release cadence has had a big impact in many ways. One of these is that Oracle decided that offering extended support (in the form of updates) for all releases was quickly going to become impractical. To solve this issue, and to provide a slower deployment cadence for those who need it, nominated long-term support (LTS) releases were introduced.

One thing that’s important to clarify here is that LTS releases of Java are an Oracle-only concept. The OpenJDK project, where the source code for the reference implementation of the Java SE specification resides, does not recognise this idea. All JDK releases have their own separate project, and various people and organisations make contributions to these projects. In the case of Oracle, they have been very clear that their engineers will only contribute to the current feature release. The OpenJDK binaries, provided by Oracle and available from jdk.java.net under the GPLv2 with classpath exception license, are only updated for six months. The Oracle JDK, available from java.oracle.com under the Oracle Technology Network License Agreement, is the one that has LTS versions. It’s also the one that now requires a paid Java SE subscription if you want to use it in production.

Oracle’s LTS releases started with JDK 8. That was logical since it was the version being used by most people for production when Oracle made their announcements. Oracle also decided to classify JDK 11 as the next LTS release and that subsequent LTS releases would be every three years (or every sixth release, depending on how you want to look at it).

Existing providers of OpenJDK binaries, like Azul and Red Hat as well as newer ones have all decided to follow this strategy. This makes a lot of sense since it keeps things aligned. Users who don’t want to change JDK version every six months are going to be much happier if they have a clear choice between Zulu 11 say and Oracle JDK 11, knowing that they are both LTS releases.

It is up to each provider to decide how long they want to continue to provide builds of a given release and how much effort they want to put into keeping it updated. Since Oracle only contribute changes to the current OpenJDK feature release, keeping older versions updated requires work backporting those changes. In the case of Zulu Enterprise, Azul will provide scheduled updates for nine years after each LTS release. This is followed by a further two years of passive support (no scheduled updates but issues can still be reported, and fixes will be produced).

By default, this makes all non-LTS releases effectively short-term releases since they will only be updated for six months.

Or does it?

Just as each provider can choose how long they want to continue updating an LTS release, there is nothing to prevent a provider extending support through updates for other releases as well.

That’s precisely what we, at Azul, have decided to do with what we are calling our Medium-Term Support (MTS) releases.

Given the rapid rate of change of the JDK and the continued introduction of new features, it may be the case that a really useful feature is delivered between LTS releases. If you were keen to deploy that JDK into production, you would be faced with having to switch to each new JDK until the next LTS release in order to maintain the maximum level of security and stability.  This could be up to 30 months in the most extreme case. To make this simpler, Azul will nominate two releases between each LTS as MTS. We will provide updates to these releases in the same way as LTS ones. Since it may not be convenient to switch from an MTS JDK to the next LTS one as soon as it is released, we will provide updates for each MTS release until 18 months after the next LTS one. This gives plenty of time for a planned migration.

This sounds a bit complicated so I produced the diagram below to make things (hopefully) clearer.

MTS/LTS diagram

JDK 13 is our first MTS release, and the next will be JDK 15. One other thing to bear in mind is that each MTS release also includes the cumulative new features of releases since the last LTS. JDK 13, therefore, also has all the features of JDK 12.

To ensure users have the best possible choice of OpenJDK builds, Azul are also providing MTS updates for our free Zulu Community editions.

To use a certain well-known coffee chain’s cup sizes as an analogy, you now have three choices in terms of how long you can get updates to your JDK. Tall for feature releases, Grande for the new MTS from Azul and Venti for LTS. Which one is right for you?

You can find details of all Azul’s Zulu offerings, here.