JDK 23 Early-Access Release Notes

New javap option, -verify, prints additional class verification info.

When looking up a keytab or credentials cache (ccache) entry for a Kerberos principal, the principal name is compared with the entry name in a case-insensitive manner. However, many Kerberos implementations treat principal names as case-sensitive. As a result, if two principals have names that differ only by case, there is a risk of selecting the incorrect keytab or ccache entry.

A new security property named jdk.security.krb5.name.case.sensitive is introduced to control name comparison. If this property is set to "true", the comparison of principal names during keytab and ccache entry lookup will be case-sensitive. The default value is "false" to ensure backward compatibility.

In addition, if a system property with the same name is specified, it will override the security property value defined in the java.security file.

The JVM TI function GetObjectMonitorUsage has been re-specified in this release to not return monitor information when a monitor is owned by a virtual thread. It is now specified to return the monitor owner only when the monitor is owned by a platform thread. Furthermore, the array of threads waiting to own, and the array of threads waiting to be notified, that the function returns, are now re-specified to only include platform threads.

The corresponding JDWP command ObjectReference.MonitorInfo is re-specified. The methods owningThread(), waitingThreads() and entryCount() defined by com.sun.jdi.ObjectReference are also re-specified.

Future JDK releases will continue to move towards making XML processing more restrictive by default. In order to help developers prepare for these changes, this release includes a JAXP Configuration File template, $JAVA_HOME/conf/jaxp-strict.properties.template, specifying more restrictive XML processing settings.

The following steps may be used to test an application with the JAXP Configuration file template:

• Copy the template file to a location outside of $JAVA_HOME/conf:

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

• Run the application specifying the system property java.xml.config.file to the path where the JAXP configuration file template was copied in order to override the default JAXP configuration:

  java -Djava.xml.config.file=/<my_path>/jaxp-strict.properties myApp

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

+ GlobalSign
  + globalsignr46
    DN: CN=GlobalSign Root R46, O=GlobalSign nv-sa, C=BE

+ GlobalSign
  + globalsigne46
    DN: CN=GlobalSign Root E46, O=GlobalSign nv-sa, C=BE

In previous releases, RandomGeneratorFactory.create(long) falls back by invoking the no-arg create() method if the underlying algorithm does not support a long seed. The create(byte[]) method works in a similar fashion.

Starting with this release, these methods now throw an UnsupportedOperationException rather than silently falling back to create().

A new method has been added to java.time.Instant class to obtain the Duration until the specified Instant. The new method Instant.until(Instant) produces the same duration as Duration.between(Temporal, Temporal) but is easier for users to discover. Also, this new method is more convenient than the method Instant.until(Temporal, TemporalUnit), in that the new method directly returns a Duration without a unit conversion.

The following methods have been added to java.io.Console class that take a java.util.Locale argument:

• public Console format(Locale locale, String format, Object ... args)
• public Console printf(Locale locale, String format, Object ... args)
• public String readLine(Locale locale, String format, Object ... args)
• public char[] readPassword(Locale locale, String format, Object ... args) Users can now output the string or display the prompt text formatted with the specified Locale, which may be independent of the default locale. For example, a snippet System.console().printf(Locale.FRANCE, "%1$tY-%1$tB-%1$te %1$tA", new Date()) will display:

2024-mai-16 jeudi

The Http server no longer immediately sends response headers if chunked mode is selected or if the response has a body. The previous behavior had the effect of slowing down response times due to delayed acknowledgments on some operating systems. With this change, the headers will be buffered and sent with the response body if one is expected. This should result in improved performance for certain kinds of responses. Note, it is advisable now to always close the Http exchange or response body stream to force the sending of the response headers and is required in all cases except where there is no response body.

The jdk.random module has been removed from the JDK. This module contained the implementations of the java.util.random.RandomGenerator algorithms. The implementations have moved to the java.base module and java.base module will now be responsible for supporting these algorithms.

Applications that relied on jdk.random module, either through their build scripts or through module dependencies, should remove references to this module.

javax.lang.model.type.TypeMirror::toString for an inner class always returns a qualified class name.

The undocumented DontYieldALot product flag was introduced to mitigate a scheduling anomaly that could arise on the Solaris operating system. It has not been needed for many years nor has it operated as described for many years. The flag has now been marked as deprecated and will be obsoleted and then removed in future releases.

