If you have been a long-term Oracle customer, migration from Oracle Java to an open-source OpenJDK distribution (for some, as good as diving into the unknown) seems to be a tall order. However, the key is to break the task down into manageable steps.
BellSoft helped numerous enterprises migrate from Oracle JDK to OpenJDK, gaining extensive experience in the process. Our experience allowed us to develop a strategy for smooth and painless migration to OpenJDK.
Don’t worry; with BellSoft, migration from Oracle is not as painful as it may appear. Below is a surefire roadmap for efficient and comfortable migration.
Table of Contents
- Stage 1. Make an inventory of all enterprise Java runtimes
- Step 1. Create inventory of all Java runtimes in your fleet
- Step 2. Identify which JDKs you actually need
- Step 3. Determine Java versions you use now or plan to integrate later
- Step 4. Features from older Oracle Java versions
- Step 5. Specify the platforms and environments in use now or to be introduced later
- Stage 2. Change all Java runtimes to the chosen OpenJDK distribution
- Stage 3. Verify that everything works correctly
- Need help with the migration? BellSoft experts are ready to support you!
Stage 1. Make an inventory of all enterprise Java runtimes
Step 1. Create inventory of all Java runtimes in your fleet
The initial stage of the migration process involves creating an inventory of all Java runtimes installed in your corporate environment. To do this, you can use IT Asset Management (ITAM) tools, designed to gather information about IT assets (in our case, JDK) across the network.
For Windows-based systems, you can use Liberica Administration Center (LAC). It conducts a thorough scan of all machines, identifying:
- JDKs from different vendors installed on the standard path;
- JDKs tied to keys in Windows Registry;
- Running processes that use Java (e.g., idea.exe) along with the corresponding JDK installations.
LAC efficiently gathers crucial information about Java runtimes, including versions, end-of-life notices, vulnerabilities, and potential licensing risks. This information is then conveniently aggregated into a comprehensive report.
For other systems (or if you don’t use any ITAM solution), manual inventory becomes inevitable. It is crucial to leave no stone unturned, as any neglected JDK left hanging on your machine may pose potential licensing issues.
Step 2. Identify which JDKs you actually need
When you list all JDKs installed in your corporate fleet, you may notice that some runtimes are redundant because they are no longer used with corporate workloads. In such cases, you can safely delete them, reducing JDK licensing costs.
However, if your company relies on third-party Java applications that come with a runtime, it’s crucial to consider the support terms associated with this application because they may cover the JDK. In addition, the vendor may only provide support if you use the bundled JDK or the one from the vendor’s list.
Nevertheless, the vendor may agree to support the application even if you utilize another JDK, provided that it fully complies with the Java SE standards. To ensure compliance, specific tests are conducted, known as Technology Compatibility Kit or TCK. Only Java runtimes that successfully passed the TCK verification can guarantee seamless migration.
In any case, consulting the application vendor for detailed information is strongly recommended.
Step 3. Determine Java versions you use now or plan to integrate later
Corporate Java fleet is often diverse. Java’s excellent backward compatibility enables the developers to introduce new services and technologies running on newer Java versions without upgrading the existing stack. This means that some companies may have older services running on Java 6 & 7 (or even earlier versions), while recently added services utilize JDK 17 or JDK 21.
At the same time, you may soon want to take advantage of the latest and greatest JDK versions, each incorporating dozens of innovative features (such as virtual threads in JDK 21).
Either way, finding a vendor that supports a wide range of Java versions is crucial. Some OpenJDK vendors support only LTS versions, but only two, including BellSoft, offer extended support for Java 6 & 7 with regular security patches and updates.
Step 4. Features from older Oracle Java versions
Starting with Java 11, Oracle JDK and OpenJDK features are compatible. However, migrating from older Oracle Java versions requires special consideration as they contain technologies that weren’t released into open source:
- JavaFX: Developed as a separate OpenJDK project, OpenJFX, but it’s not included in the OpenJDK binaries by default. Certain OpenJDK vendors, such as BellSoft, offer JDK builds bundled with OpenJFX.
- Java Web Start: Deprecated in Oracle JDK 9 and removed from Oracle JDK 11. However, this technology remains closed-source. For those dependent on it, seek a vendor supporting the open-source reimplementation of Web Start like OpenWebStart.
- Applets: Still supported on Windows as part of Oracle Java 8 and earlier, but modern browsers don’t support the technology for security reasons. No OpenJDK vendor offers support for applets.
- Lucida fonts family: Used in Oracle JDK 8 and earlier. These fonts aren’t included in OpenJDK. Switch to other fonts supported by the JDK (use the GraphicsEnvironment class to find out which fonts are available) or acquire them separately or as part of other software products.
- Java Control Panel: Not part of the OpenJDK, but the keytool utility can be used instead.
- Windows Registry Keys: add registry keys for an application to locate a Java runtime. Some vendors may provide different functionality.
Regarding registry keys, Liberica JDK offers similar settings. For instance, let’s look at installing Liberica JDK 11 on Windows using a .msi file and how registry keys are added.
Subfeatures can be selectively chosen.
Set the JAVA_HOME accordingly and set the association with the Jar. After that, you can double-click any .jar file, and Liberica JDK will launch it.
The registry keys setup varies depending on 32- or 64-bit architecture, as well as Java version
Step 5. Specify the platforms and environments in use now or to be introduced later
In addition to determining the required Java versions, it’s crucial to identify the platforms your company currently uses or plans to integrate in the future. The understanding of your tech stack is vital for selecting a Java runtime compatible with the necessary architectures and operating systems.
The platform inventory should include the cloud environment if you run cloud-native applications or consider moving your server workloads to the cloud. While some cloud vendors provide a JDK distribution as part of their offering, it may not always meet your specific requirements for versions, features, performance (e.g., memory consumption), or SLA. Unifying the JDKs across development, CI (building and testing), and production environments is optimal. This approach reduces complexity, accelerates time-to-market by ensuring consistent application performance across all environments without the need for reconfiguration, and lowers the total cost of ownership (TCO).
Even with a unified Java runtime across the enterprise, don’t neglect the containers, a cornerstone of cloud deployments. A perfect container balances a small size with enterprise-grade security. To minimize a container size, developers may choose lightweight Alpine Linux, suitable for optimizing memory footprint but lacking security features for enterprise development.
A perfect solution is to select a vendor providing a Java runtime and optimized containers with updates and support for both Linux and Java. BellSoft offers containers tailor-made for Java development. They are based on Liberica JDK Lite, a Liberica JDK flavor with multiple backports from recent versions and better compression for a reduced container footprint, and Alpaquita Linux, inspired by Alpine but boasting
- additional security strengthening:
- kernel hardening,
- regular updates,
- LTS releases,
- enhanced flexibility:
- two libc implementations (optimized musl and glibc,
- four memory allocators.
Alpaquita Containers, based on Liberica JRE Lite and musl-based Alpaquita, take up tens of megabytes compared to many others that can be hundreds of megabytes. As a result, they enable significant cloud cost savings. In addition, regular updates for JDK and Linux keep these containers secure and performant.
Stage 2. Change all Java runtimes to the chosen OpenJDK distribution
Once you’ve gathered information about all corporate JDKs and decided which ones to migrate, the migration process can commence. Download the bundle from the selected vendor and replace Oracle JDK with the new distribution.
Note that if you’re using Liberica Administration Center for Windows-based systems, you can conveniently update all Java runtimes from a single window.
Otherwise, various installation paths are available, allowing you to choose the most convenient one. Below, we outline possible installation methods of Liberica JDK (note that other vendors may offer different installation formats).
Binaries on the website
Download binaries for Windows, macOS, and Linux in various formats: .msi, .dmg, .pkg, .zip, .tar.gz, .deb, .rpm, .apk
Pull Liberica JDK images from Docker Hub, GHCR, and MCR
REST Discovery API
Find and download the necessary Liberica JDK versions via REST API
Liberica JDK builds are available in SDKMAN, Brew, SCOOP, winget
Pull Liberica JDK from YUM, APT, Zypper, APK
Use buildpacks with Liberica JDK or Alpaquita Linux + Liberica JDK Lite to automate containerization
Ready Liberica JDK instances are available in AWS and Azure.
Once you’ve chosen the installation path, proceed to downloading and installing the necessary versions.
At this stage, upgrading the Java version (e.g., from JDK 8 to 11) is unnecessary. While it’s recommended to install the latest minor update for security considerations, you can opt out for a version equivalent to the one currently installed to avoid the risk of regressions. Updates within one version may differ significantly due to the introduced fixes and changes.
When performing the update, categorize your services into less and more critical ones. Less critical services can be updated in one go, whereas critical ones require additional attention in case something needs to be fixed.
After the update, change the JAVA_HOME environment variable and other relevant configurations to point to a new JDK.
Stage 3. Verify that everything works correctly
After migrating all your applications, run tests to ensure that they function without failures and regressions. If the selected JDK is TCK-verified and versions are compatible, you’re unlikely to encounter any issues. Note, however, that the older the Java version is, the more “surprises” it may reveal upon migration. In addition, if you’ve opted out for a newer version and run into errors, the cause probably lies in the changes introduced between versions.
Either way, if you subscribed to commercial support, your vendor will help you root cause and promptly resolve any issues that may arise.
Need help with the migration? BellSoft experts are ready to support you!
While the key steps of the migration plan are universal, every enterprise project is unique. BellSoft engineers are here to guide you through the entire process, ensuring a smooth and efficient migration. We’ll help address any potential issues at any stage. Contact our migration experts today and embark on a path to highly performant, secure, and cost-efficient Java development!