The java.security.debug system property now accepts arguments which add thread ID, thread name, caller information, and timestamp information to debug statements for all components or a specific component.

+timestamp can be appended to debug options to print a timestamp for that debug option. +thread can be appended to debug options to print thread and caller information for that debug option.

Examples: -Djava.security.debug=all+timestamp+thread adds timestamp and thread information to every debug statement generated.

-Djava.security.debug=properties+timestamp adds timestamp information to every debug statement generated for the properties component.

You can also specify -Djava.security.debug=help which will display a complete list of supported components and arguments.

See Printing Thread and Timestamp Information for more information.

Fixed the issue with entries in the "java" and "javac" groups not being properly managed during an RPM upgrade.

Upgrading from an older Java RPM installed into a shared directory (/usr/lib/jvm/jdk-${FEATURE}-oracle-${ARCH}) to a Java RPM installing into a version-specific directory (/usr/lib/jvm/jdk-${VERSION}-oracle-${ARCH}), results in the older Java entries in the "java" and "javac" groups not being deleted.

The issue does not manifest until the new Java is uninstalled. When it is uninstalled and Java from the lower release is installed, running Java commands like java or keytool without the full path specified will result in the "command not found" error. For example, install 21.0.3; upgrade it to 21.0.4; uninstall 21.0.4; install any Java update of 17 or 11 or 8 release; run "java" from the command line. The command will fail with the "command not found" error.

Manually delete orphan Java entries in the "java" and "javac" groups to workaround the issue.

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

+ SSL.com

  + ssltlsrootecc2022
    DN: CN=SSL.com TLS ECC Root CA 2022, O=SSL Corporation, C=US

+ SSL.com
  + ssltlsrootrsa2022
    DN: CN=SSL.com TLS RSA Root CA 2022, O=SSL Corporation, C=US

This JDK release relaxes the specification of java.awt.Robot to account for possible platform and desktop environment access restrictions or limitations.

In the JDK, java.text.MessageFormat now has an implementation limit for the ArgumentIndex pattern element. The hard limit for the value is 10,000.

If an ArgumentIndex value is equal to or exceeds the upper limit, an IllegalArgumentException will now be thrown by

• MessageFormats constructors
• applyPattern(String pattern) instance method
• format(String pattern, Object... arguments) static method

De-serializing a MessageFormat object with an ArgumentIndex value at or over the limit will throw an InvalidObjectException.

The showSettings launcher option no longer prints available locales information by default, when -XshowSettings is used. The -XshowSettings:locale option will continue to print all settings related to available locales.

New, default limits have been added to HTTP in the JDK.

The JDK built-in implementation of the URL protocol handler for HTTP (HttpURLConnection) now has a default limit on the maximum response headers size that will be accepted from a remote party. The limit is set by default at 384kB (393216 bytes) and is computed as the cumulative size of all header names and header values plus an overhead of 32 bytes per header name value pair.

The default value of the limit can be changed by specifying a positive value with the jdk.http.maxHeaderSize system property on the command line, or in the conf/net.properties file. A negative or zero value is interpreted as no limit. If the limit is exceeded, the request will fail with a protocol exception.

The JDK built-in implementation of the com.sun.net.httpserver.HttpServer implements a similar limit for the maximum request header size the server is prepared to accept. The HttpServer limit can be changed by specifying a positive value with the sun.net.httpserver.maxReqHeaderSize system property on the command line. A negative or zero value is interpreted as no limit. The limit is set by default at 384kB (393216 bytes) and the size is computed in the same way as explained above. If the limit is exceeded, the connection is closed.

Fixed the issue with entries in the "java" and "javac" groups not being properly managed during an RPM upgrade.

Upgrading from an older Java RPM installed into a shared directory (/usr/lib/jvm/jdk-${FEATURE}-oracle-${ARCH}) to a Java RPM installing into a version-specific directory (/usr/lib/jvm/jdk-${VERSION}-oracle-${ARCH}), results in the older Java entries in the "java" and "javac" groups not being deleted.

The issue does not manifest until the new Java is uninstalled. When it is uninstalled and Java from the lower release is installed, running Java commands like java or keytool without the full path specified will result in the "command not found" error. For example, install 21.0.3; upgrade it to 21.0.4; uninstall 21.0.4; install any Java update of 17 or 11 or 8 release; run "java" from the command line. The command will fail with the "command not found" error.

Manually delete orphan Java entries in the "java" and "javac" groups to workaround the issue.

New, default limits have been added to HTTP in the JDK.

The JDK built-in implementation of the URL protocol handler for HTTP (HttpURLConnection) now has a default limit on the maximum response headers size that will be accepted from a remote party. The limit is set by default at 384kB (393216 bytes) and is computed as the cumulative size of all header names and header values plus an overhead of 32 bytes per header name value pair.

The default value of the limit can be changed by specifying a positive value with the jdk.http.maxHeaderSize system property on the command line, or in the conf/net.properties file. A negative or zero value is interpreted as no limit. If the limit is exceeded, the request will fail with a protocol exception.

The JDK built-in implementation of the com.sun.net.httpserver.HttpServer implements a similar limit for the maximum request header size the server is prepared to accept. The HttpServer limit can be changed by specifying a positive value with the sun.net.httpserver.maxReqHeaderSize system property on the command line. A negative or zero value is interpreted as no limit. The limit is set by default at 384kB (393216 bytes) and the size is computed in the same way as explained above. If the limit is exceeded, the connection is closed.

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

+ SSL.com

  + ssltlsrootecc2022
    DN: CN=SSL.com TLS ECC Root CA 2022, O=SSL Corporation, C=US

+ SSL.com
  + ssltlsrootrsa2022
    DN: CN=SSL.com TLS RSA Root CA 2022, O=SSL Corporation, C=US

