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
