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.

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.

A new system property, beans.defaultmethods, has been introduced to disable Bean Introspection from reporting default methods inherited from interfaces. Set the value of the beans.defaultmethods property to false, for example, by adding -Dbeans.defaultmethods=false to the command line, to exclude default methods.

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.

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.