The TLS_ECDH cipher suites have been disabled by default, by adding "ECDH" to the jdk.tls.disabledAlgorithms security property in the java.security configuration file. The TLS_ECDH cipher suites do not preserve forward-secrecy and are rarely used in practice. Note that some TLS_ECDH cipher suites were already disabled because they use algorithms that are disabled, such as 3DES and RC4. This action disables the rest. Any attempts to use cipher suites starting with "TLS_ECDH_" will fail with an SSLHandshakeException. Users can, at their own risk, re-enable these cipher suites by removing "ECDH" from the jdk.tls.disabledAlgorithms security property.

Please note that this change has no effect on the TLS_ECDHE cipher suites, which are still enabled by default.

The JDK will stop trusting TLS server certificates issued after November 11, 2024 and anchored by Entrust root certificates, in line with similar plans recently announced by Google and Mozilla. The list of affected certificates includes certificates branded as AffirmTrust, which are managed by Entrust.

TLS server certificates issued on or before November 11, 2024 will continue to be trusted until they expire. Certificates issued after that date, and anchored by any of the Certificate Authorities in the table below, will be rejected.

The restrictions will be enforced in the JDK implementation (the SunJSSE Provider) of the Java Secure Socket Extension (JSSE) API. A TLS session will not be negotiated if the server's certificate chain is anchored by any of the Certificate Authorities in the table below and the certificate has been issued after November 11, 2024.

An application will receive an Exception with a message indicating the trust anchor is not trusted, for example:

TLS server certificate issued after 2024-11-11 and anchored by a distrusted legacy Entrust root CA: CN=Entrust.net Certification Authority (2048),

OU=(c) 1999 Entrust.net Limited, OU=www.entrust.net/CPS_2048 incorp. by ref. (limits liab.), O=Entrust.net

If necessary, and at your own risk, you can work around the restrictions by removing "ENTRUST_TLS" from the jdk.security.caDistrustPolicies security property in the java.security configuration file.

The restrictions are imposed on the following Entrust Root certificates included in the JDK:

You can also use the keytool utility from the JDK to print out details of the certificate chain, as follows:

keytool -v -list -alias <your_server_alias> -keystore <your_keystore_filename>

If any of the certificates in the chain are issued by one of the root CAs in the table above are listed in the output you will need to update the certificate or contact the organization that manages the server.

This JDK release relaxes the specification of java.awt.Robot to account for possible platform and desktop environment access restrictions or limitations.

This JDK implements Maintenance Release 6 of the Java SE 8 specification JSR 337. This is indicated by the system property java.specification.maintenance.version having the value of "6".

In the JDK, java.text.MessageFormat now has an implementation limit for the ArgumentIndex pattern element. The hard limit for the value is 10,000.

If an ArgumentIndex value is equal to or exceeds the upper limit, an IllegalArgumentException will now be thrown by

• MessageFormats constructors
• applyPattern(String pattern) instance method
• format(String pattern, Object... arguments) static method

De-serializing a MessageFormat object with an ArgumentIndex value at or over the limit will throw an InvalidObjectException.

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

DTLS 1.0 has been disabled by default, by adding "DTLSv1.0" to the jdk.tls.disabledAlgorithms security property in the java.security configuration file. DTLS 1.0 has weakened over time and lacks support for stronger cipher suites. Any attempts to use DTLSv1.0 will fail with an SSLHandshakeException. Users can, at their own risk, re-enable the version by removing "DTLSv1.0" from the jdk.tls.disabledAlgorithms security property.

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.

The XML Signature implementation has been updated to Santuario 3.0.3. Support for four new SHA-3 based RSA-MGF1 signature methods have been added: SHA3_224_RSA_MGF1, SHA3_256_RSA_MGF1, SHA3_384_RSA_MGF1, and SHA3_512_RSA_MGF1. While these new algorithm URIs are not defined in javax.xml.crypto.dsig.SignatureMethod in the JDK update releases, they may be represented as string literals in order to be functionally equivalent. SHA-3 hash algorithm support was delivered to JDK 9 via JEP 287. Releases earlier than that may use third party security providers.

Additionally, support for the following EdDSA signatures has been added: ED25519 and ED448. While these new algorithm URIs are not defined in javax.xml.crypto.dsig.SignatureMethod in the JDK Update releases, they may be represented as string literals in order to be functionally equivalent. The JDK supports EdDSA since JDK 15. Releases earlier than that may use 3rd party security providers. One other difference is that the JDK still supports the here() function by default. However, we recommend avoiding the use of the here() function in new signatures and replacing existing signatures that use the here() function. Future versions of the JDK will likely disable, and eventually remove, support for this function, as it cannot be supported using the standard Java XPath API. Users can now disable the here() function by setting the security property jdk.xml.dsig.hereFunctionSupported to "false".

The java.awt.SystemTray API is used for notifications in a desktop taskbar and may include an icon representing an application. On Linux, the Gnome desktop's own icon support in the taskbar has not worked properly for several years due to a platform bug. This, in turn, has affected the JDK's API, which relies upon that.

Therefore, in accordance with the existing Java SE specification, java.awt.SystemTray.isSupported() will return false where ever the JDK determines the platform bug is likely to be present.

The impact of this is likely to be limited since applications always must check for that support anyway. Additionally, some distros have not supported the SystemTray for several years unless the end-user chooses to install non-bundled desktop extensions.

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

+ Certainly

  + certainlyrootr1
    DN: CN=Certainly Root R1, O=Certainly, C=US

+ Certainly
  + certainlyroote1
    DN: CN=Certainly Root E1, O=Certainly, C=US

The XML Signature implementation has been updated to Santuario 3.0.3. Support for four new SHA-3 based RSA-MGF1 signature methods have been added: SHA3_224_RSA_MGF1, SHA3_256_RSA_MGF1, SHA3_384_RSA_MGF1, and SHA3_512_RSA_MGF1. While these new algorithm URIs are not defined in javax.xml.crypto.dsig.SignatureMethod in the JDK update releases, they may be represented as string literals in order to be functionally equivalent. SHA-3 hash algorithm support was delivered to JDK 9 via JEP 287. Releases earlier than that may use third party security providers.

