1. Language Previews

2. Performance and Runtime

3. Libraries

3.1 Security Libraries

4. Removals and Warnings for Future Changes

The static factory method java.io.Reader.of(CharSequence) has been added to get a Reader that reads characters from a CharSequence, String and StringBuilder are examples of a CharSequence. The returned Reader is more efficient than using a java.io.StringReader in some cases, as the latter requires conversion to String and synchronization.

This release upgrades the Unicode version to 16.0, which includes updated versions of the Unicode Character Database and Unicode Standard Annexes #9, #15, and #29:

• The java.lang.Character class supports the Unicode Character Database, which adds 5,185 characters, for a total of 154,998 characters. The new additions include seven new scripts:
  • Garay is a modern-use script from West Africa.
  • Gurung Khema, Kirat Rai, Ol Onal and Sunuwar are four modern-use scripts from Northeast India and Nepal.
  • Todhri is an historic script used for Albanian.
  • Tulu-Tigalari is an historic script from Southwest India.
• The java.text.Bidi and java.text.Normalizer classes support Unicode Standard Annexes, #9 and #15, respectively.
• The java.util.regex package supports Extended Grapheme Clusters based on the Unicode Standard Annex #29.

For more details about Unicode 16.0, refer to the Unicode Consortium’s release note.

A new, overloaded method, java.lang.Process#waitFor(Duration), has been added. The existing waitFor() method with timeout needs both a primitive time out value and its unit. The new method uses java.time.Duration so that the user will not be confused with the unit.

The jar tool's extract operation has been enhanced to allow the --keep-old-files and the -k options to be used in preventing the overwriting of existing files.

Examples:

jar xkf foo.jar

or

jar --extract --keep-old-files --file foo.jar

Either of these commands will extract the contents of foo.jar. If an entry with the same name already exists in the target directory, then the existing file will not be overwritten.

A new, JDK-specific monitoring and management interface, jdk.management.VirtualThreadSchedulerMXBean, has been added to allow Java Management Extension (JMX) based tooling to monitor and manage the virtual thread scheduler. The interface supports monitoring the virtual thread scheduler's target parallelism, the threads used by the scheduler, and the number of virtual threads queued to the scheduler. It also supports dynamically changing the scheduler's target parallelism.

Two commands have been added to the jcmd command line tool to print information that may be useful when diagnosing issues with virtual threads.

jcmd <pid> Thread.vthread_scheduler prints the virtual thread scheduler, the target parallelism, number of threads, and other useful counters. The output also includes the delayed task schedulers that support virtual threads doing timed operations.

jcmd <pid> Thread.vthread_pollers prints the I/O pollers that support virtual threads doing blocking network I/O operations.

For more details, see the jar command man page.

The java.security security properties file, and those referred to by the java.security.properties system property, now support including other properties files. The directive include <path-to-a-file> can be used for this purpose. The effect of including a file is equivalent to defining its properties inline at the inclusion point. Find more information and examples in the Security Properties Files Inclusion section of the Security Developer Guide and in JDK-8319333.

As a result of this change, the name include can no longer be used to define a property in a security properties file. If the name include is passed to the java.security.Security::getProperty or ::setProperty APIs, an IllegalArgumentException is thrown.

A new section for PSSParameterSpec algorithm names has been added to the Java Security Standard Algorithm Names specification. This section lists the standard hash and message generation function (MGF) algorithms that can be specified when initializing an RSASSA-PSS signature with a PSSParameterSpec object.

The SunPKCS11 provider has been enhanced to support the following AES CTS transformations for the Cipher service type:

• AES/CTS/NoPadding
• AES_128/CTS/NoPadding
• AES_192/CTS/NoPadding
• AES_256/CTS/NoPadding

