Which Java Version Should You Use?

In the first of this two-part blog post, we looked at OpenJDK release cadences, upgrading Java versions, and updating OpenJDK features. In the second part, we explore how to decide which Java version to use when you have a choice.

Each new version of the OpenJDK brings new and experimental features, including speed and memory improvements. So it would make sense to upgrade all your runtime environments each time a new version becomes available. But that would involve testing and upgrading all your servers and/or applications every six months. In small setups with only a few instances, this is a small job. But as Java is used in many business environments with tens, hundreds, or thousands of services, such an upgrade requires a lot of planning and effort. For these use cases, you might stick to a version for a longer time. There are several criteria for choosing which version:

• LTS: the lifetime of this version is known upfront and is guaranteed to get updates for a longer time. The upgrade to the next LTS version can be scheduled well in advance, as the date is already known.
• Features: if the development team requires a specific feature only available from a particular version.
• Experimental: many developers use the latest version on their work PC. This allows experimenting with new features while being able to build and compile applications with backward compatibility with the runtime used in the production environment.

A real-life example of the impact of upgrading or updating

Upgrading to a newer release (for instance, from one LTS version to another, like 11 to 17) requires a lot of testing to ensure your production environment keeps running as intended. You can expect performance improvements with each new release; but as the code and runtime keep evolving, you can expect bugs to pop up too. These upgrade paths and tests need to be entirely handled by your team.

But once you have deployed a particular release, updating to newer versions becomes much more manageable when you follow the CPU/PSU cycle discussed in my last blog post. Let’s take an example based on the October 2022 Release Notes of Azul Zulu Builds of OpenJDK.

A complete overview of the support duration of the different versions, also comparing the commercial support offered by Oracle, Eclipse Temurin, and Azul is available in our support roadmap.

New versions of OpenJDK are released and maintained by Oracle in the first half year. For example, OpenJDK 19 will have its final Oracle-managed release, 19.0.2, in January, after which it can become a community project if a member of the OpenJDK community steps up to become the maintainer for the remaining part of the lifetime. If there are multiple candidates, the community decides who will become the maintainer. I have maintained version OpenJDK 6 for 4 years until 2020, and OpenJDK 7 until 2022. Those were pretty stable versions and only needed some security fixes to be ported in a conservative matter. My colleague Yuri Nesterenko is still the maintainer for OpenJDK 13 and 15 until March 2023.

Andrew Brygin, Staff Software Engineer, Azul

The shortest path to deploying CVE fixes in your environment

• Your production system should already be running on the Zulu PSU release of July 2022, Zulu PSU 17.36, to include all preceding fixes and updates.
• The release of October contains both a CPU and PSU package:
  • Zulu CPU 17.37, based on OpenJDK 17.0.4.1.101
    • Minimal changes to make the runtime safer.
      • For example, for the October 2022 OpenJDK 11.0.16.1.101 update: 14 fixes.
    • Easier to put it into production as a limited test is needed.
    • It needs to be deployed to your production environment as soon as possible.
  • Zulu PSU 17.38, based on OpenJDK 17.0.5
    • Contains the same critical changes and other improvements.
      • For example, for the October 2022 OpenJDK 11.0.17 update: 220 fixes.
    • First needs to be tested more in-depth as this contains more changes.
    • It needs to be deployed in between the quarterly release schedule.
• Your system is now running on Zulu PSU 17.38 (OpenJDK 17.0.5) and is ready to handle the same flow with the next quarterly update in January 2023 to move to the next CPU as soon as it becomes available.

Following this approach, you will have the CVE fixes deployed in your environment within the shortest term possible to ensure its security.

As the name says, a CRITICAL Patch Update needs to be deployed as fast as possible as it adds security fixes. This is established by providing an easy-to-upgrade version with the minimal required set of changes, limited to several files. Although the small number of changes, creating a new CPU release takes several weeks within Azul! New versions are tested on all supported platforms, meaning up to 100 million test executions are performed on all those platforms combined. The results are handled by a team of more than ten quality engineers. As a result, our customers only need a limited test to put such a CPU update in production, as Azul has done thorough testing.

On the other hand, PSU updates can contain hundreds of changes in many files, as these also include both security updates and other improvements. Testing of PSU updates takes two months by the Azul quality team as again, we want to minimize the impact and the number of tests needed on the client side. CPU and PSU have been verified to behave appropriately in most real-life use cases and are TCK certified where applicable.

To give you an idea of the number of versions being tested and distributed: with each new version, we create +500 CPU and +1000 PSU packages which are all included in our quality process!

Sergey Grinev, QA Manager, Azul

Conclusion

To stay on top of the latest Java improvements and security fixes, it is vital to keep your OpenJDK up-to-date! Luckily Azul provides new versions of many different versions within hours after new CVEs have been reported each quarter. Check the download page for all the available versions for all platforms.