JDK 25 Early-Access Release Notes

File.delete is changed on Windows so that it now fails and returns false for regular files when the DOS read-only attribute is set. Prior to JDK 25, File.delete deleted read-only files by removing this DOS attribute before attempting to delete. As removing the attribute and deleting the file do not comprise a single atomic operation, this could result in the file still existing but with modified attributes if the deletion were to fail. Applications that depend on long standing behavior should be changed to clear the file attributes prior to deletion.

As part of the change, a system property has been introduced to restore long standing behavior. Running with -Djdk.io.File.allowDeleteReadOnlyFiles=true will restore old behavior so that File.delete removes the DOS read-only attribute before attempting to delete the file.

The jwebserver tool is updated to allow the -d and --directory command line options, configuring the directory to serve, to accept a directory specified with a relative path. This is made available both when jwebserver is invoked as an executable:

jwebserver --directory some/relative/path

and as a module:

java --module jdk.httpserver --directory some/relative/path

As earlier, -d and --directory command line options also still support absolute paths.

In the Java source code, character literals can only contain a single UTF-16 character. The javac compiler was incorrectly accepting character literals consisting of two UTF-16 surrogate characters, only using the first surrogate, and ignoring the second surrogate. This has now been corrected, and javac will produce a compile-time error when it detects a character literal which consists of two UTF-16 surrogate characters.

The output for -Xprint has been updated to include bounds for type variables and java.lang.Object as a supertype if the supertype is annotated.

For example, this code:

public class PrintingTest<T extends CharSequence> extends @TA Object {
}

the newly produced output is:

$ java -Xprint PrintingTest.java
public class PrintingTest<T extends java.lang.CharSequence> extends java.lang.@TA Object {

  public PrintingTest();
}

The password-based SecretKeyFactory implementations from the SunJCE provider used to reject non-ASCII passwords. They have been enhanced to use UTF-8 and thus allow Unicode characters to be used as passwords.

The java.net.http.HttpClient will now reject HTTP/2 responses that contain header fields prohibited by the HTTP/2 specification (RFC 9113). This is an implementation detail that should be transparent to the users of the HttpClient API, but could result in failed requests if connecting to a non-conformant HTTP/2 server.

The headers that are now rejected in HTTP/2 responses include:

• connection-specific header fields (Connection, Proxy-Connection, Keep-Alive, Transfer-Encoding, and Upgrade)
• request pseudo-header fields (:method, :authority, :path, and :scheme)

Two new MessageDigest algorithms, SHAKE128-256 and SHAKE256-512, have been added to the SUN provider. These are fixed-length versions of the SHAKE128 and SHAKE256 Extendable-Output Functions (XOFs) defined in NIST FIPS 202.

Starting with JDK 21, the SunPKCS11 provider added several password-based SecretKeyFactory implementations, e.g.

• SecretKeyFactory.PBEWithHmac[MD]AndAES_128
• SecretKeyFactory.PBEWithHmac[MD]AndAES_256
• SecretKeyFactory.HmacPBE[MD]

where [MD] is one of the SHA1, SHA224, SHA256, SHA384, and SHA512 algorithms.

However, the key objects produced by these implementations use the PBKDF2-derived values as key encodings. This is different than the SunJCE counterparts which use the password bytes as key encodings. These differences can be very confusing and may cause interoperability issues since both keys have the same algorithm and format, but different encodings. Thus, for consistency sake, these SunPKCS11 password-based SecretKeyFactory implementations have been removed.

Prior to JDK 25, the javac compiler was allowing the type of lambda expressions to be classes in some cases. This implies that the javac compiler was accepting code like:

    class Test {
        void m() {
            Test r = (Test & Runnable) () -> System.out.println("Hello, World!");
        }
    }

Starting from JDK 25 the javac compiler will reject lambda expressions which type is a class

