Debug log files for Java Updater and JCP have been added to the directory $HOME/Library/Application Support/Oracle/Java/Java Updater/ for macOS x64 and aarch64. Logs for Java Updater and JCP are separated into two log files: JavaUpdaterLog.txt and JCPUpdateLog.txt.

JavaUpdaterLog.txt is generated and logs debug lines if it does not already exist when Java Updater is run. Likewise, JCPUpdateLog.txt is generated and logs debug lines if it does not already exist when Java Control Panel is run.

If a log file already exists for Java Updater or JCP, the newly logged debug lines are appended at the end of the log file. Each log session has a header with a timestamp of when the application was run.

The -XshowSettings launcher has a new security category. Settings from security properties, security providers and TLS related settings are displayed with this option. A security sub-category can be passed as an argument to the security category option. See the output from java -X:

   -XshowSettings:security

       show all security settings and continue
   -XshowSettings:security:*sub-category*
       show settings for the specified security sub-category and continue. Possible *sub-category* arguments for this option include:
       all: show all security settings and continue
       properties: show security properties and continue
       providers: show static security provider settings and continue
       tls: show TLS related security settings and continue

Third party security provider details will be reported if they are included in the application class path or module path and such providers are configured in the java.security file.

On Windows, once the feature “Use certificates and keys in browser keystore” is enabled (which it is by default), Java WebStart and Java Plugin can access the certificates that are currently trusted by the local machine. There is no guarantee that the full list of trusted certificates is available, since the certificates are dynamically loaded. As a result, Java applets and Java WebStart applications might experience signature validation and secure connection issues caused by a lack of relevant certificates since the Deployment framework can only access the certificates that are 'active' at the time of an application's launch.

To allow the java, javaw, and javaws executables to be run from any location, the JRE 8 Windows installers copy java.exe, javaw.exe, and javaws.exe helper files into the following directory:

C:\Program Files (x86)\Common Files\Oracle\Java\java8path

Also, the system PATH variable is updated to include this location.

These helper files are lightweight executables that launch the latest version installed. They pass any commandline arguments along to the real executables in the bin directory. They are not specificially tied to a version other than the FileVersion of the exe. The installers will leave the latest versions of the shims in this location until the last Java 8 is uninstalled.

Note: In 8u411 and later releases, the directory name was changed from "javapath" to "java8path" to ensure compatibility with newer JDK family versions.

Delete nonfunctional desktop integration functionality from Linux installers. The installers will stop depositing files in /usr/share/icons, /usr/share/mime, and /usr/share/applications subtrees.

This fix will add the STATIC=1 installer argument and deprecating the RETAIN_ALL_VERSIONS=1 installer argument. Passing STATIC=1 will protect older JRE 8 versions from being uninstalled during a manual upgrade or an auto-update.

The "Obsoletes" tag has been removed from "jdk-1.8" and "jre-1.8" RPM packages.

New stub "jdk1.8" and "jre1.8" RPM packages have been provided. These are the pre-8u371 names without a dash. These packages do not install any files, but require corresponding update releases for "jdk-1.8" and "jre-1.8" packages, the post-8u371 name with the dash, respectively.

Users who only have 8u371 or newer RPM packages installed do not need to use the new stub "jdk1.8" or "jre1.8" RPM packages, and will not be affected by this change.

Users who install the new stub "jdk1.8" package and would like to downgrade it to 8u361 or an older version, will need to first manually uninstall the "jdk-1.8" package before the downgrade to prevent the side-by-side installation of older and newer Java 8 JDK RPM packages. The same applies to the "jre1.8" and "jre-1.8" packages.

If the "jdk-1.8" package is stored in an RPM repository, maintainers of the repository need to place an additional stub "jdk1.8" package next to "jdk-1.8" in that RPM repository. The same applies to the "jre1.8" and "jre-1.8" packages.

Users who install the "jdk-1.8" package from something other than an RPM repository need to specify paths to the RPM files with "jdk1.8" and "jdk-1.8" packages in a single update command if they would like to upgrade from 8u361 or older "jdk1.8" package. The same applies to the "jre1.8" and "jre-1.8" packages.

The following root certificates have been added to the cacerts truststore:

+ GlobalSign

  + globalsignr46
    DN: CN=GlobalSign Root R46, O=GlobalSign nv-sa, C=BE

+ GlobalSign
  + globalsigne46
    DN: CN=GlobalSign Root E46, O=GlobalSign nv-sa, C=BE

Native executables and libraries on Linux have switched to using RPATH instead of RUNPATH in this release.

JDK native executables and libraries use embedded runtime search paths to locate other internal JDK native libraries. On Linux these can be defined as either RPATH or RUNPATH. The main difference is that the dynamic linker considers RPATH before the LD_LIBRARY_PATH environment variable, while RUNPATH is only considered after LD_LIBRARY_PATH.

By making the change to using RPATH, it is no longer possible to replace JDK internal native libraries using LD_LIBRARY_PATH.

The installation directory name of the Oracle JDK in RPM and DEB packages has changed from /usr/lib/jvm/jdk-1.8-oracle-${ARCH} to /usr/lib/jvm/jdk-${VERSION}-oracle-${ARCH}.

The installation directory name of the Oracle JRE in RPM and DEB packages has changed from /usr/lib/jvm/jre-1.8-oracle-${ARCH} to /usr/lib/jvm/jre-${VERSION}-oracle-${ARCH}.

Every update release will be installed in a separate directory on Linux platforms.

Installers will create a /usr/java/jdk-1.8-oracle-${ARCH} link pointing to the installation directory to allow programs to find the latest JDK8 version.

Installers will create a /usr/java/jre-1.8-oracle-${ARCH} link pointing to the installation directory to allow programs to find the latest JRE8 version.

The JRE will be installed in the following location, C:\Program Files\Java\jre$fullversion, where $fullversion is the technical version of the JRE. For instance, 8u421 will install into C:\Program Files\Java\jre1.8.0_421.

"C:\Program Files" will be adjusted to "C:\Program Files (x86)" for 32-bit Java.

For 64-bit installs, a junction will be created at C:\Program Files\Java\latest\jre-1.8. It will point to the latest 64-bit JRE of the Java 8 family.

For 32-bit installs, a junction will be created at C:\Program Files (x86)\Java\latest\jre-1.8. It will point to the latest 32-bit JRE of the Java 8 family.

This change of the JRE installation directories will also be reflected in the public JRE that is shipped with the JDK installer. Such changes were part of STATIC support implementation introduced in the 8u421 release.