The Addendum to NIST Special Publication 800-38A defines three variants of Ciphertext Stealing for CBC mode: CBC-CS1, CBC-CS2, and CBC-CS3. To ensure interoperability with SunJCE and Kerberos, which use the CS3 variant, the SunPKCS11 provider needs to know the variant implemented by the underlying PKCS #11 library and convert the data if it is not in the CS3 variant. A new SunPKCS11 provider configuration attribute named cipherTextStealingVariant is introduced and must be set with any of the following values: CS1, CS2, or CS3, to indicate the CTS variant of the underlying PKCS #11 library. An exception exists for NSS as it is known to be CS1. Otherwise, the PKCS #11 CKM_AES_CTS mechanism is disabled.

For further information, see SunPKCS11 Configuration and SunPKCS11 Provider Supported Algorithms.

A new system property, jdk.tls.server.newSessionTicket, sets the number of TLSv1.3 resumption tickets sent by a JSSE server per session. It can be set on the command line with -Djdk.tls.server.newSessionTicket=#, where # ranges from 0 to 10. The default is 1.

For more details, see Customizing JSSE.

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 jar tool's extract operation has been enhanced to allow the --dir or the -C options to be used to specify the directory where the archive will be extracted.

Example Usages:

jar -xf foo.jar -C /tmp/bar/

or

jar --extract --file foo.jar --dir /tmp/bar/

Either of these commands will extract the foo.jar to the /tmp/bar directory.

For more details, see the jar command man page.

The API documentation contains a new summary page listing external specifications referenced by Java SE and JDK APIs. A link to the new summary page can be found in the Index page linked in the API documentation navigation bar.

For more details, see External Specifications.

jpackage can use WiX Toolset v4 and v5, in addition to v3, on Windows. It will automatically choose the newest installed version.

jpackage supports custom WiX sources in both WiX v3 and v4 formats. If WiX Toolset v4 or v5 is used, jpackage will automatically convert custom WiX sources in WiX v3 format to WiX v4 format.

The JDK built-in XML Catalog, introduced in JDK 22 with standard DTDs of the Java Platform, now includes the following DTDs and XSDs defined by W3C specifications. These DTDs and XSDs will be loaded locally from the XML Catalog, without requiring network access.

• The "xml:" Namespace
• XML Schema Part 1: Structures
• XML Schema Part 2: Datatypes
• XHTML™ 1.0 The Extensible HyperText Markup Language
• XHTML™ 1.1 Module-based XHTML
• XML DTD for W3C specifications

The JDK's java.desktop module has internal code that interoperates with multiple versions of the GTK platform library. This is primarily to support the Swing GTK LookAndFeel.

The JDK previously included support for interoperating with the GTK 2 version of the library, which is reaching the end of its life. GTK 3 long ago superseded it and is supported by the JDK as the preferred default. To use GTK 2, apps must request it using the jdk.gtk.version System property. And since many recent Linux distributions make GTK 2 only an optional install, it may require extra work to use it. Future Linux distributions will likely not provide any way to install it.

Since all versions of Linux to be supported by JDK 24 provide GTK3, GTK2 support in JDK is now removed.

Setting the jdk.gtk.version System property to 2 or 2.2 will no longer have any effect. GTK 3 will be loaded.

The JDK 1.1-compatible behavior for the "EST," "MST," and "HST" time zones has been removed. Previously, this behavior could be enabled using the sun.timezone.ids.oldmapping system property, but this property is no longer operational in this release. In general, the use of all legacy Three-letter time zone IDs is deprecated. Instead, use the corresponding region-based time zone IDs listed in ZoneId.SHORT_IDS.

The javax.naming.Context.APPLET constant, which has been deprecated since Java 9, has been removed from the javax.naming.Context class. Applications relying on this constant will require modification.

The JNDI environment property java.naming.rmi.security.manager is no longer supported. This property, used to request installation of the RMISecurityManager, is no longer effective. As the SecurityManager is removed, this property is no longer needed.

JNDI remote code downloading for LDAP and RMI providers is now permanently disabled. The com.sun.jndi.rmi.object.trustURLCodebase and com.sun.jndi.ldap.object.trustURLCodebase system properties are removed.

Some javax.management classes contained a feature for Serialization compatibility with very old JMX releases (1.0, 1.1, 1.2), which are from before JMX was an integrated part of the JDK (in JDK 5). This was enabled using the jmx.serial.form system property.

