java

Consolidated JDK 23 Release Notes

Consolidated Release Notes

This page contains all of the release notes for the JDK 23 General Availability (GA) releases:


Java™ SE Development Kit 23.0.2 (JDK 23.0.2)

Release date: January 21, 2025

The full version string for this update release is 23.0.2+7 (where "+" means "build"). The version number is 23.0.2. This JDK conforms to version 23 of the Java SE Specification (JSR 398 2024-09-17).

 

IANA TZ Data 2024b

JDK 23.0.2 contains IANA time zone data 2024b which contains the following changes:

  • Improve historical data for Mexico, Mongolia, and Portugal.
  • System V names are now obsolescent.
  • The main data form now uses %z.
  • The code now conforms to RFC 8536 for early timestamps.
  • Support POSIX.1-2024, which removes asctime_r and ctime_r.

For more information, refer to Timezone Data Versions in the JRE Software.

 

Security Baselines

The security baselines for the Java Runtime at the time of the release of JDK 23.0.2 are specified in the following table:

Java Family Version Security Baseline (Full Version String)
2323.0.2+7
2121.0.6+8
1717.0.14+8
1111.0.26+7
81.8.0_441-b07

 

Keeping the JDK up to Date

Oracle recommends that the JDK is updated with each Critical Patch Update. In order to determine if a release is the latest, the Security Baseline page can be used to determine which is the latest version for each release family.

Critical patch updates, which contain security vulnerability fixes, are announced one year in advance on Critical Patch Updates, Security Alerts and Bulletins. It is not recommended that this JDK (version 23.0.2) be used after the next critical patch update scheduled for April 15, 2025.

Java Management Service, available to all users, can help you find vulnerable Java versions in your systems. Java SE Subscribers and customers running in Oracle Cloud can use Java Management Service to update Java Runtimes and to do further security reviews like identifying potentially vulnerable third party libraries used by your Java programs. Existing Java Management Service user click here to log in to your dashboard. The Java Management Service Documentation provides a list of features available to everyone and those available only to customers. Learn more about using Java Management Service to monitor and secure your Java Installations.

 

Other Notes

core-libs/java.lang
 ProcessBuilder on Windows Quotes Argument Strings Containing Any Space Character (JDK-8335428 (not public))

On Windows, the ProcessBuilder has expanded the quoting of argument strings when starting a process to ensure they are recognized by the application as a single command argument. The set of space characters has been expanded from space (0x20) to include all space characters as defined by java.lang.Character.isSpaceChar, which includes all Unicode space separator characters, such as EN-SPACE (0x2002), and line separator and paragraph separator characters.

core-libs/java.time
 Support for Time Zone Database 2024b (JDK-8339637)

IANA Time Zone Database has been upgraded to 2024b. This version mainly includes changes to improve historical data for Mexico, Mongolia, and Portugal. It also changes one timestamp abbreviation, for the time zone 'MET'. Also Asia/Choibalsan is now an alias for Asia/Ulaanbaatar.

The new tzdata changes also impact some legacy time zone IDs. As per 2024b changes "EST" links to "America/Panama", "HST" links to "Pacific/Honolulu" and "MST" links to "America/Phoenix". To maintain compatibility with the Java SE specification, the java.time.ZoneId.SHORT_IDS Map has not changed. Further details are available at JDK-8342331

 

Bug Fixes

This release also contains fixes for security vulnerabilities described in the Oracle Critical Patch Update.

