Should You Update Java or Upgrade?

What’s the difference and what are the consequences of your decision?

The first of this two-part blog post examines OpenJDK release cadences, upgrading Java versions, and updating OpenJDK features. It’s critical to understand the parts of Java that enhance performance and the parts that keep your environment safe.

Since 2018, every six months we get an upgrade to a new OpenJDK version, including versions 18 and 19 in 2022. Next to these six-month releases, Azul provides four critical patch updates (CPU) and patch set updates (PSU) per year. So what’s the difference between a Java upgrade and an update?

Upgrades are new versions of OpenJDK

Updates are security fixes and improvements to existing Java versions

Upgrades are new versions of OpenJDK

Until OpenJDK 9 in 2017, Oracle didn’t have a schedule of new releases. It established a set of new features and released a new version whenever those features were finished. This approach led to versions with stable features but unpredictable release dates:

• Version 6 in 2006
• Version 7 in 2011
• Version 8 in 2014
• Version 9 in 2017

In 2018 Oracle introduced a new strategy with a fixed six-months release cycle:

• Twice a year, a new version is published, including all the finished and agreed fixes and improvements.
• Some unfinished new features can be included. They are called experimental or incubator features, and they require additional actions to be usable, so most users don’t even know they are available.

Java Updates are fixes and improvements in existing versions

The release of a new version of OpenJDK is not an endpoint. New updates are released regularly that contain security fixes and/or new features. In some cases, there are even backports of new features introduced in higher versions. For instance, TLS 1.3, which was released in 2020, was backported for Java 8, which was released in 2014.

Common Vulnerabilities and Exposures (CVEs)

One of the most critical goals of these updates is to keep the Java environment safe. CVEs (common vulnerabilities and exposures) refer to vulnerabilities that are publicly known and available in the CVE List. A group of Java distributors maintains this list and defines their impact, resulting in a Common Vulnerability Severity Score (CVSS). Based on this score, the urgency is defined to fix the vulnerability. Azul keeps a list of the CVEs and which Java update release contains a fix on our docs website.

CVEs affect Java applications in two ways:

1. CVEs in Java Runtime can be addressed by upgrading your instance of the Java Runtime, most often by a system or application administrator.
2. CVEs in third-party Java libraries can be addressed by upgrading the library within the application, most often by an application developer or DevOps.

Within the OpenJDK project, CVEs are handled in a continuous process, there are no specific CVE-fix releases. All the issues that are fixed in a build are included in a single message that is addressed to the jdk-update-dev mailing list to keep the community informed. The entire timeline of an OpenJDK version is available on wiki.openjdk.org. Here are a few links with examples of how the OpenJDK community is organized:

• All the mailing lists: https://mail.openjdk.org/mailman/listinfo 
• The timeline for OpenJDK 15: https://wiki.openjdk.org/display/JDKUpdates/JDK+15u
• Message about “OpenJDK 15.0.8 released”: https://mail.openjdk.org/pipermail/jdk-updates-dev/2022-July/016055.html

CPU and PSU releases

Azul uses an approach with Critical Patch Updates (CPU) and Patch Set Updates (PSU) to organize the release of new versions. Updates are released several times a year for all “active” (still maintained) OpenJDK versions. These updates don’t introduce significant new features; they keep the OpenJDK safe and in sync with newer versions by backporting some new features that are in high demand.

Critical Patch Update (CPU)

• Four releases per year in January, April, July, and October on the third Tuesday of the month.
• Contains fixes for security vulnerabilities and critical bugs, only impacting a minimal number of files.
• With only a limited number of changes, a more stable release is achieved with fewer risks of regressions.
• All users should upgrade their OpenJDK to the newest CPU as soon as possible to keep a safe environment.
• Azul Zulu CPU Builds of OpenJDK get an odd-numbered version (second digit), e.g., 17.37.

Patch Set Update (PSU)

• Contains security updates and critical bugs from a CPU, non-critical bug fixes, and new (backported) features.
• They are released at the same time as or shortly after the CPU.
• Be sure to use PSUs if you are impacted by a bug that was fixed or needs a new feature.
• PSUs should be used in your production system before the next CPU/PSU release, as fixes in a PSU will be present in the next CPU release.
• Azul Zulu PSU Builds of OpenJDK get an even-numbered version (second digit), e.g., 17.38.

Despite some skepticism in the Java community, new versions have been released on schedule since OpenJDK 10. In fact, the increased speed of new releases has led to more improvements, new features, and fast feedback on experimental additions.

Support Durations of OpenJDK

OpenJDK versions are usually called LTS (Long-Term Supported) or non-LTS. However, non-LTS versions can be separated into MTS (Mid-Term Supported) and STS (Short-Term Supported).

LTS Versus MTS Versus STS

OpenJDK versions only get updates for a predefined time:

• Long-Term Supported (LTS)
  • This is a version selected to be supported and updated for an average of eight years
  • Most companies stick to these LTS versions for their production deployments
  • After the release of version 17 in 2021, Oracle switched from a three-year LTS release cycle to a two-year cycle
  • LTS versions are: 8, 11, 17, and 21 (in September 2023)
  • LTS versions 6 and 7 are no longer available or supported, except for Azul customers with a specific support contract
• Mid-Term Supported (MTS)
  • Other lesser releases during the three-year gap between LTS versions were defined as MTS
  • These versions will be supported and updated for an average of three years
  • This term is now obsolete since a new LTS will be released every two years, so there is no added value anymore in supporting MTS versions
  • MTS versions are: 13 and 15
• Short-Term Supported (STS):
  • These are the releases between LTS and MTS and are mainly focused on delivering new and preview features for teams who need them or want to experiment with them
  • These versions will only be supported and updated for an average of six months by most distributors (but up to 1.5 years by Azul)
  • Versions: all others

NOTE: the support duration is not a “fixed value.” Each distributor can freely choose how long to support a version with critical updates and/or backports of new features. For instance, Oracle dropped support for Java 7 after more than 11 years, but you can still get commercial support from Azul for five more years till 2027.

Conclusion

Keeping your Java environment stable requires discerning which updates to install and then installing them appropriately. With multiple LTS versions available, and perhaps not the resources or the need to stay on the latest version, you need to make decisions about which version to be on for the greatest benefit of your organization.

If you update Java, you keep the same version but improve it with features and security measures. If you upgrade, you move to a new version of Java, which is more work. For more information on choosing your Java version, read part 2 next week.