This compatibility logic offered no value, and only added complexity, so has been removed. This will not affect any JMX features, or any interactions between JMX features in different JDKs.

The java command no longer accepts the -t, -tm, -Xfuture, -checksource, -cs, and -noasyncgc options.

These options are henceforth treated as unrecognized and usage of any of these options will lead to an error resulting in a failure to launch java. Applications that were launching java with the -Xfuture option may consider using -Xverify:all in its place - the rest of the options have no replacements.

java.util.zip.ZipError has been deprecated for removal. This error class has been obsolete for many releases and has not been used by the reference implementation since Java 8.

Any existing code that used to throw java.util.zip.ZipError should consider throwing java.util.zip.ZipException instead. Code needing to catch this error when running on releases prior to Java 9 may be updated to catch the parent java.lang.InternalError class instead.

The jstatd tool is deprecated, for removal in a future release. jstatd is an RMI server application which monitors HotSpot VMs, and provides a remote interface for jstat. This will not affect use of jstat to read the performance counters from local VMs.

jrunscript tool has been deprecated and will be removed in a future release. Usage of this tool will now print a deprecation warning.

The jdk.jsobject module is deprecated, and will be removed in a future release. The jdk.jsobject module will instead be delivered with JavaFX 24 and later. To facilitate the transition, jdk.jsobject is now an upgradable module in the JDK. This allows applications to use the version of jdk.jsobject delivered with JavaFX in place of the one in the JDK to avoid the compiler warning.

A new, lightweight locking mechanism for object monitor locking was introduced in JDK 21 under JDK-8291555. The LockingMode flag was introduced to allow selection of this new mechanism, (LM_LIGHTWEIGHT, value 2), in place of the default mechanism, (LM_LEGACY, value 1). In JDK 23, the LockingMode default was changed to LM_LIGHTWEIGHT.

In JDK 24, the LockingMode flag, along with the LM_LEGACY (1) and LM_MONITOR (0) modes, are deprecated. The default locking mode, LM_LIGHTWEIGHT, will be the only internal implementation that is supported when these locking modes become obsolete in a future release.

This is not expected to change any semantic behavior of Java monitor locking and it is expected to be performance neutral for almost all applications.

The debugd subcommand of the jhsdb tool is deprecated, for removal in a future release. jhsdb debugd is an RMI server which provides a remote interface for other jhsdb commands. Those commands use the --connect option which is also deprecated for removal. This will not affect usage of jhsdb for debugging local VMs or core files.

The -verbosegc, -noclassgc, -verify, -verifyremote, -ss, -ms, and -mx options of the java command are deprecated for removal. Usage of any of these options when launching java will now log a deprecation warning.

Applications may consider replacing usages of these options with the following:

In previous releases, MethodTypeDesc.resolveConstantDesc threw an unchecked TypeNotPresentException instead of a checked ReflectiveOperationException when a component class was not found. This behavior is now corrected to throw a ClassNotFoundException, conforming to the specification.

Code that previously handled TypeNotPresentException in addition to ReflectiveOperationException can consolidate the exception handling into the existing ReflectiveOperationException handling.

Reflectively invoking VarHandle signature polymorphic methods is specified to throw UnsupportedOperationException. However, the implementation previously threw UnsatisfiedLinkError in such cases. The behavior was adjusted to conform to the specification.

Core reflection now throws a TypeNotPresentException instead of substituting a null value when encountering an undefined type variable in a generic signature. The previous incorrect behavior had been in place since the addition of generic signatures in JDK 5. The TypeNotPresentException::typeName method may return type variable names in addition to fully qualified names of classes.

DecimalFormat, when the format expects a suffix, now parses correctly when the parse value contains a decimal symbol and isParseIntegerOnly() would return true. Previously, parsing would fail for such cases and the correct value never returned.

For example, in the following snippet, 5 will now be returned by the parse(String) invocation, instead of a ParseException thrown.

    NumberFormat fmt = NumberFormat.getPercentInstance(Locale.US);

    fmt.setParseIntegerOnly(true);
    fmt.parse("500.55%");