Additionally, support for the following EdDSA signatures has been added: ED25519 and ED448. While these new algorithm URIs are not defined in javax.xml.crypto.dsig.SignatureMethod in the JDK Update releases, they may be represented as string literals in order to be functionally equivalent. The JDK supports EdDSA since JDK 15. Releases earlier than that may use 3rd party security providers. One other difference is that the JDK still supports the here() function by default. However, we recommend avoiding the use of the here() function in new signatures and replacing existing signatures that use the here() function. Future versions of the JDK will likely disable, and eventually remove, support for this function, as it cannot be supported using the standard Java XPath API. Users can now disable the here() function by setting the security property jdk.xml.dsig.hereFunctionSupported to "false".

The java.awt.SystemTray API is used for notifications in a desktop taskbar and may include an icon representing an application. On Linux, the Gnome desktop's own icon support in the taskbar has not worked properly for several years due to a platform bug. This, in turn, has affected the JDK's API, which relies upon that.

Therefore, in accordance with the existing Java SE specification, java.awt.SystemTray.isSupported() will return false where ever the JDK determines the platform bug is likely to be present.

The impact of this is likely to be limited since applications always must check for that support anyway. Additionally, some distros have not supported the SystemTray for several years unless the end-user chooses to install non-bundled desktop extensions.

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

+ Certainly

  + certainlyrootr1
    DN: CN=Certainly Root R1, O=Certainly, C=US

+ Certainly
  + certainlyroote1
    DN: CN=Certainly Root E1, O=Certainly, C=US

The XML Signature secure validation mode has been enabled by default (previously it was not enabled by default unless running with a security manager). When enabled, validation of XML signatures are subject to stricter checking of algorithms and other constraints as specified by the jdk.xml.dsig.secureValidationPolicy security property.

If necessary, and at their own risk, applications can disable the mode by setting the org.jcp.xml.dsig.secureValidation property to Boolean.FALSE with the DOMValidateContext.setProperty() API.

A new system property named org.jcp.xml.dsig.secureValidation has been added. It can be used to enable or disable the XML Signature secure validation mode. The system property should be set to "true" to enable, or "false" to disable. Any other value for the system property is treated as "false". If the system property is set, it supersedes the XMLCryptoContext property value.

Secure validation mode is enabled by default if you are running the code with a SecurityManager, otherwise it is disabled by default.

When the C1 compiler is the only compiler available to the VM, it applies loop predication to remove array access range checks from loop bodies. Due to a defect, this optimization was disabled, potentially leading to a performance regression.

This only affects the client VM or VM's running with the non-default command line flags -XX:+NeverActAsServerClassMachine or -XX:TieredStopAtLevel=[1,2,3].

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

+ DigiCert, Inc.

  + digicertcseccrootg5
    DN: CN=CN=DigiCert CS ECC P384 Root G5, O="DigiCert, Inc.", C=US

+ DigiCert, Inc.
  + digicertcsrsarootg5
    DN: CN=DigiCert CS RSA4096 Root G5, O="DigiCert, Inc.", C=US

+ DigiCert, Inc.
  + digicerttlseccrootg5
    DN: DigiCert TLS ECC P384 Root G5, O="DigiCert, Inc.", C=US

+ DigiCert, Inc.
  + digicerttlsrsarootg5
    DN: DigiCert TLS RSA4096 Root G5, O="DigiCert, Inc.", C=US

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

+ eMudhra Technologies Limited

  + emsignrootcag1
    DN: CN=emSign Root CA - G1, O=eMudhra Technologies Limited, OU=emSign PKI, C=IN

+ eMudhra Technologies Limited
  + emsigneccrootcag3
    DN: CN=emSign ECC Root CA - G3, O=eMudhra Technologies Limited, OU=emSign PKI, C=IN

+ eMudhra Technologies Limited
  + emsignrootcag2
    DN: CN=emSign Root CA - G2, O=eMudhra Technologies Limited, OU=emSign PKI, C=IN

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

+ Let's Encrypt

  + letsencryptisrgx2
    DN: CN=ISRG Root X2, O=Internet Security Research Group, C=US

The (D)TLS implementation in JDK now calls X509KeyManager.chooseClientAlias() only once during handshaking for client authentication, even if there are multiple algorithms requested .

A new system property named org.jcp.xml.dsig.secureValidation has been added. It can be used to enable or disable the XML Signature secure validation mode. The system property should be set to "true" to enable, or "false" to disable. Any other value for the system property is treated as "false". If the system property is set, it supersedes the XMLCryptoContext property value.

Secure validation mode is enabled by default if you are running the code with a SecurityManager, otherwise it is disabled by default.

A new JDK Flight Recorder (JFR) event has been added to monitor deserialization of objects. When JFR is enabled and the JFR configuration includes deserialization events, JFR will emit an event whenever the running program attempts to deserialize an object. The deserialization event is named java/deserialization, and it is disabled by default. The deserialization event contains information that is used by the serialization filter mechanism. Additionally, if a filter is enabled, the JFR event indicates whether the filter accepted or rejected deserialization of the object.

The new Deserialization Event captures:

• Whether a serialization filter is configured or not.
• The serialization filter status, if one is configured.
• The class of the object being deserialized.
• The number of array elements when deserializing an array.
• The current graph depth.
• The current number of object references.
• The current number of bytes in the stream that have been consumed.
• The exception type and message, if thrown by the serialization filter.

Refer to Context-Specific Deserialization Filter and Serialization Filtering Guide for details.

When the C1 compiler is the only compiler available to the VM, it applies loop predication to remove array access range checks from loop bodies. Due to a defect, this optimization was disabled, potentially leading to a performance regression.

This only affects the client VM or VM's running with the non-default command line flags -XX:+NeverActAsServerClassMachine or -XX:TieredStopAtLevel=[1,2,3].

The system property, jdk.jar.maxSignatureFileSize, allows applications to control the maximum size of signature files in a signed JAR. Its default value has been increased from 8000000 bytes (8 MB) to 16000000 bytes (16 MB).

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