The locale data based on the Unicode Consortium's CLDR has been upgraded to version 45. Besides the usual addition of new locale data and translation changes, there is one notable number format change from the upstream CLDR, affecting the java.text.CompactNumberFormat class:

• Compact form for Italian "million" switched back to "Mln" (CLDR-17482)

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.

Fixed an issue on Debian Linux distros where jpackage could not always build an accurate list of required packages from shared libraries with symbolic links in their paths, causing installations to fail due to missing shared libraries.

The VM option UseNotificationThread is deprecated, it will be obsoleted and then removed in future releases. When debugging notifications were switched from being sent by the hidden "Service Thread" to the non-hidden "Notification Thread", this option was provided (default true) so that it could be disabled if any problems arose using the "Notification Thread". As no problems have been reported, the "Notification Thread" will become the only way that notifications are sent in the future, and the option will no longer be available.

The HotSpot VM option (-XX:[+-]RegisterFinalizersAtInit ) has been obsoleted in this release. The option was deprecated in JDK 22.

The option -XX:+UseEmptySlotsInSupers has been deprecated in JDK 23 and will become obsolete in JDK 24. The default value is true, which means that the HotSpot JVM will always allocate fields in a super class during field layout where there is aligned space to fit the fields. Code that relies on the position of instance fields should be aware of this detail of instance field layout. The JVM field layout format is not specified by the JVMLS and is subject to change.

The size of CipherInputStream's internal buffer has been increased from 512 bytes to 8192 bytes.

The VM option PreserveAllAnnotations is deprecated. Use of this option will produce a deprecation warning. The option will be obsoleted and then removed in future releases. This option was introduced to support testing of Java Annotation code and has always been disabled by default.

The JMX Subject Delegation feature has been removed. The method javax.management.remote.JMXConnector.getMBeanServerConnection(Subject delegationSubject) will throw an UnsupportedOperationException if a non-null delegation subject is provided. 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.

See Security in Java Management Extensions Guide for more information.

The java.security.debug system property now accepts arguments which add thread ID, thread name, caller information, and timestamp information to debug statements for all components or a specific component.

+timestamp can be appended to debug options to print a timestamp for that debug option. +thread can be appended to debug options to print thread and caller information for that debug option.

Examples: -Djava.security.debug=all+timestamp+thread adds timestamp and thread information to every debug statement generated.

-Djava.security.debug=properties+timestamp adds timestamp information to every debug statement generated for the properties component.

You can also specify -Djava.security.debug=help which will display a complete list of supported components and arguments.

See Enabling Debugging in JGSS and Kerberos for more information.

By default, the generated API documentation now includes DejaVu web fonts used by the default style sheet.

A new --no-fonts option was added to the Standard Doclet to omit web fonts from the generated documentation when they are not needed.

JDK 17 introduced the performance improvement that made OCSP client unconditionally use GET requests for small requests, while doing POST requests for everything else. This is explicitly allowed and recommended by RFC 5019 and RFC 6960. However, we have seen OCSP responders that, despite RFC requirements, are not working well with GET requests.

This release introduces a new JDK system property to allow fallback to POST-only behavior to unblock interaction with those OCSP responders: -Dcom.sun.security.ocsp.useget={false,true}. This amends the original change that introduced GET OCSP requests (JDK-8179503). The default behavior is not changed; the option defaults to true. Set the option to false to disable GET OCSP requests. Any value other than false (case-insensitive) defaults to true.

This option is non-standard, and might go away once problematic OCSP responders get upgraded.

The terminally deprecated method Subject.getSubject(AccessControlContext) has been re-specified to throw UnsupportedOperationException if invoked when a Security Manager is not allowed.

This method will be degraded further in a future release to throw UnsupportedOperationException unconditionally.

Maintainers of code using Subject.doAs and Subject.getSubject are strongly encouraged to migrate this code to the replacement APIs, Subject.callAs and Subject.current, as soon as possible. The jdeprscan tool can be used to scan the class path for usages of deprecated APIs and may be useful to find usage of these two methods.

The temporary workaround in this release to keep older code working is to run with

-Djava.security.manager=allow to allow a Security Manager be set. The Subject.getSubject method does not set a Security Manager but requires the feature be "allowed" due to the AccessControlContext parameter.

As background, the changes in this release are to help applications prepare for the eventual removal of the Security Manager. For this release, subject authorization and the Subject APIs behave differently depending on whether a Security Manager is allowed or not:

