RMI will use TLS connections if the javax.rmi.ssl.SslRMIClientSocketFactory class is used. These connections now have TLS endpoint identification enabled by default. This may cause some previously-working TLS connections to fail. If this occurs, ensure that the certificate presented by the server has a Subject Alternative Name that matches the server's hostname. Alternatively, endpoint identification for RMI TLS connections can be disabled on the client side by setting the jdk.rmi.ssl.client.enableEndpointIdentification system property to false.

The SHA-1 algorithm has been disabled by default in TLS 1.2 and DTLS 1.2 handshake signatures, by adding "rsa_pkcs1_sha1 usage HandshakeSignature, ecdsa_sha1 usage HandshakeSignature, dsa_sha1 usage HandshakeSignature" to the jdk.tls.disabledAlgorithms security property in the java.security config file. RFC 9155 deprecates the use of SHA-1 in TLS 1.2 and DTLS 1.2 digital signatures. Users can, at their own risk, re-enable the SHA-1 algorithm in TLS 1.2 and DTLS 1.2 handshake signatures by removing "rsa_pkcs1_sha1 usage HandshakeSignature, ecdsa_sha1 usage HandshakeSignature, dsa_sha1 usage HandshakeSignature" from the jdk.tls.disabledAlgorithms security property.

The TLS_RSA cipher suites have been disabled by default, by adding TLS_RSA_* to the jdk.tls.disabledAlgorithms security property in the java.security configuration file. The TLS_RSA cipher suites do not preserve forward-secrecy and are not commonly used. Some TLS_RSA cipher suites are already disabled because they use DES, 3DES, RC4, or NULL, which are disabled. This action disables all remaining TLS_RSA cipher suites. Any attempts to use cipher suites starting with TLS_RSA_ will fail with an SSLHandshakeException. Users can, at their own risk, re-enable these cipher suites by removing TLS_RSA_* from the jdk.tls.disabledAlgorithms security property. The following previously enabled cipher suites are now disabled:

    TLS_RSA_WITH_AES_256_GCM_SHA384
    TLS_RSA_WITH_AES_128_GCM_SHA256
    TLS_RSA_WITH_AES_256_CBC_SHA256
    TLS_RSA_WITH_AES_128_CBC_SHA256
    TLS_RSA_WITH_AES_256_CBC_SHA
    TLS_RSA_WITH_AES_128_CBC_SHA

The HotSpot runtime code has been updated to allow the jcmd -l and jps commands discover JVMs running in a container.

For the JDK11+ LTS families, the JDK will install into a version-specific installation directory by default. The installation directory of 11+ will have a - before the version-specific string to keep consistency with the past 11+ conventions per family. A junction, also known as a symlink for Windows, will also be created in a "latest" directory. It will point to the latest version of that family. Here is a breakdown example of installation and junction locations 11+ families:

Each junction will always point to the latest JDK of the matching LTS family. The junction for each family will be removed when the last JDK of the matching LTS family is uninstalled.

A new system and security property, com.sun.security.allowedAIALocations, has been introduced. This property allows users the ability to define one or more filtering rules to be applied to URIs obtained from the authority info access extension on X.509 certificates. These filter rules are applied specifically to the CA issuers access method. Any CA issuers URIs in X.509 certificates are only followed when the com.sun.security.enableAIAcaIssuers system property is enabled and the filter allows the URI.

In order to set the rules, the user must set either the com.sun.security.allowedAIALocations security property or the system property by the same name. If the system property has a value, it will override the security property. By default the property is blank, which enacts a deny-all ruleset.

For either property, the value consists of a set of space-separated rules that take the form of a URI, with the following constraints:

• The URI must be absolute and hierarchical.
• The URI must only use one of the following schemes: http, https, ldap, or ftp (case-insensitive).
• A hostname or address must be specified and must match (case-insensitive). No name resolution is performed on hostnames to match URIs with IP addresses.
• The port number must match. Where a port number is omitted, the well-known port will be used in the comparison.
• For hierarchical schemes (http[s], ftp):
  • A rule's normalized path portion of the URI is matched in a case-sensitive manner. If the final component does not end in a slash (/), it is considered to be a file path and must match the CA issuer URI path component. If the rule's path component ends in a slash, then it must match or be a prefix of the CA issuer URI path component. (for example, a filter path of /ab/cd/ will match a CA issuer path of /ab/cd/, /ab/cd/ef and /ab/cd/ef/ghi.).
  • Query strings and fragments will be ignored when matching CA issuer URIs.