Fixed the issue with entries in the "java" and "javac" groups not being properly managed during an RPM upgrade.

Upgrading from an older Java RPM installed into a shared directory (/usr/lib/jvm/jdk-${FEATURE}-oracle-${ARCH}) to a Java RPM installing into a version-specific directory (/usr/lib/jvm/jdk-${VERSION}-oracle-${ARCH}), results in the older Java entries in the "java" and "javac" groups not being deleted.

The issue does not manifest until the new Java is uninstalled. When it is uninstalled and Java from the lower release is installed, running Java commands like java or keytool without the full path specified will result in the "command not found" error. For example, install 21.0.3; upgrade it to 21.0.4; uninstall 21.0.4; install any Java update of 17 or 11 or 8 release; run "java" from the command line. The command will fail with the "command not found" error.

Manually delete orphan Java entries in the "java" and "javac" groups to workaround the issue.

DocLint in javac and javadoc no longer warns about a /// single-line, dangling comment that starts a file. This is to accommodate systems that support a stylized comment on the first line of a source file as a way to "auto-execute" the file.

The Java Virtual Machine Specification is permissive regarding the number of entries of the RuntimeVisibleParameterAnnotations and RuntimeInvisibleParameterAnnotations attributes in the class file format. The javac tool was less permissive, and was rejecting class files that had a different number of entries than javac expected.

With JDK 24, this is fixed, and javac now accepts class files with any number of entries in the RuntimeVisibleParameterAnnotations and RuntimeInvisibleParameterAnnotations attributes. A compile-time warning is produced if the content of the attributes cannot be mapped to the corresponding method's parameters.

Integer.numberOfLeadingZeros may return an incorrect result on x86_64 with AVX2. The issue is caused by an incorrect JIT compiler optimization. As a workaround, the following command-line options can be used -XX:+UnlockDiagnosticVMOptions -XX:DisableIntrinsic=_numberOfLeadingZeros_i.

On Windows, the OperatingSystemMXBean CPU load methods, such as getSystemCpuLoad, getCpuLoad, and getProcessCpuLoad, always return -1. This error affects CPU usage monitoring of Windows targets.

This issue was introduced during JDK 24 development. It does not affect earlier releases. It was found too late to be fixed in JDK 24, but will be resolved in an update release.

New methods have been added to sun.reflect.ReflectionFactory to allow custom serialization libraries get MethodHandles to invoke methods that implement the default behavior for serializable classes. The new methods are defaultReadObjectForSerialization and defaultWriteObjectForSerialization. The method serialPersistentFields has also been added to allow custom serialization libraries obtain the serialPersistentFields from a serializable class.

sun.reflect.ReflectionFactory is an undocumented API in the jdk.unsupported module. It serves as a stop-gap for custom serialization that would otherwise need to break encapsulation to access inaccessible fields.

On Windows, the ProcessBuilder has expanded the quoting of argument strings when starting a process to ensure they are recognized by the application as a single command argument. The set of space characters has been expanded from space (0x20) to include all space characters as defined by java.lang.Character.isSpaceChar, which includes all Unicode space separator characters, such as EN-SPACE (0x2002), and line separator and paragraph separator characters.

The system property sun.misc.URLClassPath.disableJarChecking controls whether the first 4 bytes of JAR files on the class path are checked to be the magic number for ZIP files ("PK"). The check is not performed by default.

If the system property is set on the command line to the value false, then JAR files on the class path are checked. JAR files used by java.net.URLClassLoader at run time are also checked. JAR files that fail the check are ignored.

New Default limits have been added to HTTP in the JDK.

The JDK built-in implementation of the legacy URL protocol handler for HTTP, HttpURLConnection, and the new HttpClient, in the module java.net.http, now have a default limit on the maximum response headers size they will accept from a remote party. The limit is set by default at 384kB (393216 bytes) and is computed as the cumulative size of all header names and header values plus an overhead of 32 bytes per header name value pair.