Issues fixed in 23.0.2:
# JBS Component/Subcomponent Summary
1JDK-8337753core-libs/java.lang.foreignTarget class of upcall stub may be unloaded
2JDK-8341127core-libs/java.lang.foreignExtra call to MethodHandle::asType from memory segment var handles fails to inline
3JDK-8340812core-libs/java.lang.invokeLambdaForm customization via MethodHandle::updateForm is not thread safe
4JDK-8342145core-libs/java.nioFile libCreationTimeHelper.c compile fails on Alpine
5JDK-8341881core-libs/java.nio[REDO] java/nio/file/attribute/BasicFileAttributeView/CreationTime.java#tmp fails on alinux3
6JDK-8340073core-libs/java.util:i18nSupport "%z" time zone abbreviation format in TZ files
7JDK-8321509hotspot/compilerFalse positive in get_trampoline fast path causes crash
8JDK-8333791hotspot/compilerFix memory barriers for @Stable fields
9JDK-8335709hotspot/compilerC2: assert(!loop->is_member(get_loop(useblock))) failed: must be outside loop
10JDK-8342496hotspot/compilerC2/Shenandoah: SEGV in compiled code when running jcstress
11JDK-8340313hotspot/compilerCrash due to invalid oop in nmethod after C1 patching
12JDK-8340214hotspot/compilerC2 compilation asserts with "no node with a side effect" in PhaseIdealLoop::try_sink_out_of_loop
13JDK-8337066hotspot/compilerRepeated call of StringBuffer.reverse with double byte string returns wrong result
14JDK-8340824hotspot/compilerC2: Memory for TypeInterfaces not reclaimed by hashcons()
15JDK-8342681hotspot/gcTestLoadBypassesNullCheck.java fails improperly specified VM option
16JDK-8339648hotspot/gcZGC: Division by zero in rule_major_allocation_rate
17JDK-8340586hotspot/gcJdkJfrEvent::get_all_klasses stores non-strong oops in JNI handles
18JDK-8338389hotspot/jfr[JFR] Long strings should be added to the string pool
19JDK-8337331hotspot/jvmticrash: pinned virtual thread will lead to jvm crash when running with the javaagent option
20JDK-8339725hotspot/jvmtiConcurrent GC crashed due to GetMethodDeclaringClass
21JDK-8335283hotspot/runtimeBuild failure due to 'no_sanitize' attribute directive ignored
22JDK-8335007hotspot/runtimeInline OopMapCache table
23JDK-8340383hotspot/runtimeVM issues warning failure to find kernel32.dll on Windows nanoserver
24JDK-8338058hotspot/runtimemap_or_reserve_memory_aligned Windows enhance remap assertion
25JDK-8338101hotspot/runtimeremove old remap assertion in map_or_reserve_memory_aligned after JDK-8338058
26JDK-8341688hotspot/runtimeAarch64: Generate comments in -XX:+PrintInterpreter to link to source code
27JDK-8325937hotspot/runtimeruntime/handshake/HandshakeDirectTest.java causes "monitor end should be strictly below the frame pointer" assertion failure on AArch64
28JDK-8337958hotspot/runtimeOut-of-bounds array access in secondary_super_cache
29JDK-8340387hotspot/runtimeUpdate OS detection code to recognize Windows Server 2025
30JDK-8335299hotspot/testRemove hs-atr-ci-genzgc
31JDK-8328723security-libs/java.securityIP Address error when client enables HTTPS endpoint check on server socket
32JDK-8337795tools/javacType annotation attached to incorrect type during class reading
33JDK-8337998tools/javacCompletionFailure in getEnclosingType attaching type annotations


Java™ SE Development Kit 23.0.1 (JDK 23.0.1)

Release date: October 15, 2024

The full version string for this update release is 23.0.1+11 (where "+" means "build"). The version number is 23.0.1.

 

IANA TZ Data 2024a

For more information, refer to Timezone Data Versions in the JRE Software.

 

Security Baselines

The security baselines for the Java Runtime at the time of the release of JDK 23.0.1 are specified in the following table:

Java Family Version Security Baseline (Full Version String)
2323.0.1+11
2121.0.5+9
1717.0.13+10
1111.0.25+9
81.8.0_431-b10

 

Keeping the JDK up to Date

Oracle recommends that the JDK is updated with each Critical Patch Update. In order to determine if a release is the latest, the Security Baseline page can be used to determine which is the latest version for each release family.

Critical patch updates, which contain security vulnerability fixes, are announced one year in advance on Critical Patch Updates, Security Alerts and Bulletins. It is not recommended that this JDK (version 23.0.1) be used after the next critical patch update scheduled for January 21, 2025.

