Hey David,
Thank you for the updates. Everything looking good on our end:
Hibernate ORM: Version 6.6 tested against JDK 23 (EA 33) / 24 (EA 7). No
problems to report.
Hibernate Validator: Version 9.0 tested against JDK 23 (EA 33) / 24 (EA 7).
No problems to report.
Hibernate Search: Version 7.2 tested against JDK 23 (EA 33) / 24 (EA 7). No
problems to report.
Hibernate Reactive: Version 2.3 tested against JDK 23 (EA 31) / 24 (EA 6).
No problems to report.
So I assume Locale/SecurityManager changes don't affect these versions of
Hibernate projects. SecurityManager support is going to get removed in
future Hibernate versions, at any rate.
Sanne has been looking into Leyden, but you may already be aware, as I
think he reached out already (reporting issues in particular).
Have a nice weekend,
Yoann
Hibernate team
On Mon, Jul 22, 2024 at 8:37 AM David Delabassee via hibernate-dev <
hibernate-dev(a)lists.jboss.org> wrote:
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/sp...
## 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
_______________________________________________
hibernate-dev mailing list -- hibernate-dev(a)lists.jboss.org
To unsubscribe send an email to hibernate-dev-leave(a)lists.jboss.org
Privacy Statement:
https://www.redhat.com/en/about/privacy-policy
List Archives:
https://lists.jboss.org/archives/list/hibernate-dev@lists.jboss.org/messa...