API differences in Hibernate ORM 5.1 vs 5.3
by Gail Badner
Hi,
There were lots of differences in the compatibility report, so as a first
step, I've excluded packages/classes that I considered SPI, internal, or
"grey area". This reduced the the differences to a more manageable amount.
You can see a summary of the incompatibilities along with suggested
mitigation at [1].
The report is attached to [1], along with a zip with instructions for
running the report.
I believe there are some "false positives" in the report, and I have
documented them in the section, "False Positives?".
Feel free to comment on the article.
Thanks,
Gail
[1]
https://developer.jboss.org/wiki/HibernateORMBinaryCompatibilityBetween51...
3 weeks, 6 days
IP banned from forum
by Gunnar Morling
Hi,
Is anyone banning users from the forum? I am getting "A ban has been
issued on your IP address."
I don't think banning by IP is a good strategy as many users will have
dynamic IPs from their hoster's shared pool, so it's a random game to
hit an IP previously banned due to some other user's spam.
Thanks,
--Gunnar
4 weeks
New CI machine preview
by Sanne Grinovero
You're all welcome to play with http://54.225.162.168/
however please keep these in mind:
- it's not the final machine: don't put too much effort in creating
nice build scripts as we'll reset it to clean state soon. We *might*
be able to store jobs defined so far, but we might choose not to.
- domain name should be coming: ci.hibernate.org ..not sure when, got
no replies so far from.
- authentication: just click on login, it will use OAuth2 to request
your identity via your GitHub account. Permissions to create new jobs,
edit existing jobs, run a build manually depend on your github account
be part of the Hibernate organization (or not, in which case you have
read only status)
At this stage I'd like to get a feeling if the hardware is powerful
enough, and also we need to select which other plugins we want to use,
I'm looking especially to:
- static analysis reports
- pull requests integration
both are relatively undefined, we can of course start simple and
improve later.. just checking this fits basic needs now.
Sanne
3 months, 1 week
Re: JDK 23 RDP2 | Removal of the legacy COMPAT locale provider and more heads-up!
by Yoann Rodiere
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...
>
1 year, 6 months
JDK 23 RDP2 | Removal of the legacy COMPAT locale provider and more heads-up!
by David Delabassee
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
1 year, 6 months
Testing email routing
by Yoann Rodiere
This is just to test email routing through the mailing list, feel free to
mute the conversation if it bothers you.
@marko(a)hibernate.org <marko(a)hibernate.org> , can you please answer
something so I can see if I get the message?
Make sure to send to the list only, not to me personally.
Yoann Rodière
Hibernate Team
yoann(a)hibernate.org
1 year, 6 months
