JDK 25 Initial Release Candidate
by David Delabassee
Welcome to the OpenJDK Quality Outreach summer update!
Everything is on track for the General Availability of Java 25 on September 16 as the JDK 25 Release Candidate builds (RC1 - builds 35) are now available[1]. If you haven't done so yet, please start testing your project(s) using JDK 26 early-access builds and let us know the results.
Changing topics, the JVM Language Summit (JVMLS) was held last week in Santa Clara (California). JVMLS is a unique event that brings together Java and JVM architects and OpenJDK developers to discuss the evolution and future directions of the platform. The first JVMLS video has just been published, with more to follow. To stay informed about the latest developments, keep an eye on this JVMLS playlist[2].
[1] https://mail.openjdk.org/pipermail/jdk-dev/2025-August/010296.html
[2] https://www.youtube.com/playlist?list=PLX8CzqL3ArzUOgZpIX6GsoRhPbnij-sco
# JDK 25
The JDK 25 early-access builds 35 are available[3], and are provided under the GNU General Public License v2, with the Classpath Exception. The Release Notes are available here[4]. For more details on Java 25, please refer to the “Topics of Interest” section below.
## JEPs Integrated into JDK 25:
- JEP 470: PEM Encodings of Cryptographic Objects (Preview)
- JEP 502: Stable Values (Preview)
- JEP 503: Remove the 32-bit x86 Port
- JEP 505: Structured Concurrency (5th Preview)
- JEP 506: Scoped Values
- JEP 507: Primitive Types in Patterns, instanceof, and switch (3rd Preview)
- JEP 508: Vector API (1Oth Incubator)
- JEP 509: JFR CPU-Time Profiling (Experimental)
- JEP 510: Key Derivation Function API
- JEP 511: Module Import Declarations
- JEP 512: Compact Source Files and Instance Main Methods
- JEP 513: Flexible Constructor Bodies
- JEP 514: Ahead-of-Time Command-Line Ergonomics
- JEP 515: Ahead-of-Time Method Profiling
- JEP 518: JFR Cooperative Sampling
- JEP 519: Compact Object Headers
- JEP 520: JFR Method Timing & Tracing
- JEP 521: Generational Shenandoah
## Changes in Recent JDK 25 Builds of Interest:
- JDK-8359596: Behavior change when both -Xlint:options and -Xlint:-options flags are given [Reported by Apache Lucene]
- JDK-8356698: JFR: @Contextual
- JDK-8351594: JFR: Rate-limited sampling of Java events
- JDK-8241678: Remove PerfData sampling via StatSampler
- JDK-8356870: HotSpotDiagnosticMXBean.dumpThreads and jcmd Thread.dump_to_file updates
- JDK-8350689: Turn on timestamp and thread metadata by default for java.security.debug
- JDK-8354450: A File should be invalid if an element of its name sequence ends with a space
- JDK-8350880: (zipfs) Add support for read-only zip file systems
- JDK-8341346: Add support for exporting TLS Keying Material
- JDK-8345431: Improve jar --validate to detect duplicate or invalid entries
- JDK-8359170: Added 4 New Root Certificates from Sectigo Limited
- JDK-8358590: JFR: Include min and max in MethodTiming event
- JDK-8228773: URLClassLoader constructors should include API note warning that the parent should not be null
- JDK-8356049: Need a simple way to play back a sound clip
- JDK-8357955: java.lang.classfile.Signature.ArrayTypeSig.of IAE not thrown for dims > 255
- JDK-8359729: Remove the multiplex protocol from the RMI specification
Note: A more exauhstive list of changes can be found here[5].
[3] https://jdk.java.net/25/
[4] https://jdk.java.net/25/release-notes
[5] https://github.com/openjdk/jdk/compare/jdk-25+25...jdk-25+35
# JDK 26
The JDK 26 early-access builds 10 are available[6] and are provided under the GNU General Public License v2, with the Classpath Exception. The release notes are available here[7].
## Changes in Recent JDK 26 Builds of Interest:
- JDK-8361380: ARM32: Atomic stubs should be in pre-universe [Reported by JaCoCo]
- JDK-8359170: Add 2 TLS and 2 CS Sectigo roots
- JDK-8359809: AttributeList, RoleList and UnresolvedRoleList should never accept other types of Object
- JDK-8268406: Deallocate jmethodID native memory
- JDK-8314180: Disable XPath in XML Signatures
- JDK-8330940: Impossible to create a socket backlog greater than 200 on Windows 8+
- JDK-8357653: Inner classes of type parameters emitted as raw types in signatures
- JDK-8347114: JMXServiceURL should require an explicit protocol
- JDK-8309399: JVMTI spec needs to clarify when OPAQUE_FRAME is thrown for reasons other than a native method
- JDK-8361212: Remove AffirmTrust root CAs
- JDK-8353925: Remove Sun Microsystems JCE Code Signing Root CA
- JDK-8361964: Remove outdated algorithms from requirements and add PBES2 algorithms
- JDK-8332623: Remove setTTL()/getTTL() methods from DatagramSocketImpl/MulticastSocket and MulticastSocket.send(DatagramPacket, byte)
- JDK-8359760: Remove the jdk.jsobject module
- JDK-8356557: Update CodeSource::implies API documentation and deprecate java.net.SocketPermission class for removal
- JDK-8310932: [win] Install the JDK in a per-release directory pointed to by a shared junction
- JDK-8359956: Support algorithm constraints and certificate checks in SunX509 key manager
- JDK-8359395: XML signature generation does not support user provided SecureRandom
- JDK-8356645: Javac should utilize new ZIP file system read-only access mode
Note: A complete list of changes can be found here[8].
[6] https://jdk.java.net/26/
[7] https://jdk.java.net/26/release-notes
[8] https://github.com/openjdk/jdk/compare/jdk-26+1...jdk-26+10
# Topics of Interest
- Java 25 Encodes PEM
https://inside.java/2025/06/19/newscast-93/
- JDK 25: Just Be Lazy
https://inside.java/2025/07/29/just-be-lazy/
- JDK 25: A Sneak Peek at the Stable Values API
https://inside.java/2025/07/22/javaone-stablevalues/
- Java 25 is ALSO no LTS Version
https://inside.java/2025/07/03/newscast-94/
- JVMLS: The not-so-final word on `final`
https://inside.java/2025/08/12/jvmls-final-to-immutable/
- HTTP/3 in Java
https://inside.java/2025/07/31/newscast-96/
- Project Leyden's AOT / Shifting Java Startup into High Gear
https://inside.java/2025/06/29/javaone-leyden-aot/
- Java Security Evolution - Out with the Old, In with the New
https://inside.java/2025/07/20/javaone-security/
- Java GPGPU Enablement: Are We There Yet?
https://inside.java/2025/07/14/javaone-hat/
- Podcast “Deprecations & Removals” with Stuart Marks
https://inside.java/2025/07/28/podcast-039/
- Podcast “Integrity by Default” with Ron Pressler
https://inside.java/2025/06/24/podcast-038/
- A New Model for Java Object Initialization
https://inside.java/2025/07/27/javaone-object-initialization/
- ZGC: Paving the GC On-Ramp
https://inside.java/2025/07/10/javaone-zgc/
- Marshalling: Data-Oriented Serialization
https://inside.java/2025/07/08/javaone-marshalling/
- Interconnecting Java and Native Code with the FFM API
https://inside.java/2025/06/14/javaone-ffm/
- FFM vs. Unsafe. Safety (Sometimes) Has a Cost
https://inside.java/2025/06/12/ffm-vs-unsafe/
- Java Gets a JSON API
https://inside.java/2025/07/17/newscast-95/
~
That’s it for now. If you run into any issues while testing your projects with the latest JDK 26 early-access builds, don’t hesitate to reach out. The end of summer is going to be exciting and busy with the Java 25 launch coming up, so stay tuned!
PS: If you no longer wish to receive OpenJDK Quality Outreach updates, please let me know.
--David
5 months
WildFly 37 is released!
by Brian Stansberry
Phew! WildFly 37.0.0.Final is available at wildfly.org and in JBoss Nexus.
The release announcement is at
https://www.wildfly.org/news/2025/08/04/WildFly-37-is-released/.
Thanks for hanging in there on this one during a quarter with a lot of
transition. Commonhaus, JBoss Nexus, employer transition from Red Hat to
IBM for any of you. You deserve some nice vacation time!
Note the Nexus migration is still in progress. I'll follow up on my recent
threads about that tomorrow.
Best regards,
--
Brian Stansberry
Architect, JBoss EAP
WildFly Project Lead
He/Him/His
5 months
Bom builder thoughts
by Brian Stansberry
Some thoughts related to our 'bom builder' modules, sparked by the fact
they are causing issues with syncing WildFly content from JBoss Nexus to
Maven Central.
1) The configuration of the plugin that generates the bom includes elements
like 'parent' and 'license' that also appear in the root level of a pom.
This has led to trouble, so I suggest renaming these elements.
https://issues.redhat.com/browse/NEXUS-967 was a problem where some tooling
on JBoss Nexus was confused by these and was unwilling to sync content to
Central because of the presence of these artifacts. This is now fixed.
But, now we see Central is rejecting these poms. Exactly why is still
unclear but a theory is that they are looking at the plugin configuration
section, confusing them for document roots, and rejecting the pom because
the 'document root' is missing required elements.
I'll probably file an issue to rename these config elements.
2) Full WF uses `wildfly-bom-builder-plugin` for bom generation, while core
has a 'component-matrix-builder' module that uses a
`wildfly-component-matrix-plugin`. These look very similar. Can't we just
use `wildfly-bom-builder-plugin` in core? Both plugins have a similar
config that has the issues discussed in #1.
3) AFAICT output of Core's component-matrix-builder module isn't used
anywhere, nor do we do anything to maintain it. One substantive commit
since 2019. We should either:
a) Drop this, or
b) Use it in WF as the 'core-bom' instead of using wildfly-core-parent.
I filed https://issues.redhat.com/browse/WFLY-20833 to explore the latter
idea.
Best regards,
--
Brian Stansberry
Architect, JBoss EAP
WildFly Project Lead
He/Him/His
5 months
Updates to SECURITY.md files
by Brian Stansberry
One of our TODOs related to moving to Commonhaus is housekeeping related to
SECURITY.md files.
Note: This is initially intended as a discussion thread, not a call for
people to start making updates.
1) A lot of our SECURITY.md files say to report issues via email to
secalert(a)redhat.com. This is ok for now (i.e. this isn't a crisis) but we
should move to using a community address.
WildFly AS has a security(a)wildfly.org address, which is what we ask people
to use on a number of SECURITY.md files, including the one in the main
wildfly/wildfly repo. There's a small group of people who monitor that
address and react to posts on it. We bring in others to assist when needed.
I think all projects under the WildFly umbrella at Commonhaus should use
security(a)wildfly.org in their SECURITY.md. For sure repos under the WildFly
AS top-level project should. If other top-level projects have their own
different mechanisms, that's ok.
Thoughts?
2) Call for volunteers! We're considering adding GPG encryption
instructions to our recommended SECURITY.md content, so people can encrypt
their reports. If you're interested in helping with that, please let Darran
or I know. Tasks include working on:
* Evaluation of whether we should publish a GPG key for CVE reporting.
* Creation of said key including securely sharing of the private key with
the required audience.
* Coordination of publication of the public key on relevant SECURITY.md
files.
The last one I see as mostly being about drafting suitable language and
assisting with questions about how to incorporate the language.
Before people start changing lots of SECURITY.md files we should discuss a
bit here first and see what comes of #2 above. Changing dozens of files
only to turn around and change them again a few weeks later would be a
waste of valuable time.
--
Brian Stansberry
Architect, JBoss EAP
WildFly Project Lead
He/Him/His
5 months
