JDK 25 feature set frozen!
by David Delabassee
Welcome to the June edition of the OpenJDK Quality Outreach update.
JDK 25, scheduled for General Availability on September 16, 2025, has entered Rampdown Phase One (RDP1)[1]. The JDK 25 feature set is now frozen (see JDK 25 details below), and only low-risk enhancements will be considered. Please help us identify potential issues in the coming weeks by testing your projects on JDK 25 EA builds. With enough lead time, we can resolve them before JDK 25 transitions to the Release Candidate phase in early August[2].
Be make sure to review the JDK 25 heads-ups below; two of them pertain to changes in file operations on Windows.
Last but certainly not least, you are invited to attend next week’s JCP EC online public meeting, where Alex Buckley will give a presentation on Tip & Tail Development—a topic particularly relevant for open-source project maintainers. See [3] for details, the meeting will be recorded.
[1] https://mail.openjdk.org/pipermail/jdk-dev/2025-June/010191.html
[2] https://openjdk.org/projects/jdk/25/
[3] https://jcp.org/aboutJava/communityprocess/ec-public/materials/2025-06-10...
# Heads-up - JDK 25: java.io.File.delete no longer deletes read-only files on Windows
`File.delete` has been changed on Windows so that it now fails and returns `false` for regular files when the DOS read-only attribute is set. Prior to JDK 25, `File.delete` would delete read-only files by first removing the DOS read-only attribute before attempting deletion. However, because removing the attribute and deleting the file are not a single atomic operation, this could result in the file remaining but with modified attributes if the deletion failed. Applications that depend on the previous behavior should be updated to clear the file attributes before deleting files.
To ease the transition, a system property has been introduced to restore the previous behavior. Running with `-Djdk.io.File.allowDeleteReadOnlyFiles=true` will cause `File.delete` to remove the DOS read-only attribute before attempting deletion, restoring the legacy behavior.
See https://bugs.openjdk.org/browse/JDK-8355954 for more details.
# Heads-up - JDK 25: File operations on Windows now always fail if the used name ends with a space
File operations on a path with a trailing space in a directory or file name, e.g. "C:\\SomeFolder\\SomeFile ", now fail consistently on Windows. For example. `File::mkdir` will return `false`, or `File::createNewFile` will throw `IOException` if an element in the path has a trailing space. Such pathnames are not legal on Windows. Prior to JDK 25, operations on a `File` created from such an illegal abstract pathname could appear to succeed when in fact they did not.
See https://bugs.openjdk.org/browse/JDK-8354450 for more details.
# Heads-up - JDK 25: Separate Metaspace and GC Printing
Historically the printing of Metaspace and GC logs have been combined; this was a result of permanent generation (PermGen) being a part of the GC Heap. However, Metaspace has replaced PermGen and resides in its own native memory location outside of the GC Heap. With Metaspace no longer a part of the GC Heap, the reason for combining the messaging no longer makes sense and could lead to confusion.
Starting with JDK 25, the way logging is tagged in the HotSpot JVM will change: although the content of the logs will remain the same, messages related to Metaspace will now use the existing Metaspace tag.
As part of this update, there are also some user-facing changes to `jcmd`. To better clarify that Metaspace is not part of the GC Heap, Metaspace information is no longer displayed with the `GC.heap_info` command. Instead, details about Metaspace memory usage have been moved to the `VM.metaspace` command.
See https://bugs.openjdk.org/browse/JDK-8356848 for more details.
# JDK 25
The JDK 25 early-access builds 25 are available[4] and are provided under the GNU General Public License v2, with the Classpath Exception. The Release Notes are available here[5].
Please refer to the “Topics of Interest” section at the end of this update for additional information on JDK 25.
## JEPs integrated in 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 (10th 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 that may be of interest:
- JDK-8340321: Disable SHA-1 in TLS/DTLS 1.2 handshake signatures
- JDK-8354276: Strict HTTP header validation
- JDK-8356848: Separate Metaspace and GC printing
- JDK-8355954: java.io.File.delete no longer deletes read-only files on Windows
- JDK-8353440: Disable FTP fallback for non-local file URLs by default
- JDK-8354908: javac mishandles supplementary character in character literal
- JDK-8355360: -d option of jwebserver command should accept relative paths
- JDK-8354084: Streamline XPath API's extension function control
- JDK-8354305: SHAKE128 and SHAKE256 MessageDigest algorithms
- JDK-8343110: Add getChars(int, int, char[], int) to CharSequence and CharBuffer
- JDK-8356154: Respecify java.net.Socket constructors that allow creating UDP sockets to throw IllegalArgumentException
- JDK-8322810: Lambda expression types can't be classes
- JDK-8352612: No way to add back lint categories after "none"
- JDK-8348732: SunJCE and SunPKCS11 have different PBE key encodings
- JDK-8350498: Remove two Camerfirma root CA certificates
- JDK-8350441: ZGC: Overhaul Page Allocation
- JDK-8347337: ZGC: String dedups short-lived strings
- JDK-8350279: HttpClient: Add a new HttpResponse method to identify connections
- JDK-8350753: Deprecate UseCompressedClassPointers
- JDK-8254622: Hide superclasses from conditionally exported packages
- JDK-8346465: Add a check in setData() to restrict the update of Built-In ICC_Profiles
- JDK-8347472: Correct Attribute traversal and writing for Code attributes
- JDK-8351654: Agent transformer bytecodes should be verified
- JDK-8348967: Deprecate security permission classes for removal
- JDK-8353642: Deprecate URL::getPermission method and networking permission classes for removal
- JDK-8353856: Deprecate FlighRecorderPermission class for removal
- JDK-8353614: JFR: jfr print --exact
- JDK-8346109: Create JDK taglet for additional preview notes
- JDK-8285888: Clarify that java.net.http.HttpClient do NOT support Digest authentication
- JDK-8350542: Optional.orElseThrow(Supplier) does not specify behavior when supplier returns null
- JDK-8342206: Convenience method to check if a constant pool entry matches nominal descriptors
Note: For a more exhaustive list of changes, please see here[6].
[4] https://jdk.java.net/25/
[5] https://jdk.java.net/25/release-notes
[6] https://github.com/openjdk/jdk/compare/jdk-25+17...jdk-25+25
# JavaFX 25 Early-Access Builds
These are early access builds of the JavaFX 25 Runtime, built from the openjdk/jfx repository. They enable JavaFX application developers to build and test their applications with JavaFX 25 on JDK 25. Although these builds are designed to work with JDK 25 EA, they are also compatible with JDK 22 and later versions.
The latest early access builds of JavaFX 25 Builds 18 (2025/5/23) are available[7], under the GNU General Public License, version 2, with the Classpath Exception. JavaFX 25 API Javadocs[8] are available too.
[7] https://jdk.java.net/javafx25/
[8] https://download.java.net/java/early_access/javafx25/docs/api/overview-su...
# JavaFX Direct3D 12 Early-Access Builds
These are early access builds of JavaFX from the "direct3d12" branch of the openjdk/jfx-sandbox repository[9], which implement the new Direct3D 12 graphics rendering pipeline for Windows x64. The goal of these EA builds is to solicit feedback as we work toward integrating this functionality into JavaFX. Binaries[10] are provided for convenience, so users do not need to build from source.
Feedback can be reported to the openjfx-dev mailing list[11]. These builds are provided under the GNU General Public License, version 2, with the Classpath Exception, and are based on an incomplete version of JavaFX 25.
[9] https://github.com/openjdk/jfx-sandbox/tree/direct3d12
[10] https://jdk.java.net/javafxdirect3d12/
[11] https://mail.openjdk.org/pipermail/openjfx-dev/
# Topics of Interest
- Java 25 Brings 18 JEPs - Inside Java Newscast
https://inside.java/2025/06/05/newscast-92/
- Strings Just Got Faster in JDK 25
https://inside.java/2025/05/01/strings-just-got-faster/
- What's new for JFR in JDK 25
https://egahlin.github.io/2025/05/31/whats-new-in-jdk-25.html
- Structured Concurrency Revamp in Java 25 - Inside Java Newscast
https://inside.java/2025/05/08/newscast-91/
- Where Is the Java Language Going?
https://inside.java/2025/04/20/javaone-future-java/
- Java for AI
https://inside.java/2025/05/03/javaone-java-ai/
- Pattern Matching in Java: Better Code, Better APIs
https://inside.java/2025/05/24/javaone-pattern-matching/
- Towards a JSON API for the JDK
https://mail.openjdk.org/pipermail/core-libs-dev/2025-May/145905.html
- Modern Java Development with Tip & Tail
https://inside.java/2025/05/17/javaone-tip-tail/
- Java 24, Faster Than Ever
https://inside.java/2025/05/17/javaone-faster-jdk24/
- “Ahead of Time Computation” with Dan Heidinga - Inside Java Podcast
https://inside.java/2025/05/16/podcast-036/
- “Stream Gatherers” with Viktor Klang - Inside Java Podcast
https://inside.java/2025/05/05/podcast-035/
- Garbage Collection in Java: The Performance Benefits of Upgrading
https://inside.java/2025/05/14/javaone-garbage-collection/
- JavaFX 24 and Beyond
https://inside.java/2025/05/10/javaone-javafx/
- JDK 24 Security Enhancements
https://seanjmullan.org/blog/2025/04/07/jdk24
~
This concludes the update for now. Should you experience any difficulties while testing your projects with the latest JDK early-access builds, just ping me.
PS: If you no longer wish to receive OpenJDK Quality Outreach updates, please let me know.
--David
1 year
Commonhaus update
by Brian Stansberry
I'm pleased to report that yesterday Tom Jenkinson and I signed the
agreement with Commonhaus for them to sponsor the WildFly family of
projects. And last week Red Hat and Commonhaus signed an agreement that
transfers intellectual property associated with WildFly to Commonhaus.
These are the legal agreements involved with moving the project from Red
Hat to Commonhaus sponsorship, so I'm very pleased that this is done and
Commonhaus is now our sponsor!
There's still more to do as we complete the Commonhaus onboarding process,
including things like the transfer of domains to the registrar Commonhaus
uses, making sure repos and github orgs meet requirements etc.
I've created a Zulip channel where more chatty discussions focused on
things related to WildFly and Commonhaus can happen:
https://wildfly.zulipchat.com/#narrow/channel/507977-Commonhaus
One thing to do is to update the SECURITY.md files in our repos, as the
ones many repos currently use are focused to greater or lesser degrees on
Red Hat. https://github.com/wildfly/.github/blob/main/SECURITY.md is a
standard one to use. The main wildfly/wildfly repo has one much like that
which I updated as follows:
https://github.com/wildfly/wildfly/pull/18978
That file and the one in
https://github.com/wildfly/.github/blob/main/SECURITY.md differ only in the
presence of the 'Note that we will only fix such issues in the most recent
minor release of WildFly' sentence in the wildfly/wildfly repo. That
sentence is valid but may be less appropriate for a repo that produces a
component where the typical thing is to fix a security issue by producing a
bug fix release.
Projects in the WildFly family that have their own separate identity of
course might use different language.
Best regards,
--
Brian Stansberry
Principal Architect, Red Hat JBoss EAP
WildFly Project Lead
He/Him/His
1 year
