In this chapter, you see how providers like Azul enable you to scale your Java team by assuring the stability and security of your Java Development Kit (JDK), maintaining bundled technologies, protecting your intellectual property (IP), assisting with migration planning, and delivering innovation directly to your doorstep.

The OpenJDK project releases updates four times a year, on the third Tuesday of January, April, July, and October. Changes are applied directly to the current version of Java at that time as well as to the most current Long-Term Support (LTS) version. This means that anyone can download the OpenJDK source code and build their own updated JDK, and it will always be current with security patches, bug fixes, and enhancements.

The problem is that building your own JDK isn’t feasible for most organizations. It’s a little like assembling a working car from parts, assuming all the parts are digital but require the same level of know-how about mechanical engineering, electrical engineering, physics, materials science, safety regulations, and testing. For a good portion of the 2010s, organizations that ran Java apps relied on Oracle for their JDKs — unless they needed a very highperforming JDK, in which case they turned to a provider like Azul.

This started to change with the release of OpenJDK 9 in September 2017, when Oracle introduced the concept of a long-term release on a fixed schedule.

Until OpenJDK 9, the gap between Java releases varied. JDK 6 shipped in 2006, followed by JDK 7 in 2011 and JDK 8 in 2014.

Feature releases would receive two updates before the next feature release. Oracle LTS releases would receive updates for five years with an additional three years of passive support (no scheduled updates). The feature releases were targeted at developers so they can leverage new features in production as soon as possible. The LTS releases were for enterprises that preferred stability so that they could run multiple large applications on a single shared Java release.

The new release cadence and the new distinction between feature releases and LTS releases paved the way for Oracle to announce a paid support offering in the form of an Oracle Java SE subscription the following year.

Several license and pricing changes later, Oracle settled into the cadence of free updates noted earlier. The current version of Java (the feature release) and the long-term release were updated on a quarterly basis. Organizations who were using older versions of Java could pay Oracle for support, but many also began turning to alternative providers who supported more versions on more platforms and who moved more quickly to new architectures, such as Apple silicon ARM-based Macs and Amazon Web Services (AWS) Graviton2 and Graviton3.

Getting the support you need to remain on older or less common versions of Java, or on the newest processor architectures, is one reason enterprises turn to commercial support.

Following the introduction of LTS releases and the Java SE subscription, organizations quickly learned that getting the highest levels of reliability from their Java runtimes required more than free updates. They needed timely access to updates on a continuous basis — and they needed those updates backported to older versions. This was important because a newly discovered vulnerability that got fixed in a current feature release probably also existed in many older Java versions, too.

Vulnerabilities affecting older Java releases continue to be reported. In 2022, vulnerabilities were reported as far back as Java 6, as well as in Java 7 and 8. However, Oracle stopped premier support for Java 7 in July 2019 and ended extended support in July 2022. In March 2022, Oracle ended premier support for Java 8, once the most popular release, and still in use in 33 percent of applications in production (according to New Relic’s 2023 State of the Java Ecosystem, published in April 2023).