The default value of the limit can be changed by specifying a positive value with the jdk.http.maxHeaderSize system property on the command line, or in the $JAVA_HOME/conf/net.properties file. A negative or zero value is interpreted as no limit. If the limit is exceeded, the request will fail with a protocol exception.

The JDK built-in implementation of the com.sun.net.httpserver.HttpServer (jdk.httpserver) implements a similar limit for the maximum request header size the server is prepared to accept. The HttpServer limit can be changed by specifying a positive value with the sun.net.httpserver.maxReqHeaderSize system property on the command line. A negative or zero value is interpreted as no limit. The limit is set by default at 384kB (393216 bytes) and the size is computed in the same way as explained above. If the limit is exceeded, the connection is closed.

In addition, the JDK built-in implementation of the new java.net.http.HttpClient enforces two additional limits:

The system property jdk.httpclient.maxNonFinalResponses can be specified with a positive value on the java command line, or in the $JAVA_HOME/conf/net.properties file, to control how many interim responses the client will accept before receiving a final response. An interim response is considered informational and is a response whose status is in the range [100, 199]. These responses are typically either handled internally or simply discarded by the implementation. The default limit is now set at a maximum of 8 interim responses before receiving the final response. A negative or zero value is interpreted as no limit. If the limit is exceeded, the request will fail with a protocol exception.

The system property jdk.httpclient.maxLiteralWithIndexing can be specified with a positive value on the java command line, or in the $JAVA_HOME/conf/net.properties file, to control how many additions a server may request a client to make to the HPack dynamic table when decoding a set of headers. The default maximum value is now set to 512. A negative or zero value is interpreted as no limit. If the limit is exceeded, the request will fail with a protocol exception.

java.net.http.HttpClient would previously timeout if a server didn’t respond to a request which included a Expect: 100-Continue header. 
This release updates HttpClient to send the request body if the server doesn’t respond. This brings the implementation in line with RFC 9110.

The connect methods defined by java.net.Socket are now specified, and changed, to close the Socket if the connection cannot be established, or the timeout (if provided) expires before the connection is established.

The behavior in previous JDK releases was to close the underlying socket when a connection could not be established but leave the Socket open. The resulting Socket was "useless" as most methods behaved as if the Socket was closed.

The behavior of the connect methods when invoked with an unresolved InetSocketAddress was unspecified in previous releases. The behavior in JDK 11 and older releases was to close the underlying socket, throw UnknownHostException, but leave the Socket open in a "useless" state. The behavior in JDK 12 to JDK 23 was to throw UnknownHostException without closing the Socket or underlying socket. This case is now specified, and changed, to close the Socket, the underlying socket, and throw UnknownHostException if the connection cannot be established because the address is unresolved.

As part of this change, calling the connect method on a Socket obtained from a SocketChannel will now throw IOException if already connected. This is the specified exception for this scenario. The incorrect behavior in previous releases was to throw AlreadyConnectedException for this case.

Prior to JDK 24, if a java.net.Authenticator is set on a HttpClient, then any user set Authorization or Proxy-Authorization headers will be removed or overwritten by values generated by the client library. From JDK 24, if such headers are set by the user, then they will be left in place and the authenticator will not be invoked for the respective header. In particular, if the authentication fails for the provided header, the failed response with the 401 0r 407 status code will be returned directly to the calling code. One use case for this could be to let the authenticator handle proxy authentication and for the user to set the Authorization headers for the server.

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 Java Virtual Machine (JVM) option MaxDirectMemorySize controls the maximum total size of memory that may be used for direct buffers in an instance of the JVM. Its default value is the maximum size of the heap. Prior to JDK 24, the amount of memory allocated for internal, temporary direct buffers such as used, for example, when reading from or writing to a java.nio.channels.FileChannel, was included in this total. As of JDK 24, internal use of temporary direct buffers is no longer included in the total.

In the JDK, java.text.MessageFormat now has an implementation limit for the ArgumentIndex pattern element. The hard limit for the value is 10,000.

If an ArgumentIndex value is equal to or exceeds the upper limit, an IllegalArgumentException will now be thrown by

• MessageFormats constructors
• applyPattern(String pattern) instance method
• format(String pattern, Object... arguments) static method

