Additional mergers for the wildfly/wildfly GitHub repo
by Brian Stansberry
I'm proposing we significantly expand the set of people who have write
permissions to the wildfly/wildfly GitHub repo. The following folks are all
experienced WildFly developers who act as a component lead for components
in the WFLY JIRA project, but they don't have write permissions to the main
server code repository:
Tomasz Adamski
Jean Francois Denise
Emmanuel Hugonnet
Rado Husar
Tom Jenkinson
Jason Lee
Scott Marlow
Eduardo Martins
Brad Maxwell
Matěj Novotny
Richard Opalka
Harald Pehl
Flavia Rainone
Marco Sappe Griot
I think they should all have write perms.
WDYT about this? Please feel free to let me know either here or privately.
I'd like to leave the topic open for discussion for a week and then, if
there is consensus around it, move forward.
Historically, we've had a pretty small set of people with write permissions
to this repository. That made sense in the early days of AS 7 and WildFly
when the scope and structure of the project were changing rapidly. And it
made sense in the years after 2018 when we started releasing quarterly,
which was new, and we added some pretty opaque and hard to understand
processes around feature development.
But those days are long behind us and TBH I think adding more mergers is
long overdue. It's been on my todo list for too long; my apologies for
that! I think these folks have the experience and judgement needed to know
whether pressing the green button is ok or whether it's better to stop and
ask questions or defer to others.
Note: I'm not proposing changing the set of people who rotate in the role
of release coordinator for micro releases. IOW, having write perms to the
repo doesn't mean you have to act as an RC sometimes. Changing the RC
rotation would be a separate discussion.
Best regards,
--
Brian Stansberry
WildFly Project Lead
He/Him/His
6 months, 1 week
Confirmation Request: Is WildFly 26.0.1 Final Considered End-of-Life?
by Nadia Rosdie
Dear WildFly Maintainers,
Hope you are well.
We are currently using WildFly 26.0.1 Final in a regulated production
environment and need to confirm the platform's lifecycle status for
internal compliance purposes.
I really need your help to kindly clarify the following:
1. Is WildFly 26.0.1 Final considered End Of Life (EOL) i.e. no longer
supported by WildFly team?
2. If possible, is there any official documentation or page we can refer
to that confirms this status?
FYI, based on our internal records, WildFly 26.0.1 Final was released
in Nov 2021 and WildFly 27.0.0 Final was released in Nov 2022. We believe
support for 26.0.1 Final may have ended around that time but would like to
confirm this with your team.
Thank you very much in advance for your time and kind assistance.
Warm regards,
Nadia Rosdie
Compliance Officer for Takaful Operator.
6 months, 1 week
Testing application service runtimes cross-product scenarios
by Fabio Burzigotti
Hello! We've been using the Intersmash framework [1] for a couple of years now, to run WildFly cross-product tests against several middleware services on OpenShift, including Infinispan, Keycloak, ActiveMQ Broker and Strimzi.
Now we are moving some existing test coverage upstream to the Intersmash org, which you can read more about in the related GitHub org README [2]. Specifically we'll move tested applications to the intersmash-applications [3] repository, while actual test cases will be moved to the intersmash-tests [4] repository.
We would like to have WildFly developers involved in reviewing applications - e.g.: by providing input about a specific configuration related to a given use case etc. - and the related test cases, when new ones are added to the aforementioned repositories.
The final goal is to have a common org where developers can interact to review existing test cases while we move them, or to create new ones.
As a payback, the intersmash-tests [4] repository can be used by the community to run complex, real-world interoperability tests on OpenShift, and catch interoperability issues early and effectively in the development process.
Disclaimer: the Intersmash framework codebase is extrapolated from an internal test suite, and as such it might look naive or questionable in some cases.
We're in the process of improving and fixing it along the way, but at the moment it does the job very well, and we found a lot of interoperability issues thanks to it.
Anyway, there is definitely room from improvement, and by the way this is one of the reasons for bringing the whole work upstream, so feel free to contribute!
[1] https://github.com/Intersmash/intersmash/tree/main
[2] https://github.com/Intersmash/.github/blob/main/profile/README.md
[3] https://github.com/Intersmash/intersmash-applications/tree/main
[4] https://github.com/Intersmash/intersmash-tests/tree/main
6 months, 1 week
Java 25 Released - New Leyden EA Builds
by David Delabassee
Welcome to the latest OpenJDK Quality Outreach update.
JDK 25[1] and JavaFX 25[2] were released as planned a few days ago. Additional Java 25 materials, including the "Road to 25" video series, are listed in the "Topics of Interest" section at the end of this update. If you missed it, you can also rewatch the Java 25 launch stream[3].
Thank you to all the projects that contributed to this release by testing early access builds, providing feedback, or identifying issues. Your participation helps shape the Java platform!
Let’s now turn our attention to JDK 26[4], which is expected to enter the Rampdown Phase in just over two months. As of today, three JEPs have already been targeted for inclusion in JDK 26. If you use JavaFX, please pay attention to the time-sensitive heads-up below.
[1] https://blogs.oracle.com/java/post/the-arrival-of-java-25
[2] https://inside.java/2025/09/23/javafx-25/
[3] https://inside.java/2025/09/17/java25-launch-stream/
[4] https://openjdk.org/projects/jdk/26/
# Heads-up - JavaFX 26: Temporary switch to macOS Metal Rendering Pipeline
On macOS, the default JavaFX rendering pipeline has been temporarily switched to Metal since JavaFX 26 early access build 5. This change will remain in place until October 8, 2025. The goal is to enable wider testing of the Metal rendering pipeline.
If you need to revert to the previous macOS ES2 pipeline, you can do so by adding the `-Dprism.order=es2` flag to your Java command.
The latest JavaFX 26 EA builds are now available for download[5] and testing. You can share your feedback on the openjfx-dev[6] list (registration required), through JBS[7] or bugreport.java.com[8].
[5] https://jdk.java.net/javafx26/
[6] https://mail.openjdk.org/mailman/listinfo/openjfx-dev
[7] https://bugs.openjdk.org/
[8] https://bugreport.java.com
# Heads-up - New Leyden Early-Access Builds
The purpose of Leyden early access builds is to prototype improvements in startup time, time to peak performance, and footprint of Java programs, with the hope that some of these enhancements can eventually be incorporated into future JDK releases. The Java community is invited to test these prototypes and provide feedback to the Project Leyden team.
The latest Leyden "premain" prototype[9] introduces several experimental Ahead-of-Time (AOT) optimizations not yet part of the JDK mainline. These include AOT code compilation for frequently used methods, AOT generation of dynamic proxies and reflection data to improve start-up time, and a cache for failed class lookups to speed up repeated attempts. All these experimental features are, in the Leyden EA2 builds, enabled by default when creating an AOT cache and can be disabled via specific flags.
More details on how to use these features can be found in the EA2 Release Notes[10]. Feedback should be sent to the leyden-dev[11] mailing list (registration required).
[9] https://jdk.java.net/leyden/
[10] https://github.com/openjdk/leyden/blob/leyden-ea2-release-notes/README.md
[11] https://mail.openjdk.org/mailman/listinfo/leyden-dev
# JDK 26 Early-Access Builds
The JDK 26 early access builds 16 are available[12], and are provided under the GNU General Public License v2, with the Classpath Exception. You can review the Release Notes here[13].
## JEPs targeted to JDK 26, so far:
- JEP 504: Remove the Applet API
- JEP 517: HTTP/3 for the HTTP Client API
- JEP 522: G1 GC: Improve Throughput by Reducing Synchronization
## Changes in recent JDK 26 EA builds that may be of interest:
- JDK-8244336: Restrict algorithms at JCE layer
- JDK-8366911: (fs) Remove support for normalizing file names to Unicode normalized form D (macOS)
- JDK-8367112: HttpClient does not support Named Groups set on SSLParameters
- JDK-8367031: [backout] Change java.time month/day field types to 'byte'
- JDK-8366434: THP not working properly with G1 after JDK-8345655
- JDK-8365086: CookieStore.getURIs() and get(URI) should return an immutable List
- JDK-8364993: JFR: Disable jdk.ModuleExport in default.jfc
- JDK-8364556: JFR: Disable SymbolTableStatistics and StringTableStatistics in default.jfc
- JDK-8359443: Make jcmd command available in the headless JDK RPM
- JDK-8362304: Fix JDWP spec w.r.t. OPAQUE_FRAME and INVALID_SLOT errors
- JDK-8277585: Remove the terminally deprecated finalize() method from javax.imageio.stream APIs
- JDK-8362448: Make use of the Double.toString(double) algorithm in java.text.DecimalFormat
- JDK-8309400: JDI spec needs to clarify when OpaqueFrameException and NativeMethodException are thrown
- JDK-8363972: Lenient parsing of minus sign pattern in DecimalFormat/CompactNumberFormat
- JDK-8329829: HttpClient: Add a BodyPublishers.ofFileChannel method
- JDK-8364227: MBeanServer registerMBean throws NPE
- JDK-8361614: Missing sub-int value validation in the Class-File API
- JDK-8361635: Missing List length validation in the Class-File API
- JDK-8364751: ConstantBootstraps.explicitCast contradictory specification for null-to-primitive
- JDK-8361613: System.console() should only be available for interactive terminal
- JDK-8365676: javac incorrectly allows calling interface static method via type variable
Note: A more exhaustive list of changes can be found here[14].
[12] https://jdk.java.net/26/
[13] https://jdk.java.net/26/release-notes
[14] https://github.com/openjdk/jdk/compare/jdk-26+10...jdk-26+16
# Topics of Interest
- Java 25 Launch Stream
https://inside.java/2025/09/17/java25-launch-stream/
- The Arrival of Java 25
https://blogs.oracle.com/java/post/the-arrival-of-java-25
- JDK 25: G1/Parallel/Serial GC changes
https://tschatzl.github.io/2025/08/12/jdk25-g1-serial-parallel-gc-changes...
- JavaFX 25 Highlights
https://inside.java/2025/09/23/javafx-25/
- Road To 25: All API Additions From Java 21 to 25
https://inside.java/2025/09/09/roadto25-api/
- Road To 25: How to Handle Security Changes in Java 25
https://inside.java/2025/09/07/roadto25-security/
- Road To 25: Java 21 ⮕ 25 - Performance and Runtime Enhancements
https://inside.java/2025/09/05/roadto25-performance/
- Road To 25: All New Java Language Features Since Java 21
https://inside.java/2025/08/31/roadto25-java-language/
- Road To 25: Ahead-of-Time Computation
https://inside.java/2025/08/28/roadto25-aot/
- Road To 25: How to Upgrade to Java 25
https://inside.java/2025/08/24/roadto25-upgrade/
- JVMLS: Growing the Java Language
https://inside.java/2025/08/21/jvmls-growing-java-language/
- JVMLS: Auto-Vectorization in HotSpot
https://inside.java/2025/08/16/jvmls-hotspot-auto-vectorization/
- JVMLS: Paths to Support Additional Numeric Types on the Java Platform
https://inside.java/2025/09/21/jvmls-java-additional-numeric-types/
- Java Architects Answer Your Questions
https://inside.java/2025/08/14/newscast-97/
- GC-Agnostic Load Barriers for Ahead-of-Time Compilation
https://inside.java/2025/08/27/thesis-gc-agnostic-load-barriers/
~
This concludes the update. Please don’t hesitate to reach out if you encounter any issues while testing your projects with the latest JDK 26 early access builds.
P.S.: If you no longer wish to receive these Quality Outreach updates, please let me know.
--David
6 months, 1 week
Next steps on WildFly Governance
by Brian Stansberry
We've taken a bit of an August holiday away from the WildFly Governance
topic, but I'd like to pick it up and try and by the end of October get
GOVERNANCE.md files in places for the WildFly Application Server project
and the overall WildFly Commonhaus Organization.
From our discussions I think we need to do 3 things:
1) Identify all the people who currently have write permissions to all the
various repos.
This list becomes the base for identifying the initial set of folks in the
proposed Maintainer role.
Maybe on Friday I'll take a crack at a JBang script to extract this data
via the GitHub REST API.
2) For WildFly AS itself, for all the various subprojects, identify which
have leads. For this, you tell me. :-)
I don't think either 1) or 2) really block the big one, which is....
3) Adopt GOVERNANCE.md documents for the WildFly Commonhaus Organization
and the WildFly Application Server top level WCO project.
Toward this end, I've taken the content of the draft governance Google doc
we discussed this summer and converted the WCO and WildFly AS tabs into
markdown files. I then opened PRs in the new 'wildfly-governance' repo:
WCO -- https://github.com/wildfly/wildfly-governance/pull/4
WildFly AS -- https://github.com/wildfly/wildfly-governance/pull/5
Each of those branches has a commit for the original Google doc content and
then other commits to incorporate various ideas we discussed in July.
I propose the following:
A) Between now and Mon Oct 6 we discuss those PRs via comments on the PRs,
making appropriate edits as we go. Goal is to finalize the proposed text.
B) For two weeks starting then we let more formally express their agreement
disagreement via a simple GitHub emoji reaction thing Commonhaus has used.
(I'll explain more on that later; this message is already long enough.)
So the key thing is to look at and react to those 2 PRs!
Thanks,
--
Brian Stansberry
WildFly Project Lead
He/Him/His
6 months, 2 weeks
