[wildfly-dev] WildFly and Jakarta EE 9

[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/JakartaEE9ReleasePlan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20200619/4ade5ac7/attachment.html