RELEASE NOTES: JDK 23

Type Element Name of an Inner Class Is Always Qualified

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

New javac `-Xlint` Suboption to Report "Dangling Doc Comments"

A new suboption is provided for the javac -Xlint option, to detect issues related to the placement of documentation comments in source code.

The name for the new suboption is dangling-doc-comments. The suboption can be specified explicitly (for example, -Xlint:dangling-doc-comments) or implicitly, as one of all the suboptions (for example, -Xlint or -Xlint:all). When the suboption is enabled, javac will report any unexpected or misplaced documentation comments in the vicinity of a declaration, such as in the following situations:

• a documentation comment for a top-level class before any package or import declaration;
• a documentation comment for a declaration that appears after the first token of that declaration, such as after any annotations or other modifiers for the declaration; or
• any additional documentation comments before a declaration, which javac would otherwise ignore.

As with any suboption for -Xlint, warnings can be suppressed locally, using an @SuppressWarnings annotation on an enclosing declaration, specifying the names of the suboptions for the warnings to be suppressed.

Note: it is possible that when the suboption is enabled, javac may report some "false positives" if there are any decorative comments that begin with /** and thus may resemble a documentation comment. For example, comments using a line of asterisks before and after the rest of the comment text, to help make the comment "stand out". The remedy in such cases is to change the comment so that it does not begin with /** -- perhaps by changing at least the second asterisk to some other character.

Annotation processing in `javac` disabled by default

As of JDK 23, annotation processing is only run with some explicit configuration of annotation processing or with an explicit request to run annotation processing on the javac command line. This is a change in behavior from the existing default of looking to run annotation processing by searching the class path for processors without any explicit annotation processing related options needing to be present.

Invocations of javac that rely on annotation processing without any explicit annotation processing configuration will need to be updated to keep running annotation processors. In JDK 21 and 22, javac prints a note identifying such invocations. To preserve the old behavior, "-proc:full" can be passed to javac. Support for "-proc:full" has been backported to several update release trains and is also supported as of a recent version of the Maven Compiler plugin. In updated versions of the Compiler plugin, the property in question will appear as: "User Property: maven.compiler.proc" and users can configure it via -Dmaven.compiler.proc=full on the command-line.

Local Classes Declared before Superclass Construction No Longer Have Enclosing Instances

Local classes declared inside superclass constructor invocation parameter expressions are no longer compiled with immediately enclosing outer instances.

According to JLS 21 §15.9.2, local and anonymous classes declared in a static context do not have immediately enclosing outer instances. This includes classes declared inside a parameter expression of a super() or this() invocation in a constructor for some class C. Previously, the compiler was incorrectly allowing local classes declared within such parameter expressions to contain references to the C outer instance; this is no longer allowed. Although previously allowed, such references were pointless because any subsequent attempt to instantiate the class would trigger a cannot reference this before supertype constructor has been called error. Note that the compiler was already correctly disallowing anonymous classes from containing such references.

Although declaring an anonymous inner class within a super() or this() parameter expression is easy and common, for example in an expression like super(new Runnable() { ... }), declaring a local class within a super() or this() parameter expression is much less common as it requires more syntactic gymnastics. Here's an example that compiled previously but no longer compiles after this change: ` import java.util.concurrent.atomic.*; public class Example extends AtomicReference<Object> { public Example() { super(switch (0) { default -> { class Local { { System.out.println(Example.this); } } yield null; // yield new Local(); // generates compiler error } }); } } After this change, the reference toExample.thisgenerates ano enclosing instance of type Example is in scope` compiler error.

Deprecation of the `java.beans.beancontext` Package

The java.beans.beancontext.* package was added in the JDK 1.2 release, well in advance of new language features such as annotations, lambdas, and modules, as well as programming paradigms such as "Declarative Configuration", "Dependency Injection", and "Inversion of Control".

Based on concepts from OpenDoc, developed by Apple Computer in the mid to late 1990's, this package was intended to provide mechanisms for the assembly of JavaBeans(tm) components into hierarchies. This enabled individual components to produce and consume services expressed as interfaces by their peers, ancestors, and descendants.

With the advancements in the language, these APIs are now both obsolete and express an "anti-pattern" of component assembly and interaction. They are therefore deprecated for removal in a future release.

Developers should no longer use these APIs. They should plan to migrate any existing code dependent on this package to an alternate solution in anticipation of their future removal.

Removal of Module `jdk.random`

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.

Methods `RandomGeneratorFactory.create(long)` and `create(byte[])` Now Throw `UnsupportedOperationException` Instead of Falling Back to `create()`

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().

`HttpServer` No Longer Immediately Sends Response Headers

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 Meaning of Contended Monitor Has Been Clarified in JVM TI, JDWP, and JDI

The JVMTI GetCurrentContendedMonitor implementation has been aligned with the spec. Thus, a 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 Implementation of JVMTI `GetObjectMonitorUsage` Has Been Corrected

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.

The JVM TI `GetObjectMonitorUsage` Function No Longer Supports Virtual Threads

The JVM TI function GetObjectMonitorUsage has been respecified 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 respecified to only include platform threads.

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

The `Subject.getSubject` API now Requires Setting the `java.security.manager` System Property to '`allow`' on the Command Line

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

When the Security Manager is removed in a future release, the Subject.getSubject(AccessControlContext) method will be degraded further 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 to be set. The Subject.getSubject method does not depend on 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.

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

Fallback Option For POST-only OCSP Requests

JDK 17 introduced a performance improvement that made OCSP clients 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 clients to fallback to POST-only behavior. This unblocks interactions with those OCSP responders through the use of -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.

Verify Classes in `javap`

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

Removal of the Legacy Locale Data

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 with JDK 9 (JEP252). The JRE locale data served as a tool to migrate applications for the time being. Since JDK 21, users have been notified of its future removal with a 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 the 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. JEP 252: Use CLDR Locale Data by Default has been updated with recommendations for developers impacted by the removal of this legacy locale data.

Support for CLDR Version 45

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.

Removal of `Thread.suspend/resume` and `ThreadGroup.suspend/resume`

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 now throw NoSuchMethodError instead of UnsupportedOperationException if executed on JDK 23 or newer.

Removal of `ThreadGroup.stop`

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 now throw NoSuchMethodError instead of UnsupportedOperationException if executed on JDK 23 or newer.

the legacy mechanism check in SunPKCS11 provider is enhanced with service type

Native PKCS11 mechanisms which support decryption but not encryption or signature verification but not signing are considered legacy and are disabled by default. The legacy mechanism check in SunPKCS11 provider is enhanced with the service type. For example, prior to this fix, a mechanism supporting encryption, decryption, and verification but not signing, is considered legacy and can't be used at all. After this fix, the corresponding Cipher service using this mechanism is available since both encryption and decryption are supported. However, the corresponding Signature service is not since only verification is supported. To bypass the legacy mechanism check, set the PKCS11 provider configuration attribute "allowLegacy" to true (default value: false). Note that it is the caller's responsibility to make sure the legacy mechanism is not used for the unsupported functionality, e.g. use this mechanism to sign.

Native Executables and Libraries on Linux Use `RPATH` Instead of `RUNPATH`

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.

Enhance Kerberos Debug Output

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, and others.

Deprecation of the `UseNotificationThread` VM Option

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 (defaulting to 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.

`clhsdb jstack` No Longer Scans for `java.util.concurrent` Locks by Default

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.

Removal of JMX Subject Delegation

To prepare the platform for the removal of the Security Manager, the Java Management Extensions (JMX) "Subject Delegation" feature has been removed in this release.

The method javax.management.remote.JMXConnector.getMBeanServerConnection(Subject delegationSubject) will now throw UnsupportedOperationException if invoked with a non-null delegation subject. If a client application needs to perform operations as, or on behalf of, multiple identities, it will now 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.

Removal of the JMX Management Applet (m-let) Feature

To prepare the platform for the removal of the Security Manager, 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

Make `TrimNativeHeapInterval` a Product Switch

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.

Deprecation of the `PreserveAllAnnotations` VM Option

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.

Java Terminates Unexpectedly on Apple silicon Systems With macOS 14.4

Apple’s final release of the 14.4 update to macOS 14 Sonoma causes some Java applications on Apple silicon systems (M1/M2/M3) to terminate unexpectedly. The issue is not present on Intel-based systems and affects all Java versions.

Although most Java applications will not be affected, at this time there is no practical way to determine if they will be. There is currently no workaround.

Deprecation of the `-XX:+UseEmptySlotsInSupers`

The option -XX:+UseEmptySlotsInSupers has been deprecated in JDK 23 and will become obsolete in JDK 24. The default value is "true". This 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.

Obsolescence of the `RegisterFinalizersAtInit` Option

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

Relax Alignment of Array Elements

Array element bases are no longer unconditionally aligned to eight bytes. Instead, they are now aligned to their element type size. This improves the 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. A workaround is the 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 a particular array base alignment.

The `-Xnoagent` Option for the `java` Launcher Is Obsolete

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.

Change LockingMode Default from `LM_LEGACY` to `LM_LIGHTWEIGHT`

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. 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 legacy mode is expected to be removed in a future release.

Deprecation of the `DontYieldALot` Flag

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.

Added Certainly R1 and E1 Root Certificates

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 ```

Support for KeychainStore-ROOT Keystore

The "KeychainStore" of the Apple provider now supports two types of keystores: - "KeychainStore": contains private keys and certificates for the user's current keychain - "KeychainStore-ROOT": contains certificates from the system root certificates keychain

Thread and Timestamp Options for java.security.debug System Property

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 Printing Thread and Timestamp Information for more information.

Thread and Timestamp Options for java.security.debug System Property

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 Printing Thread and Timestamp Information for more information.

Thread and Timestamp Options for java.security.debug System Property

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 Printing Thread and Timestamp Information for more information.

Added GlobalSign R46 and E46 Root CA Certificates

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 ```

Loose Matching of Space Separators in Lenient Date/Time Parsing Mode

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); `

Support for Duration Until Another Instant

A new method has been added to the 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.

Template for Creating Strict JAXP Configuration File

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

Add `jdk.SerializationMisdeclaration` JFR Event

A new jdk.SerializationMisdeclaration JFR event type is added to the platform. Such an event is triggered at runtime when some aspect 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 the writeObject() method on a Serializable class has the correct signature but is unintentionally declared public, it is not selected by the serialization machinery. This might come as 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.

Enable Case-Sensitive Check in `ccache` and `keytab` Kerberos Entry Lookup

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.

See Kerberos System Properties, Security Properties, and Environment Variables.

Removal of Aligned Access Modes for `MethodHandles::byteArrayViewVarHandle`, `byteBufferViewVarHandle`, and Related Methods

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. They 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. Therefore, it is 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 `

`jpackage` Apps May Fail to Build on Debian Linux Distros Due to Missing Shared Libraries

There is 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.

`jpackage` May Produce an Inaccurate List of Required Packages on Debian Linux Distros

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.

Change of the Default Maximum Fraction Digits for the Empty Pattern of `java.text.DecimalFormat`

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().

Escaping in `MessageFormat` Pattern Strings

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 (that is, 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.

`GZIPInputStream` Will No Longer Use `InputStream.available()` to Check for the Presence of Concatenated GZIP Stream

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.

Latency Issue Due to `ICBufferFull` Safepoints Resolved

The invokevirtual bytecode implementation relied on spinning up machine code stubs called "inline cache stubs" to achieve better performance. However, these stubs were created in a buffer of a fixed size, and when the buffer got exhausted, safepoints would be scheduled to refill the buffer. This could lead to latency issues. It was particularly problematic during concurrent class unloading using ZGC. The issue has been resolved by going back to the original problem the stubs set out to solve, and solving it in a different way without any stubs.

Increase `CipherInputStream` Buffer Size

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

KEM.getInstance() Should Check If a Third-Party Security Provider Is Signed

When instantiating a third-party security provider's implementation (class) of a KEM algorithm, the framework will determine the provider's codebase (JAR file) and verify its signature. In this way, JCA authenticates the provider and ensures that only providers signed by a trusted entity can be plugged into the JCA. This is consistent with other JCE service classes, such as Cipher, Mac, KeyAgreement, and others.

Add a System Property to Set the Maximum Number of `WatchService` Events before Overflow

The java.nio.file.WatchService implementations buffer up to a maximum number of events before discarding events and then queuing the OVERFLOW event. A new system property, jdk.nio.file.WatchService.maxEventsPerPoll, has been added to allow someone to specify the maximum number of pending events which may be enqueued before an OVERFLOW event is emitted. The value of this property must be a positive integer.

JFR: Increased Startup Time when Using `-XX:StartFlightRecording`

A noticeable increase in startup time can be observed when using the -XX:StartFlightRecording option with smaller applications. This is due to an ongoing initiative to reduce technical debt in the JFR bytecode instrumentation. The work is anticipated to be finished in a future release, resulting in a startup time that is comparable to JDK 21.

Resolution of Startup Time Regression with `-XX:StartFlightRecording`

The technical debt in the JFR bytecode instrumentation that caused a noticeable increase in startup time in JDK 22 when using the -XX:StartFlightRecording option with smaller applications has been fixed. Startup times are now comparable to JDK 21.

AWT SystemTray API Is Not Supported on Most Linux Desktops

The java.awt.SystemTray API is used for notifications in a desktop taskbar and may include an icon representing an application. On Linux, the Gnome desktop's own icon support in the taskbar has not worked properly for several years due to a platform bug. This, in turn, has affected the JDK's API, which relies upon that.

Therefore, in accordance with the existing Java SE specification, java.awt.SystemTray.isSupported() will return false where ever the JDK determines the platform bug is likely to be present.

The impact of this is likely to be limited since applications always must check for that support anyway. Additionally, some distros have not supported the SystemTray for several years unless the end-user chooses to install non-bundled desktop extensions.

Improve Structural Navigation in API Documentation

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.

`javadoc` Now Requires Correct Class Name in Member Reference

A bug has been fixed in javadoc. Previously, the @see and {@link...} tags allowed a nested class to be used to qualify the name of a member of the enclosing class. They no longer do so. Because of this, documentation comments that previously relied on this behavior will now trigger a warning or error when processed by javadoc.

Add DejaVu Web Fonts

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.

Support for JavaScript Modules in `javadoc`

The javadoc --add-script option now supports JavaScript modules in addition to conventional script files. Modules are detected automatically by inspecting the extension or content of the file passed as option argument.

Console Methods With Explicit Locale

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 `

JVM May Crash or Malfunction When Using ZGC and Non-Default `ObjectAlignmentInBytes`

Running the JVM with -XX:+UseZGC and non-default value of -XX:ObjectAlignmentInBytes may lead to JVM crashes or incorrect execution.

Parallel GC Throws OOM Before Heap Is Fully Expanded

An existing bug may have prevented the full usage of the Java heap allotted with the command line flag -Xmx. That bug has been fixed with JDK-8328744. As a side effect of this fix, installations may experience an increased heap usage when using Parallel GC. Customers should, if necessary, adjust the maximum heap size.

New Parallel GC Full GC algorithm

Parallel GC now uses the same Full GC algorithm found in Serial GC and G1 GC Full GCs.

The previous algorithm consisted of three passes through every live object in the Java heap:

1. Marking live objects
2. Calculating new locations for every live object
3. Moving objects to new locations and update fields of every object

The object locations calculated in step 2 are stored using off-heap memory to avoid a fourth pass through the live objects in the Java heap. The problem is that this scheme does not scale well for certain problematic workloads. Additionally this data structure uses 1.5% of the Java heap in off-heap memory.

The new algorithm performs significantly better for the problematic workloads, and does not need the additional memory, reducing the footprint for all workloads.

G1: Grow Marking Stack during Reference Processing

During the Concurrent Mark phase, G1 may increase the marking stack size on demand, starting from a minimum and potentially reaching a maximum value as defined by the -XX:MarkStackSize and -XX:MarkStackSizeMax command line options.

Previously, G1 has been unable to grow the marking stack during the Reference Processing phase in the Remark pause, which could result in a mark stack overflow error that exits the virtual machine before reaching the limit imposed by -XX:MarkStackSizeMax.

With this update, the marking stack is allowed to also expand during Reference Processing, preventing this premature overflow error.

Name Change for Filler Array Objects from `jdk.vm.internal.FillerArray` to `[Ljdk/internal/vm/FillerElement;`

One HotSpot virtual machine internal class to indicate an area of dead (unreachable) memory has been renamed to conform to the Java class naming standard to avoid confusing external applications parsing virtual machine class histograms provided by jmap -histo.

There are applications that parse the output of jmap -histo which fail when encountering the class jdk.vm.internal.FillerArray. In particular, the issue is that this type of filler object represents a flexibly sized range of unreachable memory but is named as if it were a fixed size non-array object. Then, for example, calculating the instance size of these objects from the jmap -histo output can result in non-integral instance sizes, confusing applications.

This problem has been fixed by changing the name of this class to the array-like name [Ljdk/internal/vm/FillerElement;.

The ClassLoadingMXBean and MemoryMXBean isVerbose Methods Are Now Consistent with Their setVerbose Methods

The ClassLoadingMXBean::setVerbose(boolean enabled) method will set class+load* logging on log output stdout to level info if enabled is true, and to level off otherwise. In contrast, the isVerbose method would check if exactly class+load logging was enabled at the info level on any log output. This could result in counter-intuitive behavior when logging class+load=info to a file via the command-line, as it caused isVerbose to return true, even after a call to setVerbose(false) had been made. A similar problem existed for the MemoryMXBean::isVerbose method. Starting with this release, the behavior is as follows:

• ClassLoadingMXBean::isVerbose will return true only if class+load* logging (note the wildcard use) has been enabled at the info level (or above) on the stdout log output.
• MemoryMXBean::isVerbose will return true only if gc logging has been enabled at the info level (or above) on the stdout log output.