Many organisations poised to migrate from Oracle Java SE will wonder how long the process will take. There isn’t a one-size-fits-all answer to that question, though. The time needed for a migration depends on at least half a dozen variables that are specific to an organisation.
One of those variables is a firm’s migration goals – some goals take longer to achieve than others. For example, if the goal is to completely transition off Oracle Java as quickly as possible, the migration plan will differ to that of an organisation that is primarily seeking support for legacy applications running older versions of Java, such as Java 6 and 7, and would prefer a phased approach over a longer period.
Preparing to migrate from Oracle Java SE
The first stage of a migration is taking a Java inventory, which is often the most time-consuming part of a Java Development Kit (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 and there are concerns over the performance of the application or a known security vulnerability that needs to be addressed.
To create a complete JDK usage inventory, organisations must examine each machine in their estate that runs any Java virtual machine (JVM)-based applications. This can be straightforward if IT asset management (ITAM) tools are used to monitor software use. Many enterprises deploy these tools to ensure they’re complying with licensing terms and conditions. These tools can quickly produce a report showing which machines have which versions of Java installed. Scripts are also available from suppliers such as Azul to help inventory JVMs seamlessly.
Next, the organisation should start thinking about the potential problems that may crop up based on what was found during the inventory.
For instance, it’s very common for users to buy applications instead of developing them. Not having to develop and maintain bespoke software in-house can be very cost-effective. 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 used with the correct JDK. This is sensible for the application developer because it can help eliminate issues caused by the use of 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.
Recent changes to Oracle JDK licensing and pricing, however, mean users are increasingly demanding support when running on alternative JDKs. Many application suppliers will now provide support as 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 worry about testing multiple distributions with their applications.
Sometimes an application will state that certain OpenJDK distributions are valid for support, but not the one an organisation wants to use. In this case, users should contact the application supplier to have the required distribution added to their list. As long as it’s TCK tested, the supplier should have no objection.
In any large organisation 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 and/or are concerned with the health of their applications.
Migrating to OpenJDK
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.
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 applications.
In the vast majority of cases, the update process is straightforward and without issues. However, sometimes an update includes changes that can change an application’s behaviour.
A Tomcat example
Let’s look at an 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 that can provide older updates can be extremely beneficial in such cases. 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, we 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, we should test all applications that have been switched to the new JDK to ensure correct functionality. Users probably won’t observe any different behaviour unless changes have occurred between updates.
Testing to verify correct behaviour
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 behaviour.
Third-party applications (either open source or commercial) may have a set of standard tests that can be 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. The organisation will now be in a strong position to maintain its Java estate to the highest levels of security and stability, often more so than before. In addition, it will have a clear picture of where the Java runtime is in use and more experience in upgrading machines to the latest Java update.
This article is based on an excerpt from OpenJDK migration for dummies, Azul special edition, by Java champion Simon Ritter.