• For ldap URIs:
  • The base DN must be an exact match (case-insensitive).
  • Any query string in the rule, if specified, will be ignored.

For the properties, a single value of "any" (case-insensitive) will create an allow-all rule.

RMI will use TLS connections if the [javax.rmi.ssl.SslRMIClientSocketFactory] class is used. These connections now have TLS endpoint identification enabled by default. This may cause some previously-working TLS connections to fail. If this occurs, ensure that the certificate presented by the server has a Subject Alternative Name that matches the server's hostname. Alternatively, endpoint identification for RMI TLS connections can be disabled on the client side by setting the jdk.rmi.ssl.client.enableEndpointIdentification system property to false.

The SHA-1 algorithm has been disabled by default in TLS 1.2 and DTLS 1.2 handshake signatures, by adding "rsa_pkcs1_sha1 usage HandshakeSignature, ecdsa_sha1 usage HandshakeSignature, dsa_sha1 usage HandshakeSignature" to the jdk.tls.disabledAlgorithms security property in the java.security config file. RFC 9155 deprecates the use of SHA-1 in TLS 1.2 and DTLS 1.2 digital signatures. Users can, at their own risk, re-enable the SHA-1 algorithm in TLS 1.2 and DTLS 1.2 handshake signatures by removing "rsa_pkcs1_sha1 usage HandshakeSignature, ecdsa_sha1 usage HandshakeSignature, dsa_sha1 usage HandshakeSignature" from the jdk.tls.disabledAlgorithms security property.

For the JDK11+ LTS families, the JDK will install into a version-specific installation directory by default. The installation directory of 11+ will have a - before the version-specific string to keep consistency with the past 11+ conventions per family. A junction, also known as a symlink for Windows, will also be created in a "latest" directory. It will point to the latest version of that family. Here is a breakdown example of installation and junction locations 11+ families:

Each junction will always point to the latest JDK of the matching LTS family. The junction for each family will be removed when the last JDK of the matching LTS family is uninstalled.

jcmd command will be available in the headless JDK RPM instead of the headful JDK RPM.

It will be added to the java alternatives group instead of the javac alternatives group.

The TLS_RSA cipher suites have been disabled by default, by adding "TLS_RSA_" to the jdk.tls.disabledAlgorithms security property in the java.security configuration file. The TLS_RSA cipher suites do not preserve forward-secrecy and are not commonly used. Some TLS_RSA cipher suites are already disabled because they use DES, 3DES, RC4, or NULL, which are disabled. This action disables all remaining TLS_RSA cipher suites. Any attempts to use cipher suites starting with "TLS_RSA_" will fail with an SSLHandshakeException. Users can, at their own risk, re-enable these cipher suites by removing "TLS_RSA_" from the jdk.tls.disabledAlgorithms security property. The following previously enabled cipher suites are now disabled:

TLS_RSA_WITH_AES_256_GCM_SHA384

TLS_RSA_WITH_AES_128_GCM_SHA256
TLS_RSA_WITH_AES_256_CBC_SHA256
TLS_RSA_WITH_AES_128_CBC_SHA256
TLS_RSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_AES_128_CBC_SHA

On Debian-based Linux distributions such as Ubuntu, the /etc/timezone file was previously used to determine the JDK's default time zone (TimeZone.getDefault()). According to Debian's Wiki, /etc/localtime is now the primary source for the system's default time zone, making /etc/timezone redundant. As a result, the JDK's default time zone detection logic has been updated to use /etc/localtime instead of /etc/timezone. If /etc/localtime and /etc/timezone are inconsistent for any reason, the JDK's default time zone is now determined solely based on /etc/localtime file.

The HotSpot runtime code has been updated to allow the jcmd -l and jps commands discover JVMs running in a container.

A new system and security property, com.sun.security.allowedAIALocations, has been introduced. This property allows users the ability to define one or more filtering rules to be applied to URIs obtained from the authority info access extension on X.509 certificates. These filter rules are applied specifically to the CA issuers access method. Any CA issuers URIs in X.509 certificates are only followed when the com.sun.security.enableAIAcaIssuers system property is enabled and the filter allows the URI.

In order to set the rules, the user must set either the com.sun.security.allowedAIALocations security property or the system property by the same name. If the system property has a value, it will override the security property. By default the property is blank, which enacts a deny-all ruleset.

For either property, the value consists of a set of space-separated rules that take the form of a URI, with the following constraints:

