JDK 23 Early-Access Release Notes

This is a draft of the release notes that will accompany JDK 23. The contents are subject to change until release.

Build 12

Relax alignment of array elements (JDK-8139457)

hotspot/runtime

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

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

Build 11

Added Certainly R1 and E1 Root Certificates (JDK-8321408)

security-libs/java.security

The following root certificate has 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

Build 10

Removal of Aligned Access Modes for MethodHandles::byteArrayViewVarHandle, byteBufferViewVarHandle and Related Methods (JDK-8318966)

core-libs/java.lang.invoke

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

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

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

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

Build 9

Loose Matching of Space Separators in Lenient Date/Time Parsing Mode (JDK-8324665)

core-libs/java.time

Parsing of date/time strings now allows the "loose matching" of spaces. This enhancement is mainly to address the [incompatible changes](https://www.oracle.com/java/technologies/javase/20-relnote-issues.html#JDK-8284840) 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);

Build 6

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

core-svc/javax.management

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

Build 2

ThreadGroup.stop is removed (JDK-8320786)

core-libs/java.lang

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

Thread.suspend/resume and ThreadGroup.suspend/resume are removed (JDK-8320532)

core-libs/java.lang

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