JDK 21 Early-Access Release Notes

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

Build 23

Support Variant Collations (JDK-8307547)

core-libs/java.text

java.text.Collator now supports multiple collations for a locale. The type of collation may be specified with the [https://www.unicode.org/reports/tr35/#UnicodeCollationIdentifier](Unicode collation identifier) if the runtime provides the implementation. For example, the Collator instance created with the locale sv-u-co-trad (Traditional collation in the Swedish language) may sort strings, treating v and w the same.

Build 22

Deprecate GTK2 for removal (JDK-8280031)

client-libs/java.awt

Implementation support for AWT/Swing using GTK2 on Linux is now deprecated for removal.

With the announcement of the GTK4 release in December 2020, the GTK 2 toolkit is reaching its end of life. GTK2 support is therefore is expected to be removed some time after no JDK supported platform needs it.

GTK3 is the current default and Swing applications which opt in to using GTK2 on Linux by setting the System Property -jdk.gtk.version=2 will now see a warning printed

WARNING: the GTK 2 library is deprecated and its support will be removed in a future release

Added 4 GTS Root CA Certificates (JDK-8307134)

security-libs/java.security

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

+ Google Trust Services LLC
 + gtsrootcar1
  DN: CN=GTS Root R1, O=Google Trust Services LLC, C=US

+ Google Trust Services LLC
 + gtsrootcar2
  DN: CN=GTS Root R2, O=Google Trust Services LLC, C=US

+ Google Trust Services LLC
 + gtsrootecccar3
  DN: CN=GTS Root R3, O=Google Trust Services LLC, C=US

+ Google Trust Services LLC
 + gtsrootecccar4
  DN: CN=GTS Root R4, O=Google Trust Services LLC, C=US

-XshowSettings:locale output now includes tzdata version (JDK-8305950)

tools/launcher

The -XshowSettings launcher option has been enhanced to print the tzdata version configured with the JDK. The tzdata version is displayed as part of the locale showSettings option.

Example output using -X:showSettings:locale:

.....
Locale settings:
    default locale = English
    default display locale = English
    default format locale = English
    tzdata version = 2023c
    .....

Build 21

Added Microsoft Corporation's 2 TLS Root CA Certificates (JDK-8304760)

security-libs/java.security

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

+ Microsoft Corporation
  + microsoftecc2017
    DN: CN=Microsoft ECC Root Certificate Authority 2017, O=Microsoft Corporation, C=US

+ Microsoft Corporation
  + microsoftrsa2017
    DN: CN=Microsoft RSA Root Certificate Authority 2017, O=Microsoft Corporation, C=US

Added TWCA Root CA Certificate (JDK-8305975)

security-libs/java.security

The following root certificate has been added to the cacerts truststore:

+ TWCA
  + twcaglobalrootca
    DN: CN=TWCA Global Root CA, OU=Root CA, O=TAIWAN-CA, C=TW

Swedish collation rules (JDK-8306927)

core-libs/java.text

Swedish collation rules have been modified to reflect the modern sorting for the language. Collation in Swedish now distinguishes 'v' and 'w', and they are sorted alphabetically. For example, {"wb", "va", "vc"} is sorted as {"va", "vc", "wb"} with this change, whereas previously it was sorted as {"va", "wb", "vc"}. In order to specify the old collation, use co Unicode identifier in the locale. Refer to Support variant collations for more detail.

Thread.sleep(millis, nanos) Is Now Able to Perform Sub-Millisecond Sleeps (JDK-8305092)

core-libs/java.lang

The Thread.sleep(millis, nanos) method is now able to perform sub-millisecond sleeps on POSIX platforms. Before this change, a non-zero nanos argument would round up to a full millisecond. While the precision is improved on most POSIX systems, the actual sleep duration is still subject to the precision and accuracy of system facilities.

Build 20

Removal of java.compiler system property (JDK-8041676)

core-libs/java.lang

The system property java.compiler has been removed from the list of standard system properties.

Running with this system property set on the command line will now print a warning to say that the system property is obsolete, it has no other effect. In previous releases, running with -Djava.compiler or -Djava.compiler=NONE on the command line selected interpreter only execution mode. If needed, the -Xint option can be used to run in interpreter only mode.

Build 19

Support for CLDR Version 43 (JDK-8296248)

core-libs/java.util:i18n

Locale data based on the Unicode Consortium's CLDR has been upgraded to version 43. The JDK locale data now employs coverageLevels.txt, including the 'basic' and above level locale data, in addition to the data already existing in prior JDK releases for compatibility. For detailed locale data changes, please refer to the Unicode Consortium's CLDR release notes.

Build 18

Remove the JAR Index feature (JDK-8302819)

core-libs/java.util.jar

The "JAR Index" feature has been dropped from the JAR file specification. JAR Index was a legacy optimization in early JDK releases to allow downloading of JAR files to be postponed when loading applets or other classes over the network. The feature has been disabled since JDK 18, meaning the META-INF/INDEX.LIST entry in a JAR file is ignored at run-time.

The system property jdk.net.URLClassPath.enableJarIndex, introduced in JDK 18 to re-enable the feature, has been removed. Setting this property no longer has any effect.

As part of the change, the jar tool will now output a warning if the -i or --generate-index options are used.

The java.net.http.HttpClient Is Now AutoCloseable (JDK-8267140)

core-libs/java.net

The java.net.http.HttpClient is now AutoCloseable.

The following methods have been added to the API:

  • void close(): closes the client gracefully, waiting for submitted requests to complete.
  • void shutdown(): initiates a graceful shutdown, then returns immediately without waiting for the client to terminate.
  • void shutdownNow(): initiates an immediate shutdown, trying to interrupt active operations, and returns immediately without waiting for the client to terminate.
  • boolean awaitTermination(Duration duration), waits for the client to terminate, within the given duration; returns true if the client is terminated, false otherwise.
  • boolean isTerminated(): returns true if the client is terminated.

The instances returned by HttpClient.newHttpClient() and the instances built from HttpClient.newBuilder() provide a best effort implementation for these methods, that allow to reclaim the resources allocated by the HttpClient early, without waiting for its garbage collection.

Note that an HttpClient instance typically manages its own pools of connections, which it may then reuse as and when necessary. Connection pools are typically not shared between HttpClient instances. Creating a new client for each operation, though possible, will usually prevent reusing such connections.

The java.lang.Compiler Class has Been Removed (JDK-8205129)

core-libs/java.lang

The java.lang.Compiler class has been removed. This under-specified API dates from JDK 1.0 and the "Classic VM" used in early JDK releases. Its implementation on the HotSpot VM "does nothing", it was never implemented. The class has been deprecated, for removal, since Java 9.

Build 17

Emit Warning for Removal of COMPAT Provider (JDK-8304982)

core-libs/java.util:i18n

Users now see a warning message if they specify COMPAT or JRE locale data with the java.locale.providers system property and call some locale-sensitive operations. COMPAT has been provided for migration to the CLDR locale data at the time of JDK 9, where it became the default locale data (JEP 252). It retains the legacy locale data of JDK 8 for compatibility, but some of the newer functionalities are not applied. It is planned to be removed in a future release of the JDK. Users are encouraged to migrate to the CLDR locale data.

Emoji Related Binary Properties in RegEx (JDK-8305107)

core-libs/java.util.regex

Emoji-related properties introduced in ([JDK-8303018](https://bugs.openjdk.org/browse/JDK-8303018)) can now be used as binary properties in the java.util.regex.Pattern class. One can match characters that have Emoji-related properties with the new p{IsXXX} constructs, e.g.,

Pattern.compile("\p{IsEmoji}").matcher("🉐").matches()

returns true.

Build 16

Detection for Output File Clashes (JDK-8296656)

tools/javac

A new compiler lint flag output-file-clash enables detection of output file clashes. An output file clash is when the compiler intends to write two different output files, but due to the behavior of the operating system, these files end up being written to the same underlying file.

This usually happens due to case-insensitive filesystems. For example, a class like this would cause two class files to be written to the same file Test$Inner.class:

public class Test {
    class Inner {
    }
    class INNER {
    }
}

However, this problem can also happen when the filesystem "normalizes" file names. For example, on MacOS, compiling this class will generate such a clash:

public class Test {
    interface Cafeu0301 {
    }
    interface Cafu00e9 {
    }
}

The reason is that u0301 is the Unicode character "Combining Acute Accent" which means "add an accent over the previous character". So MacOS normalizes the letter e followed by a u0301 into a Unicode u00e9, that is, é. However, the Java language treats these the two names Cafeu0301 and Cafu00e9 as distinct.

Compiling this example above on MacOX with -Xlint:output-file-clash will now generate a warning like this:

    warning: [output-file-clash] output file written more than once: /home/test/Test$Café.class

Runtime.exec and ProcessBuilder Logging of Command Arguments (JDK-8303392)

core-libs/java.lang

Processes started by Runtime.exec and ProcessBuilder can be enabled to log the command, arguments, directory, stack trace, and process id. The logged information may contain sensitive security information and the potential exposure of the information should be carefully reviewed. Logging of the information is enabled when the logging level of the System#getLogger(String) named java.lang.ProcessBuilder is System.Logger.Level.DEBUG or Logger.Level.TRACE. When enabled for Level.DEBUG only the process id, directory, command, and stack trace are logged. When enabled for Level.TRACE the command arguments are included with the process id, directory, command, and stack trace.

Build 15

Unicode Emoji Properties (JDK-8303018)

core-libs/java.lang

The following six new methods are added to java.lang.Character for obtaining Emoji character properties, which are defined in the Unicode Emoji Technical Standard (UTS #51) :

   - isEmoji(int codePoint)
   - isEmojiPresentation(int codePoint)
   - isEmojiModifier(int codePoint)
   - isEmojiModifierBase(int codePoint)
   - isEmojiComponent(int codePoint)
   - isExtendedPictographic(int codePoint)

Obsolete legacy HotSpot parallel class loading workaround option -XX:+EnableWaitForParallelLoad (JDK-8298469)

hotspot/runtime

Some user-defined, older class loaders would workaround a deadlock issue by releasing the class loader lock during the loading process. To prevent these loaders from encountering a “java.lang.LinkageError: attempted duplicate class definition” while loading the same class by parallel threads, the HotSpot Virtual Machine introduced a workaround in JDK 6 that serialized the load attempts, causing the subsequent attempts to wait for the first to complete.

The need for class loaders to work this way was removed in JDK 7 when parallel-capable class loaders were introduced, but the workaround remained in the VM. The workaround was deprecated in JDK 20 and the option -XX:+EnableWaitForParallelLoad was introduced for users who relied on this legacy behavior. The default for this option was off.

In JDK 21, the option -XX:+EnableWaitForParallelLoad and code to support this has been removed.

See CSR JDK-8304056 for more details.

Build 14

Deprecate JMX Subject Delegation and the JMXConnector.getMBeanServerConnection(Subject) Method for Removal (JDK-8298966)

core-svc/javax.management

The JMX Subject Delegation feature is deprecated, for removal in a future release. This feature is enabled by the method javax.management.remote.JMXConnector.getMBeanServerConnection(javax.security.auth.Subject) which is deprecated for removal.

If a client application needs to perform operations as or on behalf of multiple identities, it will need to make multiple calls to JMXConnectorFactory.connect() and to the getMBeanServerConnection() method on the returned JMXConnector.

New network interface names on Windows (JDK-8302659)

core-libs/java.net

Maintainers of applications that do network multicasting or use the java.net.NetworkInterface API should note that the names that the JDK assigns to network interfaces on Windows have changed in this release. The JDK historically synthesized names for network interfaces on Windows. This has changed to use the names assigned by the Windows operating system. For example, the JDK may have historically assigned a name such as “eth0” for an ethernet interface and “lo” for the loopback. The equivalent names that Windows assigns may be names such as “ethernet_32768” and “loopback_0".

This change may impact code that does a lookup of network interfaces with the NetworkInterace.getByName(String name) method. It also may also be surprising to code that enumerates all network interfaces with the NetworkInterfaces.networkInterfaces() or NetworkInterface.getNetworkInterfaces() methods as the names of the network interfaces will look different to previous releases. Depending on configuration, it is possible that enumerating all network interfaces will enumerate network interfaces that weren’t previously enumerated because they didn’t have an Internet Protocol address assigned. The display name returned by NetworkInterface::getDisplayName has not changed so this should facilitate the identification of network interfaces when using Windows native tools.

Remove ContentSigner APIs and jarsigner -altsigner and -altsignerpath options (JDK-8303410)

security-libs/jdk.security

The jarsigner options -altsigner and -altsignerpath have been removed, along with the underlying ContentSigner API in the com.sun.jarsigner package. The mechanism was deprecated in JDK 9 and marked for removal in JDK 15.

Build 13

SunPKCS11 provider now uses the same DH private exponent length as other JDK providers (JDK-8295425)

security-libs/javax.crypto:pkcs11

When initializing the DH KeyPairGenerator impl of SunPKCS11 provider with the keysize argument, it looks up the default DH parameters including the default private exponent length used by other JDK providers to initialize the underlying native PKCS11 implementation. If the KeyPairGenerator impl is initialized with the DHParameterSpec object with negative private exponent length, this invalid negative value will also be overridden with a default value matching the DH prime size.

Build 12

Generate "potentially ambiguous overload" for Inherited Methods (JDK-8026369)

tools/javac

Prior to JDK 21, the javac compiler was omitting some "potentially ambiguous overload" warnings enabled by option -Xlint:overloads.

If option -Xlint:overloads is enabled, the compiler warns when the methods in a class create a potential ambiguity for method invocations containing an implicit lambda expression parameter like x -> { ... }. An ambiguity can occur if two or more methods could match such a method call, like when one method takes a Consumer<Integer> parameter where the other takes an IntConsumer. For example the javac compiler should issue a warning for code such as:

    interface I {
        void foo(Consumer<Integer> c);
        void foo(IntConsumer c);
    }

Prior to JDK 21 the warning was only issued for a class if one of the methods was declared in the class. The javac compiler now also warns when neither method is declared in the class, that is, both methods are inherited from supertypes, for example for code like:

    interface I {
        void foo(Consumer<Integer> c);
    }

    interface J {
        void foo(IntConsumer c);
    }

    interface K extends I, J {}

Support for GB18030-2022 (JDK-8301119)

core-libs/java.nio.charsets

China National Standard body (CESI) has recently published GB18030-2022 which is an updated version of the GB18030 standard and brings GB18030 in sync with Unicode version 11.0. The Charset implementation for this new standard has now replaced the prior 2000 standard. However, this new standard has some incompatible changes from the prior implementation, so for those who need to use the old mappings, a new system property jdk.charset.GB18030 is introduced. By setting its value to 2000, the previous JDK releases' mappings for the GB18030 Charset are used which are based on the 2000 standard.

Build 11

System.exit and Runtime.exit() Logging (JDK-8301627)

core-libs/java.lang

Calls to java.lang.System.exit() and Runtime.exit() are logged to the logger named java.lang.Runtime with a logging level of System.Logger.DEBUG. When the configuration of the logger allows, the caller can be identified from the stacktrace included in the log.

Build 10

The Default TLS Diffie-Hellman Group Size Has Been Increased from 1024-bit to 2048-bit (JDK-8301700)

security-libs/javax.net.ssl

The JDK implementation of TLS 1.2 now uses a default Diffie Hellman keysize of 2048 bits when a TLS_DHE cipher suite is negotiated and either the client or server does not support FFDHE, which can negotiate a stronger keysize. The JDK TLS implementation supports FFDHE and it is enabled by default.

As a workaround, users can revert to the previous size by setting the jdk.tls.ephemeralDHKeySize system property to 1024 (at their own risk).

This change does not affect TLS 1.3 as the minimum DH group size is already 2048 bits.

New system property to toggle XML Signature secure validation mode (JDK-8301260)

security-libs/javax.xml.crypto

A new system property named "org.jcp.xml.dsig.secureValidation" has been added that can be used to enable or disable the XML Signature secure validation mode. The system property should be set to "true" to enable, or "false" to disable. Any other value for the system property is also treated as "false". If the system property is set, it supersedes the XMLCryptoContext property value.

By default, the secure validation mode is enabled. Disabling the secure validation mode should be done at your own risk.

Added Certigna(Dhimyotis) Root CA Certificate (JDK-8245654)

security-libs/java.security

The following root certificate has been added to the cacerts truststore:

+ Certigna (Dhimyotis)
  + certignarootca
    DN: CN=Certigna, O=Dhimyotis, C=FR

Removal of G1 Hot Card Cache (JDK-8225409)

hotspot/gc

The G1 Hot Card Cache has been removed. Performance testing has shown that after improvements to the concurrent refinement control earlier it does not contribute to performance.

Removal reduces memory footprint of the G1 garbage collector by around 0.2% of the Java heap size.

The associated configuration options G1ConcRSLogCacheSize and G1ConcRSHotCardLimit have been obsoleted and a warning will be issued at startup about the obsolete option if they are used.

Build 9

keytool -genseckey And -importpass Commands Warn if Weak PBE Algorithms Are Used (JDK-8286907)

security-libs/java.security

The keytool -genseckey and -importpass commands have been updated to warn users when weak password-based encryption algorithms are specified by the -keyalg option.

java.util.Formatter May Return Slightly Different Results on double and float (JDK-8300869)

core-libs/java.util

The implementation of java.util.Formatter for double and float conversions to decimal ('e', 'E', 'f', 'g', 'G') is now aligned with the one in Double.toString(double), which was changed in JDK 19.

As a consequence, in some rare circumstances, the outcomes may slightly differ from the ones in earlier releases.

One example is with double 2e23 and format "%.16e". With this change, the outcome is 2.0000000000000000e+23, while earlier releases produce 1.9999999999999998e+23. Any smaller precision in the format (e.g., "%.15e") on this value will produce outcomes that are equal to each other, though.

Another example is with double 9.9e-324 and format "%.2g". The new outcome is 9.9e-324, but earlier releases generate "1.0e-323".

Build 8

Clarification of the default charset initialization with file.encoding (JDK-8300916)

core-libs/java.nio.charsets

If the system property “file.encoding” is set on the command line to the name of a Charset that is not in the java.base module then the JDK will ignore it and default to UTF-8. In the JDK 17 and older, the JDK would attempt to locate the charset, even though it was never supported/documented to change the value of this system property in these releases. Since JDK 18 it is possible to set the system property on the command to the value “UTF-8" (the default) or “COMPAT”, setting it to any other value is not defined.

SunJCE provider now supports SHA-512/224 and SHA-512/256 as digests for the PBES2 algorithms (JDK-8288050)

security-libs/javax.crypto

SunJCE provider is enhanced with additional PBES2 Cipher and Mac algorithms, e.g. those using SHA-512/224 and SHA-512/256 message digests. To be more specific, callers can now use SunJCE provider for "PBEWithHmacSHA512/224AndAES_128", "PBEWithHmacSHA512/256AndAES_128", "PBEWithHmacSHA512/224AndAES_256", and "PBEWithHmacSHA512/256AndAES_256" Cipher and "PBEWithHmacSHA512/224", and "PBEWithHmacSHA512/256" Mac.

Build 7

File::listRoots Changed to Return All Available Drives on Windows (JDK-8208077)

core-libs/java.io

The behavior of the method java.io.File.listRoots() on Microsoft Windows has changed in this release so that the returned array includes a File object for all available disk drives. This differs from the behavior in JDK 10 to JDK 20, where this method filtered out disk drives that were not accessible or did not have media present. This change avoids performance issues observed in the previous releases and also ensures that the method is consistent with the root directories in the iteration returned by FileSystem.getDefault().getRootDirectories().

Build 2

ThreadGroup.allowThreadSuspension is removed (JDK-8297295)

core-libs/java.lang

The method java.lang.ThreadGroup.allowThreadSuspension(boolean) has been removed in this release. The method was used for low memory handling in JDK 1.1 but was never fully specified. It was deprecated and changed to "do nothing" in JDK 1.2 (1998).

Not Yet Integrated

Support Unicode Extension for Collation Settings (JDK-8308108)

core-libs/java.text

BCP 47 Unicode extension for strength and normalization collation settings are now supported in the java.text.Collator. If the specified locale to getInstance(Locale) factory method contains ks and/or kk collation settings, the created Collator instance is set to have the strength and the decomposition modes corresponding to the specified strength and normalization settings.