Restrictions on extension functions has been removed in the XPath API, specifically those imposed by FEATURE_SECURE_PROCESSING (FSP) and the jdk.xml.enableExtensionFunctions property. Previously, for extension functions to work, even with a user-defined XPathFunctionResolver, FSP had to be set to false and jdk.xml.enableExtensionFunctions true. For example, an XPath created via the following factory would fail with an XPathExpressionException when encountering an Extension Function:

        XPathFactory xpf = XPathFactory.newInstance();
        xpf.setFeature(XMLConstants.FEATURE_SECURE_PROCESSING, true);

With this change, extension functions now work solely based on the presence of a properly registered XPathFunctionResolver, making extension straightforward:

        XPathFactory xpf = XPathFactory.newInstance();
        xpf.setXPathFunctionResolver(new MyXPathFunctionResolver());

The default value of FSP has also been changed from false to true. Since extension functions are no longer governed by this setting, and the default XPath limits already conform to the secure configurations, this update has no effect on standard XPath behavior.

A new system property stdin.encoding has been added. This property contains the name of the recommended Charset for reading character data from System.in, for example, when using InputStreamReader or Scanner. By default, the property is set in a system-specific fashion based on querying the OS and user environment. Note that its value may differ from the value of the file.encoding property (the default Charset) and the value of the native.encoding property. The value of stdin.encoding may be overridden to be UTF-8 by providing the argument -Dstdin.encoding=UTF-8 on the command line.

The following root certificates, which are terminated and no longer in use, have been removed from the cacerts keystore:

+ alias name "camerfirmachamberscommerceca [jdk]"
  Distinguished Name: CN=Chambers of Commerce Root, OU=http://www.chambersign.org, O=AC Camerfirma SA CIF A82743287, C=EU

+ alias name "camerfirmachambersignca [jdk]"
  Distinguished Name: CN=Global Chambersign Root - 2008, O=AC Camerfirma S.A., SERIALNUMBER=A82743287, L=Madrid (see current address at www.camerfirma.com/address), C=EU

JavaDoc now treats classes and interfaces from packages that are not exported or exported by qualified export as hidden unless they are explicitly included in the documentation. Such classes and interfaces do not appear in the generated documentation, even if they are extended or implemented by a documented type. Other instances of hidden types are private or package-private types, or types marked with the @hidden JavaDoc tag.

A new connectionLabel method has been added to java.net.http.HttpResponse. This new method returns an opaque connection label that callers can leverage to associate a response with the connection it is carried on. This is useful to determine whether two requests were carried on the same connection or on different connections.

The option UseCompressedClassPointers is deprecated in Java 25 and will be removed in a future Java version.

This option was used to switch between two modes:

• The compressed class pointer mode (-XX:+UseCompressedClassPointers, default if the switch is not specified)
• The uncompressed class pointer mode (-XX:-UseCompressedClassPointers)

The uncompressed class pointer mode will be removed in a future version of Java; since that only leaves the default compressed class pointer mode, the switch will also be removed.

The uncompressed class pointer mode causes the JVM to use more memory. It serves very little purpose today.

The default compressed class pointer mode causes the JVM to place classes into the class space; the class space is limited by default to 1GB and can hold up to ~1.5 million classes. In the rare case that an application must load more than that, the class space can be extended up to 4 GB with -XX:CompressedClassSpaceSize . That increases the number of classes the class space can hold to ~6 million classes.

Note that these numbers are extremely high; it is rare even for a huge Java application to even load more than 100,000 classes. If your application loads significantly more classes than that, it is very likely a pathological situation, such as a class loader leak.

The class space is reserved up front when the JVM starts. However, that memory is virtual: no actual memory is used until classes are loaded, and then, only as many pages are allocated as are needed to hold the class data.

If your application specifies -XX:+UseCompressedClassPointers, remove that option. It is superfluous since enabling compressed class pointers is the default.

