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