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

Reply via email to