Welcome to the OpenJDK Quality Outreach summer update.

JDK 23 is now in Rampdown Phase Two [1], its overall feature has been frozen a few weeks ago. Per the JDK Release Process, we have now turned our focus to P1 and P2 bugs, which can be fixed with approval [2]. Late enhancements are still possible, with approval, but the bar is now extraordinarily high. That also means that the JDK 23 Initial Release Candidates are fast approaching, i.e., August 8th [3]! So, and in addition to testing your projects with the latest JDK 23 early-access builds, it is now a good time to start testing with the JDK 24 early-access builds.

Make sure to also check the heads-up below as some are related to JDK 23 and might have some impact, i.e., the first one being related to the eventual removal of the Security Manager and the second one discusses the removal of the legacy COMPAT locale provider.

[1] https://mail.openjdk.org/pipermail/jdk-dev/2024-July/009252.html

[2] https://openjdk.org/jeps/3#rdp-2

[3] https://openjdk.org/projects/jdk/23/

## Heads-up - JDK 23: Subject.getSubject API Requires Allowing the Security Manager

In JDK 17 and as announced in JEP 411 [4], the Security Manager was deprecated for removal. As part of that change, several Security Manager APIs, such as `AccessControlContext`, were deprecated for removal. The `Subject::doAs` and `Subject::getSubject` APIs depend on Security Manager related APIs even though they do not require Security Manager to be installed to use them.

As of JDK 23 [5], to help applications prepare for the eventual removal of the Security Manager, subject authorization and the Subject APIs' behavior depend on allowing the Security Manager:

- If 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 compared to previous releases.

