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.

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.

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.

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.

The java.net.http.HttpClient will now report HTTP/2 flow control errors to the server when they are detected. This is an implementation detail that should be transparent to users of the HttpClient API, but could result in streams being reset or connections being closed if connecting to a non-conformant HTTP/2 server.

The flow control limits enforced by the client can be specified with two system properties, which can be set on the java command line:

• jdk.httpclient.connectionWindowSize specifies the HTTP/2 client connection window size in bytes. The default value, if unspecified, is 2^26. Valid values are in the range [2^16-1, 2^31-1]. If an invalid value is provided, the default value is used. The implementation guarantees that the actual value will be no smaller than the stream window size, which can be configured through the jdk.httpclient.windowsize system property.

• jdk.httpclient.windowsize specifies the HTTP/2 client stream window size in bytes. The default value if unspecified is 16777216 or 16 MB. Valid values are in the range [2^14, 2^31-1]. If an invalid value is provided, the default value is used.

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

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. Its default value only allows object factories defined in the java.naming module.

• 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. Its default value only allows object factories defined in the jdk.naming.rmi module.

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

The Local Computer key store is accessed using the CERT_STORE_MAXIMUM_ALLOWED_FLAG. Since this store is typically managed by administrators for security reasons, processes are only given read-only access to specific private keys. By opening the store in read-only mode, non-elevated processes can now securely use these keys without requiring elevated permissions.

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.

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.

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 XPath processor prevents evaluation of external DTD references in raw XML documents if secure processing is enabled explicitly, such as follows:

XPathFactory xf = XPathFactory.newInstance();

xf.setFeature(XMLConstants.FEATURE_SECURE_PROCESSING, true);

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 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:

xf.setProperty(ACCESS_EXTERNAL_DTD, "file");

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.