• The URI must be absolute and hierarchical.
• The URI must only use one of the following schemes: http, https, ldap, or ftp (case-insensitive).
• A hostname or address must be specified and must match (case-insensitive). No name resolution is performed on hostnames to match URIs with IP addresses.
• The port number must match. Where a port number is omitted, the well-known port will be used in the comparison.
• For hierarchical schemes (http[s], ftp):
  • A rule's normalized path portion of the URI is matched in a case-sensitive manner. If the final component does not end in a slash (/), it is considered to be a file path and must match the CA issuer URI path component. If the rule's path component ends in a slash, then it must match or be a prefix of the CA issuer URI path component. (for example, a filter path of /ab/cd/ will match a CA issuer path of /ab/cd/, /ab/cd/ef and /ab/cd/ef/ghi.).
  • Query strings and fragments will be ignored when matching CA issuer URIs.
• For ldap URIs:
  • The base DN must be an exact match (case-insensitive).
  • Any query string in the rule, if specified, will be ignored.

For the properties, a single value of "any" (case-insensitive) will create an allow-all rule.

TLS protocol specific usage constraints are now supported by the jdk.tls.disabledAlgorithms property in the java.security configuration file, as follows:

UsageConstraint:

    usage UsageType { UsageType }

UsageType:
    HandshakeSignature | CertificateSignature

HandshakeSignature restricts the use of an algorithm in TLS handshake signatures. CertificateSignature restricts the use of an algorithm in certificate signatures. An algorithm with this constraint cannot include other usage types defined in the jdk.certpath.disabledAlgorithms property. The usage type follows the keyword and more than one usage type can be specified with a whitespace delimiter.

TLS cipher suites can be disabled with the jdk.tls.disabledAlgorithms security property in the java.security configuration file using one or more * wildcard characters. For example, "TLS_RSA_*" disables all cipher suites that start with "TLS_RSA_". Only cipher suites starting with "TLS_" are allowed to have wildcard characters.

The XML Signature implementation has been updated to Santuario 3.0.5. Support for four new SHA-3 based ECDSA SignatureMethod algorithms have been added: SignatureMethod.ECDSA_SHA3_224, SignatureMethod.ECDSA_SHA3_256, SignatureMethod.ECDSA_SHA3_384, and SignatureMethod.ECDSA_SHA3_512.

java.lang.CharSequence has been updated in this release to define a default isEmpty method that tests if a character sequence is empty. Testing for, and filtering out, empty Strings and other CharSequences is a common occurrence in code and CharSequence::isEmpty can be used as a method reference. Classes that implement java.lang.CharSequence and another interface that defines isEmpty method should be aware of this addition as they may need to be modified to override the isEmpty method.

When IPv6 is enabled, the JDK uses dual stack IPv4/IPv6 sockets by default. Binding, connecting, or sending datagrams uses IPv4-mapped IPv6 addresses in this case.

On some hosts running macOS version 15.6.x and above, and macOS 26, it has been observed that when a datagram socket bound to a IPv4 mapped IPv6 address sends a packet, either using the java.net.DatagramSocket or java.nio.channels.DatagramChannel APIs, then the first packet is lost and never gets delivered. A second invocation of send on the same socket, even to the same destination address, correctly delivers the packet and it is received by the recipient.

A bug has been filed with Apple (feedback issue id FB20302424) seeking their assistance. The issue is currently unresolved.

Until the issue is resolved, there are a couple of workarounds that applications can consider:

• If using IPv4 is acceptable, then the java command can be launched with -Djava.net.preferIPv4Stack=true to use IPv4 sockets by default.
• If using -Djava.net.preferIPv4Stack=true is not acceptable, a more local workaround can be applied by changing the application code to create a java.nio.channels.DatagramChannel with java.net.StandardProtocolFamily.INET as the protocol family and then bind the channel to a IPv4 address.

The following root certificates, which are deactivated and no longer in use, have been removed from the cacerts keystore:

+ alias name "affirmtrustcommercialca [jdk]"

  Distinguished Name: CN=AffirmTrust Commercial, O=AffirmTrust, C=US

+ alias name "affirmtrustnetworkingca [jdk]"
  Distinguished Name: CN=AffirmTrust Networking, O=AffirmTrust, C=US

+ alias name "affirmtrustpremiumca [jdk]"
  Distinguished Name: CN=AffirmTrust Premium, O=AffirmTrust, C=US

+ alias name "affirmtrustpremiumeccca [jdk]"
  Distinguished Name: CN=AffirmTrust Premium ECC, O=AffirmTrust, C=US