De-serializing a MessageFormat object with an ArgumentIndex value at or over the limit will throw an InvalidObjectException.

IANA Time Zone Database has been upgraded to 2024b. This version mainly includes changes to improve historical data for Mexico, Mongolia, and Portugal. It also changes one timestamp abbreviation, for the time zone 'MET'. Also Asia/Choibalsan is now an alias for Asia/Ulaanbaatar.

The new tzdata changes also impact some legacy zone IDs. Mapping of EST/MST/HST in java.time.ZoneId.SHORT_IDS have changed from fixed offset zones to links to other existing time zones with 2024b. "EST" now links to "America/Panama", "HST" links to "Pacific/Honolulu" and "MST" links to "America/Phoenix". Parsing of the short zone names "EST", "MST", and "HST" is not affected by this change. Further details are available at JDK-8340138

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

• First day of week is Monday in UAE CLDR-15697
• Default numbering system for Arabic in non-Arabic-speaking locations CLDR-17553
• Comma is added for some date formatting patterns CLDR-17812 -
• Some time zone names changed due to them becoming links to other zones CLDR-17960

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.

When redefining a class with JVMTI RedefineClasses, the new bytecodes are verified with the Class File Verifier regardless of the setting of the deprecated -Xverify option.

Unified Logging now outputs a special empty decorator [ ] followed by a space after newlines in multiline log messages. This change allows unambiguous parsing of Unified Logging output.

To illustrate the change, consider the output of log_info(gc)("A\n[gc] B");:

[gc] A

[  ] [gc] B

It is possible to parse this multiline message unambiguously. This was previously not possible, as the output was

[gc] A

[gc] B

which could (and likely would be) parsed as two distinct log messages A and B.

Tools that currently deal with multiline parsing ambiguities in Unified Logging require an update. The updates will likely result in simpler and more robust implementations.

This release adds experimental support for compact object headers. In current 64-bit implementations, Java objects have a 12-byte header. Compact object headers reduce header sizes to 8 bytes, improving the Java heap footprint. This experimental feature can be enabled with -XX:+UnlockExperimentalVMOptions -XX:+UseCompactObjectHeaders. Find more details in JEP 450.

The CDS archives for the Compact Object Headers feature are not included in the JDK released by Oracle. In order to take advantage of the start-up performance offered by CDS, the user can build the CDS archives with Compact Object Headers as follows:

java -Xshare:dump -XX:+UnlockExperimentalVMOptions -XX:+UseCompactObjectHeaders

The above command generates the classes_coh.jsa which is located in the same directory as the default CDS archive (classes.jsa). For example, on Linux, it is located in the <jdk>/lib/server directory.

To generate a CDS archive with Compact Object Headers and with compressed oops disabled:

java -Xshare:dump -XX:+UnlockExperimentalVMOptions -XX:+UseCompactObjectHeaders -XX:-UseCompressedOops

The above command generates the classes_nocoops_coh.jsa which is located in the same directory as the default CDS archive with compressed oops disabled (classes_nocoops.jsa). For example, on Linux, it is located in the <jdk>/lib/server directory.

There are some scenarios where upgrading from a JRE version 8u361 or below to a newer JRE version of Java 8 may break some of the Windows registry keys for the Java Runtime Environment. The Java Uninstall Tool will repair such situations, regardless if a JRE is selected for uninstall or not.

The following root certificates have been added to the cacerts truststore:

+ SSL.com

  + ssltlsrootecc2022
    DN: CN=SSL.com TLS ECC Root CA 2022, O=SSL Corporation, C=US

+ SSL.com
  + ssltlsrootrsa2022
    DN: CN=SSL.com TLS RSA Root CA 2022, O=SSL Corporation, C=US

The performance of the MessageDigest implementations that belong to the SHA3 family (SHA3-224, SHA3-256, SHA3-384, and SHA3-512) has been improved by 6-27%, depending on digested message length and on the platform used. An additional 30-40% can be experienced on AVX-512 capable platforms due to new intrinsic implementations on that platform.

