Java JDK 23 (64-bit)

What's new in this version:

Major New Functionality:
Primitive Types in Patterns, instanceof, and switch (Preview):
- Enhance pattern matching by allowing primitive type patterns in all pattern contexts, and extend instanceof and switch to work with all primitive types. This is a preview language feature.
- Module Import Declarations (Preview):
- Enhance the Java programming language with the ability to succinctly import all of the packages exported by a module. This simplifies the reuse of modular libraries, but does not require the importing code to be in a module itself. This is a preview language feature.
- Flexible Constructor Bodies (Second Preview):
- In constructors in the Java programming language, allow statements to appear before an explicit constructor invocation, i.e., super(..) or this(..). The statements cannot reference the instance under construction, but they can initialize its fields. Initializing fields before invoking another constructor makes a class more reliable when methods are overridden. This is a preview language feature.
- Implicitly Declared Classes and Instance Main Methods (Third Preview):
- Evolve the Java programming language so that beginners can write their first programs without needing to understand language features designed for large programs. Far from using a separate dialect of the language, beginners can write streamlined declarations for single-class programs and then seamlessly expand their programs to use more advanced features as their skills grow. Experienced developers can likewise enjoy writing small programs succinctly, without the need for constructs intended for programming in the large. This is a preview language feature.
- Libraries Previews and Incubator:
- Class-File API (Second Preview):
- Provide a standard API for parsing, generating, and transforming Java class files. This is a preview API.
- Stream Gatherers (Second Preview):
- Enhance the Stream API to support custom intermediate operations. This will allow stream pipelines to transform data in ways that are not easily achievable with the existing built-in intermediate operations. This is a preview API.
- Structured Concurrency (Third Preview):
- Simplify concurrent programming by introducing an API for structured concurrency. Structured concurrency treats groups of related tasks running in different threads as a single unit of work, thereby streamlining error handling and cancellation, improving reliability, and enhancing observability. This is a preview API.
- Scoped Values (Third Preview):
- Introduce scoped values, which enable a method to share immutable data both with its callees within a thread, and with child threads. Scoped values are easier to reason about than thread-local variables. They also have lower space and time costs, especially when used together with virtual threads (JEP 444) and structured concurrency (JEP 480). This is a preview API.
- Vector API (Eighth Incubator):
- Introduce an API to express vector computations that reliably compile at runtime to optimal vector instructions on supported CPU architectures, thus achieving performance superior to equivalent scalar computations.
- Performance:
- Graal JIT now Available as Part of the Oracle JDK:
- The Oracle GraalVM JIT compiler (Graal JIT) is now included among the JITs available as part of the Oracle JDK. This integration offers innovations previously made available via GraalVM, such as novel JIT code optimization techniques. This provides developers and sysadmins more options to help fine tune and improve peak performance of their applications. The Graal JIT is enabled by passing the command line options to the Java executable:
- -XX:+UnlockExperimentalVMOptions -XX:+UseGraalJIT
- If you do not pass these flags at JVM startup the Oracle JDK default JIT (C2) will run as usual.
- ZGC: Generational Mode by Default:
- Switch the default mode of the Z Garbage Collector (ZGC) to the generational mode. Deprecate the non-generational mode, with the intent to remove it in a future release.
- Tooling:
- Markdown Documentation Comments:
- Enable JavaDoc documentation comments to be written in Markdown rather than solely in a mixture of HTML and JavaDoc @-tag
- Stewardship:
- Deprecate the Memory-Access Methods in sun.misc.Unsafe for Removal:
- Deprecate the memory-access methods in sun.misc.Unsafe for removal in a future release. These unsupported methods have been superseded by standard APIs, namely the VarHandle API (JEP 193, JDK 9) and the Foreign Function & Memory API (JEP 454, JDK 22). We strongly encourage library developers to migrate from sun.misc.Unsafe to supported replacements, so that applications can migrate smoothly to modern JDK releases.
- Withdrawn JEP:
- String Templates:
- String Templates were first previewed in JDK 21 (JEP 430) and re-previewed in JDK 22 (JEP 459). After feedback and extensive discussion, we concluded that the feature is unsuitable in its current form. There is no consensus on what a better design will be, therefore we have withdrawn the feature for now, and JDK 23 will not include it.
- Important Changes and Information:
- The following are some important changes in and information about this release. In some cases, additional details about the changes described below are provided in these Release Notes.
- tools/javac