The HotSpot runtime code has been updated to additionally print a container's 'rss' and 'cache'. The additional output can be found in the JVM's response to a "jcmd [PID] VM.info" request and in the hs_err file generated in case of JVM abrupt termination.

This will help monitoring and troubleshooting OutOfMemory situations as OOM killer can terminate a process if its rss + cache usage reaches the max memory limit of the container.

On Solaris, the CKM_DH_PKCS_KEY_PAIR_GEN and CKM_DH_PKCS_DERIVE mechanisms offered by the SunPKCS11-Solaris provider have been disabled via the $JAVA_HOME/conf/security/sunpkcs11-solaris.cfg configuration file. The SunJCE provider also supports these DH crypto services and may be chosen instead. The DH mechanisms can be re-enabled by removing them from the "disabledMechanisms" section of the configuration file. However, please note that the DHParameterSpec object for any generated DH key pair will always have its optional L value (the private value length) set to 0.

The bug reporting URL that users are directed to as a result of crashes has been updated to use the HTTPS protocol, rather than the HTTP protocol. The old bug reporting URL, http://bugreport.java.com/bugreport/crash.jsp, already redirects to https://, so this change should have no impact on users reporting bugs.

On Solaris, the CKM_TLS_KEY_AND_MAC_DERIVE mechanism offered by the SunPKCS11-Solaris provider and specific to TLSv1.0, can derive incorrect key data causing TLSv1.0 communication failure. That mechanism has been disabled via the $JAVA_HOME/conf/security/sunpkcs11-solaris.cfg configuration file. The JCE provider now manages these cryptographic requests.

Locale data based on Unicode Consortium's CLDR has been upgraded to their version 37. For the detailed locale data changes, please refer to the Unicode Consortium's CLDR release notes:

• http://cldr.unicode.org/index/downloads/cldr-37

The logging behavior of the TLS javax.net.debug system property has been improved in this release. The javax.net.debug property is used to generate TLS debug logs from the default JSSE provider. Previously, using the ssl option via -Djavax.net.debug=ssl produced very limited output, which reduced its usefulness for troubleshooting.

With this update, setting -Djavax.net.debug=ssl now enables comprehensive SSL debug logging, except for the data, packet, and plaintext sub-options. Applications using this option will now see significantly more detailed debug information in logs.

TLS protocol specific usage constraints are now supported by the jdk.tls.disabledAlgorithms property in the java.security configuration file, as follows:

UsageConstraint:

    usage UsageType { UsageType }

UsageType:
    HandshakeSignature | CertificateSignature

HandshakeSignature restricts the use of an algorithm in TLS handshake signatures. CertificateSignature restricts the use of an algorithm in certificate signatures. An algorithm with this constraint cannot include other usage types defined in the jdk.certpath.disabledAlgorithms property. The usage type follows the keyword and more than one usage type can be specified with a whitespace delimiter.

TLS cipher suites can be disabled with the jdk.tls.disabledAlgorithms security property in the java.security configuration file using one or more * wildcard characters. For example, "TLS_RSA_*" disables all cipher suites that start with "TLS_RSA_". Only cipher suites starting with "TLS_" are allowed to have wildcard characters.

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.

The XML Signature implementation has been updated to Santuario 3.0.5. Support for four new SHA-3 based ECDSA SignatureMethod algorithms have been added: SignatureMethod.ECDSA_SHA3_224, SignatureMethod.ECDSA_SHA3_256, SignatureMethod.ECDSA_SHA3_384, and SignatureMethod.ECDSA_SHA3_512.

On Solaris 11.4, Java applications may experience user interface (UI) issues, such as:

• Frame title bars not displaying correctly
• Mouse events not being delivered to the application

Workaround:
To resolve these issues, add the following line to the /usr/bin/gnome-session file:

export GSK_RENDERER=cairo

After making this change, restart gdm and vncserver for the update to take effect.

A permanent fix will be included in Solaris SRU 87.

When IPv6 is enabled, the JDK uses dual stack IPv4/IPv6 sockets by default. Binding, connecting, or sending datagrams uses IPv4-mapped IPv6 addresses in this case.

On some hosts running macOS version 15.6.x and above, and macOS 26, it has been observed that when a datagram socket bound to a IPv4 mapped IPv6 address sends a packet, either using the java.net.DatagramSocket or java.nio.channels.DatagramChannel APIs, then the first packet is lost and never gets delivered. A second invocation of send on the same socket, even to the same destination address, correctly delivers the packet and it is received by the recipient.