+ DigiCert, Inc.

  + digicertcseccrootg5
    DN: CN=CN=DigiCert CS ECC P384 Root G5, O="DigiCert, Inc.", C=US

+ DigiCert, Inc.
  + digicertcsrsarootg5
    DN: CN=DigiCert CS RSA4096 Root G5, O="DigiCert, Inc.", C=US

+ DigiCert, Inc.
  + digicerttlseccrootg5
    DN: DigiCert TLS ECC P384 Root G5, O="DigiCert, Inc.", C=US

+ DigiCert, Inc.
  + digicerttlsrsarootg5
    DN: DigiCert TLS RSA4096 Root G5, O="DigiCert, Inc.", C=US

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

+ eMudhra Technologies Limited

  + emsignrootcag1
    DN: CN=emSign Root CA - G1, O=eMudhra Technologies Limited, OU=emSign PKI, C=IN

+ eMudhra Technologies Limited
  + emsigneccrootcag3
    DN: CN=emSign ECC Root CA - G3, O=eMudhra Technologies Limited, OU=emSign PKI, C=IN

+ eMudhra Technologies Limited
  + emsignrootcag2
    DN: CN=emSign Root CA - G2, O=eMudhra Technologies Limited, OU=emSign PKI, C=IN

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

+ Telia Root CA v2

  + teliarootcav2
    DN: CN=Telia Root CA v2, O=Telia Finland Oyj, C=FI

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

+ Let's Encrypt

  + letsencryptisrgx2
    DN: CN=ISRG Root X2, O=Internet Security Research Group, C=US

The (D)TLS implementation in JDK now calls X509KeyManager.chooseClientAlias() only once during handshaking for client authentication, even if there are multiple algorithms requested .

A virtual machine crash was observed in JDK 11.0.19 and 17.0.7 when executing the GregorianCalender.computeTime() method (JDK-8307683). It was found that although the root cause of the crash is an old issue, a recent fix for a rare issue in the C2 compiler (JDK-8297951) made the crash much more likely. To mitigate this, the fix has been reverted in JDK 11.0.20 and 17.0.8 and will be reapplied once JDK-8307683 is resolved.

A new Java Flight Recorder (JFR) event has been added to record details of java.security.Provider.getService(String type, String algorithm) calls.

The new event name is jdk.SecurityProviderService and contains the following fields:

This event is disabled by default and can be enabled via the JFR configuration files or via standard JFR options.

The -XshowSettings launcher option has been enhanced to print the tzdata version configured with the JDK. The tzdata version is displayed as part of the locale showSettings option.

Example output using -X:showSettings:locale:

.....

Locale settings:
    default locale = English
    default display locale = English
    default format locale = English
    tzdata version = 2023c
    .....

Media playback does not work on Ubuntu 23.10. This affects most media formats such as MP4 with H.264/H.265, MP3, AAC, and HTTP Live Streaming. This is because JavaFX Media does not support libavcodec version 60. Support for libavcodec version 60 will be added with JDK-8317508. As a workaround, install libavcodec version 59 compiled with support for at least the following:

• decoder: aac, mp3, mp3float, h264, hevc
• parser: aac, h264, hevc
• demuxer: aac, h264, hevc, mpegts, mpegtsraw

The following root certificate from SECOM Trust System has been removed from the cacerts keystore:

+ alias name "secomscrootca1 [jdk]"

  Distinguished Name: OU=Security Communication RootCA1, O=SECOM Trust.net, C=JP

Platform support for Linux ARM32 in JDK 8 has been removed. As a result, the ARM32 Hard Float ABI download will not be available. Operating Systems that supported ARM32 have reached their End of Life, thus there is no known OS support available.

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

+ Certigna (Dhimyotis)

  + certignarootca
    DN: CN=Certigna Root CA, OU=0002 48146308100036, O=Dhimyotis, C=FR

In JDK 12, two new token options for the java.security.manager system property, "allow" and "disallow", were introduced.

Many applications and frameworks are designed to run on multiple JDKs. For those that enable the SecurityManager at runtime via System.setSecurityManager, they have to specify the "allow" option as of JDK 18 (see JDK-8203316). However, these applications would also prefer to use the same command line across multiple versions of the JDK, especially if it is not known what JDK version a user will use.

Currently, if these options are specified in JDK 12 or earlier, the runtime attempts to load a SecurityManager implementation with the classname "allow" or "disallow", which results in a Could not create SecurityManager Error and the application will not start up.

From this release onward, the "allow" and "disallow" options for the java.security.manager system property will be ignored.

The JDK implementation of TLS 1.2 now uses a default Diffie Hellman keysize of 2048 bits when a TLS_DHE cipher suite is negotiated and either the client or server does not support FFDHE, which can negotiate a stronger keysize. The JDK TLS implementation supports FFDHE and it is enabled by default.

As a workaround, users can revert to the previous size by setting the jdk.tls.ephemeralDHKeySize system property to 1024 (at their own risk).

This change does not affect TLS 1.3 as the minimum DH group size is already 2048 bits.

In 8u371, the behavior of the JRE installer was changed from installing the JRE in a full-version-specific directory to installing the JRE into a common shared directory. It also removed all older JRE versions in that same family.

In JDK 8u391, a new argument, RETAIN_ALL_VERSIONS=1, was introduced for the MSI installer. If the argument is used, the JRE will install into a jre$fullversion directory. Other JREs of the Java SE 8 family will not be automatically removed. More information can be found in the MSI Enterprise JRE Installer Guide for Windows.

The readObject method changes made to _DynAnyFactoryStub in JDK-8285021, have been extended to a set of stub classes that have been categoriezed as pseudo IDL interfaces. These include:

org.omg.DynamicAny._DynArrayStub,

