A native GSS-API library named sspi_bridge.dll has been added to the JDK on the Windows platform. The library is client-side only and uses the default credentials. It will be loaded when the sun.security.jgss.native system property is set to "true". A user can still load a third-party native GSS-API library by setting the sun.security.jgss.lib system property to its path.

Native GSS automatically uses cached credentials from operating systems, thus the javax.security.auth.useSubjectCredsOnly system property should be set to false.

com.sun.security.auth.module.Krb5LoginModule does not call native JGSS. Avoid using com.sun.security.auth.module.Krb5LoginModule from JAAS config.

The AppleScript engine implementing the javax.script engine API has been removed without replacement. The AppleScript engine has worked inconsistently. The services configuration (META-INF/services) file was missing and only worked by accident when installing JDK 7 or JDK 8 on systems that had Apple's version of AppleScriptEngine.jar already on the system.

The com.apple.concurrent.Dispatch API was a Mac-only API. It was carried into JDK 7u4 with the port of Apple's JDK 6 code. Developers are encouraged to use the standard java.util.concurrent.Executor and java.util.concurrent.ExecutorService APIs instead.

This issue prevents yum from automatically installing the correct packages required by Oracle Linux specific x86_64 headless and headful JDK packages. Instead of x86_64 packages, it will install i686 packages. To workaround the issue, you may manually install packages with the same names as indicated by yum but with the x86_64 architecture.

After you have the x86_64 headless and/or headful jdk packages installed, you can get the list of required x86_64 packages by running the following script:

rpm -qa | grep -E -e '^jdk-.*-headful-.*\.x86_64$' -e '^jdk-.*-headless-.*\.x86_64$' | xargs -r rpm -q --requires | sort -u | cut -d ' ' -f 1 | grep -v '^rpmlib' | xargs -r rpm -q --whatprovides | sort -u | grep -e '.i[3456]86$' | xargs -r rpm -q --queryformat '%{name}.x86_64\n' | xargs -r echo

It will output a space-separated list of names of required x86_64 packages to stdout. You can pass this list to a sudo yum install command to ensure the installation of the required packages.

Fixed a regression where the /usr/java/default symlink is not created by RPM installers on Linux platforms. Now, installers will create the /usr/java/default symlink if it doesn't exist, targeting the /usr/java/latest symlink.

After upgrading to JDK 8u371 or later, there is the possibility of an application crash. The error log has a stack trace that starts with the following:

# Internal Error (g1CollectedHeap.cpp:5923), pid=xxxxx, tid=xxxxxx
# guarantee(!dcqs.completed_buffers_exist_dirty()) failed: must be

The above error may impact applications using G1 GC on all supported platforms.

Those who encounter the above error are encouraged to create a Service Request through My Oracle Support so that we can provide an interim solution to resolve the error.

Some Swing components, such as JLabels and JButtons, which display application text, will try to interpret that text as HTML, principally to enable styled text. The HTML processing of the text for these components will no longer recognize the <object> tag which allows for subclasses of java.awt.Component to be rendered on the component. To re-enable this, applications must specify -Dswing.html.object=true.

The installation directory name of the Oracle JRE in an RPM package has changed from /usr/java/jre-1.8.0_${UPDATE}-${ARCH} to /usr/lib/jvm/jre-1.8-oracle-${ARCH}. The installation directory name of the Oracle JDK in an RPM package has changed from /usr/java/jdk-1.8.0_${UPDATE}-${ARCH} to /usr/lib/jvm/jdk-1.8-oracle-${ARCH}. Thus the 8u371 and 8u381 releases of JDK for x64 will both be installed in the /usr/lib/jvm/jdk-1.8-oracle-x64 directory and the JRE for x64 will both be installed in the /usr/lib/jvm/jre-1.8-oracle-x64 directory. Both JDK and JRE RPM packages will create /usr/java/jdk-1.8.0-${ARCH} and /usr/java/jre-1.8.0-${ARCH} links respectively pointing to the installation directories for backward compatibility.

For the x86_64 platform, the value of the ${ARCH} suffix has changed from amd64 to x64. For the x86_32 platform, the value of the ${ARCH} has changed from i586 to x86.

The JRE RPM package name has changed from jre1.8 to jre-1.8 to make it consistent with other release families. To prevent confusion between the old and new naming patterns, the new package cannot be upgraded using a single "rpm -i ..." or "rpm -U ..." command. Please uninstall the old JRE and then install the new JRE. For example, sudo rpm -e jre1.8; sudo rpm -i jre-8u371-linux-x64.rpm. The JDK RPM package name has changed from jdk1.8 to jdk-1.8 to make it consistent with other release families. To prevent confusion between the old and new naming patterns, the new package cannot be upgraded using a single "rpm -i ..." or "rpm -U ..." command. Please uninstall the old JDK and then install the new JDK. For example, sudo rpm -e jdk1.8; sudo rpm -i jdk-8u371-linux-x64.rpm.

Communication with the alternatives framework for the JDK RPM package has changed. JDK RPM packages of prior versions registered a single java group of commands with the alternatives framework. The JDK 1.8 RPM package registers java and javac groups with the alternatives framework. The java group is for commands used to run applications: java, javaws, jcontrol, jjs, keytool, orbd, pack200, policytool, rmic, rmid, rmiregistry, servertool, tnameserv, unpack200. The javac group is used for all other commands. The set of commands registered by the package has not changed.