A bug has been filed with Apple (feedback issue id FB20302424) seeking their assistance. The issue is currently unresolved.

Until the issue is resolved, there are a couple of workarounds that applications can consider:

• If using IPv4 is acceptable, then the java command can be launched with -Djava.net.preferIPv4Stack=true to use IPv4 sockets by default.
• If using -Djava.net.preferIPv4Stack=true is not acceptable, a more local workaround can be applied by changing the application code to create a java.nio.channels.DatagramChannel with java.net.StandardProtocolFamily.INET as the protocol family and then bind the channel to a IPv4 address.

The following root certificates, which are deactivated and no longer in use, have been removed from the cacerts keystore:

+ alias name "affirmtrustcommercialca [jdk]"

  Distinguished Name: CN=AffirmTrust Commercial, O=AffirmTrust, C=US

+ alias name "affirmtrustnetworkingca [jdk]"
  Distinguished Name: CN=AffirmTrust Networking, O=AffirmTrust, C=US

+ alias name "affirmtrustpremiumca [jdk]"
  Distinguished Name: CN=AffirmTrust Premium, O=AffirmTrust, C=US

+ alias name "affirmtrustpremiumeccca [jdk]"
  Distinguished Name: CN=AffirmTrust Premium ECC, O=AffirmTrust, C=US

Linux RPM JDK installers now use systemd instead of init to manage the automatic jar file execution (jexec) service.

In this release, new system and security properties are introduced to allow more granular control over the set of JNDI object factories allowed to reconstruct Java objects from JNDI/LDAP and JNDI/RMI contexts:

• The new jdk.jndi.ldap.object.factoriesFilter property specifies which object factory classes are allowed to instantiate Java objects from object references returned by JNDI/LDAP contexts. By default, only object factories defined with the setting of the property 'jdk.jndi.ldap.object.factoriesFilter=com.sun.jndi.ldap.**;!*' are allowed.

• The new jdk.jndi.rmi.object.factoriesFilter property specifies which object factory classes are allowed to instantiate Java objects from object references returned by JNDI/RMI contexts. By default, only object factories defined with the setting of the property jdk.jndi.rmi.object.factoriesFilter=com.sun.jndi.rmi.**;!* are allowed.

These new factory filter properties complement the jdk.jndi.object.factoriesFilter global factories filter property by determining if a specific object factory is permitted to instantiate objects for the LDAP or RMI protocols used in JNDI.

An application depending on custom object factories to recreate Java objects from JNDI/LDAP or JNDI/RMI contexts will need to supply a security or system property with an updated value to allow such third-party object factories to reconstruct LDAP or RMI objects. If usage of a factory is denied, the lookup operation may result in a plain instance of javax.naming.Reference instance returned, which may lead to a ClassCastException being thrown in the application.

The HotSpot runtime code in the JDK has been updated in order for diagnostic commands like jcmd and jstack be able to attach to JVM processes running in a container.

The bug reporting URL that users are directed to as a result of crashes has been updated to use the HTTPS protocol, rather than the HTTP protocol. The old bug reporting URL, http://bugreport.java.com/bugreport/crash.jsp, already redirects to https://, so this change should have no impact on users reporting bugs.

The HotSpot runtime code has been updated to additionally print a container's 'rss' and 'cache'. The additional output can be found in the JVM's response to a "jcmd [PID] VM.info" request and in the hs_err file generated in case of JVM abrupt termination.

This will help monitoring and troubleshooting OutOfMemory situations as OOM killer can terminate a process if its rss + cache usage reaches the max memory limit of the container.

Command line arguments to the Java launcher are no longer converted with Windows' "best-fit" mapping when the arguments include unmappable characters for the ANSI code page. This mapping has been intervening in the Java launcher's argument parsing. Unmappable characters are now replaced with the default replacement character, such as '?' in some cases. For rare cases, where applications need those unmappable characters on the command line, select UTF-8 in Windows Regional Settings.

The JDK XPath implementation now supports External Access Properties. It also enables restriction through these properties when secure processing is set to true explicitly. To secure an XPath processor against risky evaluation of external DTD references, enable secure processing as demonstrated in the following code:

This process will cause the XPath processor created via the factory to throw XPathExpressionException if used to evaluate a raw XML document that contains external references such as an external DTD.

Mitigation includes using the External Access Properties to override that enabled by FSP. For example, the following setting will allow the process to continue when there is a reference to a file-based external DTD in the XML document:

It is recommended that applications use the XPath processor to evaluate DOM rather than raw XML documents.

