After you’ve identified your goals, the methodology we suggest for migrating from the Oracle Java Development Kit (JDK) can be broken down into three stages:

1. Discovery. Identify which versions of Java are being used by which applications and on which machines within your organization, including cloud instances. You’ll use this inventory to create a migration plan.
2. Execution. For each machine that requires a Java runtime, install the same version (or versions) of the OpenJDK distribution you choose.
3. Validation. Test your applications to verify that everything works as expected.

The rest of this chapter covers the discovery stage, where a little bit of additional attention can have the biggest impact on shortening your migration time frame and eliminating issues. Chapter 3 walks you through the execution and validation stages.

The first stage is often the most time-consuming in a JDK migration because of the variety of JDK versions in use. Typically, when a new application is deployed, it uses the latest version of the JDK
at that time and continues to use it even as newer versions of Java are released. This is quite logical, because it has been tested with the deployed version. Assuming the application works without issue, there is no requirement to update its JDK version. An update is required only when security patches and bug fixes are no longer available for the version in use.

To create a complete JDK usage inventory, you must examine each machine in your estate that runs any Java Virtual Machine (JVM)–based applications. This can be straightforward if you use IT asset management (ITAM) tools to monitor software usage. Many enterprises deploy these tools to ensure that they’re complying with licensing terms and conditions. These tools can quickly produce a report showing which machines have which versions of Java installed.

Even with a report like this, however, producing a definitive inventory of JDKs in use may not be straightforward. For example, many enterprises use standard builds for server and desktop deployments. These may include a Java runtime even where no Java applications will be used.

Many users won’t be using ITAM software, so they’ll need to perform a manual inventory of machines. Tools are available to assist with this. These tools can scan the filesystem of a machine, looking for a Java executable and recording the version string when it’s run. They can also scan the process table to determine whether Java applications are running and which JDK they use. Take care in analyzing these results — applications may be used only when required. If an application isn’t running at the time the process table is being scanned, it won’t be included.

The process of choosing which JDKs to include is similar to one you might follow when dealing with a collection of cords and power adapters for mobile devices. Over time, you build up a collection of different adapters, each applicable to one or more devices. When clearing out your collection, you must determine if each is still required. The same goes for JDKs; you must figure out which ones still have a purpose and which ones don’t match up with anything you still run.

Typically, when a JDK is installed using an automated installer like a Microsoft Software Installer (MSI) file on Windows or a Red Hat Package Manager (RPM) file on Linux, it becomes the default Java runtime. However, some applications may be installed using a bundled JDK that is used only for that application. In such situations, the JDK may be included in the application’s support contract. In many (perhaps most) cases, maintaining that support is desirable and you won’t want to migrate that application. When compiling the inventory, you’ll want to be aware of such applications and, when in doubt, confirm the terms of ongoing JDK support with the application provider.

With the continued trend of moving server applications to the cloud, it’s also necessary to include JDKs used in these environments. Most cloud providers supply and support Java runtimes as part of their platform as a service (PaaS) offering. However, there may be situations where a different JDK is used (for example, to deliver better performance).

It’s becoming increasingly common to use microservice architectures to deploy applications into the cloud. Doing so separates monolithic applications into multiple, loosely coupled services packaged in containers. A container is a fully functional, portable, virtualized computing environment surrounding a service and isolating it from other services. This is a very flexible deployment method, because it eliminates the need to ensure that the correct versions of libraries, frameworks, and runtimes are available where the service is deployed. All dependencies, including the JDK, are bundled into the container. Once again, when creating a JDK inventory, all containers that include a Java runtime should
be added.

For each entry in the inventory, there should be the following fields at a minimum.

» Type: A physical desktop, physical server, cloud instance, and/or container.
» Access details: The credentials needed to access a physical machine or cloud instance via a network connection with sufficient privileges to permit the JDK’s installation. For containers, these details will relate to how the container image is generated. This will probably be via continuous integration/continuous delivery (CI/CD) tooling and should include information enabling you to configure a different JDK for inclusion in the image.
» Operating system (OS): Which OS is in use, plus additional details about it, such as the edition, version, build number, and whether it’s 32 bit or 64 bit. The OS will typically be Windows, macOS, or Linux. For Linux, you should also note the distribution (distro) because it may make a difference in the installation format.
» Automated or manual install: Whether the installation will take place using an installer. If the JDK doesn’t use an installer, this field should also note the location in which the JDK should be manually unpacked.
» JDK version: This field should also include the installed update level, such as JDK 8u202.

At the end of this process, you should have a complete list of all places where the Oracle JDK is located.

For classification purposes, you may want additional fields. Visit www.openjdk-migration.com/inventory-worksheet for a complete worksheet.

If you have a large Java deployment, you’ll be looking for additional resources to assist with the inventory. You can find sample worksheets and a survey to use with application owners at www.openjdk-migration.com/application-owner-survey.

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.

Java started life in the mid-’90s and has continued to be developed ever since. Its popularity took off quickly, resulting in people using early versions of the platform to deploy enterprise-wide and mission-critical applications. Most JVM-based applications are replaced or upgraded to a newer version of Java before support for the JDK version expires. However, some applications continue to use very old versions of the Java platform, and that can be a problem.

Through Azul’s Platform Core support, you can continue to receive all scheduled and out-of-bounds updates to JDK 6 and 7, even though Oracle and other distributions have discontinued support.(OpenJDK started with Java SE 7, but a project for Java SE 6 was subsequently created. You can read more about the early days of Java and OpenJDK in Appendix A.)

Versions of Java prior to JDK 6 were never released as open source, so there is no way to provide distributions with backported security patches or bug fixes. The last public update to JDK 5 was in
November 2009 (which was when Sun Microsystems was still developing Java).

Because of Java’s excellent backward compatibility, it’s quite probable that something that runs on JDK 5 (or even earlier versions) will run without issue on JDK 6. However, if you’re still running applications from JDK 1.0 or 1.1, these may not work on JDK 6.

Prior to JDK 11, the Oracle (and Sun Microsystems) JDK included features that were not included in the core OpenJDK project. The following sections cover these features.

This section lists the furthest corners of edge cases for OpenJDK migration and offers some possible solutions.

It’s very common for users to buy applications instead of developing them. This can be very cost effective to not have to develop and maintain bespoke software in-house.

Many such applications that use Java will specify a required version of the JDK and even possibly a minimum version update level. (This is no different from the way other applications specify a minimum version of Windows or Linux.)

The user must source the JDK and make it available to the application. Application providers often state in their documentation that they’ll support the application only if you’re using the correct
JDK. This is sensible for the application developer, because it can help eliminate issues caused by using out-of-date or inappropriate Java runtimes. Because the Oracle JDK has been so ubiquitous in the past, many application providers have stated that only the Oracle JDK will qualify for support. With the recent changes to the Oracle JDK licensing and pricing, however, users are increasingly demanding that they provide support when running on alternative JDKs.

Many application vendors will now provide support so long as the app is running on a Technology Compatibility Kit (TCK)–certified build of OpenJDK. Because they can trust such distributions to be functionally identical to the Oracle JDK, they don’t need to be worried about testing multiple distributions with their applications.

Sometimes an application will state that certain OpenJDK distributions are valid for support but not the one you want to use. In this case, you should contact the application vendor to have them add the distribution you want to use to their list. As long as it’s TCK tested, the vender should have no objection.

In any large organization, where multiple Java applications are in use, applications will have different owners. When planning a successful migration, it’s essential to include all concerned parties — that is, all owners of the applications that must use the new Java runtime.