WildFly 36 Final is released!
by Brian Stansberry
WildFly 36.0.0.Final is now released! The release announcement is at
https://www.wildfly.org/news/2025/04/10/WildFly36Released/.
It's been a hectic quarter for a lot of us, so it's great to see the
continued innovation, with stuff that wasn't particularly on the radar
screen a few months ago now available. A source-only Jakarta REST +
Microprofile app with JBang? Boom! Try it out! MCP? Boom! Try it out! And
we continue with bread-and-butter value like exposing Micrometer metrics
over Prometheus.
Thank you all!
A process note -- on the feature planning board (
https://github.com/orgs/wildfly/projects/7/views/1) for any issues with
WildFly 36 set as their development window, if it wasn't part of the
release I cleared the development window, so the feature teams should
consult each other and pick a new target if they can. I don't want to just
roll things under the assumption the feature will happen in 37.
Best regards,
--
Brian Stansberry
Principal Architect, Red Hat JBoss EAP
WildFly Project Lead
He/Him/His
1 year, 1 month
Fwd: [ejb-dev] New release for Jakarta EE 12?
by Brian Stansberry
I'm forwarding this to the wildfly-dev list to ensure those of us involved
with EJB are aware and can comment.
You can blame me for the 'was identified' part re SecurityManager, or at
least for pointing out the problematic text section that Jared linked.
Best regards,
Brian
---------- Forwarded message ---------
From: Jared Anderson via ejb-dev <ejb-dev(a)eclipse.org>
Date: Wed, Apr 9, 2025 at 3:39 PM
Subject: Re: [ejb-dev] New release for Jakarta EE 12?
To: ejb-dev(a)eclipse.org <ejb-dev(a)eclipse.org>, Edward Burns <
Edward.Burns(a)microsoft.com>
Cc: Jared Anderson <jhanders(a)us.ibm.com>
Community members,
I am writing this email to your community now that the April 15 deadline is
fast approaching. As of now, a release plan for a next release of your
component has not been created or an indication put in the opened issue in
my original email to state that you do not plan a release that could be
considered for Jakarta EE 12.
It was brought to my attention that people may not realize what is being
asked to be done when creating a release plan. There is information in the
issue provided on the how, but the main point of having a release plan is
that we are looking to know that you are planning to do something and
whether you are looking at doing a minor release or a major release
depending on the types of changes. What is in the release plan that you
create can change over time, but at least there is an indication that you
are working to make a new release even if you don't know what all will be
in it yet. We are not asking for all issues to be created and code, tests,
implementation or specs to be updated in order to make a release plan. If
you look at the release plans created so far, you will find that some of
them are quite vague. They are just saying yes we plan on doing a new
version of the component. A release plan also gives an indication to those
not in the Jakarta community that work is happening in the specification
that they can look forward to and possibly suggest changes. If you need
help with making your release plan, please reach out to Ed or me on slack
or email.
Enterprise Beans was identified as a component that requires a new release
in order to remove Java SecurityManager language from the specification at
this location
<https://jakarta.ee/specifications/enterprise-beans/4.0/jakarta-enterprise...>
.
If there are no other things to be added to a release plan for Enterprise
Beans, that is ok. It can just be a very minor release to update the
specification to remove SecurityManager references.
Thanks,
Jared Anderson
Jakarta EE 12 Release Co-coordinator
------------------------------
*From:* Jared Anderson <jhanders(a)us.ibm.com>
*Sent:* Wednesday, February 26, 2025 3:55 PM
*To:* ejb-dev(a)eclipse.org <ejb-dev(a)eclipse.org>; Edward Burns <
Edward.Burns(a)microsoft.com>
*Subject:* New release for Jakarta EE 12?
Community members,
*Executive Summary*
1. See issue #153 <https://github.com/jakartaee/enterprise-beans/issues/153>
.
a. If you don't plan to have a new version for your specification in EE 12,
just close the issue.
b. If you plan to have a new version, use the issue to create a release
plan by April 15, 2025.
2. See this dashboard <https://github.com/orgs/jakartaee/projects/17> where
the component release plan issues are tracked.
*Details*
On Monday I opened issue #153
<https://github.com/jakartaee/enterprise-beans/issues/153> in your
repository to request your community to consider a new release of your
component for Jakarta EE 12 by creating a new release plan. The issue
contains a lot of details that explain what to do to create a release plan.
You can use the issue to document initial thoughts and reference other
issues in your repository as you work out what you want to include in a
release plan.
A dashboard in GitHub was created to track the status of the release plan
issues. The dashboard, located here
<https://github.com/orgs/jakartaee/projects/17>, contains both a Board and
Table view of the release plan issues. What is being asked of each
community is to decide on if you plan to have a new release to be
considered for EE 12 or not. If not, closing the issue will move it to the
final column on the dashboard. If you are planning to have a new version
of your component for EE 12, please follow the instructions in the issue by
April 15, 2025 in order to get your issue moved to the second column for
your mentor to look at the issue and get it ready for a plan ballot. You
will see that your issue in the board includes the name of the mentor that
was assigned to your component in EE 11.
Thanks,
Jared Anderson and Ed Burns
Jakarta EE 12 Release Co-coordinators
_______________________________________________
ejb-dev mailing list
ejb-dev(a)eclipse.org
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/ejb-dev
--
Brian Stansberry
Principal Architect, Red Hat JBoss EAP
WildFly Project Lead
He/Him/His
1 year, 1 month
OpenJDK Quality Outreach: Java 24 Is Now Available
by David Delabassee
Greetings and welcome to the latest OpenJDK Quality Outreach update!
JDK 24 was officially released (General Availability) on March 18th during JavaOne. You can rewatch the Java 24 launch and the J1 keynote here [1]. Be sure to also check out the Quality Outreach section here [2]. JavaOne was amazing, and if you couldn't attend, make sure to watch the JavaOne 2025 playlist [3] regularly as sessions are gradually being added.
With the release of JDK 24, the focus now moves to JDK 25 testing. On that note, be sure to check out the heads-up below, with more to follow. And as always, if you experience any issues with your project running on a JDK 25 early-access builds, please don't hesitate to reach out.
[1] https://www.youtube.com/watch?v=mk_2MIWxLI0&t=12s
[2] https://www.youtube.com/live/GwR7Gvi80Xo?si=gxdqAhVbnNV0JZGt&t=2795
[3] https://www.youtube.com/playlist?list=PLX8CzqL3ArzVV1xRJkRbcM2tOgVwytJAi
# Heads-up - JDK 25: New Null Checks in Inner Class Constructors
The Java Language Specification prescribes that various use sites of inner class constructors should include null checks of the immediately enclosing instance and from then on assumes that the reference is non-null. However, it does not mandate such checks of the incoming instance at the declaration site of these constructors and so core reflection, method handles, and direct bytecode invocation can pass null as enclosing instance, which can lead to NullPointerExceptions down the road.
Since a null enclosing instance is outside of the JLS and the future evolution of inner classes may lead to unexpected NPEs, Java 25 will start ensuring that references to the immediately enclosing instance are always non-null.
Starting with JDK 25, when javac is targeting release 25 or higher, it will emit null checks for the enclosing instances in inner class constructors.
This behavioral change will lead to new NPEs in code that uses core reflection, method handles, or direct bytecode invocation to pass null as enclosing instance. Such code is rare and usually found in libraries or frameworks (as opposed to in applications). It should be changed to no longer pass a null reference.
In case these additional checks lead to issues, their emission can be prevented with a flag: `-XDnullCheckOuterThis=(true|false)`. This should be seen as a temporary workaround and no guarantees are made for how long this flag will be available.
For more details, check JDK-8351274 [4].
[4] https://bugs.openjdk.org/browse/JDK-8351274
# JDK 25
The JDK 25 early-access builds 17 are available [5] and are provided under the GNU General Public License v2, with the Classpath Exception. The Release Notes are available here [6].
The following JEPs have been targeted to JDK 25, so far:
- JEP 502: Stable Values (Preview)
- JEP 503: Remove the 32-bit x86 Port
## Changes in recent JDK 25 builds that may be of interest:
- JDK-8353118: Deprecate the use of `java.locale.useOldISOCodes` system property
- JDK-8351435: Change the default Console implementation back to the built-in one in `java.base` module
- JDK-8350459: MontgomeryIntegerPolynomialP256 multiply intrinsic with AVX2 on x86_64
- JDK-8349583: Add mechanism to disable signature schemes based on their TLS scope
- JDK-8338675: javac shouldn't silently change .jar files on the classpath
- JDK-8319447: Improve performance of delayed task handling
- JDK-8341775: Duplicate manifest files are removed by jarsigner after signing
- JDK-8303770: Remove Baltimore root certificate expiring in May 2025
- JDK-8346948: Update CLDR to Version 47.0
- JDK-8348829: Remove ObjectMonitor perf counters
- JDK-8164714: Constructor.newInstance creates instance of inner class with null outer class
- JDK-8352716: (tz) Update Timezone Data to 2025b
- JDK-8347946: Add API note that caller should validate/trust signers to the getCertificates and getCodeSigners methods of JarEntry and JarURLConnection
- JDK-8345213: JVM Prefers /etc/timezone Over /etc/localtime on Debian 12
- JDK-8350646: Calendar.Builder.build() Throws ArrayIndexOutOfBoundsException
- JDK-8347433: Deprecate XML interchange in java.management/javax/management/modelmbean/DescriptorSupport for removal
- JDK-8328119: Support HKDF in SunPKCS11 (Preview)
- JDK-8327378: XMLStreamReader throws EOFException instead of XMLStreamException
- JDK-8024695: new File("").exists() returns false whereas it is the current working directory
- JDK-8351224: Deprecate com.sun.tools.attach.AttachPermission for removal
- JDK-8351310: Deprecate com.sun.jdi.JDIPermission for removal
- JDK-8348561: Add aarch64 intrinsics for ML-DSA
- JDK-8351266: JFR: -XX:StartFlightRecording:report-on-exit
- JDK-8350638: Make keyboard navigation more usable in API docs
- JDK-8350464: The flags to set the native priority for the VMThread and Java threads need a broader range
- JDK-8348596: Update FreeType to 2.13.3
- JDK-8349860: Make Class.isArray(), Class.isInterface() and Class.isPrimitive() non-native
- JDK-8347335: ZGC: Use limitless mark stack memory
Note: A more exhaustive list of changes can be found here [7].
[5] https://jdk.java.net/25/
[6] https://jdk.java.net/25/release-notes
[7] https://github.com/openjdk/jdk/compare/jdk-25+10...jdk-25+17
# JavaFX 25 Early-Access Builds
These are early access builds of the JavaFX 25 Runtime built from openjdk/jfx [8]. These builds 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 builds, they are also known to work with JDK 22 and later versions.
The latest early access builds of JavaFX 25 Builds 11 (2025/4/4) are now available [9], under the GNU General Public License, version 2, with the Classpath Exception. JavaFX 25 API Javadocs [10] are available too.
[8] https://github.com/openjdk/jfx
[9] https://jdk.java.net/javafx25/
[10] https://download.java.net/java/early_access/javafx25/docs/api/overview-su...
# Topics of Interest
- The Arrival of Java 24
https://blogs.oracle.com/java/post/the-arrival-of-java-24
- Performance Improvements in JDK 24
https://inside.java/2025/03/19/performance-improvements-in-jdk24/
- Java 24 - Better Language, Better APIs, Better Runtime
https://inside.java/2025/03/01/jfokus-better-jdk24/
- JDK 24 Release Notes Overview - Security Update
https://inside.java/2025/04/05/java-24-security-notes/
- JDK 24 Release Notes Review for Developers
https://inside.java/2025/03/13/newscast-87/
- JDK 24 Release Notes Overview for Operations
https://inside.java/2025/03/29/java-24-for-ops/
- JDK 24 G1/Parallel/Serial GC Changes
https://tschatzl.github.io/2025/04/01/jdk24-g1-serial-parallel-gc-changes...
- Scoped Values in Java 24
https://inside.java/2025/02/27/newscast-86/
- Stable Values in Java 25
https://inside.java/2025/03/27/newscast-88/
- New Write Barriers for G1
http://tschatzl.github.io/2025/02/21/new-write-barriers.html
- SuperWord (Auto-Vectorization) - Scheduling
https://eme64.github.io/blog/2023/05/16/SuperWord-Scheduling.html
~
That's it for this time. Feel free to reach out if you encounter any issues while testing your project(s) with the latest JDK early-access builds.
--David
1 year, 1 month
WildFly 36 Schedule
by Brian Stansberry
Hello,
Work is well underway on WildFly 36. These are the dates we're planning for
releasing 36 Beta and Final:
36 Beta
Freeze (PRs ready deadline) - Wed Mar 19
Tag/deploy of main WildFly bits - Wed Mar 26
Other deliverables, announcement - Thu Mar 27
36 Final
Freeze (PRs ready deadline) - Wed Apr 2
Complete merging - Mon Apr 7
Buffer day - Tue Apr 8
Tag/deploy of main WildFly bits - Wed Apr 9
Other deliverables, announcement - Thu Apr 10
Best regards,
--
Brian Stansberry
Principal Architect, Red Hat JBoss EAP
WildFly Project Lead
He/Him/His
1 year, 1 month