The logging behavior of the TLS javax.net.debug system property has been improved in this release. The javax.net.debug property is used to generate TLS debug logs from the default JSSE provider. Previously, using the ssl option via -Djavax.net.debug=ssl produced very limited output, which reduced its usefulness for troubleshooting.

With this update, setting -Djavax.net.debug=ssl now enables comprehensive SSL debug logging, except for the data, packet, and plaintext sub-options. Applications using this option will now see significantly more detailed debug information in logs.

The following root certificates, which are terminated and no longer in use, have been removed from the `cacerts` keystore:

+ alias name "camerfirmachamberscommerceca [jdk]"
  Distinguished Name: CN=Chambers of Commerce Root, OU=http://www.chambersign.org, O=AC Camerfirma SA CIF A82743287, C=EU

+ alias name "camerfirmachambersignca [jdk]"
  Distinguished Name: CN=Global Chambersign Root - 2008, O=AC Camerfirma S.A., SERIALNUMBER=A82743287, L=Madrid (see current address at www.camerfirma.com/address), C=EU

The following expired root certificate has been removed from the `cacerts` keystore:

+ alias name "baltimorecybertrustca [jdk]"
  Distinguished Name: CN=Baltimore CyberTrust Root, OU=CyberTrust, O=Baltimore, C=IE

The oracle.com JDK RPM packages meant to be downloaded directly to the target system, now are signed with the OL9 signing key instead of the OL8 signing key. The RPM packages hosted on YUM repositories remain signed with the appropriate key for the target repository.

The following expired root certificate has been removed from the cacerts keystore:

+ alias name "baltimorecybertrustca [jdk]"

  Distinguished Name: CN=Baltimore CyberTrust Root, OU=CyberTrust, O=Baltimore, C=IE

The following root certificates, which are terminated and no longer in use, have been removed from the cacerts keystore:

+ alias name "camerfirmachamberscommerceca [jdk]"

  Distinguished Name: CN=Chambers of Commerce Root, OU=http://www.chambersign.org, O=AC Camerfirma SA CIF A82743287, C=EU

+ alias name "camerfirmachambersignca [jdk]"
  Distinguished Name: CN=Global Chambersign Root - 2008, O=AC Camerfirma S.A., SERIALNUMBER=A82743287, L=Madrid (see current address at www.camerfirma.com/address), C=EU

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

+ Sectigo Limited

  + sectigocodesignroote46
    DN: CN=Sectigo Public Code Signing Root E46, O=Sectigo Limited, C=GB

+ Sectigo Limited
  + sectigocodesignrootr46
    DN: CN=Sectigo Public Code Signing Root R46, O=Sectigo Limited, C=GB

+ Sectigo Limited
  + sectigotlsroote46
    DN: CN=Sectigo Public Server Authentication Root E46, O=Sectigo Limited, C=GB

+ Sectigo Limited
  + sectigotlsrootr46
    DN: CN=Sectigo Public Server Authentication Root R46, O=Sectigo Limited, C=GB

The oracle.com JDK RPM packages meant to be downloaded directly to the target system, now are signed with the OL9 signing key instead of the OL8 signing key. The RPM packages hosted on YUM repositories remain signed with the appropriate key for the target repository.

There are some scenarios where upgrading from a JRE version 8u361 or below to a newer JRE version of Java 8 may break some of the Windows registry keys for the Java Runtime Environment. The Java Uninstall Tool will repair such situations, regardless if a JRE is selected for uninstall or not.

The latest Gnome update installs the Cantarell font, an OpenType font with CFF2 table, as the default in the latest Red Hat, SLES, and Solaris platforms. However, the T2K rendering engine used in JDK 8 does not support OpenType CFF2 fonts. As a result, when using the GTK look and feel, none of the text renders with the Cantarell font.

Starting from JDK 8u461, the Java runtime utilizes the FreeType library installed on the end-user’s system to render certain fonts, such as Cantarell. Due to this modification, installing libfreetype.so.6 may be necessary.

In this release, the JDK implementation of the LDAP provider no longer supports deserialization of Java objects by default:

• The default value of the com.sun.jndi.ldap.object.trustSerialData system property has been updated to false.

The transparent deserialization of Java objects from an LDAP context will now require an explicit opt-in. Applications that rely on reconstruction of Java objects or RMI stubs from the LDAP attributes would need to set the com.sun.jndi.ldap.object.trustSerialData system property to true.