org.omg.DynamicAny._DynEnumStub,
org.omg.DynamicAny._DynFixedStub, 
org.omg.DynamicAny._DynSequenceStub, 
org.omg.DynamicAny._DynStructStub, 
org.omg.DynamicAny._DynUnionStub, 
org.omg.DynamicAny._DynValueStub,
org.omg.DynamicAny._DynAnyStub, 

For each of these stub classes, the readObject method has been amended such that, when reading the stringified IOR from serialized data, it will, by default, accept stringified IORs in IOR: URI format only. As the above stub classes are termed, locally or as ORB constrained types, it is not useful that serialized data should contain corbaname or corbaloc URIs. Furthermore, an ORB will prohibit the binding of a name in the INS to an IOR of these stub classes. As such, using a corbaname to reference an instance of these locally constrained stub classes is not meaningful.

A system property is introduced, com.sun.CORBA.DynamicAny.Stubs.allowCorbanameInIOR, which when set to true, will revert the readObject method to its current behavior and disable the additional IOR checks. The default value of this system property is false. This system property can also be used to disable the IOR check performed in the org.omg.DynamicAny._DynAnyFactoryStub readObject method. As such, with respect to _DynAnyFactory, it complements the system property org.omg.DynamicAny.DynAnyFactoryStub.disableIORCheck introduced in JDK-8285021.

Additionally, the readObject method of the remote CORBA service stub classes:

org.omg.CosNaming._NamingContextStub.java,

org.omg.CosNaming._BindingIteratorStub.java,
org.omg.CosNaming._NamingContextExtStub.java,
org.omg.PortableServer._ServantActivatorStub.java,
org.omg.PortableServer._ServantLocatorStub.java,
com.sun.corba.se.spi.activation._ServerManagerStub.java,
com.sun.corba.se.spi.activation._ActivatorStub.java,
com.sun.corba.se.spi.activation._RepositoryStub.java,
com.sun.corba.se.spi.activation._InitialNameServiceStub.java,
com.sun.corba.se.spi.activation._LocatorStub.java,
com.sun.corba.se.spi.activation._ServerStub.java,

included in the JDK, have been similarly amended to include an IOR check when reading a stringified IOR from serialised data. To enable the IOR check, and prohibit corbaname or corbaloc URLs in a stringified IOR, the setting of the com.sun.CORBA.DynamicAny.Stubs.allowCorbanameInIOR system property to true is required.

A system property is introduced, com.sun.CORBA.IDL.Stubs.allowCorbanameInIOR, which when set to false, will activate an IOR check when reading a stringified IOR from serialised data and constrain a stringified IOR to that of IOR: URI format. Thus, prohibiting corbaname or corbaloc as a valid stringified IOR format. The default value of this system property is true. That is, corbaname or corbaloc are allowed in stringified IORs.

For TLS connections, the cipher suite selection, by default, is updated to use the server cipher suites preference. Applications can configure the behavior by using the SSLParameters.setUseCipherSuitesOrder​() method.

Starting with the July 2023 CPU, on operating systems where ASLR (Address Space Layout Randomization) is enabled, the CDS archive will be placed at a random address picked by the operating system.

This change may have a minor performance impact: (a) Start-up time may increase because the JVM needs to patch pointers inside the CDS archive; (b) Memory usage may increase because the memory used by the CDS archive is no longer shareable across processes. We expect the impact to be small because such increases should be only a small fraction of the overall application usage.

In the unlikely event that you must disable ASLR for CDS, you can use the JVM flags -XX:+UnlockDiagnosticVMOptions -XX:ArchiveRelocationMode=0. The usage of such flags is not recommended.

The China National Standard body (CESI) has recently published GB18030-2022. This is an updated version of the GB18030 standard and brings GB18030 in sync with Unicode version 11.0. The purpose of this enhancement is to incorporate 35 code points (U+9FCD - U+9FEF) from Unicode 11.0 into Java SE 8 to allow implementations to comply with their Implementation Level 1 requirements.

The China National Standard body (CESI) has recently published GB18030-2022, which is an updated version of the GB18030 standard and brings GB18030 in sync with Unicode version 11.0. The Charset implementation for this new standard has now replaced the prior 2000 standard. However, this new standard has some incompatible changes from the prior implementation. For those who need to use the old mappings, a new system property, jdk.charset.GB18030, is introduced. By setting its value to 2000, the previous JDK releases' mappings for the GB18030 Charset are used, which are based on the 2000 standard.

The China National Standard body (CESI) has recently published GB18030-2022. This is an updated version of the GB18030 standard and brings GB18030 in sync with Unicode version 11.0. The purpose of this enhancement is to incorporate 108 code points from CJK Unified Ideographs Extension E block from Unicode 11.0 into Java SE 8 to allow implementations to comply with their Implementation Level 2 requirements.

RSA private and public keys in PKCS#1 format can now be accepted by JDK providers, such as the RSA KeyFactory.impl from the SunRsaSign provider. The RSA private or public key object should have the PKCS#1 format and an encoding matching the ASN.1 syntax for a PKCS#1 RSA private key and public key.

Installing into the same, shared jdk-(family) directory is the default behavior for the JDK starting with the July 2023 CPU. It could lead to FilesInUse issues if JDK files are locked by the "System User". We recommend shutting down any apps using the JDK as the "System User" before upgrading.

There is the possibility of an application crash with the following error:

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

This affects JDK 8u371 and JDK 8u381 runtimes using G1 GC on all supported platforms.

The failure is now corrected in the JDK 8u381 b32 Bundle Patch Release available via My Oracle Support.

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

JDK 8u381 includes several enhancements and fixes to improve the cgroup v1 and v2 support for containers. The improvements include accurately detecting the resource limits of containers, correctly reporting the collected container metrics, printing additional container information, and improving application stability in containerized environments.

Some of the notable stability enhancements are:

JDK-8292083: Java applications may experience out-of-memory errors and run the risk of being killed by the OOM killer when running in a containerized environment where the container is configured with a higher memory limit than the available physical memory on the host system. JDK 8u381 addresses this stability issue. In the previous release, this situation can be avoided by using either -XX:-UseContainerSupport, or -XX:MaxRAM=<physical memory>, or by setting a memory limit for your container that is lower than the physical memory.