➜ Annotation processing in javac disabled by default (JDK-8321314)
- 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.
- New Features:
- This section describes some of the enhancements in Java SE 23 and JDK 23. In some cases, the descriptions provide links to additional detailed information about an issue or a change. The APIs described here are provided with the Oracle JDK. It includes a complete implementation of the Java SE 23 Platform and additional Java APIs to support developing, debugging, and monitoring Java applications. Another source of information about important enhancements and new features in Java SE 23 and JDK 23 is the Java SE 23 ( JSR 398) Platform Specification, which documents the changes to the specification made between Java SE 22 and Java SE 23. This document includes descriptions of those new features and enhancements that are also changes to the specification. The descriptions also identify potential compatibility issues that you might encounter when migrating to JDK 23.

core-libs/java.io ➜ Console Methods With Explicit Locale (JDK-8330276):
- 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

core-libs/java.io:serialization ➜ Add jdk.SerializationMisdeclaration JFR Event (JDK-8275338):
- 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.

core-libs/java.nio ➜ Add a System Property to Set the Maximum Number of WatchService Events before Overflow (JDK-8330077):
- 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.

core-libs/java.time ➜ Support for Duration Until Another Instant (JDK-8331202):
- 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.

hotspot/gc ➜ New Parallel GC Full GC algorithm (JDK-8329203):
- 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:
- Marking live objects
- Calculating new locations for every live object
- 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.

security-libs/java.security ➜ Thread and Timestamp Options for java.security.debug System Property (JDK-8051959):
- 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.

security-libs/java.security ➜ Support for KeychainStore-ROOT Keystore (JDK-8320362):
- The "KeychainStore" of the Apple provider now supports two types of keystores:
- "KeychainStore" which contains private keys and certificates for the user's current keychain
- "KeychainStore-ROOT" which contains certificates from the system root certificates keychain
- See The Apple Provider for more information.

security-libs/org.ietf.jgss:krb5 ➜ Enable Case-Sensitive Check in ccache and keytab Kerberos Entry Lookup (JDK-8331975):
- 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.

tools/javac ➜ New javac -Xlint Suboption to Report "Dangling Doc Comments" (JDK-8303689):
- 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.

tools/javadoc(tool) ➜ Improve Structural Navigation in API Documentation (JDK-8320458):
- 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.

tools/javadoc(tool)➜ Support for JavaScript Modules in javadoc (JDK-8317621):
- 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.

tools/javap➜ Verify Classes in javap (JDK-8182774):
- New javap option, -verify, prints additional class verification info.

xml/jaxp➜ Template for Creating Strict JAXP Configuration File (JDK-8330542):
- 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
- Removed Features and Options:
- This section describes the APIs, features, and options that were removed in Java SE 23 and JDK 23. The APIs described here are those that are provided with the Oracle JDK. It includes a complete implementation of the Java SE 23 Platform and additional Java APIs to support developing, debugging, and monitoring Java applications. Another source of information about important enhancements and new features in Java SE 23 and JDK 23 is the Java SE 23 ( JSR 398) Platform Specification, which documents changes to the specification made between Java SE 22 and Java SE 23. This document includes the identification of removed APIs and features not described here. The descriptions below might also identify potential compatibility issues that you could encounter when migrating to JDK 23. See CSRs Approved for JDK 23 for the list of CSRs closed in JDK 23.

core-libs/java.lang➜ Removal of Thread.suspend/resume and ThreadGroup.suspend/resume (JDK-8320532):
- 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.

core-libs/java.lang➜ Removal of ThreadGroup.stop (JDK-8320786):
- 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.

core-libs/java.lang.invoke➜ Removal of Aligned Access Modes for MethodHandles::byteArrayViewVarHandle, byteBufferViewVarHandle, and Related Methods (JDK-8318966):
- 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 2 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

core-libs/java.util➜ Removal of Module jdk.random (JDK-8330005):
- 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.

core-libs/java.util:i18n➜ Removal of the Legacy Locale Data (JDK-8174269):
- 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.

core-svc/javax.management➜ Removal of JMX Subject Delegation (JDK-8326666):
- 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.

core-svc/javax.management➜ Removal of the JMX Management Applet (m-let) Feature (JDK-8318707):
- 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

hotspot/runtime➜ The -Xnoagent Option for the java Launcher Is Obsolete (JDK-8312150):
- 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.

hotspot/runtime➜ Obsolescence of the RegisterFinalizersAtInit Option (JDK-8320522):
- The HotSpot VM option (-XX:[+-]RegisterFinalizersAtInit ) has been made obsolete in this release. The option was deprecated in JDK 22.