The X.509 encoded format for HSS/LMS public keys has been updated to align with the latest standard outlined in RFC 9708. Notably, the additional OCTET STRING wrapping around the public key value has been removed. For compatibility, public key encodings generated by earlier JDK releases are still recognized.

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.

The JDK will stop trusting TLS server certificates issued after November 11, 2024 and anchored by Entrust root certificates, in line with similar plans recently announced by Google and Mozilla. The list of affected certificates includes certificates branded as AffirmTrust, which are managed by Entrust.

TLS server certificates issued on or before November 11, 2024 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 will be 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 November 11, 2024.

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

If necessary, and at your own risk, you can work around the restrictions by removing "ENTRUST_TLS" from the jdk.security.caDistrustPolicies security property in the java.security configuration file.

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

The javadoc for SSLSessionContext has been reworded to make it clear that when the timeout limit is exceeded for a session, the object is marked so that future connections cannot resume or rejoin the session. Active sessions can continue to be used so long as resume and rejoin operations are not attempted.

The TLS_RSA cipher suites have been disabled by default, by adding "TLS_RSA_*" to the jdk.tls.disabledAlgorithms security property in the java.security configuration file. The TLS_RSA cipher suites do not preserve forward-secrecy and are not commonly used. Some TLS_RSA cipher suites are already disabled because they use DES, 3DES, RC4, or NULL, which are disabled. This action disables all remaining TLS_RSA cipher suites. Any attempts to use cipher suites starting with "TLS_RSA_" will fail with an SSLHandshakeException. Users can, at their own risk, re-enable these cipher suites by removing "TLS_RSA_*" from the jdk.tls.disabledAlgorithms security property.

If an entry is removed from a signed JAR file, there is no mechanism to detect that it has been removed using the JarFile API, since the getJarEntry method returns null as if the entry had never existed. With this change, the jarsigner -verify command analyzes the signature files and if some sections do not have matching file entries, it prints out the following warning: "This JAR contains signed entries for files that do not exist". Users can further find out the names of these entries by adding the -verbose option to the command.

udp_preference_limit is a krb5.conf setting to control how a KDC-REQ message is sent. If the size of the message is greater than the value of udp_preference_limit, TCP will be used; otherwise UDP will be used. Before this change, setting it to zero is ignored and the message is sent with UDP. With this change, setting it to zero forces the message to be sent with TCP. This behavior is consistent with other Kerberos 5 vendors.

Refactoring javac to support JEP 492 exposed some existing problems regarding local classes and static contexts. For example:

class O {

    static void foo(int x) { 
        class C { // in static context, so no enclosing instance
            void outer() { 
                System.out.println(x);  // capture x
            } 
        } 
        class U {
            static void test() { 
                new C();                // (a) 
            } 
        }
    }
    public static void main(String[] args) {
        foo(42);
    }
}

javac 23 compiles this program, but executing the classfile for class O throws an internal exception trying to create the instance at position (a).

javac 24 requires that any new expression creating an instance of a class C where C is an inner local class that appears in a static context, should appear in the same static context. Thus the new expression at position (a) results in a compile-time error.

There is a similar fix for new expressions that create instances of anonymous classes, that is, new expressions with class bodies.

A similar issue surrounds super constructor invocations in a local class that is in a static context different from the static context containing the superclass. For example:

class O {

    static void foo(int x) {
        class C { // in static context, so no enclosing instance
            void foo() {
                System.out.println(x); /* capture x */
            }
        }
        class I {
            static void i(int y) {
                class U extends C { // in static context, so no enclosing instance
                    U(){
                        super();
                        System.out.println(y); /* capture y */
                    }
                }
                var _ = new U();    // (b)
            }
            public static void main(String[] args) {
            }
        }
    }
}

javac 23 compiles this code, but executing the class file for class I results in a verifier error. There is no way to correctly instantiate class U, so the new expression at position (b) is always broken.

With javac 24, the class declaration of U results in a compile-time error.