If your application specifies -XX:-UseCompressedClassPointers, remove that option. In all likelihood, the application will just continue to work. Should the application exhaust the class space, you may want to examine whether that situation is pathological. If it is not pathological, increase the class space to 4GB using -XX:CompressedClassSpaceSize=4g.

The desktop module provides the ICC_Profile class used in Color Management for image processing applications. Previously an ICC_Profile instance would always allow an application to modify the raw color profile data which the ICC_Profile encapsulates. However instances of this class provided by the desktop module itself are shared and should never be modified. JDK now enforces this restriction on these shared instances. As a result, application code which tries to do this will cause a Java Exception to be thrown.

The SHA-1 algorithm has been disabled by default in TLS/DTLS 1.2 handshake signatures, by adding "rsa_pkcs1_sha1 usage HandshakeSignature, ecdsa_sha1 usage HandshakeSignature, dsa_sha1 usage HandshakeSignature" to the jdk.tls.disabledAlgorithms security property in the java.security config file. RFC 9155 deprecates the use of SHA-1 in TLS & DTLS 1.2 digital signatures. Users can, at their own risk, re-enable the SHA-1 algorithm in TLS/DTLS 1.2 handshake signatures by removing "rsa_pkcs1_sha1 usage HandshakeSignature, ecdsa_sha1 usage HandshakeSignature, dsa_sha1 usage HandshakeSignature" from the jdk.tls.disabledAlgorithms security property.

The performance of the ML-DSA key generation, sign and verify operations has been improved significantly (1.5x - 2.5x depending on operation type and input) on the aarch64 and AVX-512 platforms.

The following permission classes have been deprecated for removal:

• java.security.UnresolvedPermission
• javax.net.ssl.SSLPermission
• javax.security.auth.AuthPermission
• javax.security.auth.PrivateCredentialPermission
• javax.security.auth.kerberos.DelegationPermission
• javax.security.auth.kerberos.ServicePermission
• com.sun.security.jgss.InquireSecContextPermission
• java.lang.RuntimePermission
• java.lang.reflect.ReflectPermission
• java.io.FilePermission
• java.io.SerializablePermission
• java.nio.file.LinkPermission
• java.util.logging.LoggingPermission
• java.util.PropertyPermission
• jdk.jfr.FlightRecorderPermission
• java.net.NetPermission
• java.net.URLPermission
• jdk.net.NetworkPermission

In addition, the getPermission method defined in java.net.URLConnection and its subclass java.net.HttpURLConnection has been deprecated for removal.

These permission classes and associated methods were only useful in conjunction with the Security Manager, which is no longer supported.

When providing a class with JVMTI ClassFileLoadHook, the new bytecodes are verified with the Class File Verifier even if they are provided on the bootclass path, and regardless of the setting of the deprecated -Xverify option.

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 the algorithm in TLS handshake signatures. CertificateSignature restricts the use of the 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.

Under some conditions, javac could have modified jar or zip files places on the classpath, by writing classfile(s) to them.

The specific conditions are:

• no output directory specified (i.e. no -d option)
• no -sourcepath specified
• the jar or zip file on the classpath contains source file(s), which are compiled implicitly

This is no longer the case. Classfiles will never be written to jar or zip files, and those that would be written into the jar or zip file will be placed to the current working directory. This mimics the JDK 8 behavior.

The java.locale.useOldISOCodes system property has been deprecated. Introduced in JDK 17, it allowed users to revert to the legacy ISO 639 language codes for Hebrew, Indonesian, and Yiddish. Since its purpose was to facilitate a transition to the updated codes, we believe it is now time to retire it. In JDK 25, setting this property to true has no effect, and a warning about its future removal is displayed at runtime.

The default Console obtained via System.console() is no longer based on JLine. Since JDK 20, the JDK has included a JLine-based Console implementation, offering a richer user experience and better support for virtual terminal environments, such as IDEs. This implementation was initially opt-in via a system property in JDK 20 and JDK 21 and became the default in JDK 22. However, maintaining the JLine-based Console proved challenging. As a result, in JDK 25, it has reverted to being opt-in, as it was in JDK 20 and JDK 21.