install/install➜ Removal of Obsolete Desktop Integration from Linux Installers (JDK-8322234 (not public)):
- Delete nonfunctional desktop integration functionality from Linux installers. The installers will stop depositing files in /usr/share/icons, /usr/share/mime, and /usr/share/applications subtrees.
- Deprecated Features and Options:
- Additional sources of information about the APIs, features, and options deprecated in Java SE 23 and JDK 23 include:
- The Deprecated API page identifies all deprecated APIs including those deprecated in Java SE 23.
- The Java SE 23 ( JSR 398) specification documents changes to the specification made between Java SE 22 and Java SE 23 that include the identification of deprecated APIs and features not described here.
- JEP 277: Enhanced Deprecation provides a detailed description of the deprecation policy. You should be aware of the updated policy described in this document.
- You should be aware of the contents in those documents as well as the items described in this release notes page.
- The descriptions of deprecated APIs might include references to the deprecation warnings of forRemoval=true and forRemoval=false. The forRemoval=true text indicates that a deprecated API might be removed from the next major release. The forRemoval=false text indicates that a deprecated API is not expected to be removed from the next major release but might be removed in some later release.
- The descriptions below also identify potential compatibility issues that you might encounter when migrating to JDK 23. See CSRs Approved for JDK 23 for the list of CSRs closed in JDK 23.

client-libs/java.beans➜ Deprecation of the java.beans.beancontext Package (JDK-8321428):
- 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.

hotspot/jvmti➜ The JVM TI GetObjectMonitorUsage Function No Longer Supports Virtual Threads (JDK-8328083):
- 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.

hotspot/runtime➜ Deprecration of the PreserveAllAnnotations VM Option (JDK-8329636):
- 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.

hotspot/runtime➜ Deprecation of the DontYieldALot Flag (JDK-8331021):
- 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.

hotspot/runtime➜ Deprecation of -XX:+UseEmptySlotsInSupers (JDK-8330607):
- 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 superclass 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.

hotspot/svc➜ Deprecation of the UseNotificationThread VM Option (JDK-8329113):
- 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.
- Notable Issues Resolved:
- The following notes describe previous known issues or limitations that have been corrected in this release.

core-libs/java.net➜ HttpServer No Longer Immediately Sends Response Headers (JDK-6968351):
- 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 that 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.

core-libs/java.text➜ Escaping in MessageFormat Pattern Strings (JDK-8323699):
- 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.

core-libs/java.text➜ Change of the Default Maximum Fraction Digits for the Empty Pattern of java.text.DecimalFormat (JDK-8326908):
- 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().

core-libs/java.time➜ Loose Matching of Space Separators in Lenient Date/Time Parsing Mode (JDK-8324665):
- 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);

hotspot/gc➜ G1: Grow Marking Stack during Reference Processing (JDK-8280087):
- 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.

