RELEASE NOTES: JDK 25.0.3

Distrust TLS Server Certificates Anchored by Chunghwa Root Certificates and Issued After March 17, 2026

The JDK will stop trusting TLS server certificates issued after March 17, 2026 and anchored by Chunghwa root certificates, in line with similar plans announced by Google and Mozilla.

TLS server certificates issued on or before March 17, 2026 will continue to be trusted until they expire. Certificates issued after that date, and anchored by the Certificate Authority listed 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 March 17, 2026.

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

` "TLS Server certificate issued after 2026-03-17 and anchored by a distrusted legacy Chunghwa root CA: OU=ePKI Root Certification Authority, O="Chunghwa Telecom Co., Ltd." C=TW" `

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

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

JFR: ThreadDump and ClassLoaderStatistics events may cause back to back rotations

The jdk.ThreadDump event is currently written when a chunk begins and ends (everyChunk), but when it is written at the beginning, it may trigger another rotation within 1 second. This can cause other relevant data to be flushed out very quickly, e.g. 15 seconds if using the default max size of 250 MB.

Reproducer:

$ java Reproducer 1400 300 20

import java.util.concurrent.Semaphore; import jdk.jfr.Configuration; import jdk.jfr.Recording;

public class Reproducer { public static void main(String[] args) throws Exception { int threadCount = Integer.parseInt(args[0]); int stackDepth = Integer.parseInt(args[1]); int sleepTime = Integer.parseInt(args[2]); Semaphore semaphore = new Semaphore(0); for (int i = 0; i < threadCount; i++) { Thread t = new Thread(() -> stack(stackDepth, semaphore)); t.setDaemon(true); t.start(); } semaphore.acquire(threadCount); Configuration c = Configuration.getConfiguration("default"); try (Recording r = new Recording(c)) { r.start(); Thread.sleep(sleepTime * 1000); } }

static void stack(int depth, Semaphore semaphore) {
    if (depth > 0) {
        stack(depth - 1, semaphore);
    }
    if (depth == 0) {
        semaphore.release();
        try {
            Thread.sleep(Long.MAX_VALUE);
        } catch (InterruptedException ignored) {}
    }
}

}

Short-term, we could change the implementation so that jdk.ThreadDump and jdk.ClassLoaderStatistics are only emitted when a recording starts and a chunk ends. Such a change may be suitable for backporting.

Longer-term, we might want to address this in a more generic way so that it cannot occur with other events as well, including user-defined ones. Three alternatives:

1) Redefine "everyChunk" so that it only emits when a recording starts and when a chunk ends. 2) Create a new keyword, e.g. "rotation", with the same semantics as option 1, but keep "everyChunk" as is. 3) Broaden the setting so it can accept a combination of recording- or chunk-specific settings.

Regardless of approach, the new semantics must support cases where two recordings are in use at the same time with different settings.

Reduced frequency of JFR events jdk.ThreadDump and jdk.ClassLoaderStatistics

In applications with many threads (typically more than 1,000) and deep Java stacks (typically more than 300 frames), the jdk.ThreadDump event can become large enough to trigger a recording file rotation by itself. This can cause other events to be removed earlier than expected by the retention policy. A similar issue occurs for the jdk.ClassLoaderStatistics event in applications that use several hundred thousand class loaders.

To avoid back-to-back rotations in the default configuration (default.jfc), the jdk.ThreadDump and jdk.ClassLoaderStatistics events are now written only when a recording starts and at the end of a file rotation. They are no longer written at the beginning of a new file created by rotation.

New Security Property jdk.crypto.disabledAlgorithms for Restricting Algorithms at the JCE layer

A new security property named jdk.crypto.disabledAlgorithms has been introduced to disable algorithms for JCE/JCA cryptographic services. Initially, this property only supports the Cipher, KeyStore, MessageDigest, and Signature services. This property is defined in the java.security file and initially no algorithms are disabled by default. However, this may change in the future. This security property can be overridden by a system property of the same name if applications need to re-enable algorithms.

See Disabled and Restricted Cryptographic Algorithms for more information.

Enhanced keytool Password Handling When Output Is Redirected

The [keytool] command reads passwords from the system console to prevent them from being displayed on the screen. However, the console is usually available only when both the standard input and output streams are not redirected. Previously, if the standard output stream was redirected into a file or another command, the console was unavailable and the input password was echoed on the screen. This enhancement improves password handling to ensure that the password is not displayed on the screen even if the standard output stream is redirected. This enhancement has also been made to the [jarsigner] command and the JAAS [TextCallbackHandler] API.

G1: Support UseGCOverheadLimit

The G1 garbage collector now throws an OutOfMemoryException when the garbage collection overhead is more than GCTimeLimit percent (default value 98) and the free Java heap is less than GCHeapFreeLimit percent (default value 2) for five consecutive garbage collections.

This feature is enabled by default. It can be disabled using the -XX:-UseGCOverheadLimit option.

The implementation mirrors the functionality already provided by the Parallel garbage collector. However there may be differences in the exact conditions for the OOME triggers as G1 calculates garbage collection overhead and free Java heap slightly differently.