In Java programs, every instance of an inner class has an immediately enclosing instance. When an inner class is instantiated with the new keyword, the immediately enclosing instance is passed to the inner class's constructor via a parameter not visible in source code. The Java Language Specification (§15.9.4) requires that the immediately enclosing instance is not null.

Prior to JDK 25, javac inserted a null check on the immediately enclosing instance before it was passed to the inner class's constructor. No null check was performed in the body of the inner class's constructor. As a result, it was possible to use core reflection, e.g., java.lang.reflect.Constructor::newInstance, or specially crafted class files to invoke an inner class's constructor with null as the immediately enclosing instance. This could lead to unexpected program failures.

In JDK 25, javac inserts an additional null check on the immediately enclosing instance. This check occurs in the body of the inner class's constructor. As a result, there is no way to instantiate an inner class with null as the immediately enclosing instance.

In the extremely rare case of needing to run legacy code that passes null as the immediately enclosing instance, developers can, at their own risk, use the unsupported option -XDnullCheckOuterThis=false. This prevents javac from inserting the additional null check in inner class constructor bodies.

This release removes old object monitor performance counters, exposed in the sun.rt._sync* namespace. These counters were seldom used, and they contributed to performance problems in related VM code. Users who want to track monitor performance are advised to use related JFR events instead.

The suggested replacements are:

• _sync_ContendedLockAttempts: JavaMonitorEnter JFR event
• _sync_FutileWakeups: no replacement
• _sync_Parks: JavaMonitorWait JFR event
• _sync_Notifications: JavaMonitorNotify JFR event
• _sync_Inflations: JavaMonitorInflate JFR event
• _sync_Deflations: JavaMonitorDeflate JFR event
• _sync_MonExtant: JavaMonitorStatistics JFR event

The locale data based on the Unicode Consortium's CLDR has been upgraded to version 47. Besides the usual addition of new locale data and translation changes, there are notable changes from the upstream CLDR, affecting Date/Time/Number formattings:

