Mailing List Archive

JDK 21 is in Rampdown / The importance of testing with Early-Access Builds
Welcome to the OpenJDK Quality Outreach June update.

JDK 21 has entered Rampdown Phase One (RDP1) [1], which means that the main-line has been forked into a dedicated JDK 21 stabilization repository. At this point, the overall JDK 21 feature set is frozen. Any changes pushed to the main line are now bound for JDK 22. The stabilization repository is open for select bug fixes and, with approval, late low-risk enhancements per the JDK Release Process [2]. And in contrast to past practice, most stabilization changes will be integrated via backports from the main-line repository [1].

The coming weeks are critical to identify and resolve as many issues as possible, i.e. before JDK 21 enters the Release Candidates phase in August. We need to make sure those few weeks are leveraged to test both existing code running on top of JDK 21 and new JDK 21 features. The heads-up below illustrates the importance and the benefits of doing such tests.

[1] https://mail.openjdk.org/pipermail/jdk-dev/2023-June/007911.html
[2] https://openjdk.org/jeps/3#Integrating-fixes-and-enhancements


## Heads-up: On the Importance of Doing Tests With OpenJDK Early-Access Builds

The following is a recent example that demonstrates the benefits of testing an existing codebase using the OpenJDK early-access builds.

Last month, we published a heads-up focused on Sequenced Collections [3] as they could potentially introduce some incompatibilities.
The Eclipse Collections (EC) team did their homework and sure enough, EC was impacted as it was now throwing compilation errors with JDK 21 early-access builds. The EC team was able to quickly fix those compilation errors, i.e., it was mainly about adding overriding default methods. But once those compilation errors were fixed, and this is where it gets interesting, another issue surfaced. This time, the problem was related to LinkedHashMap serialization. After some investigation, the EC team identified that second issue as JDK one and a JBS ticket was opened. That issue was then confirmed as a JDK regression and was promptly fixed in OpenJDK main-line, i.e., JDK 22. The fix was then backported into the JDK 21 stabilization repository. This EC pull request [4] provides additional details.
In this case, the JDK fix was easy but it is nevertheless the kind of issues that could have easily fallen through the crack if the EC team wasn?t pro-actively testing with OpenJDK early-access builds. The EC issue would have then surfaced after the JDK 21 General Availability... and who knows when the JDK LinkedHashMap serialization regression would have been fixed?
TL; DR; Testing an existing codebase with OpenJDK early-access builds is a win-win situation. It helps the project itself, Eclipse Collections in this case, as it enables developers to identify issues in their own codebase before that new JDK version is Generally Available. It helps the JDK too as any JDK issue detected early enough in the development cycle gives the OpenJDK engineers a chance to address it before the General Availability of that new JDK version. And last but not least, having a robust JDK is also a win for the Java community at large.

And thanks to the Eclipse Collections team and especially to Don Raab for helping to make the Java platform more robust!

[3] https://inside.java/2023/05/12/quality-heads-up/
[4] https://github.com/eclipse/eclipse-collections/pull/1461


## JDK 21 Early-Access Builds

JDK 21 Early-Access builds 26 are now available [5], and are provided under the GNU General Public License v2, with the Classpath Exception. The Release Notes are available here [6] and the javadocs here [7].

### JEPs integrated into JDK 21:
- 430: String Templates (Preview)
- 431: Sequenced Collections
- 439: Generational ZGC
- 440: Record Patterns
- 441: Pattern Matching for switch
- 442: Foreign Function & Memory API (3rd Preview)
- 443: Unnamed Patterns and Variables (Preview)
- 444: Virtual Threads
- 445: Unnamed Classes and Instance Main Methods (Preview)
- 446: Scoped Values (Preview)
- 448: Vector API (6th Incubator)
- 449: Deprecate the Windows 32-bit x86 Port for Removal
- 451: Prepare to Disallow the Dynamic Loading of Agents
- 452: Key Encapsulation Mechanism API
- 453: Structured Concurrency (Preview)

It is worth mentioning that JEP 404 (Generational Shenandoah - Experimental) has been proposed to drop from JDK 21 [8].

### Changes in recent JDK 21 builds (b23-b26) that may be of interest:

Note that this is only a curated list of changes, make sure to check [9] for additional changes.

