WildFly and Jakarta EE 9
by Brian Stansberry
The Jakarta EE community has been making great strides in its work on
Jakarta EE 9, and in the run-up to next Tuesday's Jakarta EE 9 Milestone
Release Party[1] I wanted to give the WildFly community an update on what's
been going on regarding EE 9 in WildFly and a heads up on what I expect
will be happening over the summer and the rest of this year.
As discussed in the Jakarta EE 9 Release Plan[2], EE 9 is primarily about
implementing the necessary change in the Jakarta EE APIs from the javax.*
package namespace to the jakarta.* namespace. It isn't about bringing new
functionality to end users; the focus is on providing a platform that all
of us in the EE ecosystem can use to adapt to the namespace change,
ensuring we're all in a solid position to take advantage of new features
and approaches to doing things that we'd like to see in EE 10.
The WildFly project is an important part of the EE ecosystem, so of course
we're going to participate in this. Besides work from WildFly community
members on the Jakarta platform (big shout out to Scott Marlow for his TCK
work) and the different specs, there's been background prototyping work
going on exploring how WildFly can provide an EE 9 compatible distribution.
That work is now far enough along that it's time to make it a part of the
main WildFly development work.
The javax.* to jakarta.* transition is a big task and it's going to take a
while to percolate through our ecosystem. I don't think it's good for
WildFly to stop providing new features and fixes to our community while we
take this on, so I'd like WildFly's primary distribution to continue to be
based on the EE 8 APIs. I think this should continue to be the case until
we begin work toward EE 10.
But we also need to provide an EE 9 server so our community can see what EE
9 will mean to them and so they can use us in their own EE 9 work. So I'd
like us to begin producing a tech preview/beta EE 9 variant of WildFly.
Ideally there would be at least one very early alpha type milestone over
the summer but I don't expect the first version to appear on the
wildfly.org/downloads page until some time after the WildFly 21 release,
perhaps late September or October. Then another version shortly after the
WildFly 22 release, probably in December or early January. Eventually I'd
like these to start coming out at the same time as the main WildFly
releases.
The main goal of these is to allow people to adapt to the jakarta.*
namespace change. However, I would also like them to serve as a bit of a
preview for how we see WildFly evolving in the future. For example WildFly
21 will still have the legacy Picketbox-based security as the default
security layer, but I'd prefer not to have that layer even be present in
the EE 9 variant.
Although I'd like this EE 9 variant to be an evolution from what we have
now, and a good way to adapt to the namespace change, it's important to
point out that any EE 10 variant of WildFly may evolve quite significantly
from what we'll be doing with EE 9. There is some uncertainty around how EE
10 will evolve and an expectation that Eclipse MicroProfile will need to
integrate into a base profile for EE 10, so what we're doing with EE 9 is
likely not going to align fully with our efforts in the future. We are
working on getting this notion better codified.
WildFly is a huge codebase, so maintaining two completely distinct flavors
of it is not feasible. Furthermore, for a long time at least some of the
binaries we ship will have been compiled against EE 8 APIs, with no native
EE 9 variant available. To make this work, the EE 9 server would be based
on a separate Galleon feature pack from what we use for the main
distribution. The large majority of the software artifacts that feature
pack references will be the same as what's in the EE 8 distribution.
However, as part of provisioning, any EE 8 content in the server will be
transformed (primarily bytecode transformation) to use the EE 9 APIs. Scott
Marlow, Richard Opalka and Jean-Francois Denise, with much appreciated
assistance from B.J. Hargrave and others on the Eclipse Transformer
project, have been making good progress on the needed transformation
technology, and Jean-Francois has done well with the needed Galleon
tooling. Jean-Francois's latest POC is able to provision a server that can
pass a significant chunk of the WildFly testsuite. That's a good sign that
it's time for this work to start surfacing in the main WildFly and WildFly
Core repos.
Expect to hear more discussion, JIRAs, PRs, etc about this in the coming
few weeks as we begin implementing changes in the main code base to make
the EE 9 variant more maintainable and as development branches get
underway. I'd love to hear your voices!
To be honest, when the need for the javax.* to jakarta.* transition came up
last year I was dreading dealing with it, but now I think it will be a lot
of fun. Part of the overall goal with what we've been doing with Galleon
has been to make it easier for users to have the WildFly they want. That
rightfully should include truly distinct flavors, not just different
subsets of a single flavor. This EE 9 work is going to be a great
opportunity for us to make progress on that goal.
Best regards,
Brian
[1] https://twitter.com/JakartaEE/status/1273001150711844867
[2]
https://eclipse-ee4j.github.io/jakartaee-platform/jakartaee9/JakartaEE9Re...
2 years, 9 months
Multi-release module JARs
by Paul Ferraro
In version 30 of jboss-parent-pom, David Lloyd added the ability to
easily produce multi-release jars [1]. While several components
consumed by WildFly currently produce multi-release jars (e.g.
wildfly-common, Undertow, Infinispan, etc.), as far as I am aware,
none of the modules in WildFly (or wf-core) do this.
I recently created a pull request to WildFly [2] that ports a
collection class from Undertow [3], which, when built using Java 9+,
results in faster expiration scheduling for persistent HttpSessions
and local @Stateful EJBs. While the changes introduced in this PR are
still compatible with JDK 8 [4], this optimization will not be
available to users unless they build wildfly using JDK 9+ in order to
produce the requisite multi-release jar for the
wildfly-clustering-ee-cache module.
What do people think about this?
Is there any reason why we should *not* compile using JDK 11 when
building releases (while still maintaining Java 8 source
compatibility, of course)?
Even if we continue to create releases using JDK 8 builds, does anyone
object to giving users the option to build WildFly with multi-release
module jars when compiling with a more recent JDK version?
[1] https://issues.redhat.com/browse/WFLY-10178
[2] https://github.com/wildfly/wildfly/pull/13334
[3] https://github.com/undertow-io/undertow/blob/master/core/src/main/java9/i...
[4] https://ci.wildfly.org/buildConfiguration/WFPR/207451
2 years, 9 months
WildFly 20 is released!
by Brian Stansberry
Hello everyone,
I'm very happy to announce that WildFly 20.0.0.Final is now available for
download at https://wildfly.org/downloads/. Please try it out and give us
your feedback.
WildFly 20 is heavily focused on bug fixing, but we've got some nice new
security and EJB features, and the RESTEasy team have brought some nice
integration with Eclipse MicroProfile Config. I get into the details in my
post at https://wildfly.org/news/2020/06/08/WildFly20-Final-Released/.
I expect a busy summer working on WildFly 21, which is currently slated for
an early September release.
Take care; I hope you are all safe and well!
Best regards,
Brian
2 years, 9 months