Java Management Service, available to all users, can help you find vulnerable Java versions in your systems. Java SE Subscribers and customers running in Oracle Cloud can use Java Management Service to update Java Runtimes and to do further security reviews like identifying potentially vulnerable third party libraries used by your Java programs. Existing Java Management Service user click here to log in to your dashboard. The Java Management Service Documentation provides a list of features available to everyone and those available only to customers. Learn more about using Java Management Service to monitor and secure your Java Installations.

 

Notable Issues Resolved

install/install
 JDK RPM Upgrade Leaves Orphan Alternatives Entry (JDK-8336107 (not public))

Fixed the issue with entries in the "java" and "javac" groups not being properly managed during an RPM upgrade.

Upgrading from an older Java RPM installed into a shared directory (/usr/lib/jvm/jdk-${FEATURE}-oracle-${ARCH}) to a Java RPM installing into a version-specific directory (/usr/lib/jvm/jdk-${VERSION}-oracle-${ARCH}), results in the older Java entries in the "java" and "javac" groups not being deleted.

The issue does not manifest until the new Java is uninstalled. When it is uninstalled and Java from the lower release is installed, running Java commands like java or keytool without the full path specified will result in the "command not found" error. For example, install 21.0.3; upgrade it to 21.0.4; uninstall 21.0.4; install any Java update of 17 or 11 or 8 release; run "java" from the command line. The command will fail with the "command not found" error.

Manually delete orphan Java entries in the "java" and "javac" groups to workaround the issue.

 

Other Notes

core-libs/java.net
 New Default Limits in the JDK HTTP Implementations (JDK-8328286 (not public))

New Default limits have been added to HTTP in the JDK.

The JDK built-in implementation of the legacy URL protocol handler for HTTP, HttpURLConnection, and the new HttpClient, in the module java.net.http, now have a default limit on the maximum response headers size they will accept from a remote party. The limit is set by default at 384kB (393216 bytes) and is computed as the cumulative size of all header names and header values plus an overhead of 32 bytes per header name value pair.

The default value of the limit can be changed by specifying a positive value with the jdk.http.maxHeaderSize system property on the command line, or in the appropriate conf.properties or net.properties file. A negative or zero value is interpreted as no limit. If the limit is exceeded, the request will fail with a protocol exception.

The JDK built-in implementation of the com.sun.net.httpserver.HttpServer (jdk.httpserver) implements a similar limit for the maximum request header size the server is prepared to accept. The HttpServer limit can be changed by specifying a positive value with the sun.net.httpserver.maxReqHeaderSize system property on the command line. A negative or zero value is interpreted as no limit. The limit is set by default at 384kB (393216 bytes) and the size is computed in the same way as explained above. If the limit is exceeded, the connection is closed.

In addition, the JDK built-in implementation of the new java.net.http.HttpClient enforces two additional limits:

The system property jdk.httpclient.maxNonFinalResponses can be specified with a positive value on the java command line, or in the conf.properties or net.properties file, to control how many interim responses the client will accept before receiving a final response. An interim response is considered informational and is a response whose status is in the range [100, 199]. These responses are typically either handled internally or simply discarded by the implementation. The default limit is now set at a maximum of 8 interim responses before receiving the final response. A negative or zero value is interpreted as no limit. If the limit is exceeded, the request will fail with a protocol exception.

The system property jdk.httpclient.maxLiteralWithIndexing can be specified with a positive value on the java command line, or in the conf.properties or net.properties file, to control how many additions a server may request a client to make to the HPack dynamic table when decoding a set of headers. The default maximum value is now set to 512. A negative or zero value is interpreted as no limit. If the limit is exceeded, the request will fail with a protocol exception.

security-libs/java.security
 Added SSL.com TLS Root CA Certificates issued in 2022 (JDK-8341057)

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

+ SSL.com

  + ssltlsrootecc2022
    DN: CN=SSL.com TLS ECC Root CA 2022, O=SSL Corporation, C=US

+ SSL.com
  + ssltlsrootrsa2022
    DN: CN=SSL.com TLS RSA Root CA 2022, O=SSL Corporation, C=US