- If 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`, invoking the `Subject.getSubject` method will throw `UnsupportedOperationException`.

Yet, running an application with `-Djava.security.manager=allow` is a temporary workaround to keep older code working. Maintainers of code using `Subject.doAs` and `Subject.getSubject` are strongly encouraged to migrate it with utmost priority to the replacement APIs, `Subject.callAs` and `Subject.current`. Make sure to check [5] and [6] for additional details.

The jdeprscan tool [7] scans a JAR file for usage of deprecated API elements and is helpful to find code using these methods. Additionally, consider migrating as soon as possible code that stores a `Subject` in an `AccessControlContext` and invokes `AccessController.doPrivileged` with that context. Such code will stop working when the Security Manager is removed.

[4] https://openjdk.org/jeps/411

[5] https://jdk.java.net/23/release-notes#b15

[6] https://inside.java/2024/07/08/quality-heads-up/

[7] https://dev.java/learn/jvm/tools/core/jdeprscan/

## Heads-up - JDK 23: Unicode / Removal of COMPAT Locale Provider

### A Quick History of Locale Data in the JDK

Before the Unicode Consortium created the Common Locale Data Repository (CLDR) in 2003 to manage locale data, the JDK had to provide its own collection. It did so successfully and in JDK 8 supported about 160 locales. To reduce maintenance effort, allow better interoperability between platforms, and improve locale data quality, the JDK started to move towards CLDR in 2014:

- JDK 8 comes with two locale data providers, which can be selected with the system property java.locale.providers:

   . JRE/COMPAT for the JDK’s legacy data collection (default)

   . CLDR for the CLDR data

   . a custom locale provider can be implemented

- JDK 9 picks CLDR by default

- JDK 21 issues a warning on JRE/COMPAT

There are plenty of minor and a few notable differences between the legacy data and CLDR - the recently rewritten JEP 252 [8] lists a few of them.

### Locale Data in JDK 23

JDK 23 [9] removes legacy locale data. As a consequence, setting java.locale.providers to JRE or COMPAT has no effect.

Projects that are still using legacy locale data are highly encouraged to switch to CLDR as soon as possible. Where that is infeasible, two alternatives remain:

- Create custom formatters with patterns that mimic the legacy behavior and use them everywhere where locale-sensitive data is written or parsed.

- Implement a custom locale data provider [10].

For more details on that as well as on CLDR in the JDK in general, please check JEP 252 [8] that has been recently rewritten to provide better information and guidance.

[8] https://openjdk.org/jeps/252

[9] https://bugs.openjdk.org/browse/JDK-8325568

[10] https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/util/spi/LocaleServiceProvider.html

## Heads-up - JDK 23:  Initial Leyden Early-Access Builds

Project Leyden published its first early-access builds (24-leyden+2-8 2024/6/20) [11]. The initial release is focused on improving Java applications start-up time, but other Leyden optimizations will be explored in future releases.

Below are some of the highlights of these Leyden EA builds:

- Ahead-of-time compilation of Java methods to natively execute them as soon as the application starts up in the production run;

- Ahead-of-time resolution of constant pool entries allows the AOT compiler to generate better code and for your application to start faster;

- Ahead-of-time generation of Dynamic Proxies and reflection data as frameworks use those extensively during start-up time;

- A unified Cache Data Store (CDS) archive to simplify the creation of the CDS archive, while supporting multiple types of optimization artifacts;

- Loaded Classes in the CDS archive as soon the application starts up;

- Class loader lookup cache to help application frameworks perform repeated lookups without repeatedly scanning the classpath;

- Archived Method Profiles to reach Java application peak performance faster.

The easiest way to start with Leyden features is by using the java program in the Leyden Early Access Release with the -XX:CacheDataStore flag. More details of this Leyden EA Build can be found in the release notes [12].

[11] https://jdk.java.net/leyden/

[12] https://github.com/openjdk/leyden/blob/leyden-ea1-release-notes/README.md

## JDK 23 Early-Access Builds

The JDK 23 early-access builds 32 are available [13], and are provided under the GNU General Public License v2, with the Classpath Exception. The Release Notes are available here [14] and the Javadoc here [15].

[13] https://jdk.java.net/23/

[14] https://jdk.java.net/23/release-notes

[15] https://download.java.net/java/early_access/jdk23/docs/api/

## JDK 24 Early-Access Builds

The JDK 24 early-access builds 7 are available [16], and are provided under the GNU General Public License v2, with the Classpath Exception. The Release Notes are available here [17].

### Changes in recent JDK 24 builds that may be of interest:

- JDK-8334299: Deprecate LockingMode option, along with LM_LEGACY and LM_MONITOR

- JDK-8330846: Add stacks of mounted virtual threads to the HotSpot thread …

- JDK-8333649: Allow different NativeCall encodings

- JDK-8333755: NumberFormat integer only parsing breaks when format has suffix

- JDK-8330842: Support AES CBC with Ciphertext Stealing (CTS) in SunPKCS11

- JDK-8327793: Deprecate jstatd for removal

- JDK-8248981: Specify list of standard message digest and mgf algorithms for RSASSA-PSS signature

- JDK-8334580: Deprecate no-arg constructor BasicSliderUI() for removal

- JDK-8320448: Accelerate IndexOf using AVX2

- JDK-8333749: Consolidate ConstantDesc conversion in java.base

- JDK-8329141: Obsolete RTM flags and code

- JDK-8330198: Add some class loading related perf counters to measure VM startup

- JDK-8330699: Obsolete -XX:+UseEmptySlotsInSupers

- JDK-8334734: Remove specialized readXxxEntry methods from ClassReader

This is only a curated list, a complete list of changes can be found here [18].

[16] https://jdk.java.net/24/

[17] https://jdk.java.net/24/release-notes

[18] https://github.com/openjdk/jdk/compare/jdk-24+0...jdk-24+7

## Topics of Interest

- Integrity by Default - Inside Java Newscast

https://inside.java/2024/07/18/newscast-73/

- Java and AI? - Inside Java Newscast

https://inside.java/2024/07/04/newscast-72/

- What Happened to String Templates? - Inside Java Newscast

https://inside.java/2024/06/20/newscast-71/

- Java Language Futures - Spring 2024 Edition

https://inside.java/2024/07/01/java-language-futures/

- Project Loom - Structured Concurrency

https://inside.java/2024/07/13/structured-concurrency/

- How to Build Custom Java Runtimes with Jlink

https://inside.java/2024/06/21/build-runtimes-with-jlink/

## July 2024 Critical Patch Update Released

As part of the July 2024 CPU, Oracle released OpenJDK 22.0.2, JavaFX 22.0.2, JDK 22.0.2, JDK 21.0.4 LTS, JDK 17.0.12 LTS, JDK 11.0.24 LTS, JDK 8u421 as as well as JDK 8u421-perf.

~

We still have a few days before JDK 23 enters into the Release Candidate phase so please make sure to test your projects on the latest early-access builds and report any issue… but that shouldn't be a reason to not enjoy the summer and recharge your batteries! 😎

--David