Publication Date: 17 September 2024
The following sections are included in these Release Notes:
These notes describe important changes, enhancements, removed APIs and features, deprecated APIs and features, and other information about JDK 23 and Java SE 23. In some cases, the descriptions provide links to additional detailed information about an issue or a change. This page does not duplicate the descriptions provided by the Java SE 23 ( JSR 398) Platform Specification, which provides informative background for all specification changes and might also include the identification of removed or deprecated APIs and features not described here. The Java SE 23 ( JSR 398) specification provides links to:
Annex 1: The complete Java SE 23 API Specification.
Annex 2: An annotated API specification showing the exact differences between Java SE 22 and Java SE 23. Informative background for these changes may be found in the list of approved Change Specification Requests for this release.
Annex 3: Java SE 23 Editions of The Java Language Specification and The Java Virtual Machine Specification. The Java SE 23 Editions contain all corrections and clarifications made since the Java SE 22 Editions, as well as additions for new features.
You should be aware of the content in the Java SE 23 ( JSR 398) specification as well as the items described in this page.
The descriptions on this Release Notes page also identify potential compatibility issues that you might encounter when migrating to JDK 23. The Kinds of Compatibility page on the OpenJDK wiki identifies the following three types of potential compatibility issues for Java programs that might be used in these release notes:
Source: Source compatibility preserves the ability to compile existing source code without error.
Binary: Binary compatibility is defined in The Java Language Specification as preserving the ability to link existing class files without error.
Behavioral: Behavioral compatibility includes the semantics of the code that is executed at runtime.
See CSRs Approved for JDK 23 for the list of CSRs closed in JDK 23 and the Compatibility & Specification Review (CSR) page on the OpenJDK wiki for general information about compatibility.
The full version string for this release is build 23+37 (where "+" means "build"). The version number is 23.
IANA Data 2024a
JDK 23 contains IANA time zone data version 2024a. For more information, refer to Timezone Data Versions in Java Runtimes.
➜ 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.
See JEP 476
➜ 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.
See JEP 477
➜ Class-File API (Second Preview)
Provide a standard API for parsing, generating, and transforming Java class files. This is a preview API.
See JEP 466
➜ 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.
See JEP 473
➜ 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.
See JEP 480
➜ 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.
See JEP 481
➜ 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.
See JEP 469
➜ 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.
See JEP 474
➜ Markdown Documentation Comments
Enable JavaDoc documentation comments to be written in Markdown rather than solely in a mixture of HTML and JavaDoc @
-tags.
➜ 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.
➜ 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.
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.
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.
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.
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
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.
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.
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.
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:
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.
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.
The "KeychainStore" of the Apple provider now supports two types of keystores:
See The Apple Provider for more information.
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.
-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:
package
or import
declaration;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.
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
(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.
javap
(JDK-8182774)
New javap
option, -verify
, prints additional class verification info.
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
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.
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.
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.
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
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.
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.
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.
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
-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.
RegisterFinalizersAtInit
Option
(JDK-8320522)
The HotSpot VM option (-XX:[+-]RegisterFinalizersAtInit
) has been made obsolete in this release. The option was deprecated in JDK 22.
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.
Additional sources of information about the APIs, features, and options deprecated in Java SE 23 and JDK 23 include:
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.
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.
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.
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.
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.
-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.
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.
The following notes describe previous known issues or limitations that have been corrected in this release.
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.
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.
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()
.
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);
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.
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;
.
-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.
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 monitorwaiters
[jthread*
]: The waiter_count
waiting threadsIn 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
.
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."
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.
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
.
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.
The following notes describe known issues or limitations in this release.
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.
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]
.
ObjectAlignmentInBytes
(JDK-8325074)
Running the JVM with -XX:+UseZGC
and non-default value of -XX:ObjectAlignmentInBytes
may lead to JVM crashes or incorrect execution.
-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.
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.
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()
.
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.
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:
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.
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.
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.
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.
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.
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.
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.
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.
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
.
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.
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
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
CipherInputStream
Buffer Size
(JDK-8330108)
The size of CipherInputStream
's internal buffer has been increased from 512 bytes to 8192 bytes.
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.
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.
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.
javax.lang.model.type.TypeMirror::toString
for an inner class always returns a qualified class name.
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.
Although we have stated the goal to have Oracle JDK and OpenJDK binaries be as close to each other as possible, there remain several differences between the two options.
The current differences are:
msi
, rpm
, deb
, etc.) which not only place the JDK binaries in your system but also contain update rules and in some cases handle some common configurations like set common environmental variables (such as, JAVA_HOME in Windows) and establish file associations (such as, use java
to launch .jar
files). OpenJDK is offered only as compressed archive (tar.gz
or .zip
).java -version
is different. Oracle JDK returns java and includes the Oracle-specific identifier. OpenJDK returns OpenJDK and does not include the Oracle-specific identifier.\legal\java.desktop\freetype.md
is therefore different.