If an entry is removed from a signed JAR file, there is no mechanism to detect that it has been removed using the JarFile API, since the getJarEntry method returns null as if the entry had never existed. With this change, the jarsigner -verify command analyzes the signature files and if some sections do not have matching file entries, it prints out the following warning: "This JAR contains signed entries for files that do not exist". Users can further find out the names of these entries by adding the -verbose option to the command.

The implementation of the ExpandEntityReferences feature was changed to comply with the specification of the DocumentBuilderFactory.setExpandEntityReferences method. Now, when the method is set to false and encounters an entity reference, a DOM parser created by the DocumentBuilderFactory adds the EntityReference node to the DOM tree without the expanded Text node. Before the change, the implementation incorrectly added both nodes.

With the change, the DOM parser no longer reads and resolves entity references when the feature ExpandEntityReferences is set to false. For applications that intend to avoid resolving entity references, it will work as expected.

This change also affects the DOM Load and Save parser. The entities parameter is aligned with the ExpandEntityReferences feature, so that setting the entities parameter to true is equivalent to setting ExpandEntityReferences to false. In the following code snippet, the document will contain EntityReference nodes but not expanded Text nodes:

        LSParser domParser = domImplementationLS.createLSParser(MODE_SYNCHRONOUS, null);

        domParser.getDomConfig().setParameter("entities", true);
        LSInput src = domImplementationLS.createLSInput();
        src.setStringData(source);
        Document document = domParser.parse(src);

Because the references are not resolved, the resulting string will contain entity references without the text when the document is serialized:

        LSSerializer lsSerializer = domImplementationLS.createLSSerializer();

        lsSerializer.getDomConfig().setParameter("format-pretty-print", true);
        String result = lsSerializer.writeToString(document);

Native PKCS11 mechanisms which support decryption but not encryption, or signature verification but not signing, are considered legacy and are disabled by default. The legacy mechanism check in SunPKCS11 provider is enhanced with the service type. For example, prior to this fix, a mechanism supporting encryption, decryption, and verification but not signing, is considered legacy and can't be used at all. After this fix, the corresponding Cipher service using this mechanism is available since both encryption and decryption are supported. However, the corresponding Signature service is not since only verification is supported. To bypass the legacy mechanism check, set the PKCS11 provider configuration attribute "allowLegacy" to true. The default value is false. Note that it is the caller's responsibility to make sure the legacy mechanism is not used for the unsupported functionality.

In prior releases, JNI_GetCreatedJavaVMs:

jint JNI_GetCreatedJavaVMs(JavaVM **vmBuf, jsize bufLen, jsize *nVMs);

could return a JavaVM, via the vmBuf array, that was still in the process of being initialized and may not be ready for use. This has now changed so that it will only return fully initialized VMs. It is important that the programmer checks that the returned number of VMs, in nVMs, is greater than zero, before trying to use any vmBuf entries.

JDK 17 introduced a performance improvement that made OCSP clients unconditionally use GET requests for small requests, while doing POST requests for everything else. This is explicitly allowed and recommended by RFC 5019 and RFC 6960. However, we have seen OCSP responders that, despite RFC requirements, are not working well with GET requests.

This release introduces a new JDK system property to allow clients to fallback to POST-only behavior. This unblocks interactions with those OCSP responders through the use of -Dcom.sun.security.ocsp.useget={false,true}. This amends the original change that introduced GET OCSP requests (JDK-8179503). The default behavior is not changed; the option defaults to true. Set the option to false to disable GET OCSP requests. Any value other than false (case-insensitive) defaults to true.

This option is non-standard, and might go away once problematic OCSP responders get upgraded.

Native PKCS11 mechanisms which support decryption but not encryption, or signature verification but not signing, are considered legacy and are disabled by default. The legacy mechanism check in SunPKCS11 provider is enhanced with the service type. For example, prior to this fix, a mechanism supporting encryption, decryption, and verification but not signing, is considered legacy and can't be used at all. After this fix, the corresponding Cipher service using this mechanism is available since both encryption and decryption are supported. However, the corresponding Signature service is not since only verification is supported. To bypass the legacy mechanism check, set the PKCS11 provider configuration attribute "allowLegacy" to true. The default value is false. Note that it is the caller's responsibility to make sure the legacy mechanism is not used for the unsupported functionality.

As announced in 2020, support for JavaFX on JDK 8, the last commercially supported version of JavaFX from Oracle, ended in March 2025. JDK 8 update 451 is the first upgrade of JDK/JRE 8 without JavaFX. Oracle continues to develop and release JavaFX as stand-alone modules via the OpenJFX project for the latest versions of Java only. For more details see the Java SE Spring 2024 Roadmap Update. Please contact Oracle Sales if you have any additional needs.