JDK-8286030: This release addresses an issue where Java applications may encounter a fatal error when the same /tmp directory is shared across multiple containers. In earlier releases, this crash can be avoided by mounting /tmp to different locations for different containers. Alternatively, the '-XX:-UsePerfData' JVM option can be used to prevent JVMs running within different containers from writing performance data to the shared /tmp folder and thus avoid this issue.

Added an "Obsoletes" tag to JDK 8 RPM packages to allow automatic upgrades from older JDK 8 RPM packages.

• jdk-1.8 package obsoletes jdk1.8 package.
• jre-1.8 package obsoletes jre1.8 package.
• jdk-1.8-headful package obsoletes jdk1.8 package.
• jre-1.8-headful package obsoletes jre1.8 package.

No "Obsoletes" tag was added to the jdk-1.8-headless package to prevent upgrading from the full to headless JDK.

The changes allow automatic upgrades for JDK 8 RPM packages starting from the 8u151 update when jdk1.8 and jre1.8 package names were first introduced. Older JDK 8 updates will not be eligible for automatic upgrades to 8u381 and newer updates.

Due to the limitations of "Obsoletes" tag downgrades from 8u381 to older versions are not supported.

A regression where the /usr/java/default symlink is not created by RPM installers on Linux platforms has been fixed. Installers will create the /usr/java/default symlink if it doesn't exist, targeting the /usr/java/latest symlink.

The JDK RPM installer will remove incorrectly constructed entries of "java" and "javac" groups registered by older Oracle JDK RPM installers from the alternatives before registering new "java" and "javac" entries.

An incorrectly constructed entry of the "java" group contains commands that are supposed to belong to the "javac" group.

An incorrectly constructed entry of the "javac" group contains commands that are supposed to belong to the "java" group.

All incorrectly constructed entries belonging to Oracle JDK RPM packages will be removed from the alternatives to avoid corruption of the alternatives internal data.

The removal has a potential side effect for users who have installed multiple JDK versions that are not updated to the latest release. Commands from a removed "java" or "javac" group are now unavailable for system Java switch, which potentially changes the current system Java without a warning. For example, if there is an out-of-date JDK RPM from an 11+ release, say 11.0.17, with an incorrectly constructed single "java" group installed and 8u381 RPM with this patch is installed, it will remove an entry from the "java" group belonging to the 11.0.17 RPM and thus will switch the current system Java from 11.0.17 to 8u381. The side effect will only happen when you install a lower JDK family with the fix, such as 8u381, and there is an out-of-date JDK from a higher family, such as 11.0.17, installed on the system. In that case, 8u381 will replace the older 11.0.17 as the latest. The remedy for the user is to install the latest JDK 11.

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

+ TWCA

  + twcaglobalrootca
    DN: CN=TWCA Global Root CA, OU=Root CA, O=TAIWAN-CA, C=TW

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

+ Google Trust Services LLC

 + gtsrootcar1
  DN: CN=GTS Root R1, O=Google Trust Services LLC, C=US

+ Google Trust Services LLC
 + gtsrootcar2
  DN: CN=GTS Root R2, O=Google Trust Services LLC, C=US

+ Google Trust Services LLC
 + gtsrootecccar3
  DN: CN=GTS Root R3, O=Google Trust Services LLC, C=US

+ Google Trust Services LLC
 + gtsrootecccar4
  DN: CN=GTS Root R4, O=Google Trust Services LLC, C=US

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

+ Microsoft Corporation

  + microsoftecc2017
    DN: CN=Microsoft ECC Root Certificate Authority 2017, O=Microsoft Corporation, C=US

+ Microsoft Corporation
  + microsoftrsa2017
    DN: CN=Microsoft RSA Root Certificate Authority 2017, O=Microsoft Corporation, C=US

This JDK implements Maintenance Release 5 of the Java SE 8 specification (JSR 337). This is indicated by the system property java.specification.maintenance.version having the value of "5".

Starting with the July 2023 CPU, on operating systems where ASLR (Address Space Layout Randomization) is enabled, the CDS archive will be placed at a random address picked by the operating system.

This change may have a minor performance impact: (a) Start-up time may increase because the JVM needs to patch pointers inside the CDS archive; (b) Memory usage may increase because the memory used by the CDS archive is no longer shareable across processes. We expect the impact to be small because such increases should be only a small fraction of the overall application usage.

In the unlikely event that you must disable ASLR for CDS, you can use the JVM flags -XX:+UnlockDiagnosticVMOptions -XX:ArchiveRelocationMode=0. The usage of such flags is not recommended.

A behavioral change has been made when the default conf/security/java.security security configuration file fails to load. In such a scenario, the JDK will now throw an InternalError.

Such a scenario should never occur. The default security file should always be present. Prior to this change, a static security configuration was loaded.

A new system property, jdk.jar.maxSignatureFileSize, has been added to allow applications to control the maximum size of signature files in a signed JAR. The value of the system property is the desired size in bytes. The default value is 8000000 bytes.

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

The JVM will fail to initialize on Linux systems where /proc/self/mountinfo does not contain any mounted filesystem or controllers for cgroups. This failure occurs due to faulty detection logic where it incorrectly detects a cgroup v1 system, having no mounted controllers, as a cgroup v2 system.

A fix is available via the 8u361 b32 BPR available on My Oracle Support (see KM Doc ID 2923131.1).

• Palestine transitions are now Saturdays at 02:00.
• Simplify three Ukraine zones into one.
• Jordan and Syria switch from +02/+03 with DST to year-round +03.
• Mexico will no longer observe DST except near the US border.
• Chihuahua moves to year-round -06 on 2022-10-30.
• Fiji no longer observes DST.
• Move links to 'backward'.
• In vanguard form, GMT is now a Zone and Etc/GMT a link.
• zic now supports links to links, and vanguard form uses this.
• Simplify four Ontario zones.
• Fix a Y2438 bug when reading TZif data.
• Enable 64-bit time_t on 32-bit glibc platforms.
• Omit large-file support when no longer needed.
• In C code, use some C23 features if available.
• Remove no-longer-needed workaround for Qt bug 53071.

