This chapter’s examples use Azul Zulu Builds of OpenJDK (also referred to as the Zulu JDK) as the new JDK. You can use any JDK distribution you prefer, but other distributions may differ in some ways, such as installation formats or supported platforms. (Chapter 4 explains how to select the right distribution for your organization.)

You can download Azul Zulu Builds of OpenJDK in all the formats available for the Oracle JDK. The following sections review the formats available and provide a few key facts about each one.

Windows JDKs typically come in two installation formats:

» For a manual install, archive files are available in ZIP format. Copy the file to the appropriate location and extract the file.
» Microsoft Software Installer (MSI) files are available for automated installation, including updating registry entries and environment variables. You can copy MSI files to individual machines, or you can install remotely using msiexec and psexec.

Linux JDKs are available in six installation formats:

» Archive files are available either in ZIP or compressed TAR files. As with Windows, you can copy these to the appropriate location and extract the file.
» Debian Format Package (DEB) files are available for automated installation using the dpkg command on Debianbased distributions.
» Red Hat Package Manager (RPM) files can be used for automated installation using the rpm command.
» Two Azul package repositories are available for Linux: one for use with apt (for Debian-based distributions) and one for use with yum (for Red Hat–based distributions). You can find instructions for configuring and using these on the Azul website.

macOS JDKs can be installed using three formats.

» Archive files are available either as ZIP or compressed TAR files. As with Windows and Linux, copy these to the appropriate location and uncompress them.
» Apple Disk Image (DMG) files can be used for automated installation, either graphically or via hdiutil attach from the command line

Multiple image files are available from Docker Hub to install a JDK.

Zulu Docker files are available from Docker Hub for Alpine, CentOS, Debian, and Ubuntu Linux distributions. You can use these files as the base for building containerized applications and services.

OpenJDK distributions do not support patch-in-place for updates; applying an update to the JDK requires installing a whole new JDK. This means the migration installation process can be treated exactly like deploying a new update, except that it installs the Zulu JDK update instead of the Oracle JDK update. Figure 3-1 provides an example of the process.

Unless there is a specific bug causing application stability issues, users won’t see any pressing need to move to a new version of Java, even if they are using quite an old version. However, from an administrative standpoint, it’s always a good idea to install the latest update when migrating to a new OpenJDK distribution, to maintain the highest level of security for your applications.

In the vast majority of cases, the update process is straightforward, and you don’t encounter any issues. However, sometimes an update includes changes that can change an application’s
behavior.

Let’s look at a particular example using the very commonly used Apache Tomcat servlet engine. Suppose we have Tomcat 8 running on Oracle JDK 8u202. This is not the most recent release of Tomcat, but it works perfectly for our application, so it hasn’t been upgraded. We have a servlet running that takes data from the client, makes a query in a MySQL database, and returns a result.

For our migration, we install Zulu 8 update 372 and restart the server. However, when we try to use the application, we get an error message telling us there was a communication link failure. This has nothing to do with switching from Oracle to Zulu. Instead, it results from a change made in JDK 8 update 291 from October 2021. In this update, the default settings for Transport Layer Security (TLS) were changed to disable TLSv1.0 and TLSv1.1 by default. Therefore, to get the application working as before, we must modify the jre/lib/security/java.security file and remove the TLS references from the jdk.tls.disabled Algorithms setting.

When something like that occurs, it’s important to verify that the problem is caused by using a different update of the JDK rather than a different distribution. Having a commercial support provider who can provide older updates can be extremely beneficial in this case. Simply install the same update level of JDK, and then retest the application. In our example case, the Azul support team would be able to provide details of the configuration changes required to resolve the issue.

After installing the new JDK, you’ll need to make any required changes to switch applications to use it. For example, it may be necessary to change the JAVA_HOME environment variable and the launchers used for individual applications, such as the Tomcat servlet engine. The safest option is to change this environment variable on all migrated machines.

After installation, you should test all applications that have been switched to the new JDK to ensure correct functionality. You probably won’t observe any different behavior unless changes have occurred between updates.

The testing process will vary greatly depending on each application. Internally developed applications may have extensive regression tests that can fully exercise all parts of the application to verify correct behavior. Third-party applications (either opensource or commercial) may have a set of standard tests that you can run. If not, an experienced user should run the application and try as many functional aspects as possible.

After all tests have passed to each user’s satisfaction, the migration is complete. You’ll now be in a strong position to maintain your Java estate to the highest levels of security and stability, often more so than before. In addition, you’ll have a clear picture of where the Java runtime is in use and more experience in upgrading machines to the latest Java update.