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.