• If a Security Manager is allowed (meaning the system property java.security.manager is set on the command line to the empty string, a class name, or the value "allow") then there is no behavior change when compared to previous releases.

• If a Security Manager is not allowed (the system property java.security.manager is not set on the command line or has been set on the command line to the value "disallow") then the doAs or callAs methods invoke an action with a Subject as the current subject for the bounded period execution of the action. The Subject can be obtained using the Subject.current method when invoked by code executed by the action. The Subject.getSubject method cannot obtain the Subject as that method will throw UnsupportedOperationException. The Subject is not inherited automatically when creating or starting new threads with the Thread API. The Subject is inherited by child threads when using [Structured Concurrency] (https://openjdk.org/jeps/462).

As noted above, maintainers of code using Subject.doAs and Subject.getSubject are strongly encouraged to migrate the code to Subject.callAs and Subject.current as soon as possible.

Code that stores a Subject in an AccessControlContext and invokes AccessController.doPrivileged with that context should also be migrated as soon as possible as this code will cease to work when the Security Manager is removed.

Maintainers of code that use the Subject API should also audit their code for any cases where it may depend on inheritance of the current Subject into newly created threads. This code should be modified to pass the Subject to the newly created thread or modified to make use of structured concurrency.

The GZipInputStream read methods have been modified to remove the usage of InputStream::available() when determining if the stream contains a concatenated GZIP stream. These methods will now read any additional data in the underlying InputStream and check for the presence of a GZIP stream header.

Debug output related to JGSS/Kerberos, including those for the JAAS Krb5LoginModule, the JGSS framework, and the Kerberos 5 and SPNEGO mechanisms (whether implemented in pure Java or through a native bridge), is now directed to the standard error output stream (System.err) instead of the standard output stream (System.out). Additionally, debug output is now prefixed with a category tag, such as krb5loginmodule, jgss, krb5, etc.

A new lightweight locking mechanism for uncontended 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 this release the LockingMode default has been changed to LM_LIGHTWEIGHT.

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.

If you need to revert to the legacy mechanism you can set the command-line flag -XX:LockingMode=1, but note that it is expected the legacy mode will be removed in a future release.

For a java.text.DecimalFormat created with an empty String pattern, the value returned by DecimalFormat.getMaximumFractionDigits() will now be 340, instead of the previous value, Integer.MAX_VALUE. This prevents an OutOfMemoryError from occurring when DecimalFormat.toPattern() is called. If the desired maximum fractional digits should exceed 340, it is recommended to achieve this behavior using the method DecimalFormat.setMaximumFractionDigits().

The JVMTI GetCurrentContendedMonitor implementation has been aligned with the spec, so the monitor is returned only when the specified thread is waiting to enter or re-enter the monitor and the monitor is not returned when the specified thread is waiting in the java.lang.Object.wait to be notified.

The JDWP ThreadReference.CurrentContendedMonitor command spec was updated to match the JVMTI GetCurrentContendedMonitor spec. It states now: "The thread may be waiting to enter the object's monitor, or in java.lang.Object.wait waiting to re-enter the monitor after being notified, interrupted, or timed-out."

This part has been removed from the command description: "... it may be waiting, via the java.lang.Object.wait method, for another thread to invoke the notify method."

The JDI ThreadReference.currentContendedMonitor method spec was updated to match the JVMTI GetCurrentContendedMonitor spec. It states now: "The thread can be waiting for a monitor through entry into a synchronized method, the synchronized statement, or Object.wait() waiting to re-enter the monitor after being notified, interrupted, or timed-out."

This part has been added to the method description: "... or Object.wait() waiting to re-enter the monitor after being notified, interrupted, or timed-out."

And this part has been removed from the method description: "The status() method can be used to differentiate between the first two cases and the third."

The JVMTI GetObjectMonitorUsage function returns the following data structure:

    typedef struct {
        jthread owner;
        jint entry_count;
        jint waiter_count;
        jthread* waiters;
        jint notify_waiter_count;
        jthread* notify_waiters;
    } jvmtiMonitorUsage;

Two fields in this structure are specified as:

• waiter_count [jint]: The number of threads waiting to own this monitor
• waiters [jthread*]: The waiter_count waiting threads

In previous releases, the waiters field included the threads waiting to enter or re-enter the monitor as specified, but also (incorrectly) the threads waiting to be notified in java.lang.Object.wait(). That has been fixed in the current release. The waiter_count always matches the returned number of threads in the waiters field.

Also, the JDWP ObjectReference.MonitorInfo command spec was updated to clarify what the waiters threads are:

waiters: "The total number of threads that are waiting to enter or re-enter the monitor, or waiting to be notified by the monitor."

The behavior of this JDWP command is kept the same, and is intentionally different to GetObjectMonitorUsage.

Native executables and libraries on Linux have switched to using RPATH instead of RUNPATH in this release.

JDK native executables and libraries use embedded runtime search paths to locate other internal JDK native libraries. On Linux these can be defined as either RPATH or RUNPATH. The main difference is that the dynamic linker considers RPATH before the LD_LIBRARY_PATH environment variable, while RUNPATH is only considered after LD_LIBRARY_PATH.

By making the change to using RPATH, it is no longer possible to replace JDK internal native libraries using LD_LIBRARY_PATH.

The legacy JRE locale data has been removed from the JDK. The legacy JRE locale data, (COMPAT is an alias for this locale data), remained after the CLDR locale data based on the Unicode Consortium's Common Locale Data Registry became the default since JDK 9. It served as an application's migration means for the time being. Since JDK 21, users have been notified of its future removal with the startup warning message as the use of JRE/COMPAT locale data was deprecated. It is now removed from JDK 23, so specifying JRE or COMPAT in java.locale.providers system property no longer has any effect. Applications using JRE/COMPAT locale data are encouraged to migrate to CLDR locale data or consider a workaround discussed in the CSR.

Array element bases are no longer unconditionally aligned to 8 bytes. Instead, they are now aligned to their element type size. This improves footprint in some JVM modes. As Java array element alignment is not exposed to users, there is no impact on regular Java code that accesses individual elements.

There are implications for bulk access methods. Unsafe accesses to arrays could now be unaligned. For example, Unsafe.getLong(byteArray, BYTE_ARRAY_BASE_OFFSET + 0) is not guaranteed to work on platforms that do not allow unaligned accesses, the workaround is Unsafe.{get, put}Unaligned* family of methods. The ByteBuffer and VarHandle APIs that allow views of byte[] are updated to reflect this change (JDK-8318966). Arrays that are acquired via GetPrimitiveArrayCritical should not be operated upon under the assumption of particular array base alignment as well.

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

+ Certainly
  + certainlyrootr1
    DN: CN=Certainly Root R1, O=Certainly, C=US

+ Certainly
  + certainlyroote1
    DN: CN=Certainly Root E1, O=Certainly, C=US

TrimNativeHeapInterval has been made an official product switch. It allows the JVM to trim the native heap at periodic intervals.

This option is only available on Linux with glibc.

The var handle returned by MethodHandles::byteArrayViewVarHandle no longer supports atomic access modes, and the var handle returned by MethodHandles::byteBufferViewVarHandle no longer supports atomic access modes when accessing heap buffers. Additionally, the ByteBuffer::alignedSlice and ByteBuffer::alignmentOffset methods are updated to reflect these changes. They no longer report aligned slices or offsets for heap byte buffers when the accessed 'unitSize' is greater than 1, and instead throw an UnsupportedOperationException in those cases.

The removed functionality was based on an implementation detail in the reference JVM implementation that is not mandated by the JVM specification, and is therefore not guaranteed to work on an arbitrary JVM implementation. This also allows the reference implementation to align array elements more loosely, if it is deemed beneficial 1.

Affected clients should consider using direct (off-heap) byte buffers, for which aligned access can reliably be guaranteed. Or they should use a long[] to store their data, which has stronger alignment guarantees than byte[]. A MemorySegment backed by a long[] array can be accessed through an atomic access mode and any primitive type, using the newly introduced Foreign Function and Memory API 3 as follows:

long[] arr = new long[10];
MemorySegment arrSeg = MemorySegment.ofArray(arr);
VarHandle vh = ValueLayout.JAVA_INT.varHandle(); // accessing aligned ints
vh.setVolatile(arrSeg, 0L, 42); // 0L is offset in bytes
long result = vh.getVolatile(arrSeg, 0L); // 42

MessageFormat objects are created from pattern strings that contain nested subformat patterns. Conversely, the MessageFormat.toPattern() instance method returns a pattern string that should be equivalent (though not necessarily identical) to the original. However, if a nested subformat pattern contained a quoted (i.e., intended to be plain text) opening or closing curly brace character ({ or }), in some cases that quoting could be incorrectly omitted in the pattern string.

As a result of this bug, creating a new MessageFormat from that pattern could fail to parse correctly (throwing an exception) or parse differently, resulting in a new instance that was not equivalent to the original.

This problem has now been fixed. The fix does not change the behavior of MessageFormat objects whose MessageFormat.toPattern() output was already correctly quoted.

Parsing of date/time strings now allows the "loose matching" of spaces. This enhancement is mainly to address the incompatible changes introduced in JDK 20 with CLDR version 42. That version replaced ASCII spaces (U+0020) between time and the am/pm marker with NNBSP (Narrow No-Break Space, U+202F) in some locales. The "loose matching" is performed in the "lenient" parsing style for both date/time parsers in java.time.format and java.text packages. In the "strict" parsing style, those spaces are considered distinct, as before.

To utilize the "loose matching" in the java.time.format package, applications will need to explicitly set the leniency by calling DateTimeFormatterBuilder.parseLenient() because the default parsing mode is strict:

    var dtf = new DateTimeFormatterBuilder()
        .parseLenient()
        .append(DateTimeFormatter.ofLocalizedTime(FormatStyle.SHORT))
        .toFormatter(Locale.ENGLISH);

In the java.text package, the default parsing mode is lenient. Applications will be able to parse all space separators automatically, which is the default behavior changes with this feature. In case they need to strictly parse the text, they can do:

    var df = DateFormat.getTimeInstance(DateFormat.SHORT, Locale.ENGLISH);
    df.setLenient(false);

The "jstack" command in "jhsdb clhsdb" has been modified to scan for java.util.concurrent locks only if given the -l option. Searching for these locks is a very expensive operation that requires scanning the entire heap. The "jhsdb jstack" and "bin/jstack" commands also have the ability to include this locking information in the output, but do not do so by default.

A new jdk.SerializationMisdeclaration JFR event type is added to the platform. Such events are triggered at runtime when some aspects of serialization related fields and methods are improperly declared. By enabling jdk.SerializationMisdeclaration, JFR will trigger an event for each incorrectly declared aspect of a serializable class when it is loaded in the JVM.

For example, if method writeObject() on a Serializable class has the correct signature but is unintentionally declared public, it is not selected by the serialization machinery. This might come to a surprise to the developer of the class. To help diagnose such problems, jdk.SerializationMisdeclaration events should be enabled.

The standard default.jfc profile does not enable these events, while the standard profile.jfc profile does.

API documentation generated by the standard doclet now comes with enhanced navigation features, including a sidebar containing a table of contents for the current page, and breadcrumb navigation for the current API element in the page header.

In the documentation for classes and interfaces, entries in the table of contents can be filtered using a text input field at the top of the sidebar. A button at the bottom of the sidebar allows the table of contents to be collapsed or expanded for the current session.

The m-let feature has been removed. This removal has no impact on the JMX agent used for local and remote monitoring, the built-in instrumentation of the Java virtual machine, or tooling that uses JMX. The API classes that have been removed are:

• javax.management.loading.MLet
• javax.management.loading.MLetContent
• javax.management.loading.PrivateMLet
• javax.management.loading.MLetMBean

The -Xnoagent option of the java launcher, which was deprecated for removal in a previous release, has now been removed. Before it was deprecated for removal, this option was treated as non-operational when specified. Launching java with this option will now result in an error and the process will fail to launch. Applications using this option when launching the java command are expected to remove it.

The method java.lang.ThreadGroup.stop() has been removed in this release. This inherently unsafe method was deprecated in JDK 1.2 (1998), deprecated for removal in Java 18, and re-specified/degraded in Java 20 to throw UnsupportedOperationException unconditionally. Code that uses this method will no longer compile. Code using this method that is compiled to older releases will throw NoSuchMethodError if executed on JDK 23. It previously threw UnsupportedOperationException.

The methods java.lang.Thread.suspend(), java.lang.Thread.resume(), java.lang.ThreadGroup.suspend(), and java.lang.ThreadGroup.resume() have been removed in this release. These deadlock prone methods were deprecated in JDK 1.2 (1998), deprecated for removal in Java 14, and re-specified/degraded in Java 19/20 to throw UnsupportedOperationException unconditionally. Code that uses these methods will no longer compile. Code using these methods that is compiled to older releases will throw NoSuchMethodError if executed on JDK 23. It previously threw UnsupportedOperationException.