JDK 24 Early-Access Release Notes

This is a draft of the release notes that will accompany JDK 24. The contents are subject to change until release.

Build 18

Added SSL.com TLS Root CA Certificates Issued in 2022 (JDK-8341057)

security-libs/java.security

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

Build 17

Support for Including Security Properties Files (JDK-8319332)

security-libs

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

Build 15

New MXBean to monitor/manage virtual thread scheduler (JDK-8338890)

core-svc/java.lang.management

A new JDK-specific monitoring and management interface jdk.management.VirtualThreadSchedulerMXBean has been added to allow Java Management Extension (JMX) based tooling 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.

javac Accepts class Files With Any Number of Entries in RuntimeVisibleParameterAnnotations and RuntimeInvisibleParameterAnnotations Attributes (JDK-8334870)

tools/javac

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.

Build 14

Distrust TLS Server Certificates Anchored by Entrust Root Certificates and Issued After Nov 11, 2024 (JDK-8337664, JDK-8341059)

security-libs/javax.net.ssl

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:

TLS server certificate issued after 2024-11-11 and anchored by a distrusted legacy Entrust root CA: CN=Entrust.net Certification Authority (2048), OU=(c) 1999 Entrust.net Limited, OU=www.entrust.net/CPS_2048 incorp. by ref. (limits liab.), O=Entrust.net

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:

Root Certificates distrusted after 2024-11-11
Distinguished Name SHA-256 Fingerprint
CN=Entrust Root Certification Authority, OU=(c) 2006 Entrust, Inc., OU=www.entrust.net/CPS is incorporated by reference, O=Entrust, Inc., C=US

73:C1:76:43:4F:1B:C6:D5:AD:F4:5B:0E:76:E7:27:28:7C:8D:E5:76:16:C1:E6:E6:14:1A:2B:2C:BC:7D:8E:4C

CN=Entrust Root Certification Authority - EC1, OU=(c) 2012 Entrust, Inc. - for authorized use only, OU=See www.entrust.net/legal-terms, O=Entrust, Inc., C=US

02:ED:0E:B2:8C:14:DA:45:16:5C:56:67:91:70:0D:64:51:D7:FB:56:F0:B2:AB:1D:3B:8E:B0:70:E5:6E:DF:F5

CN=Entrust Root Certification Authority - G2, OU=(c) 2009 Entrust, Inc. - for authorized use only, OU=See www.entrust.net/legal-terms, O=Entrust, Inc., C=US

43:DF:57:74:B0:3E:7F:EF:5F:E4:0D:93:1A:7B:ED:F1:BB:2E:6B:42:73:8C:4E:6D:38:41:10:3D:3A:A7:F3:39

CN=Entrust Root Certification Authority - G4, OU=(c) 2015 Entrust, Inc. - for authorized use only, OU=See www.entrust.net/legal-terms, O=Entrust, Inc., C=US

DB:35:17:D1:F6:73:2A:2D:5A:B9:7C:53:3E:C7:07:79:EE:32:70:A6:2F:B4:AC:42:38:37:24:60:E6:F0:1E:88

CN=Entrust.net Certification Authority (2048), OU=(c) 1999 Entrust.net Limited, OU=www.entrust.net/CPS_2048 incorp. by ref. (limits liab.), O=Entrust.net

6D:C4:71:72:E0:1C:BC:B0:BF:62:58:0D:89:5F:E2:B8:AC:9A:D4:F8:73:80:1E:0C:10:B9:C8:37:D2:1E:B1:77

CN=AffirmTrust Commercial, O=AffirmTrust, C=US

03:76:AB:1D:54:C5:F9:80:3C:E4:B2:E2:01:A0:EE:7E:EF:7B:57:B6:36:E8:A9:3C:9B:8D:48:60:C9:6F:5F:A7

CN=AffirmTrust Networking, O=AffirmTrust, C=US

0A:81:EC:5A:92:97:77:F1:45:90:4A:F3:8D:5D:50:9F:66:B5:E2:C5:8F:CD:B5:31:05:8B:0E:17:F3:F0B4:1B

CN=AffirmTrust Premium, O=AffirmTrust, C=US

70:A7:3F:7F:37:6B:60:07:42:48:90:45:34:B1:14:82:D5:BF:0E:69:8E:CC:49:8D:F5:25:77:EB:F2:E9:3B:9A

CN=AffirmTrust Premium ECC, O=AffirmTrust, C=US

BD:71:FD:F6:DA:97:E4:CF:62:D1:64:7A:DD:25:81:B0:7D:79:AD:F8:39:7E:B4:EC:BA:9C:5E:84:88:82:14:23

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.

Build 12

HttpClient 100-continue Timeout (JDK-8324209)

core-libs/java.net

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 and brings the implementation in line with RFC 9110

Build 11

Linux desktop GTK2 support is removed (JDK-8329471)

client-libs/javax.swing

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 JDK as the preferred default, in which case to use GTK 2, apps must request it using the jdk.gtk.version System property. And since many recent distros make GTK 2 only an optional install, it may require extra work to use it, and future distros 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.

Build 10

Reflective Invocation of VarHandle Signature Polymoprhic Methods Throws UnsupportedOperationException (JDK-8335638)

core-libs/java.lang.invoke

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

Disable "best-fit" Mapping on Windows Command Line (JDK-8337506)

tools/launcher

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.

SSLSessionContext clarification regarding timeout limit (JDK-4966250)

security-libs/javax.net.ssl

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.

Build 8

MethodTypeDesc.resolveConstantDesc Throws ClassNotFoundException instead of TypeNotPresentException (JDK-8304929)

core-libs/java.lang

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.

Build 5

SunPKCS11 provider is enhanced to use CKM_AES_CTS mechanism if supported by native PKCS11 library (JDK-8330842)

security-libs/javax.crypto:pkcs11

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, except for NSS as it is known to be CS1. Otherwise, the PKCS #11 CKM_AES_CTS mechanism is disabled.

Build 4

Document Standard Hash and MGF Algorithms for RSASSA-PSS Signature (JDK-8248981)

security-libs/java.security

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.

NumberFormat Supports IntegerOnly Parsing With Suffix (JDK-8333755)

core-libs/java.text

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%");

Deprecate jstatd for removal (JDK-8327793)

core-svc/tools

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 usage of jstat for monitoring local VMs using the Attach API.

The LockingMode Flag, Along With The LM_LEGACY And LM_MONITOR Modes Are Deprecated (JDK-8334299)

hotspot/runtime

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.