Lambda expressions and method references are sometimes translated as methods by the javac compiler. As of this release, the name of the generated methods for non-serializable lambdas and method references has been updated. Such updates might be visible when inspecting the content of a class containing non-serializable lambdas and method references using core reflection.

Moreover, the EnclosingMethod attribute for local and anonymous classes declared inside lambda expressions has been fixed to be compliant with JVMS 4.7.7 which states:

In particular, method_index must be zero if the current class was immediately enclosed in source code by an instance initializer, static initializer, instance variable initializer, or class variable initializer.

This means that the following code:

class Outer {

    Runnable action = () -> {
       class Inner() { }
       System.out.println(Inner.class.getEnclosingMethod());
    }
    
    public static void main(String[] args) {
       new Outer().action.run();
    }
}

will now, correctly, print null. That is, the local class Inner has no enclosing method. Earlier versions incorrectly reported the enclosing method of Inner to be the generated method for the lambda expression.

Starting with JDK 24, the jlink --add-modules ALL-MODULE-PATH option will require users to set the module path via the --module-path option. Prior to JDK 24, using --add-modules ALL-MODULE-PATH without --module-path could be used to create an image with all JDK modules from $JAVA_HOME/jmods. In JDK 24, to create an image using ALL-MODULE-PATH, it is required to explicitly set --module-path. To create an image with all JDK modules, use jlink --add-modules ALL-MODULE-PATH --module-path $JAVA_HOME/jmods instead.

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 default value of the property for XSLT and XPath Extension Functions, jdk.xml.enableExtensionFunctions, has been changed from true to false, which disables Extension Functions.

If an application handles XML transformation with a stylesheet that uses Extension Functions, it may encounter processing error such as the follows:

Use of the extension function '[function name]' is not allowed when extension functions are disabled

by the secure processing feature or the property 'jdk.xml.enableExtensionFunctions'. To enable extension
functions, set 'jdk.xml.enableExtensionFunctions' to 'true'.

For applications that require extension functions, the solution is to set the property jdk.xml.enableExtensionFunctions to true. This can be done via the Transform API, e.g.

        transformerFactory = TransformerFactory.newInstance();

        transformerFactory.setFeature("jdk.xml.enableExtensionFunctions", true);

Or in the JAXP Configuration File. A template for creating Strict JAXP Configuration File, jaxp-strict.properties.template, was provided in JDK 23 for developers to assess and prepare for this type of changes. To set the property, copy the template and create a custom configuration file:

cp $JAVA_HOME/conf/jaxp-strict.properties.template /<my_path>/jaxp-strict.properties

Edit and change the setting as follows:

jdk.xml.enableExtensionFunctions=true

Furthermore, as a system property, the property can also be set on the commandline, e.g.:

java -Djdk.xml.enableExtensionFunctions=true myApp`

The JDK's XML Processing Limits (known as JAXP Limits) are adjusted to be more in line with general applications. In particular, the default values of the limits are tuned down to more closely align with known DTDs.

If an application processes XML documents that reference an extremely large DTD, it may encounter a parsing error such as the follows:

JAXP00010001: The parser has encountered more than "2500" entity expansions in this document;

this is the limit imposed by the JDK.

To resolve the issue, application may increase the limit via the JAXP API. Using DOM processor as an example, the following code increases the expansion limit to 5000:

DocumentBuilderFactory dbf = DocumentBuilderFactory.newInstance();

dbf.setAttribute("jdk.xml.entityExpansionLimit", 5000);

Or in the JAXP Configuration File. A template for creating Strict JAXP Configuration File, jaxp-strict.properties.template, was provided in JDK 23 for developers to assess and prepare their applications for the changes.

To set the property in the configuration file, copy the template and create a custom configuration file:

cp $JAVA_HOME/conf/jaxp-strict.properties.template. /<my_path>/jaxp-strict.properties

Edit and change the setting as follows:

jdk.xml.entityExpansionLimit=5000

As a system property, this property can also be set on the commandline, e.g.:

java -Djdk.xml.entityExpansionLimit=5000 myApp

The Java tutorial, JAXP Processing Limits, provides a debug solution that can be used to analyze the usages and estimate the limits.