- JDK-8298127: HSS/LMS Signature Verification
- JDK-8305972: Update XML Security for Java to 3.0.2
- JDK-8308244: Installation of jdk rpm corrupts alternatives
- JDK-8307990: jspawnhelper must close its writing side of a pipe before reading from it
- JDK-8303465: KeyStore of type KeychainStore, provider Apple does not show all trusted certificates
- JDK-8303530: Redefine JAXP Configuration File
- JDK-8307478: Implementation of Prepare to Restrict The Dynamic Loading of Agents
- JDK-8301553: Support Password-Based Cryptography in SunPKCS11
- JDK-8308341: JNI_GetCreatedJavaVMs returns a partially initialized JVM
- JDK-8308108: Support Unicode extension for collation settings
- JDK-8305972: Update XML Security for Java to 3.0.2
- JDK-8305091: Change ChaCha20 cipher init behavior to match AES-GCM
- JDK-8179502: Enhance OCSP, CRL and Certificate Fetch Timeouts
- JDK-8307547: Support variant collations
- JDK-8308876: JFR: Deserialization of EventTypeInfo uses incorrect attribute names
- JDK-8297878: KEM: Implementation
- JDK-8308819: add JDWP and JDI virtual thread support for ThreadReference.ForceEarlyReturn
- JDK-8307779: Relax the java.awt.Robot specification
- JDK-8306703: JFR: Summary views
- JDK-8309146: extend JDI StackFrame.setValue() and JDWP StackFrame.setValues minimal support for virtual threads
- JDK-8307840: SequencedMap view method specification and implementation adjustments
- JDK-8304438: jcmd JVMTI.agent_load should obey EnableDynamicAgentLoading
- JDK-8306431: File.listRoots method description should be re-examined

[5] https://jdk.java.net/21/
[6] https://jdk.java.net/21/release-notes
[7] https://download.java.net/java/early_access/jdk21/docs/api/
[8] https://mail.openjdk.org/pipermail/jdk-dev/2023-June/007910.html
[9] https://github.com/openjdk/jdk/compare/jdk-21+23...jdk-21+26


## JDK 22 Early-Access Builds

Given that JDK 21 is now in Rampdown Phase, the initial JDK 22 Early-Access builds are now also available [10]. Those EA builds are provided under the GNU General Public License v2, with the Classpath Exception.
[10] https://jdk.java.net/22/

## JavaFX 21 Early-Access Builds

These are early access builds of the JavaFX 21 Runtime, built from openjdk/jfx [11]. They are intended to allow JavaFX application developers to build and test their applications with JavaFX 21 on JDK 21. The latest builds 21 (2023/6/8) are now available [12]. These early-access builds are provided under the GNU General Public License, version 2, with the Classpath Exception. Feedback should be reported to the openjfx-dev mailing list [13].
[11] https://github.com/openjdk/jfx
[12] https://jdk.java.net/javafx21/
[13] http://mail.openjdk.org/mailman/listinfo/openjfx-dev

## Topics of Interest

All That is in Java 21?!
https://inside.java/2023/06/08/newscast-50/

Script Java Easily in 21 and Beyond
https://inside.java/2023/05/25/newscast-49/

New JFR `view` Command
https://egahlin.github.io/2023/05/30/views.html

Patterns: Exhaustiveness, Unconditionality, and Remainder
https://openjdk.org/projects/amber/design-notes/patterns/exhaustiveness

Design Document on Nullability and Value Types
https://mail.openjdk.org/pipermail/valhalla-spec-observers/2023-May/002243.html

JFR: Java's Observability & Monitoring Framework - Stack Walker #2
https://inside.java/2023/05/14/stackwalker-02/


## JDK Crypto Roadmap Update

Oracle updated the JDK Cryptographic Roadmap to announce a change, with the Oct CPU (2023-10-17), of the priority order used by JDK 8 and JDK 11 when negotiating cipher suites to use on TLS connections. Please check the JDK Cryptographic Roadmap page [14] for more details.
[14] https://www.java.com/en/jre-jdk-cryptoroadmap.html


~

Please, make sure to test your projects using the JDK 21 EA builds as we still have time to fix potential issues. And thanks for participating in the OpenJDK Quality Outreach program!


--David
Re: JDK 21 is in Rampdown / The importance of testing with Early-Access Builds [ In reply to ]
Hi,

Thanks David! This is perfectly in time also for our release plans. See
my previous mails about Project Panama Foreign and Project Panama Vector
inclusion in Lucene 9.7. Based on the RDP1, we merged the MMapDirectory
and Vector pull requests and will release Lucene 9.7 with support for
the new APIs/changed APIs of Java 21. See also announcements on Twitter.

We strongly hope that there will be no significant bytecode incompatible
changes anymore till release. Please take this into account when you fix
bugs in Panama Foreign/Vector: No bytecode incompatible API changes
please :-)

Thanks,
Uwe

