Hey David, Since it's been a while, I'll confirm all is well on Hibernate projects:
Hibernate ORM: Version 6.6 tested against JDK 23 (EA 26) / 24 (EA 1). No problems to report. Hibernate Validator: Version 8.0 tested against JDK 23 (EA 26) / 24 (EA 1). No problems to report. Hibernate Search: Version 7.2 tested against JDK 23 (EA 26) / 24 (EA 1). No problems to report. Hibernate Reactive: Version 2.3 tested against JDK 23 (EA 26) / 24 (EA 1). No problems to report. Have a nice day, Yoann Rodière Hibernate Team yo...@hibernate.org On Mon, Jun 10, 2024 at 11:05 AM David Delabassee via hibernate-dev < hibernate-dev@lists.jboss.org> wrote: > Welcome to the latest OpenJDK Quality Outreach update! > > JDK 23, scheduled for General Availability on September 17, 2024, is now > in Rampdown Phase One (RDP1) [1]. At this point, the overall JDK 23 feature > set is frozen (see the final list of JEPs integrated into JDK 23 below) and > only low-risk enhancements might still be considered. The coming weeks > should be leveraged to identify and resolve as many issues as possible, > i.e. before JDK 23 enters the Release Candidates phase in early August [2]. > We count on you to test your projects and help us make JDK 23 another solid > release! > > This time, we are covering several heads-up related to JDK 23 : Deprecate > the Memory-Access Methods in sun.misc.Unsafe for Removal and default > annotation processing policy change. Also, make sure to check the new Loom > early-access builds which have an improved Java monitors implementation to > work better with virtual threads. > > [1] https://mail.openjdk.org/pipermail/jdk-dev/2024-June/009053.html > [2] https://openjdk.org/projects/jdk/23/ > > > ## Heads-Up - JDK 23: Deprecate the Memory-Access Methods in > sun.misc.Unsafe for Removal > > As mentioned in a previous communication [3], there’s a plan to ultimately > remove the sun.misc.Unsafe memory-access methods as the platform offers > safer alternatives. JEP 471 (Deprecate the Memory-Access Methods in > sun.misc.Unsafe for Removal) [4] outlines in more detail this plan > including the initial step which is happening in JDK 23, i.e., all of the > sun.misc unsafe memory-access methods are now marked as deprecated for > removal. This will cause, in JDK 23, compile-time deprecation warnings for > code that refers to these methods, alerting library developers to their > forthcoming removal. A new command-line option also enables application > developers and users to receive runtime warnings when those methods are > used. > > Developers relying on those sun.misc.Unsafe APIs for access memory are > strongly encouraged to start, if they haven't done so yet, the migration > from the sun.misc.Unsafe APIs to supported replacements. For more details, > make sure to read JEP 471 (Deprecate the Memory-Access Methods in > sun.misc.Unsafe for Removal). > > [3] > https://mail.openjdk.org/pipermail/quality-discuss/2024-January/001132.html > [4] https://openjdk.org/jeps/471 > > > ## Heads-Up - JDK 23: Changes Default Annotation Processing Policy > > Annotation processing is a compile-time feature, where javac scans the > to-be-compiled source files for annotations and then the class path for > matching annotation processors, so they can generate source code. Up to JDK > 22, this feature is enabled by default, which may have been reasonable when > it was introduced in JDK 6 circa 2006, but from a current perspective, in > the interest of making build output more robust against annotation > processors being placed on the class path unintentionally, this is much > less reasonable. Hence, starting with JDK 23, javac requires an additional > command-line option to enable annotation processing. > > ### New `-proc` Value > To that end, the pre-existing option `-proc:$policy` was extended, where > `$policy` can now have the following values: > - `none`: compilation _without_ annotation processing, this policy exists > since JDK 6 > - `only`: annotation processing _without_ compilation, this policy exists > since JDK 6 > - `full`: annotation processing followed by compilation, this policy is > the default in JDK ≤22 but the value itself is new (see next section for > versions that support it) > > Up to and including JDK 22, code bases that require annotation processing > before compilation could rely on javac's default behavior to process > annotations but that is no longer the case. Starting with JDK 23, at least > one annotation-processing command line option needs to be present. If > neither `-processor`, `--processor-path`, now `--processor-module-path` is > used, `-proc:only` or `-proc:full` has to be provided. In other words, > absent other command line options, `-proc:none` is the default on JDK 23. > > ### Migration to `-proc:full` > > Several measures were undertaken to help projects prepare for the switch > to `-proc:full`: > - As of the April 2024 JDK security updates, support for `-proc:full` has > been backported to 17u (17.0.11) and 11u (11.0.23) for both Oracle JDK and > OpenJDK distributions. Additionally, Oracle's 8u release (8u411) also > supports `-proc:full`. > - Starting in JDK 21, javac prints an informative message if implicit > usage of annotation processing under the default policy is detected. > > With `-proc:full` backported, it is possible to configure a build that > will work the same before and after the change in javac's default policy. > > Additional details can be found in the original proposal [5]. > > [5] https://mail.openjdk.org/pipermail/jdk-dev/2024-May/009028.html > > > ## Heads-up - Loom: New EA builds with improved Java monitors > implementation to work better with virtual threads > > Project Loom published new early-access builds [6]. These builds have an > improved object monitor implementation that should prevent virtual threads > from pinning their carrier thread in the following situations: > - when blocking on entering a synchronized method/statement because the > object's associated monitor is held by another thread, > - when parking (e.g. when doing socket I/O) while in a synchronized method, > - when calling `Object.wait` while in a synchronized method. > The changes for `Object.wait`/timed-`wait` is the main change since the > previous Loom EA build. > > The Loom team is looking for help to test the changes, i.e., trying out > these builds with code that is known to use virtual threads and with > libraries that are "very synchronized". The primary goal is to gauge both > reliability and performance. Right now, the focus is on being functional > and reliable. Please note that the performance for some cases isn't yet > fully on par with blocking on j.u.concurrent locks and condition objects. > > As before, JFR events can be used to identify remaining cases of pinning, > parking or blocking in a class initializer for example. The system property > `jdk.tracePinnedThreads`, which used to print stack traces when threads are > pinned, no longer outputs anything. > > Please send feedback via email to the Loom mailing list [7] (subscription > required). > > [6] https://jdk.java.net/loom/ > [7] http://mail.openjdk.org/mailman/listinfo/loom-dev > > > ## JDK 23 Early-Access Builds > > JDK 23 early-access builds 26 are now available [8] with the Release Notes > here [9] and the javadocs here[10]. Those builds are provided under the GNU > GPL v2, with the Classpath Exception. > > ### JEPs integrated into JDK 23: > - JEP 455: Primitive Types in Patterns, instanceof, and switch (Preview) > - JEP 466: Class-File API (2nd Preview) > - JEP 467: Markdown Documentation Comments > - JEP 469: Vector API (8th Incubator) > - JEP 471: Deprecate the Memory-Access Methods in sun.misc.Unsafe for > Removal > - JEP 473: Stream Gatherers (2nd Preview) > - JEP 474: ZGC: Generational Mode by Default > - JEP 476: Module Import Declarations (Preview) > - JEP 477: Implicitly Declared Classes and Instance Main Methods (3rd > Preview) > - JEP 480: Structured Concurrency (3rd Preview) > - JEP 481: Scoped Values (3rd Preview) > - JEP 482: Flexible Constructor Bodies (2nd Preview) > > ### Changes in recent JDK 23 builds that may be of interest: > - JDK-8331670: Deprecate the Memory-Access Methods in sun.misc.Unsafe for > Removal > - JDK-8051959: Add thread and timestamp options to java.security.debug > system property > - JDK-8321428: Deprecate for removal the package java.beans.beancontext > - JDK-8319990: Update CLDR to Version 45.0 > - JDK-8331975: Enable case-insensitive check in ccache and keytab entry > lookup > - JDK-8328083: degrade virtual thread support for GetObjectMonitorUsage > - JDK-8326666: Remove the Java Management Extension (JMX) Subject > Delegation feature > - JDK-8295111: dpkg appears to have problems resolving symbolically linked > native libraries > - JDK-8330077: Allow max number of events to be buffered to be > configurable to avoid OVERFLOW_EVENT > - JDK-8332476: j.u.r.RandomGeneratorFactor.create(long|byte[]) should > throw rather than silently fallback to no-arg create() > - JDK-8329113: Deprecate -XX:+UseNotificationThread > - JDK-8331202: Support for Duration until another Instant > - JDK-8316138: Add GlobalSign 2 TLS root certificates > - JDK-8330276: Console methods with explicit Locale > - JDK-8330005: RandomGeneratorFactory.getDefault() throws exception when > the runtime image only has java.base module > - JDK-6968351: httpserver clashes with delayed TCP ACKs for low > Content-Length > - JDK-8331021: Deprecate and then obsolete the DontYieldALot flag > - JDK-8330607: Deprecate -XX:+UseEmptySlotsInSupers > - JDK-8320522: Remove code related to `RegisterFinalizersAtInit` > - JDK-8329636: Deprecate -XX:+PreserveAllAnnotations > - JDK-8322234: Remove obsolete desktop integration from Linux installers > - JDK-8328649: Disallow enclosing instances for local classes in > constructor prologues > - JDK-8330734: JFR: Re-engineer mirror class mechanism > - JDK-8300148: Consider using a StoreStore barrier instead of Release > barrier on ctor exit > - JDK-8329997: Add provisions for checking memory segment alignment > constraints > - JDK-8305457: Implement java.io.IO > - JDK-8321314: Reinstate disabling the compiler's default active > annotation processing > - JDK-6942632: Hotspot should be able to use more than 64 logical > processors on Windows > - JDK-8332614: Type-checked ConstantPool.entryByIndex and > ClassReader.readEntryOrNull > - JDK-8206447: InflaterInputStream.skip receives long but it's limited to > Integer.MAX_VALUE > > Note: A more exhaustive list of changes can be found here [11]. > > [8] https://jdk.java.net/23/ > [9] https://jdk.java.net/23/release-notes > [10] https://download.java.net/java/early_access/jdk23/docs/api/ > [11] https://github.com/openjdk/jdk/compare/jdk-23+17...jdk-23+26 > > > ## New Jextract Early-Access Builds > > New Jextract early-access builds have been made available [12]. These > builds are based on JDK 22 and bring multiple enhancements. For additional > details, make sure to check [13]. Moreover, a new jextract guide [14] has > been published. > > [12] https://jdk.java.net/jextract/ > [13] https://mail.openjdk.org/pipermail/jextract-dev/2024-May/001699.html > [14] https://github.com/openjdk/jextract/blob/master/doc/GUIDE.md > > > ## JavaFX Early-Access Builds > > These are early access builds of the JavaFX 23 Runtime built from > openjdk/jfx [15]. These builds enable JavaFX application developers to > build and test their applications with JavaFX 23 on JDK 23. Although these > builds are designed to work with JDK 23EA, they are also known to work with > JDK 21 and later versions. > > The latest early access builds of JavaFX 23 are available here [16], under > the GNU General Public License, version 2, with the Classpath Exception. > JavaFX 23 API Javadocs [17] are also available. > > [15] https://github.com/openjdk/jfx > [16] https://jdk.java.net/javafx23/ > [17] > https://download.java.net/java/early_access/javafx23/docs/api/overview-summary.html > > > ## Topics of Interest > > - All Java 23 Features - Inside Java Newscast > https://inside.java/2024/06/06/newscast-70/ > > - Module Imports in Java 23 - Inside Java Newscast > https://inside.java/2024/05/16/newscast-69/ > > - Java 23: JavaDoc Hits the Markdown on Comments - Inside Java Newscast > https://inside.java/2024/05/01/newscast-68/ > > - Java 23: Restoring the Balance with Primitive Patterns - Inside Java > Newscast > https://inside.java/2024/04/04/newscast-66/ > > - Java in 2024 - Constant evolution, delivered. > https://inside.java/2024/06/01/java-in-2024-keynote/ > > - Introduction to JDK Mission Control > https://inside.java/2024/05/18/jmc-intro/ > > - What's New in JMC 9? - Sip of Java > https://inside.java/2024/04/21/sip096/ > > - Programmer's Guide to JDK Flight Recorder > https://inside.java/2024/04/12/programmer-guide-to-jfr/ > > - A Decade of JDK Updates in OpenJDK > https://inside.java/2024/04/09/a-decade-of-jdk-updates/ > > - Data-Oriented Programming - Version 1.1 > https://inside.java/2024/05/23/dop-v1-1-introduction/ > > > ~ > > As usual, let us know if you find any issues while testing your project(s) > with the latest JDK early-access builds. > > Thank you! > > --David > _______________________________________________ > hibernate-dev mailing list -- hibernate-dev@lists.jboss.org > To unsubscribe send an email to hibernate-dev-le...@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/message/JL4QRWPHCEXSLZSALNC5TMKS5HT5LECQ/ > _______________________________________________ hibernate-dev mailing list -- hibernate-dev@lists.jboss.org To unsubscribe send an email to hibernate-dev-le...@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/message/BBQPVKRNPND4OGBJUNF4434X4RZRFBAG/