Oracle recommends that the JDK is updated with each Critical Patch Update. In order to determine if a release is the latest, the Security Baseline page can be used to determine which is the latest version for each release family.

Critical patch updates, which contain security vulnerability fixes, are announced one year in advance on Critical Patch Updates, Security Alerts and Bulletins. It is not recommended that this JDK (version 8u361) be used after the next critical patch update scheduled for April 18, 2023.

Java SE Subscription customers managing JRE updates/installs for large number of desktops should consider using Java Advanced Management Console (AMC).

For systems unable to reach the Oracle Servers, a secondary mechanism expires this JRE (version 8u361) on 2023-05-18. After either condition is met (new release becoming available or expiration date reached), the JRE will provide additional warnings and reminders to users to update to the newer version. For more information, see 23.1.2 JRE Expiration Date in the Java Platform, Standard Edition Deployment Guide.

An OCSP response signed with the RSASSA-PSS algorithm is now supported.

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

The JVM will fail to initialize on Linux systems where /proc/self/mountinfo does not contain any mounted filesystem or controllers for cgroups. This failure occurs due to faulty detection logic where it incorrectly detects a cgroup v1 system, having no mounted controllers, as a cgroup v2 system.

A fix is available via the 8u361 b32 BPR available on My Oracle Support (see KM Doc ID 2923131.1).

Previous JDK releases used an incorrect interpretation of the Linux cgroups parameter "cpu.shares". This might cause the JVM to use fewer CPUs than available, leading to an under utilization of CPU resources when the JVM is used inside a container.

Starting from this JDK release, by default, the JVM no longer considers "cpu.shares" when deciding the number of threads to be used by the various thread pools. The -XX:+UseContainerCpuShares command-line option can be used to revert to the previous behavior. This option is deprecated and may be removed in a future JDK release.

The “JavaScript script engine” for FXML is now disabled by default. Any .fxml file that has a "javascript" Processing Instruction (PI) will no longer load by default, and an exception will be thrown.

It can be enabled by setting the system property: -Djavafx.allowjs=true

ProcessBuilder on Windows is restored to address a regression caused by JDK-8250568. Previously, an argument to ProcessBuilder that started with a double-quote and ended with a backslash followed by a double-quote was passed to a command incorrectly and may cause the command to fail. For example the argument "C:\\Program Files\", would be seen by the command with extra double-quotes. This update restores the long standing behavior that does not treat the backslash before the final double-quote specially.

Two system properties have been added which control the keep alive behavior of HttpURLConnection in the case where the server does not specify a keep alive time. Two properties are defined for controlling connections to servers and proxies separately. They are http.keepAlive.time.server and http.keepAlive.time.proxy respectively. More information about them can be found in Networking Properties.

This version of the JDK no longer includes a copy of Java VisualVM. VisualVM is now available as a separate download from https://visualvm.github.io.

The readObject method of _DynAnyFactoryStub has been amended, such that, when reading the stringified IOR from serialized data, it will, by default, accept stringified IORs in IOR: URI format, only. As DynAnyFactory is a locally or ORB constrained type, it is not useful that serialized data should contain corbaname or corbaloc URIs. Furthermore, an ORB will prohibit the binding of a name in the INS to a DynAnyFactory IOR, as such, using a corbaname to reference an instance of DynAnyFactory is not meaningful.

A system property is introduced, org.omg.DynamicAny.DynAnyFactoryStub.disableIORCheck, which when set to true, will revert the _DynAnyFactoryStub::readObject to its current behavior and bypass the additional IOR checks.

Enterprise Performance Pack supports JDK Flight Recorder (JFR).

JFR is a low-overhead data collection framework for troubleshooting Java applications and the HotSpot JVM in production. Recorded data can be opened in JDK Mission Control (JMC). To start recordings from within JMC, a new version of JMC is required. Currently, it is not released as part of the JDK but is available as a downloadable patch from Supported Java SE Downloads on MOS or from JDK Mission Control 8 Downloads. JFR comes with a supported API to produce and consume data programmatically.

Relevant Changes for JFR include JEP 328: Flight Recorder, JEP 349: JFR Event Streaming

Oracle recommends that the JDK is updated with each Critical Patch Update. In order to determine if a release is the latest, the Security Baseline page can be used to determine which is the latest version for each release family.

Critical patch updates, which contain security vulnerability fixes, are announced one year in advance on Critical Patch Updates, Security Alerts and Bulletins. It is not recommended that this JDK (version 8u351) be used after the next critical patch update scheduled for January 17, 2023.

Java SE Subscription customers managing JRE updates/installs for large number of desktops should consider using Java Advanced Management Console (AMC).

For systems unable to reach the Oracle Servers, a secondary mechanism expires this JRE (version 8u351) on 2023-02-17. After either condition is met (new release becoming available or expiration date reached), the JRE will provide additional warnings and reminders to users to update to the newer version. For more information, see 23.1.2 JRE Expiration Date in the Java Platform, Standard Edition Deployment Guide.

The default MAC algorithm used in a PKCS #12 keystore has been updated. The new algorithm is based on SHA-256 and is stronger than the old one based on SHA-1. See the security properties starting with keystore.pkcs12 in the java.security file for detailed information.

The new SHA-256 based MAC algorithms were introduced in the 11.0.12, 8u301, and 7u311 JDK versions. Keystores created using this newer, stronger, MAC algorithm cannot be opened in JDK versions earlier than 11.0.12, 8u301, and 7u311. A 'java.security.NoSuchAlgorithmException' exception will be thrown in such circumstances.

For compatibility, use the keystore.pkcs12.legacy system property, which will revert the algorithms to use the older, weaker algorithms. There is no value defined for this property.