• CLDR-9791: Add language for South Georgia and Bouvet Islands (#4166)
• CLDR-16821: Fix Australian time zone names (#4301)
• CLDR-17484: English day periods are wrong (#4375)
• CLDR-18099: Add European English locales with data (#4276, (#4302)
• CLDR-18268: Add timeData for GS (#4319)

Note that locale data is subject to change in a future release of the CLDR. Although not all locale data changes affect the JDK, users should not assume stability across releases. For more details, please refer to the Unicode Consortium's CLDR release notes and their locale data deltas.

The following expired root certificate has been removed from the cacerts keystore:

+ alias name "baltimorecybertrustca [jdk]"
  Distinguished Name: CN=Baltimore CyberTrust Root, OU=CyberTrust, O=Baltimore, C=IE

API documentation generated by javadoc no longer sets the keyboard focus to the search input field on page load. Instead, it provides keyboard shortcuts to manage keyboard focus. Press the / key to set the focus on the search input, the . key to set the focus on the filter input in the sidebar, and the Esc key to release the focus from either input field. Furthermore, content in the sidebar and search page can now be navigated using the Tab and arrow keys.

The JMX class javax.management.modelmbean.DescriptorSupport represents MBean metadata, and has a constructor and a method providing creation from, and export to, XML. These are unused in the JDK and have no commonly known wider usage, and are deprecated for removal. The class javax.management.modelmbean.XMLParseException which is only thrown by DescriptorSupport, is also deprecated for removal. This will have no impact on JMX features in general.

Calling Calendar.computeTime() with a Japanese Imperial Calendar for a Calendar.ERA field value that is too large now throws IllegalArgumentException instead of ArrayIndexOutOfBoundsException. Thus, any operations requiring time recomputation for a Japanese Imperial Calendar are now affected. For example, at the time of this release note, new Calendar.Builder().setCalendarType("japanese").set(Calendar.ERA, 6).build() now throws IllegalArgumentException.

The java.io.File class is changed so that an instance of File created from the empty abstract pathname ("") now behaves consistently like a File created from the current user directory. Long standing behavior was for some methods to fail for the empty pathname. The change means that the canRead, exists and isDirectory methods return true instead of failing with false, and the getFreeSpace, lastModified and length methods return the expected values instead of zero. Methods such as setReadable and setLastModified will attempt to change the file's attributes instead of failing. WIth this change, java.io.File now matches the behavior of the java.nio.file API.

On Debian-based Linux distributions such as Ubuntu, the /etc/timezone file was previously used to determine the JDK's default time zone (TimeZone.getDefault()). According to Debian's Wiki, /etc/localtime is now the primary source for the system's default time zone, making /etc/timezone redundant. As a result, the JDK's default time zone detection logic has been updated to use /etc/localtime instead of /etc/timezone. If /etc/localtime and /etc/timezone are inconsistent for any reason, the JDK's default time zone is now determined solely based on /etc/localtime file.

The specifications of the substring, subSequence, and toString methods of the StringBuilder and StringBuffer classes have changed not to require a new String instance to be returned every time. This allows implementations to improve performance by returning an already-existing string, such as the empty string, when that is appropriate. In all cases, a String containing the expected value will be returned. However, applications should not depend on these methods to return a new String instance every time.

An API note has been added to the getCertificates() method of the java.util.jar.JarEntry and java.net.JarURLConnection classes and the getCodeSigners() method of the JarEntry class recommending that the caller should perform further validation steps on the code signers that signed the JAR file, such as validating the code signer's certificate chain, and determining if the signer should be trusted.

In addition, the JarURLConnection.getCertificates() method has been updated to specify the order of the returned array of certificates. It is the same order as specified by java.util.jar.JarEntry.getCertificates().

The JDK will stop trusting TLS server certificates issued after April 15, 2025 and anchored by Camerfirma root certificates, in line with similar plans announced by Google, Mozilla, Apple, and Microsoft.

TLS server certificates issued on or before April 15, 2025 will continue to be trusted until they expire. Certificates issued after that date, and anchored by any of the Certificate Authorities 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 April 15, 2025.

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

"TLS Server certificate issued after 2025-04-15 and anchored by a distrusted legacy Camerfirma root CA: CN=Chambers of Commerce Root - 2008, O=AC Camerfirma S.A., SERIALNUMBER=A82743287, L=Madrid (see current address at www.camerfirma.com/address), C=EU"

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

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

Some very old JMX System Properties have been removed. These were compatibility aids that were intended as transitional, for later removal. New behaviour will be the same as current behaviour with the property unset. The removals are:

jmx.extend.open.types which was provided to aid compatibility, since overriding javax.management.openmbean.OpenType.getClassName() was made illegal in JDK 6.

jmx.invoke.getters introduced in JDK 6 for compatibility with code which depended on previous incorrect behaviour, calling invoke on getters and setters.

jdk.jmx.mbeans.allowNonPublic which was introduced in JDK 8 for compatibility with previous incorrect behaviour where it was not enforced that MBean and MXBean interfaces must be public.

jmx.mxbean.multiname which was introduced in JDK 7 for compatibility with code which may have depended on previous incorrect behaviour relating to multiple registrations of an MXBean object.

jmx.tabular.data.hash.map which was for compatibility with JDK 1.3 clients due to use of LinkedHashMap.

jmx.remote.x.buffer.size as a System Property and a JMX environment property. The correct name was always jmx.remote.x.notification.buffer.size and was correct from JDK 6, but the alternate name was recognised to aid compatibility.

In JDK 21, an enhanced syntax for various timeout properties was released through JDK-8179502. This included a new system property, com.sun.security.ocsp.readtimeout, which allows users to control the timeout while reading OCSP responses after a successful TCP connection has been established.

This changes the default posture of this property to be the value of the com.sun.security.ocsp.timeout system property from its original default of 15 seconds. If the com.sun.security.ocsp.timeout system property is also not set, then its default 15 second timeout is propagated to the default for com.sun.security.ocsp.readtimeout.

Two new methods java.net.http.HttpResponse.BodyHandlers.limiting(BodyHandler downstreamHandler, long capacity) and java.net.http.HttpResponse.BodySubsribers.limiting(BodySubscriber downstreamSubscriber, long capacity) are added to the HttpClient API. These methods extend an existing BodyHandler or BodySubscriber with the ability to limit the number of response body bytes that the application is willing to accept in response to an HTTP request. Upon reaching the limit when reading the response body, an IOException will be raised and reported to the downstream subscriber. The subscription will be cancelled, and any further response body bytes will be discarded. This makes it possible for the application to control the maximum amount of bytes that it wants to accept from the server.

java.util.zip.Inflater and java.util.zip.Deflater now implement AutoCloseable and can be used with the try-with-resources statement. Applications could previously invoke the end() method to release the resources held by the Inflater/Deflater instance. Now, either the end() or the close() method can be invoked to do the same.

Starting with JDK 25, jpackage will no longer include service bindings for a run-time image that it creates. Prior to JDK 25, jpackage would include service bindings for run-time images. As a result, the generated run-time images produced by jpackage might not include the same set of modules as it did in prior versions.

The previous behavior can be achieved with the jpackage of JDK 25 by adding the --bind-services jlink option to the default jlink options jpackage uses:

jpackage [...] --jlink-options 
   "--strip-native-commands --strip-debug --no-man-pages --no-header-files --bind-services"

TLSv1.3 and CNSA 1.0 algorithms have been added to the list of cryptographic requirements all Java SE implementations must support. All cryptographic algorithms that are needed to implement the TLSv1.3 cipher suites and signature mechanisms and that are defined by RFC 8446 as MUST or SHOULD requirements have been added. All algorithms that are required by CNSA 1.0 have also been added. No required algorithms or protocols are being removed at this time.

The following requirements have been added to the Security Algorithm Implementation Requirements section of the Java Security Standard Algorithm Names specification and to the class summary of each of the APIs below.

• AlgorithmParameters

  • ChaCha20-Poly1305
  • EC with secp256r1 or secp384r1 curves
  • RSASSA-PSS with MGF1 mask generation function and SHA-256 or SHA-384 hash algorithm

• Cipher

  • AES/GCM/NoPadding with 256 bit key size
  • ChaCha20-Poly1305

• KeyAgreement

  • ECDH with secp256r1 or secp384r1 curves
  • X25519

• KeyFactory

  • EC
  • RSASSA-PSS
  • X25519

• KeyGenerator

  • AES with 256 bit key size
  • ChaCha20

• KeyPairGenerator

  • DH with 3072 bit key size
  • EC with secp256r1 or secp384r1 curves
  • RSA with 3072 bit key size
  • RSASSA-PSS with 2048, 3072, 4096 bit key sizes
  • X25519

• MessageDigest

  • SHA-384

• Signature

  • RSASSA-PSS with MGF1 mask generation function and SHA-256 or SHA-384 hash algorithm
  • SHA256WithECDSA with secp256r1 curve
  • SHA384WithECDSA with secp384r1 curve
  • SHA384WithRSA

• SSLContext

  • TLSv1.3

The default thread pool for the system-wide default AsynchronousChannelGroup is changed to create threads that do not inherit anything from threads that initiate asynchronous I/O operations. Historically, threads in the default thread pool inherited the Thread Context ClassLoader (TCCL) and inheritable-ThreadLocals from the first thread to initiate an asynchronous I/O operation. The change in this release avoids potential memory leak and retention issues that arose when a TCCL or a thread local kept a large graph of objects reachable.

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.