hotspot/gc➜ Name Change for Filler Array Objects from jdk.vm.internal.FillerArray to [Ljdk/internal/vm/FillerElement; (JDK-8319548):
- 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;.

hotspot/jfr➜ Resolution of Startup Time Regression with -XX:StartFlightRecording (JDK-8319551):
- 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.

hotspot/jvmti➜ The Implementation of JVM TI GetObjectMonitorUsage Has Been Corrected (JDK-8247972):
- The JVM TI 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 from GetObjectMonitorUsage.

hotspot/jvmti➜ The Meaning of Contended Monitor Has Been Clarified in JVM TI, JDWP, and JDI (JDK-8256314):
- The JVM TI GetCurrentContendedMonitor implementation has been aligned with the specification. 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 JVM TI 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 JVM TI 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."

tools/javac➜ Local Classes Declared before Superclass Construction No Longer Have Enclosing Instances (JDK-8328649):
- 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 to Example.this generates a no enclosing instance of type Example is in scope compiler error.

tools/javadoc(tool)➜ javadoc Now Requires Correct Class Name in Member Reference (JDK-8164094):
- 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.

tools/jpackage➜ jpackage May Produce an Inaccurate List of Required Packages on Debian Linux Distros (JDK-8295111):
- 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.
- Known Issues:
- The following notes describe known issues or limitations in this release.

core-libs/java.nio➜ Files.readString May Return Incorrect String When Using UTF-16 or Other Charsets (JDK-8325605):
- Strings read with java.nio.files.Files.readString may return incorrect strings when decoding with a charset other than US-ASCII, ISO08859-1, or UTF-8. Reading strings with other multi-byte charsets, such as UTF_16, may produce incorrect results.
- As a workaround, disable compact strings by setting -XX:-CompactStrings on the command line.
- This issue will be fixed in a future update.

hotspot/compiler➜ Potential Performance Regression Due to Limited Range Check Elimination (JDK-8314468 (not public)):
- When the C1 compiler is the only compiler available to the VM, it applies loop predication to remove array access range checks from loop bodies. Due to a defect, this optimization was disabled, potentially leading to a performance regression.
- This only affects the client VM or VM's running with the non-default command line flags -XX:+NeverActAsServerClassMachine or -XX:TieredStopAtLevel=[1,2,3].

hotspot/gc➜ JVM May Crash or Malfunction When Using ZGC and Non-Default ObjectAlignmentInBytes (JDK-8325074):
- Running the JVM with -XX:+UseZGC and non-default value of -XX:ObjectAlignmentInBytes may lead to JVM crashes or incorrect execution.

hotspot/jfr➜ JFR: Increased Startup Time when Using -XX:StartFlightRecording (JDK-8319551):
- 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.
- Other Notes:
- The following notes describe additional changes and information about this release. In some cases, the following descriptions provide links to additional detailed information about an issue or a change.

core-libs/java.util➜ Methods RandomGeneratorFactory.create(long) and create(byte[]) Now Throw UnsupportedOperationException Instead of Falling Back to create() (JDK-8332476):
- 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().

core-libs/java.util.jar➜ GZIPInputStream Will No Longer Use InputStream.available() to Check for the Presence of Concatenated GZIP Stream (JDK-7036144):
- 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.

core-libs/java.util:i18n➜ Support for CLDR Version 45 (JDK-8319990):
- 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.

core-svc/java.lang.management➜ The ClassLoadingMXBean and MemoryMXBean isVerbose Methods Are Now Consistent with Their setVerbose Methods (JDK-8338139):
- 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.

hotspot/compiler➜ Latency Issue Due to ICBufferFull Safepoints Resolved (JDK-8322630):
- 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 was exhausted, safepoints were 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.

hotspot/gc➜ Parallel GC Throws OOM Before Heap Is Fully Expanded (JDK-8328744):
- 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.

hotspot/runtime➜ Relax Alignment of Array Elements (JDK-8139457):
- 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.

hotspot/runtime➜ Change LockingMode Default from LM_LEGACY to LM_LIGHTWEIGHT (JDK-8319251):
- 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.

hotspot/runtime➜ Make TrimNativeHeapInterval a Product Switch (JDK-8325496):
- 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.
- hotspot/svc-agent

➜ clhsdb jstack No Longer Scans for java.util.concurrent Locks by Default (JDK-8324066)
- 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.

infrastructure/build➜ Native Executables and Libraries on Linux Use RPATH Instead of RUNPATH (JDK-8326891):
- 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.

install/install➜ Install DEB and RPM Java Packages in Version Directory (JDK-8325265 (not public)):
- The installation directory name of the Oracle JDK in RPM and DEB packages has changed from /usr/lib/jvm/jdk-${FEATURE}-oracle-${ARCH} to /usr/lib/jvm/jdk-${VERSION}-oracle-${ARCH}.
- Every update release will be installed in a separate directory on Linux platform.
- Installers will create a /usr/java/jdk-${FEATURE}-oracle-${ARCH} link pointing to the installation directory to allow programs to find the latest JDK version in the ${FEATURE} release train.
- See General Notes About Installing the JDK on Linux Platforms from RPM Packages for more information.

security-libs/java.security➜ Added GlobalSign R46 and E46 Root CA Certificates (JDK-8316138):
- 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

security-libs/java.security➜ Added Certainly R1 and E1 Root Certificates (JDK-8321408):
- 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

security-libs/javax.crypto➜ Increase CipherInputStream Buffer Size (JDK-8330108):
- The size of CipherInputStream's internal buffer has been increased from 512 bytes to 8192 bytes.

security-libs/javax.security➜ The Subject.getSubject API now Requires Setting the java.security.manager System Property to 'allow' on the Command Line (JDK-8296244):
- 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 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.
- 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.
- See Migrating from the Deprecated-for-Removal Methods Subject::getSubject and Subject::doAs to Subject::current and Subject::callAs for more information.

security-libs/javax.security➜ Fallback Option For POST-only OCSP Requests (JDK-8328638):
- 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 upgrade
- See Fallback Option for POST-Only OCSP Requests for more information

security-libs/org.ietf.jgss➜ Enhance Kerberos Debug Output (JDK-8327818):
- 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.

tools/javac➜ Type Element Name of an Inner Class Is Always Qualified (JDK-8309881):
- javax.lang.model.type.TypeMirror::toString for an inner class always returns a qualified class name.

tools/javadoc(tool)➜ Add DejaVu Web Fonts (JDK-8324774):
- 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.