On platforms that support the concept of a thread name on their native threads, the java.lang.Thread.setName() method will also set that native thread name. However, this will only occur when called by the current thread, and only for threads started through the java.lang.Thread class (not for native threads that have attached via JNI). The presence of a native thread name can be useful for debugging and monitoring purposes. Some platforms may limit the native thread name to a length much shorter than that used by the java.lang.Thread, which may result in some threads having the same native name.

The Java Access Bridge checkbox in the Windows Control Panel is not available in JDK11. This registration was part of the public JRE installation.

However, Java Access Bridge can still be enabled and disabled by following these steps:

1. Copy %JAVAHOME%\bin\windowsaccessbridge-64.dll to %WINDOWSHOME%\SYSTEM32. A reboot might be required after this step.
2. Run %JAVAHOME%\bin\jabswitch /enable and %JAVAHOME%\bin\jabswitch /disable.

Note: %WINDOWSHOME% is the directory where Microsoft Windows is installed (for example, C:\WINDOWS) %JAVAHOME% is the directory where your JDK is installed (for example, C:\Program Files\Java\jdk-11)

JARs signed with SHA-1 algorithms are now restricted by default and treated as if they were unsigned. This applies to the algorithms used to digest, sign, and optionally timestamp the JAR. It also applies to the signature and digest algorithms of the certificates in the certificate chain of the code signer and the Timestamp Authority, and any CRLs or OCSP responses that are used to verify if those certificates have been revoked. These restrictions also apply to signed JCE providers.

To reduce the compatibility risk for JARs that have been previously timestamped, there is one exception to this policy:

• Any JAR signed with SHA-1 algorithms and timestamped prior to January 01, 2019 will not be restricted.

This exception may be removed in a future JDK release. To determine if your signed JARs are affected by this change, run jarsigner -verify -verbose -certs on the signed JAR, and look for instances of "SHA1" or "SHA-1" and "disabled" and a warning that the JAR will be treated as unsigned in the output.

For example:

-  Signed by "CN="Signer""

     Digest algorithm: SHA-1 (disabled)
     Signature algorithm: SHA1withRSA (disabled), 2048-bit key

WARNING: The jar will be treated as unsigned, because it is signed with a weak algorithm that is now disabled by the security property:

  jdk.jar.disabledAlgorithms=MD2, MD5, RSA keySize < 1024, DSA keySize < 1024, SHA1 denyAfter 2019-01-01

JARs affected by these new restrictions should be replaced or re-signed with stronger algorithms.

Users can, at their own risk, remove these restrictions by modifying the java.security configuration file (or override it by using the java.security.properties system property) and removing "SHA1 usage SignedJAR & denyAfter 2019-01-01" from the jdk.certpath.disabledAlgorithms security property and "SHA1 denyAfter 2019-01-01" from the jdk.jar.disabledAlgorithms security property.

The des3-hmac-sha1 and rc4-hmac Kerberos encryption types (etypes) are now deprecated and disabled by default. Users can set allow_weak_crypto = true in the krb5.conf configuration file to re-enable them (along with other weak etypes including des-cbc-crc and des-cbc-md5) at their own risk. To disable a subset of the weak etypes, users can list preferred etypes explicitly in any of the default_tkt_enctypes, default_tgs_enctypes, or permitted_enctypes settings.

This enhancement changes phantom references to be automatically cleared by the garbage collector as soft and weak references.

An object becomes phantom reachable after it has been finalized. This change may cause the phantom reachable objects to be GC'ed earlier - previously the referent is kept alive until PhantomReference objects are GC'ed or cleared by the application. This potential behavioral change might only impact existing code that would depend on PhantomReference being enqueued rather than when the referent be freed from the heap.

java.lang.ref.Reference.enqueue method clears the reference object before it is added to the registered queue. When the enqueue method is called, the reference object is cleared and get() method will return null in JDK 9.

Typically when a reference object is enqueued, it is expected that the reference object is cleared explicitly via the clear method to avoid memory leak because its referent is no longer referenced. In other words the get method is expected not to be called in common cases once the enqueuemethod is called. In the case when the get method from an enqueued reference object and existing code attempts to access members of the referent, NullPointerException may be thrown. Such code will need to be updated.

java.lang.ref.Reference::clone method always throws CloneNotSupportedException. Reference objects cannot be meaningfully cloned. To create a new Reference object, call the constructor to create a Reference object with the same referent and reference queue instead.

This version includes changes from 2022b that merged multiple regions that have the same timestamp data post-1970 into a single time zone data. All time zone IDs remain the same but the merged time zones will point to a shared zone data.

As a result, pre-1970 data may not be compatible with earlier JDK versions. The affected zones are Antarctica/Vostok, Asia/Brunei, Asia/Kuala_Lumpur, Atlantic/Reykjavik, Europe/Amsterdam, Europe/Copenhagen, Europe/Luxembourg, Europe/Monaco, Europe/Oslo, Europe/Stockholm, Indian/Christmas, Indian/Cocos, Indian/Kerguelen, Indian/Mahe, Indian/Reunion, Pacific/Chuuk, Pacific/Funafuti, Pacific/Majuro, Pacific/Pohnpei, Pacific/Wake, Pacific/Wallis, Arctic/Longyearbyen, Atlantic/Jan_Mayen, Iceland, Pacific/Ponape, Pacific/Truk, and Pacific/Yap.

For more details, refer to the announcement of 2022b.

This JDK implements Maintenance Release 4 of the Java SE 8 specification (JSR 337). Implementing this maintenance release is indicated by the new system property java.specification.maintenance.version having the value of "4".

A new system property named jdk.httpserver.maxConnections has been introduced to allow users to configure the com.sun.net.httpserver.HttpServer to limit the maximum number of open connections to the server at any given time. This system property takes an integer value and can be configured to be a positive integer. If the property is absent, set to 0, or a negative value, the server will not limit the number of open connections. By default, this system property is not set.