From JDK 11 onwards, Oracle JDK has used only the source code included in the relevant OpenJDK repository. Prior to that, Oracle also included several features that were not open source.

These features are almost all associated with desktop applications
and deployment technologies. The two most obvious are the Java plug-in (required to run applets in a browser) and Java Web Start. Chapter 2 provides some specifics on both of those.

The Oracle JDK features that don’t apply just to desktops include Mission Control and the Java Advanced Management Console. Oracle open-sourced Mission Control, a low-overhead, interactive monitoring and management tool for Java workloads, and you can obtain builds from Azul and other vendors. The Java Advanced Management Console, a sysadmin tool, is available only from Oracle.

If you’re using Oracle Java applications, you should check carefully to determine whether the JDK is included in the support contract. If it isn’t included, consider which distribution is the best choice in this situation

Provided the OpenJDK distribution you choose is built from OpenJDK source code and is TCK tested, there is essentially zero chance of a functional regression created by swapping one distribution for another. Applications will behave no differently when running on an Oracle JDK alternative.

Only in a very extreme case would you notice a performance regression where an application may be slower or faster than before. This would only be because a different compiler or compiler flag was used during the build process.

All distributions of OpenJDK provide extended maintenance for the LTS versions of Java in the form of updates. How long these updates will continue to be delivered depends on the distribution. If you’re using an older version of the Java JDK that is still being maintained, your application will continue to receive the maximum level of security and stability from its runtime. There is no need to update to the latest Java version.

For some users, the availability of newer features and potentially improved performance will be worth investing time and resources to migrate and test applications. It’s important to understand, though, that moving to the latest Java version isn’t essential.

From the very beginning, Java used the slogan “Write once, run anywhere.” The cornerstone of this claim was that all Java runtimes would provide identical functionality. The same bytecodes would execute in the same way regardless of the operating system and chip architecture.

This concept applies equally when moving to a different distribution of OpenJDK. As long as both the current and new distributions are of the same Java version and have passed all the TCK tests, you won’t need to recompile any application code.

Sometimes changes made in an OpenJDK update can impact application stability. In this case, it may be necessary to change configuration parameters, but it still won’t be necessary to recompile the application.

There is no need to recompile code when switching OpenJDK distributions. By extension, therefore, it isn’t necessary to modify or rewrite any application code as long as the Java version of both distributions is the same.

Even if the Java version is not the same, the code is still probably okay. The Java platform maintains excellent backward compatibility across versions. As a result, code written for one version of Java will almost always compile and run on a newer version.