security-libs/javax.net.ssl
 Distrust TLS Server Certificates Anchored by Entrust Root Certificates and Issued After Nov 11, 2024 (JDK-8337664)

The JDK will stop trusting TLS server certificates issued after November 11, 2024 and anchored by Entrust root certificates, in line with similar plans recently announced by Google and Mozilla. The list of affected certificates includes certificates branded as AffirmTrust, which are managed by Entrust.

TLS server certificates issued on or before November 11, 2024 will continue to be trusted until they expire. Certificates issued after that date, and anchored by any of the Certificate Authorities in the table below, will be rejected.

The restrictions will be enforced in the JDK implementation (the SunJSSE Provider) of the Java Secure Socket Extension (JSSE) API. A TLS session will not be negotiated if the server's certificate chain is anchored by any of the Certificate Authorities in the table below and the certificate has been issued after November 11, 2024.

An application will receive an Exception with a message indicating the trust anchor is not trusted, for example:

TLS server certificate issued after 2024-11-11 and anchored by a distrusted legacy Entrust root CA: CN=Entrust.net Certification Authority (2048),

OU=(c) 1999 Entrust.net Limited, OU=www.entrust.net/CPS_2048 incorp. by ref. (limits liab.), O=Entrust.net

If necessary, and at your own risk, you can work around the restrictions by removing "ENTRUST_TLS" from the jdk.security.caDistrustPolicies security property in the java.security configuration file.

The restrictions are imposed on the following Entrust Root certificates included in the JDK:

Root Certificates distrusted after 2024-11-11
Distinguished Name SHA-256 Fingerprint
CN=Entrust Root Certification Authority, OU=(c) 2006 Entrust, Inc., OU=www.entrust.net/CPS is incorporated by reference, O=Entrust, Inc., C=US

73:C1:76:43:4F:1B:C6:D5:AD:F4:5B:0E:76:E7:27:28:7C:8D:E5:76:16:C1:E6:E6:14:1A:2B:2C:BC:7D:8E:4C

CN=Entrust Root Certification Authority - EC1, OU=(c) 2012 Entrust, Inc. - for authorized use only, OU=See www.entrust.net/legal-terms, O=Entrust, Inc., C=US

02:ED:0E:B2:8C:14:DA:45:16:5C:56:67:91:70:0D:64:51:D7:FB:56:F0:B2:AB:1D:3B:8E:B0:70:E5:6E:DF:F5

CN=Entrust Root Certification Authority - G2, OU=(c) 2009 Entrust, Inc. - for authorized use only, OU=See www.entrust.net/legal-terms, O=Entrust, Inc., C=US

43:DF:57:74:B0:3E:7F:EF:5F:E4:0D:93:1A:7B:ED:F1:BB:2E:6B:42:73:8C:4E:6D:38:41:10:3D:3A:A7:F3:39

CN=Entrust Root Certification Authority - G4, OU=(c) 2015 Entrust, Inc. - for authorized use only, OU=See www.entrust.net/legal-terms, O=Entrust, Inc., C=US

DB:35:17:D1:F6:73:2A:2D:5A:B9:7C:53:3E:C7:07:79:EE:32:70:A6:2F:B4:AC:42:38:37:24:60:E6:F0:1E:88

CN=Entrust.net Certification Authority (2048), OU=(c) 1999 Entrust.net Limited, OU=www.entrust.net/CPS_2048 incorp. by ref. (limits liab.), O=Entrust.net

6D:C4:71:72:E0:1C:BC:B0:BF:62:58:0D:89:5F:E2:B8:AC:9A:D4:F8:73:80:1E:0C:10:B9:C8:37:D2:1E:B1:77

CN=AffirmTrust Commercial, O=AffirmTrust, C=US

03:76:AB:1D:54:C5:F9:80:3C:E4:B2:E2:01:A0:EE:7E:EF:7B:57:B6:36:E8:A9:3C:9B:8D:48:60:C9:6F:5F:A7

CN=AffirmTrust Networking, O=AffirmTrust, C=US