Three new Oracle Linux (OL)-specific JDK RPM packages have been added: jdk-1.8-headless, jdk-1.8-headful, and jre-1.8-headful. These packages are available in OL7, OL8, and OL9 repositories. They are not available for download from oracle.com.

• jdk-1.8-headless is a Headless Java Runtime for running non-GUI applications.
• jdk-1.8-headful is a Headful Java Runtime with Development Tools for developing and running applications of all types.
• jre-1.8-headful is a Headful Java Runtime for running applications of all types.

The combination of the OL-specific jdk-1.8-headless and jdk-1.8-headful packages provides the same JDK image and the same capabilities as the jdk-1.8 oracle.com package. The jre-1.8-headful package provides the same JRE image and the same capabilities as the jre-1.8 oracle.com package. OL-specific JDK and JRE RPM packages specify required capabilities, and the "Release" property of these packages has a %{dist} suffix. The value of the Release property of all RPM packages contains the value of the build number instead of the milestone.

Windows JDK installers must install the Oracle JDK in %Program Files%\Java\jdk-%FEATURE% instead of %Program Files%\Java\jdk-%VNUM%. That is, all updates of the same release must share one installation directory. It will not be possible to install older versions of a family if there is a newer JRE of that family already installed.

Thus the JDK 8u371 and JDK 8u381 releases will both install into %Program Files%\Java\jdk-1.8 by default, and they both cannot be installed at the same time.

Note: The Java 8u371 feature JDK-8293762 will now only allow one JRE of each family to be installed at one time. The REMOVEOLDERJRES=1 feature will no longer be supported with the standalone MSI. This is by design, as we only allow one JRE of each family of Java. The newer JREs will auto-upgrade older JREs of the same family.

The Oracle JDK installation directory name will be changed from /Library/Java/JavaVirtualMachines/jdk1.8.0_${UPDATE}.jdk to /Library/Java/JavaVirtualMachines/jdk-1.8.jdk. Thus the 8u371 and 8u381 releases will both install into the /Library/Java/JavaVirtualMachines/jdk-1.8.jdk installation directory. Installing an older JDK update release will log an error, and not install the JDK, if a newer version of the same feature release already exists. An error dialog will be shown except in the case of a silent installation. JDK 8 update releases shipped prior to this release, JDK 8u371, will not be uninstalled during installation of JDK 8u371 or later.

The following root certificate has been added to the cacerts truststore:

+ Certigna (Dhimyotis)
   + certignaca
      DN: CN=Certigna, O=Dhimyotis, C=FR

SSLv2Hello and SSLv3 have been removed from the default enabled TLS protocols.

After this update, if SSLv3 is removed from the jdk.tls.disabledAlgorithms security property, the SSLSocket.getEnabledProtocols(), SSLServerSocket.getEnabledProtocols(), SSLEngine.getEnabledProtocols() and SSLParameters.getProtocols() APIs will return "TLSv1.3, TLSv1.2, TLSv1.1, TLSv1". "SSLv3" will not be returned in this list.

If a client or server still needs to use the SSLv3 protocol they can do so by enabling it through the jdk.tls.client.protocols or jdk.tls.server.protocols system properties or with the SSLSocket.setEnabledProtocols(), SSLServerSocket.setEnabledProtocols() and SSLEngine.setEnabledProtocols() APIs.

After updating to JDK 8u361, applications failed to start, with multiple Exceptions being thrown, ultimately identified by a java.lang.ArrayIndexOutOfBoundsException occurring at jdk.internal.platform.cgroupv2.CgroupV2Subsystem.initSubsystem.

The JVM sometimes failed to initialize on Linux systems where /proc/self/mountinfo does not contain any mounted filesystem or controllers for cgroup.

For background information, see also My Oracle Support see KM Doc ID 2923131.1.

As part of ongoing maintenance, the JDK for Windows is built using the Microsoft Visual Studio 2022 toolchain starting with this release.

If you have issues with a Java application and if you have native or JNI libraries that are compiled with a different release of the compiler, then you must consider compatibility issues between the runtimes. Specifically, your environment is supported only if you follow the Microsoft guidelines when dealing with multiple runtimes. More information can be found in “C++ binary compatibility between Visual Studio versions”.

Applications using the Dell BSAFE Crypto-J 3rd party security provider may encounter an IOException if decoding DH or DSA algorithm parameters with the following exception:

Exception in thread "main" java.io.IOException: Could not decode parameters. at com.rsa.cryptoj.o.ms.engineInit(Unknown Source) at java.security.AlgorithmParameters.init(AlgorithmParameters.java:293)

Dell BSAFE Crypto-J version 6.2.6.2 has been released to address this issue. Applications using this provider should upgrade to that version or later. For applications on older versions of this provider, an interoperability fix has been added to this release of the JDK.

Upgrading from an 8u361 (or earlier) 32-bit JRE to an 8u371 (or later) 32-bit JRE when an 8u371 (or later) 64-bit JRE is already installed will cause the java.exe command to not be found. For example:

1. Install 32-bit 8u361
2. Install 64-bit 8u371 (or later)
3. Install 32-bit 8u371 (or later)

java.exe will now not work from all places. It will only work directly from the bin directory.

java.exe will not work unless you specify the full path to the bin directory of your JRE.

There are 2 workarounds:

• Workaround 1: uninstall and reinstall the latest version of 64-bit 8u371 (or later)
• Workaround 2: specify the full path to java.exe in the \bin directory of the JRE, for example: C:\Program Files\Java\jre-1.8\bin\java.exe