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