Am 14.06.2023 um 10:40 schrieb David Delabassee:
>
> Welcome to the OpenJDK Quality Outreach June update.
>
> JDK 21 has entered Rampdown Phase One (RDP1) [1], which means that the
> main-line has been forked into a dedicated JDK 21 stabilization
> repository. At this point, the overall JDK 21 feature set is frozen.
> Any changes pushed to the main line are now bound for JDK 22. The
> stabilization repository is open for select bug fixes and, with
> approval, late low-risk enhancements per the JDK Release Process [2].
> And in contrast to past practice, most stabilization changes will be
> integrated via backports from the main-line repository [1].
>
> The coming weeks are critical to identify and resolve as many issues
> as possible, i.e. before JDK 21 enters the Release Candidates phase in
> August. We need to make sure those few weeks are leveraged to test
> both existing code running on top of JDK 21 and new JDK 21 features.
> The heads-up below illustrates the importance and the benefits of
> doing such tests.
>
> [1] https://mail.openjdk.org/pipermail/jdk-dev/2023-June/007911.html
>
> [2] https://openjdk.org/jeps/3#Integrating-fixes-and-enhancements
>
> ## Heads-up: On the Importance of Doing Tests With OpenJDK
> Early-Access Builds
>
> The following is a recent example that demonstrates the benefits of
> testing an existing codebase using the OpenJDK early-access builds.
>
> Last month, we published a heads-up focused on Sequenced Collections
> [3] as they could potentially introduce some incompatibilities.
>
> The Eclipse Collections (EC) team did their homework and sure enough,
> EC was impacted as it was now throwing compilation errors with JDK 21
> early-access builds. The EC team was able to quickly fix those
> compilation errors, i.e., it was mainly about adding overriding
> default methods. But once those compilation errors were fixed, and
> this is where it gets interesting, another issue surfaced. This time,
> the problem was related to LinkedHashMap serialization. After some
> investigation, the EC team identified that second issue as JDK one and
> a JBS ticket was opened. That issue was then confirmed as a JDK
> regression and was promptly fixed in OpenJDK main-line, i.e., JDK 22.
> The fix was then backported into the JDK 21 stabilization repository.
> This EC pull request [4] provides additional details.
>
> In this case, the JDK fix was easy but it is nevertheless the kind of
> issues that could have easily fallen through the crack if the EC team
> wasn’t pro-actively testing with OpenJDK early-access builds. The EC
> issue would have then surfaced after the JDK 21 General
> Availability... and who knows when the JDK LinkedHashMap serialization
> regression would have been fixed?
>
> TL; DR; Testing an existing codebase with OpenJDK early-access builds
> is a win-win situation. It helps the project itself, Eclipse
> Collections in this case, as it enables developers to identify issues
> in their own codebase before that new JDK version is Generally
> Available. It helps the JDK too as any JDK issue detected early enough
> in the development cycle gives the OpenJDK engineers a chance to
> address it before the General Availability of that new JDK version.
> And last but not least, having a robust JDK is also a win for the Java
> community at large.
>
> And thanks to the Eclipse Collections team and especially to Don Raab
> for helping to make the Java platform more robust!
>
> [3] https://inside.java/2023/05/12/quality-heads-up/
>
> [4] https://github.com/eclipse/eclipse-collections/pull/1461
>
> ## JDK 21 Early-Access Builds
>
> JDK 21 Early-Access builds 26 are now available [5], and are provided
> under the GNU General Public License v2, with the Classpath Exception.
> The Release Notes are available here [6] and the javadocs here [7].
>
> ### JEPs integrated into JDK 21:
>
> - 430: String Templates (Preview)
>
> - 431: Sequenced Collections
>
> - 439: Generational ZGC
>
> - 440: Record Patterns
>
> - 441: Pattern Matching for switch
>
> - 442: Foreign Function & Memory API (3rd Preview)
>
> - 443: Unnamed Patterns and Variables (Preview)
>
> - 444: Virtual Threads
>
> - 445: Unnamed Classes and Instance Main Methods (Preview)
>
> - 446: Scoped Values (Preview)
>
> - 448: Vector API (6th Incubator)
>
> - 449: Deprecate the Windows 32-bit x86 Port for Removal
>
> - 451: Prepare to Disallow the Dynamic Loading of Agents
>
> - 452: Key Encapsulation Mechanism API
>
> - 453: Structured Concurrency (Preview)
>
> It is worth mentioning that JEP 404 (Generational Shenandoah -
> Experimental) has been proposed to drop from JDK 21 [8].
>
> ### Changes in recent JDK 21 builds (b23-b26) that may be of interest:
>
> Note that this is only a curated list of changes, make sure to check
> [9] for additional changes.
>
> - JDK-8298127: HSS/LMS Signature Verification
>
> - JDK-8305972: Update XML Security for Java to 3.0.2
>
> - JDK-8308244: Installation of jdk rpm corrupts alternatives
>
> - JDK-8307990: jspawnhelper must close its writing side of a pipe
> before reading from it
>
> - JDK-8303465: KeyStore of type KeychainStore, provider Apple does not
> show all trusted certificates
>
> - JDK-8303530: Redefine JAXP Configuration File
>
> - JDK-8307478: Implementation of Prepare to Restrict The Dynamic
> Loading of Agents
>
> - JDK-8301553: Support Password-Based Cryptography in SunPKCS11
>
> - JDK-8308341: JNI_GetCreatedJavaVMs returns a partially initialized JVM
>
> - JDK-8308108: Support Unicode extension for collation settings
>
> - JDK-8305972: Update XML Security for Java to 3.0.2
>
> - JDK-8305091: Change ChaCha20 cipher init behavior to match AES-GCM
>
> - JDK-8179502: Enhance OCSP, CRL and Certificate Fetch Timeouts
>
> - JDK-8307547: Support variant collations
>
> - JDK-8308876: JFR: Deserialization of EventTypeInfo uses incorrect
> attribute names
>
> - JDK-8297878: KEM: Implementation
>
> - JDK-8308819: add JDWP and JDI virtual thread support for
> ThreadReference.ForceEarlyReturn
>
> - JDK-8307779: Relax the java.awt.Robot specification
>
> - JDK-8306703: JFR: Summary views
>
> - JDK-8309146: extend JDI StackFrame.setValue() and JDWP
> StackFrame.setValues minimal support for virtual threads
>
> - JDK-8307840: SequencedMap view method specification and
> implementation adjustments
>
> - JDK-8304438: jcmd JVMTI.agent_load should obey EnableDynamicAgentLoading
>
> - JDK-8306431: File.listRoots method description should be re-examined
>
> [5] https://jdk.java.net/21/
>
> [6] https://jdk.java.net/21/release-notes
>
> [7] https://download.java.net/java/early_access/jdk21/docs/api/
>
> [8] https://mail.openjdk.org/pipermail/jdk-dev/2023-June/007910.html
>
> [9] https://github.com/openjdk/jdk/compare/jdk-21+23...jdk-21+26
>
> ## JDK 22 Early-Access Builds
>
> Given that JDK 21 is now in Rampdown Phase, the initial JDK 22
> Early-Access builds are now also available [10]. Those EA builds are
> provided under the GNU General Public License v2, with the Classpath
> Exception.
>
> [10] https://jdk.java.net/22/
>
> ## JavaFX 21 Early-Access Builds
>
> These are early access builds of the JavaFX 21 Runtime, built from
> openjdk/jfx [11]. They are intended to allow JavaFX application
> developers to build and test their applications with JavaFX 21 on JDK
> 21. The latest builds 21 (2023/6/8) are now available [12]. These
> early-access builds are provided under the GNU General Public License,
> version 2, with the Classpath Exception. Feedback should be reported
> to the openjfx-dev mailing list [13].
>
> [11] https://github.com/openjdk/jfx
>
> [12] https://jdk.java.net/javafx21/
>
> [13] http://mail.openjdk.org/mailman/listinfo/openjfx-dev
>
> ## Topics of Interest
>
> All That is in Java 21?!
>
> https://inside.java/2023/06/08/newscast-50/
>
> Script Java Easily in 21 and Beyond
>
> https://inside.java/2023/05/25/newscast-49/
>
> New JFR `view` Command
>
> https://egahlin.github.io/2023/05/30/views.html
>
> Patterns: Exhaustiveness, Unconditionality, and Remainder
>
> https://openjdk.org/projects/amber/design-notes/patterns/exhaustiveness
>
> Design Document on Nullability and Value Types
>
> https://mail.openjdk.org/pipermail/valhalla-spec-observers/2023-May/002243.html
>
> JFR: Java's Observability & Monitoring Framework - Stack Walker #2
>
> https://inside.java/2023/05/14/stackwalker-02/
>
> ## JDK Crypto Roadmap Update
>
> Oracle updated the JDK Cryptographic Roadmap to announce a change,
> with the Oct CPU (2023-10-17), of the priority order used by JDK 8 and
> JDK 11 when negotiating cipher suites to use on TLS connections.
> Please check the JDK Cryptographic Roadmap page [14] for more details.
>
> [14] https://www.java.com/en/jre-jdk-cryptoroadmap.html
>
> ~
>
> Please, make sure to test your projects using the JDK 21 EA builds as
> we still have time to fix potential issues. And thanks for
> participating in the OpenJDK Quality Outreach program!
>
> --David
>
--
Uwe Schindler
uschindler@apache.org
ASF Member, Member of PMC and Committer of Apache Lucene and Apache Solr
Bremen, Germany
https://lucene.apache.org/
https://solr.apache.org/