Changes in the Oracle JDK Installers (JDK 17, 11, and 8)

JDK 19 introduced several changes in the way JDK installers work.

These changes make it easier for system administrators to keep their Java runtimes current with the most recent updates, and have the Java programs that rely on those runtimes find the updated versions.

The changes are being back-ported from JDK 19 to JDK 17, 11, and 8, so they will soon apply to those versions as well.

Change in the Installation Directory

Before this change the JDK was installed in a directory that included the full version in its name. After installing a JDK update it was common to have to also update launch scripts and application settings to point to the new Java runtime location. In some cases updating the JAVA_HOME variable sufficed.

If you were using the JRE, the installer configured the system, so that by default you used the latest version.

However, JAVA_HOME or the JRE installer settings only worked if you had a single Java version to consider; These options don't work if some applications require Java 17 and others require Java 11.

After this change the installation directory shows only the feature version, not the complete version and remains the same for all future updates so you will no longer need to update the directory name to find the latest Java update for each version.

e.g.:

In Linux the change is more dramatic than in other operating systems, because we are aligning the Oracle JDK with common practices used by other programs and by other Java vendors.

JRE 8 will also have the installation directory name updated so, for example, 8u361 (before the change) will be installed on Windows under c:\Program Files\Java\jre1.8.0_361 whereas 8u371 (after the change) will use c:\Program Files\Java\jre1.8.

Java Alternatives Command Configuration in RPM Packages

Some Linux users take advantage of the alternatives command in Linux to easily configure which Java Runtime to use when calling Java commands, without fully specifying an installation location.

Oracle used a single command group java for all commands. To make it easier for users who interoperate between vendors we have adopted the common practice of splitting the commands into two alternatives groups java and javac.

The list of commands available under each group changes between JDK releases as new tools are introduced, and some tools are removed, Details are listed on the (draft) JEP JDK Packaging and Installation Guidelines.

Further changes for users of Oracle Linux relying on RPM repositories

JDK installers behave slightly differently on different operating systems as they try to match common practices from those Operating Systems, such as where to lay out programs, how to register them, how to let the operating system know if one of the installed programs should handle a particular file type when a user clicks on it (use java to run .jar files), etc. RPM installers for Oracle Linux have more functionality than installers on other platforms and therefore require larger changes.

Users who install the JDK using Oracle's Unbreakable Linux Network (ULN) and Oracle Cloud Infrastructure (OCI) mirrors for Oracle-provided Oracle Linux images will see further changes to align the Oracle JDK with other common Java Distributions as described on the (draft) JEP JDK Packaging and Installation Guidelines.

Split of JDK Installation Packages into two Options

Instead of offering a single package called jdk-<featureVersion>, we will offer two options: jdk-<featureVersion>-headless and jdk-<featureVersion>-headful; with the headful version requiring the headless version (If you install the headful version your system will also automatically install headless).

The headless versions are smaller and, as the name implies, do not contain many of the components used for headful applications; this is the installation option recommended for running most server and backend workloads.

The headful versions are equivalent to the jdk-<featureVersion> option from before the change; If you want to get the complete JDK use this option.

e.g. If you were using jdk-11 you can now choose between jdk-11-headful or, for a smaller package without the headful components, you can switch to jdk-11-headless

JDK 8 is Split into Headless and Headful, but JRE 8 Remains as a Single Option

For 8 we offer not just a JDK but also a JRE and, unlike later versions, JDK and JRE package names don't have a dash between jdk/jre and the version. The new names do include a dash and have a prefix of headless/headful (only headful is offered for the JRE) . We will offer jdk-1.8-headless and jdk-1.8-headful for the JDK; the JRE will be jre-1.8-headful.

e.g. if you were using jre1.8 you should now use jre-1.8-headful, if you were using jdk1.8 you should change to use either jdk-1.8-headful or jdk-1.8-headless

Downloadable RPMs

Although many RPM users rely on Oracle's RPM repositories, Oracle also offers RPMs for downloading on https://www.oracle.com/javadownload and (for customers) through https://support.oracle.com. These "Downloadable" RPMs are meant to be "generic", for use in any version of Linux that accepts RPM packages, as such they do not specify the required package dependencies directly (since that list is OS-version-specific). The RPM dependencies are listed in the documentation instead.

The downloadable RPMs have also been modified with the changes in the installation directory name and the alternative groups, but we have not split those into headless and headful. RPM packages downloaded directly from the site will retain the names jdk-11 (equivalent to jdk-11-headful) and jdk-17 (equivalent to jdk-17-headful). For JDK 8, we will offer jdk-1.8 (equivalent to jdk-1.8-headful) and jre-1.8 (equivalent to jre-1.8-headful)

FAQs

When will these changes take effect?

For JDK 17 and 11, the changes will be delivered with the Jan 2023 Critical Patch Update (2023-01-17), and for JDK 8 with the April 2023 Critical Patch Update (2023-04-18).

What is the expected impact to most users?

Most users, when they wanted to update their JDK versions, had to:

1. Download the JDK installer for each version they wanted to update. e.g. If one wanted to update JDK 17.0.4 to JDK 17.0.5. Download the jdk 17.0.5 installer from www.oracle.com/javadownload

2. Install the new versions.

3. Change launch scripts so they would use C:\Program Files\Java\jdk-17.0.5 instead of C:\Program Files\Java\jdk-17.0.4

4. Uninstall JDK 17.0.4

In Jan 2023, when those users update to 17.0.6 the steps will be almost identical, except that the installation directory that will now be specified will be `C:\Program Files\Java\jdk-17

The bigger change will happen in April, when they want to install the next updates (17.0.7). In April, and for all subsequent updates, users will only have to do the first two steps. The third and fourth steps will no longer be needed as the installers will overwrite the Java Runtimes rather than install them side-by-side.

Oracle Linux users who install the JDK using yum (or dnf), rather than calling yum update jdk-17 should select either the headless or the headful version, remove the current JDK and install the new JDK instead. e.g., assuming you choose JDK headless: yum remove jdk-17 followed by yum install jdk-17-headless. Future updates can then be applied by calling yum update jdk-17-headless (or just yum update).

But what if I don't want to replace a JDK version with the update but continue having the older versions side-by-side with the older updates remaining in my system (I don't want to remove the older versions)?

Oracle offers compressed archives (zip for Windows, tar.gz for Linux and macOS) which are not affected by this change. Using the compressed archive you have full control of the installation directory of each update release and can retain side-by-side updates as before.