Migrating to OpenJDK

In the beginning of 2019 Oracle stopped releasing free-of-charge updates to their JDK, except for personal use. At the same time Oracle started requiring a subscription for Oracle JDK use in production environments. In this blog post we will look into OpenJDK as an alternative to the Oracle provided JDK and how one would migrate to it.

The primary focus of this article revolves around Java 8 based JDKs - however much of it is also applicable to later Java versions including the Java 11 LTS release.

What is OpenJDK

OpenJDK is the upstream open source project of Java, originally open sourced by Sun Microsystems in 2006. Multiple JDKs are produced from that source base - among them commercial variants as the Oracle JDK and open source versions as the ones build by the linux distributors, such as Red Hat or Ubuntu.

Since the open source OpenJDK builds and the Oracle JDK builds share the same base, it is fair to assume that a migration should be unproblematic. And it fact it is, but there are certain proprietary additions to the Oracle JDK which are not available in the open source builds and therefore can cause problems when migrating. We’ll take a look at these differences in a minute.

OpenJDK based builds

There are a number of JDKs built from OpenJDK. The following is a subsection of the most popular options.

AdoptOpenJDK

AdoptOpenJDK is a community build for OpenJDK.

AdoptOpenJDK has a long list of sponsors among them a number of industry players, like Red Hat, Amazon and IBM. AdoptOpenJDK provides builds for all major platforms, including Linux, Windows and Mac OS X.

AdoptOpenJDK actually provides two different builds - one based on hotspot - the classic java virtual machine as also used by the Oracle JDK and OpenJ9, which is a JVM provided based on IBMs JDK. While the OpenJ9 build should have better performance for certain workloads, choose the hotspot based JDK unless you have a good reason to prefer OpenJ9.

AdoptOpenJDK has recently joined the Eclipse foundation and will change name to Eclipse Adoptium.

If you do not require support, this is the version I would recommend - but only if you are not on Linux.

Amazon Corretto

Amazon Corretto is another build based off of OpenJDK and is supported by Amazon on a best effort basis. They have publicly announced to support Amazon Corretto 8 until 2026.

However, note that Amazon also is a sponsor of the AdoptOpenJDK effort.

Oracle OpenJDK

Oracle also produces open source builds for OpenJDK, but these are mainly intended for development purposes and also do not cover Java 8. These are published at http://jdk.java.net/.

Linux distributions

All Linux distributions have been building on OpenJDK for Java support for a long time. This gives easy package installation and upgrades using the systems package manager. Generally these builds only work on their respective systems. Although Red Hat does provide OpenJDK builds for Windows also, that correspond to their Linux builds.

If you are running on a Linux distribution, I would recommend you use the provided OpenJDK builds. Your distributor will provide you with the best system integration and with timely updates - as they do with most if not all of the other software you use.

Others

There are more builds of OpenJDK, that may be applicable for more niche use cases, some of which we list here:

And there are even more. Wikipedia appears to have an exhaustive list.

Support for OpenJDK

Apart from Oracle providing support for their Oracle JDK, there are a number of support options available from the other commercial players.

Among them is Red Hat which supports its OpenJDK builds as part of a Red Hat Enterprise Linux (RHEL) or a Red Hat Middleware subscription. Apart from that Red Hat also provides subscriptions for OpenJDK for Workstations.

How to do the migration

In general, because they all are based on the same source, migrating to OpenJDK is simply done by uninstalling the current JDK and installing OpenJDK. In the migrations I have been part of, this has always been the only required action.

Nevertheless it may be a good idea to plan such a transition as there are certain differences to watch out for.

Differences between Oracle JDK and OpenJDK

The AdoptOpenJDK project has a nice document, which describes the major differences to look out for. Unfortunately this is a PDF document, but below is a screenshot of the most relevant section.

Differences between AdoptOpenJDK and Oracle JDK. © AdoptOpenJDK
Differences between AdoptOpenJDK and Oracle JDK. © AdoptOpenJDK

Please refer to the original document for the full context or any updates from AdoptOpenJDK.

So basically, if you depend on any of the proprietary components of the Oracle JDK you may experience problems when migrating to a open source JDK. In practice this is very rarely the case.

But how would one find out?

Migration toolkit for applications

The Windup project develops a tool helping migrations in a generic sense. It is a rule based tool which analyses source code for required changes, if one were to do a migration. Examples of migrations could be: from JBOSS EAP6 to JBOSS EAP7 or from Spring Boot to Quarkus. It also has support for testing a migration from oraclejdk to openjdk.

Windup is also packaged as Red Hat Migration Toolkit for Application (MTA) and can be downloaded here.

Lets quickly go through how to use this. I’ll show the CLI tool here, but there is also a webserver install that is more suited for big migration projects or multi user setups as well as Maven integration available, for use with your favourite CI/CD pipeline. Last but not least there are also integrations available for some of the most popular IDEs.

Unpack the mta_cli:

$ unzip migrationtoolkit-mta-cli-5.0.1-offline.zip

In this case we want to test the migration on wildfly-core:

$ git clone https://github.com/wildfly/wildfly-core

Create the migration report:

$ ./mta-cli-5.0.1.Final/bin/mta-cli --sourceMode --input wildfly-core --output ./wildfly-core-report-20201201 --source oraclejdk --target openjdk --packages org.jboss
Increasing the maximum of open files to 10000.
Using MTA at /home/bangert/demo/mta-cli-5.0.1.Final
Warning: JAVA_HOME environment variable is not set.
> Migration Toolkit for Applications by Red Hat (MTA) CLI, version 5.0.1.Final.
...
Report created: /home/bangert/demo/wildfly-core-report-t-source/index.html
              Access it at this URL: file:///home/bangert/demo/wildfly-core-report-t-source/index.html

Notice the usage of the --sourceMode parameter, which enables checking source code directly. The other option is to check .jar archives - so this also enables checking proprietary java applications where you do not have access to the original source code.

If you open the report with your favorite browser, you will see what the Migration Toolkit for Applications has found.

Frontpage of report
Frontpage of report

Browse through the report to find out details of what issues the Migration Toolkit for Applications has found.

Easy switching between JDKs

As there are so many different JDKs, you may find yourself needing to switch between JDKs often.

This is not only true wrt which OpenJDK build you are testing against, but also if you want to test against multiple versions of the Java language - say Java 8 and Java 11.

While many Linux systems come with built-in support for multiple JDKs (Ubuntu, RHEL), there are also tools like jenv and SDKMAN that may suit you better or if you are on MacOS or Windows.

Further reading

Thilo Bangert

Senior Systems Consultant at Redpill Linpro

Thilo is a systems engineer working with integration and helping customers apply DevOps methodologies. He is hailing from the Copenhagen office and can be contacted by mail using thilo at redpill-linpro dot com.

Moving forward with Cloudformation templates

Now we continue improving the VPC template from my previous blog entry “Starting with Cloudformation templates”

What we ended up with there was a VPC with one subnet connected to the Internet. Or what is know in AWS lingo as a “Public Subnet”.

The goal now is a VPC with presence in tree Availability Zones with a “Public Subnet” in each, and a “Private Subnet” in each as well.

Humble beginnings

Before we go all out on tree ... [continue reading]