0A:81:EC:5A:92:97:77:F1:45:90:4A:F3:8D:5D:50:9F:66:B5:E2:C5:8F:CD:B5:31:05:8B:0E:17:F3:F0B4:1B

CN=AffirmTrust Premium, O=AffirmTrust, C=US

70:A7:3F:7F:37:6B:60:07:42:48:90:45:34:B1:14:82:D5:BF:0E:69:8E:CC:49:8D:F5:25:77:EB:F2:E9:3B:9A

CN=AffirmTrust Premium ECC, O=AffirmTrust, C=US

BD:71:FD:F6:DA:97:E4:CF:62:D1:64:7A:DD:25:81:B0:7D:79:AD:F8:39:7E:B4:EC:BA:9C:5E:84:88:82:14:23


You can also use the keytool utility from the JDK to print out details of the certificate chain, as follows:

keytool -v -list -alias <your_server_alias> -keystore <your_keystore_filename>

If any of the certificates in the chain are issued by one of the root CAs in the table above are listed in the output you will need to update the certificate or contact the organization that manages the server.

core-libs/java.text
 MessageFormat ArgumentIndex Now Has a Limit (JDK-8331446 (not public))

In the JDK, java.text.MessageFormat now has an implementation limit for the ArgumentIndex pattern element. The hard limit for the value is 10,000.

If an ArgumentIndex value is equal to or exceeds the upper limit, an IllegalArgumentException will now be thrown by

  • MessageFormats constructors
  • applyPattern(String pattern) instance method
  • format(String pattern, Object... arguments) static method

De-serializing a MessageFormat object with an ArgumentIndex value at or over the limit will throw an InvalidObjectException.

 

Bug Fixes

This release also contains fixes for security vulnerabilities described in the Oracle Critical Patch Update.

Issues fixed in 23.0.1:
# JBS Component/Subcomponent Summary
1JDK-6967482client-libs/javax.swingTAB-key does not work in JTables after selecting details-view in JFileChooser
2JDK-8338696core-libs/java.nio(fs) BasicFileAttributes.creationTime() falls back to epoch if birth time is unavailable (Linux)
3JDK-8341059security-libs/javax.net.sslChange Entrust TLS distrust date to November 12, 2024


JDK 23 Release Notes

Publication Date: 17 September 2024

The following sections are included in these Release Notes:


Java™ SE Development Kit 23

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:

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.

 

TOP


Major New Functionality

 

1. Language Previews

 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.

See JEP 455

 

 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.

See JEP 482

 

 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

 

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

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

 

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

See JEP 474

 

4. Tooling

 Markdown Documentation Comments

Enable JavaDoc documentation comments to be written in Markdown rather than solely in a mixture of HTML and JavaDoc @-tags.

See JEP 467

 

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

See JEP 471

 

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

 

TOP


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.

 

TOP


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:

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

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

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

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

 

TOP


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.

 

TOP


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.

TOP

 


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.

TOP

 


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.

TOP


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.

 

TOP


Differences Between Oracle JDK and OpenJDK

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:

  • Oracle JDK includes GraalVM JIT as an optional compiler. OpenJDK does not.
  • Oracle JDK offers "installers" (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).
  • Usage Logging is only available in Oracle JDK.
  • Oracle JDK requires that third-party cryptographic providers be signed with a Java Cryptography Extension (JCE) Code Signing Certificate. OpenJDK continues allowing the use of unsigned third-party crypto providers.
  • The output of 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.
  • Oracle JDK will be released under the Oracle No-Fee Terms and Conditions License. OpenJDK is released under GPLv2wCP. License files included with each will therefore be different.
  • Oracle JDK distributes FreeType under the FreeType license and OpenJDK does so under GPLv2. The contents of \legal\java.desktop\freetype.md is therefore different.
  • Oracle JDK has Java cup and steam icons and OpenJDK has Duke icons.
  • Oracle JDK source code includes "ORACLE PROPRIETARY/CONFIDENTIAL. Use is subject to license terms." Source code distributed with OpenJDK refers to the GPL license terms instead.