WildFly 29 Beta and Final schedule
by Brian Stansberry
We've been making great progress on WildFly 29, but a lot of the WildFly
developers have been heads down on other things the last couple weeks, so
we're not quite ready to turn the crank and push out the 29 Beta release.
So we've decided to push the release of 29.0.0.Beta1 to next week,
targeting Thursday, July 6 for having the server available on wildfly.org,
and July 7 for other release deliverables.
PRs for 29 Beta should already be up and ready, particularly any that go
into WildFly Core, which we expect to tag and release either late tomorrow
or early Monday. If there's anything not ready that really needs to go into
the beta (i.e. features), please let Darran Lofthouse and I know ASAP. (We
generally don't block for features, but we can talk anyway.)
Based on a beta release next Thursday, we have the following *proposed*
schedule for WildFly 29 Final
Wed, July 12 -- Freeze (Deadline for all PRs to be submitted)
Mon, July 17 -- Tag and Release WildFly Core
Mon, July 17 -- Final merges and final checks
Wed, July 19 -- Tag 29 Final
Thu, July 20 -- Release available on wildfly.org
Fri, July 21 -- Other release deliverables available
I know that we're in the period when folks are going away for well deserved
vacations, so if this new schedule for 29 Final is a problem for any of you
who are responsible for release activities, please let me and Darran
Lofthouse know off-list.
Best regards,
Brian
1 year
JDK 21 is in Rampdown / The importance of testing with Early-Access Builds
by 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 Donald 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/00224...
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
1 year, 1 month