The JDK will stop trusting TLS server certificates issued after April 15, 2025 and anchored by Camerfirma root certificates, in line with similar plans announced by Google, Mozilla, Apple, and Microsoft.

TLS server certificates issued on or before April 15, 2025 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 are 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 April 15, 2025.

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

"TLS Server certificate issued after 2025-04-15 and anchored by a distrusted legacy

Camerfirma root CA: CN=Chambers of Commerce Root - 2008, O=AC Camerfirma S.A., 
SERIALNUMBER=A82743287, L=Madrid (see current address at www.camerfirma.com/address), C=EU"

The JDK can be configured to trust these certificates again by removing "CAMERFIRMA_TLS" from the jdk.security.caDistrustPolicies security property in the java.security configuration file.

The restrictions are imposed on the following Camerfirma 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.

The JarInputStream class now treats a signed JAR as unsigned if it detects a second manifest within the first two entries in the JAR file. A warning message "WARNING: Multiple MANIFEST.MF found. Treat JAR file as unsigned." is logged if the system property, -Djava.security.debug=jar, is set.

On Solaris, the CKM_TLS_KEY_AND_MAC_DERIVE mechanism offered by the SunPKCS11-Solaris provider and specific to TLSv1.0, can derive incorrect key data causing TLSv1.0 communication failure. That mechanism has been disabled via the $JAVA_HOME/jre/lib/security/sunpkcs11-solaris.cfg configuration file. The JCE provider now manages these cryptographic requests.

The ClassLoadingMXBean::setVerbose(boolean enabled) method will set class+load* logging on log output stdout to level info if enabled is true, and to level off otherwise. In contrast, the isVerbose method would check if exactly class+load logging was enabled at the info level on _any_ log output. This could result in counter-intuitive behavior when logging class+load=info to a file via the command-line, as it caused isVerbose to return true, even after a call to setVerbose(false) had been made. A similar problem existed for the MemoryMXBean::isVerbose method. Starting with this release, the behavior is as follows:

• ClassLoadingMXBean::isVerbose will return true only if class+load* logging (note the wildcard use) has been enabled at the `info` level (or above) on the stdout log output.
• MemoryMXBean::isVerbose will return true only if gc logging has been enabled at the info level (or above) on the stdout log output.

On Windows, the ProcessBuilder has expanded the quoting of argument strings when starting a process to ensure they are recognized by the application as a single command argument. The set of space characters has been expanded from space (0x20) to include all space characters as defined by java.lang.Character.isSpaceChar, which includes all Unicode space separator characters, such as EN-SPACE (0x2002), and line separator and paragraph separator characters.

IANA Time Zone Database has been upgraded to 2024b. This version mainly includes changes to improve historical data for Mexico, Mongolia, and Portugal. It also changes one timestamp abbreviation, for the time zone 'MET'. Also Asia/Choibalsan is now an alias for Asia/Ulaanbaatar.

The new tzdata changes also impact some legacy time zone IDs. As per 2024b changes "EST" links to "America/Panama", "HST" links to "Pacific/Honolulu" and "MST" links to "America/Phoenix". To maintain compatibility with the Java SE specification, the java.time.ZoneId.SHORT_IDS Map has not changed. Further details are available at JDK-8342331

Starting from 8u441, the JDK and JRE installation process has been updated, resulting in a change to how registry settings are configured.

Specifically, the registry key, HKEY_CURRENT_USER\SOFTWARE\JavaSoft\DeploymentProperties, is no longer created during a clean installation, such as when no previous Java versions are present.

This change impacts applications that previously relied on this key. Users may need to adjust their application configuration to account for the updated behavior.

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 $JAVA_HOME/jre/lib/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.

There are some scenarios where upgrading from a JRE version 8u361 or below to a newer JRE version of Java 8 may break some of the Windows registry keys for the Java Runtime Environment. The Java Uninstall Tool will repair such situations, regardless if a JRE is selected for uninstall or not.

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].

In a rare case, the C2 compiler attempts to apply the split-if loop optimization indefinitely. This regression manifests as continued high CPU use by C2 compiler threads.

The issue is fixed in 8u431. If the issue is encountered in 8u401, 8u411 or 8u421, the VM flag ``-XX:-SplitIfBlocks``, which disables this optimization, can be used as a workaround.

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.