Java’s built-in security measures like strong data typing make it naturally more robust than some other languages, so it can be tempting to take the security of your JDK for granted. But you’d be running an unnecessary risk to do so. Since Oracle stopped providing free updates in 2019, there have been 139 security vulnerabilities fixed in OpenJDK 8, including 21 classified as critical or high severity by the Common Vulnerability Scoring System (CVSS), published in the National Vulnerability Database
(https://nvd.nist.gov). Figures 5-1 through 5-3 show the frequency of new common vulnerabilities and exposures (CVEs) in JDK 6, 7, and 8 by severity score and update. The size of the circles corresponds to the number of vulnerabilities with that severity score in that release.

Receiving backported security fixes is another reason enterprises turn to commercial support.

Receiving backported security fixes from a commercial provider is important, and how those fixes are delivered is equally important.

Quarterly updates typically contain several hundred changes. The majority are bug fixes and minor enhancements, with security patches typically numbering less than 20 per release. In the last ten years, the largest number of security patches in an update was 37. This means that the risk of a security patch impacting the stability of an application is much lower than the risk from a nonsecurity-related change.

For this reason, Oracle and Azul offer two versions of each update:

» Critical Patch Update (CPU): This update contains only the changes related to security patches.
» Patch Set Update (PSU): This update includes all the changes, security, bug fixes, performance enhancements, and everything else.

Since the end of free updates to Oracle JDK 8, there has been at least a 25 percent chance that a PSU would experience a regression. Not only can regressions affect application uptime, but rolling back an update can expose an organization to known vulnerabilities and create compliance risk.

Securing your JDK without impacting application stability can be an important benefit of commercial support.

Just before the annual JavaOne conference in 2007, the management at Sun Microsystems was looking around for something to include as a keynote-worthy announcement. On very short notice, the decision was made to announce a new graphical application development platform that used the Java runtime. This project, dubbed F3 (for “Form follows function”) was created primarily by a single employee, Chris Oliver, and quickly rebranded as JavaFX.

Although JavaFX ran on the Java Virtual Machine (JVM), it was developed using a non-Java language that looked a lot like JavaScript (but was subtly different). This proved too hard to sell to Java developers, so two years later (again at JavaOne), JavaFX 2 was announced. This was a complete rewrite of the platform as a set of Java class libraries. Over time, Oracle added more functionality to JavaFX, including features like 3D rendering.

Although JavaFX was not included in the OpenJDK main project, Oracle bundled it with the Oracle JDK for Java 8, 9, and 10. Companies that built applications on these distributions need more than commercial support for older Java — they need formal support for JavaFX.

If a bug affects an application that relies on JavaFX, this can be reported and fixed in the same way as the JDK. (See Chapter 2 for a more detailed explanation about migration concerns for JavaFX.)

Extending the life of bundled technologies is another reason to choose commercial support.

Next, you should start thinking about the potential problems that may crop up based on what you found when making your inventory. This section describes some potential issues that you may encounter when migrating applications from the Oracle JDK to OpenJDK distributions. Altogether there are about a dozen possible edge cases to be aware of. It’s unlikely any of these will affect your applications. Almost all relate only to desktop applications that use specific deployment technologies. If your organization is among those still using desktop apps, you’ll want to be aware of these.

Many millions of Java users work with hundreds of thousands of applications, including some of the most demanding on the internet (such as credit card fraud detection for Mastercard and movie streaming on Netflix). Over nearly three decades of use, thousands of bugs have been reported and fixed in Java. This process continues as Java continues to evolve.

Although the JDK is updated regularly, there may still be situations where an application encounters a bug in it that has not been reported or fixed. What a user can do at this point will depend on which distribution they’re using.

Free distributions do not offer any formal support channel. In this case, your options are limited to reporting the problem details through the Oracle Java Bug Database. And even after submitting a bug, there is no guarantee it will be resolved in the next update (or ever).

For commercially supported distributions of OpenJDK, a formal support channel will be available to receive reports of issues 24/7/365 via a web form or email. (Some support organizations may also include phone access.) Each case will be assigned an identifier, often referred to as a support ticket. Many support contracts will include an SLA specifying how quickly the support team will respond to a ticket. This may be as little as an hour, so customers will know that for mission-critical applications, problems will get attention as quickly as possible.

The best support teams will provide deep root cause analysis. They’ll go beyond the immediate symptoms of a problem and investigate the underlying causes of problems or issues. This approach can save time and resources by eliminating the need for multiple fixes. When the solution to the problem is upstreamed to the reference implementation, everyone who uses that version of Java benefits.

Of course, the customers of the support team that developed the fix won’t have to wait until the fix is included in an OpenJDK update. They can receive the fix directly from their support provider. Likewise, the customer can expect to receive major out-ofcycle bug fixes when they’re critically necessary.

Getting expert help on a firm SLA, out-of-cycle bug fixes, and more is a common reason to get commercial support.

Open source has become a fundamental part of how the software development community operates. Freely reusing source code from other developers, rather than having to continually reinvent the wheel and write code that has been written many times before, has had a profound impact on software reliability and developer productivity.

When using open-source software, it’s essential to understand the terms of the original author’s license. However, doing so can become more complex and more fraught with potential problems the more aggregation of code that occurs.

The primary license used for OpenJDK distributions or runtimes is the GNU Public License version 2 with Classpath Exception (GPLv2+CPE). However, some of the code contributed to the project uses other licenses, such as Apache and Berkeley Software Distribution (BSD). For example, parts of the Extensible Markup Language (XML) processing libraries use the Apache license.

Not all open-source licenses are the same; some are more permissive than others. GPLv2 imposes quite strict requirements on how code can be reused. The most significant of these requirements is the copyleft nature of the license. Copyleft grants the right to freely distribute and modify the source code but mandates that the rights granted by the GPL must be preserved in any derivative works using the code. This is often referred to as a viral license, because it forces anyone using code licensed under the GPL to license their code in the same way.

If OpenJDK distributions used only the GPLv2, it would force developers to make their code available when they don’t necessarily want to.

Consider the following scenario: Let’s say you decide to ship your application bundled with an OpenJDK runtime. Doing this removes ambiguity and can increase reliability by making your code easier to test. You know precisely which runtime will be used and can test against that. However, by bundling your application with OpenJDK runtimes, you’ve created a derivative work, and the GPL now applies to your application. Anyone can now request a copy of the source code your team spent so much time and effort
developing! OpenJDK would lose its appeal to many users if this were the case.

To remedy this situation, the OpenJDK license includes the Classpath Exception (CPE). Any application code on either the class path or module path is not affected by the copyleft nature of the GPLv2.

Some people who look at this assume that all GPLv2 licensed code in OpenJDK includes the CPE, but this is not the case. For example, if you search the HotSpot (JVM) source code directory of more than 3,000 files, only 5 include the CPE. Conversely, looking at the java.base library source, just over 50 of the 3,000-plus files don’t have the CPE. This is because the CPE is only required when application code touches the JDK code directly.

For commercial OpenJDK distributions, it’s essential that all files that need the CPE have the CPE. If even one file that requires the CPE doesn’t contain it, and your application or one of your included libraries happens to make use of an application programming interface (API) in that file, the licensing implication
for your applications can be as bad as having no CPE at all for the whole JDK.

Some commercial distributions of OpenJDK perform careful scanning of the source code used to build them (both static and dynamically created) and will guarantee no exposure to the copyleft nature of the GPLv2. As a commercial feature, distributions may go even further and provide indemnification against
claims through GPL contamination.

Building on open source without the risk of copyleft contamination of your code is a valuable benefit of commercial support.

You may be surprised that in a book about migrating to OpenJDK, migration assistance shows up toward the end of a list of the benefits of commercial support for OpenJDK. For most providers, a migration support ticket is no different from any other support ticket. It will be handled according to the support tier you signed up for.

At Azul, we’ve found that what’s most helpful to our customers is assistance in planning their migration. Migrating itself is usually straightforward, but a good plan is still essential, particularly for companies that have been using Java applications for years on the desktop and on servers and, as a result, run on a variety of JDK versions.

The Azul Migration Workshop helps customers capture the scope of their migration, as well as the resources they need and the resources they have available. This enables them to build a realistic timeline and ensures they don’t miss any of the critical steps we’ve discussed here, such as taking a thorough inventory of their JDKs using IT asset management (ITAM) tools in combination with an application owner questionnaire. The workshop is customized so that each customer ends up with a comprehensive migration plan that is ready to execute. (Learn more at www.openjdk-migration.com/azul-migration-workshop.)

Assistance with migration planning is another example of the value added by some commercial support providers.

You could argue that assuring your JDK is patched against known vulnerabilities is the first job of an OpenJDK support provider, followed closely by offering stabilized builds to lower the risk of regression. But providers differ in how they deliver against these goals. In addition, some providers offer additional benefits — such as support for bundled technologies, SLA-driven responses to bug reports, and IP indemnification. But what can really set a provider of OpenJDK apart is its role in driving Java innovation and providing its customers with previews of new technologies that can offer a competitive advantage.

Major enhancements to OpenJDK around security and start-up/ warm-up time can have a long incubation time as community projects before they’re included in a feature release or an LTS release. One example of this is the OpenJDK project Coordinated Restore at Checkpoint (CRaC).

The CRaC Project defines public Java APIs that allow for the coordination of resources during checkpoint and restore operations. With CRaC, you can set a checkpoint at any point where an application can be safely paused. You can then use this checkpoint to reduce start-up and warm-up times by orders of magnitude. After about three years of community incubation, the first and only commercially supported CRaC-configured build was released by Azul in the form of a Java 17 Linux/x64 update (JDK version
17.0.7+7). As part of that update, developers using this build can deploy applications using CRaC into production with confidence that updates will be provided by Azul.

Deploying new technologies to production with full commercial support is an important advantage of working with a commercial support provider.