<div dir="ltr"><div class="gmail_default" style="font-family:trebuchet ms,sans-serif">The Jakarta EE community has been making great strides in its work on Jakarta EE 9, and in the run-up to next Tuesday&#39;s Jakarta EE 9 Milestone Release Party[1] I wanted to give the WildFly community an update on what&#39;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.<br><br>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&#39;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&#39;re all in a solid position to take advantage of new features and approaches to doing things that we&#39;d like to see in EE 10. <br><br>The WildFly project is an important part of the EE ecosystem, so of course we&#39;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&#39;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&#39;s time to make it a part of the main WildFly development work.<br><br>The javax.* to jakarta.* transition is a big task and it&#39;s going to take a while to percolate through our ecosystem. I don&#39;t think it&#39;s good for WildFly to stop providing new features and fixes to our community while we take this on, so I&#39;d like WildFly&#39;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.<br><br>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&#39;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&#39;t expect the first version to appear on the <a href="http://wildfly.org/downloads">wildfly.org/downloads</a> 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&#39;d like these to start coming out at the same time as the main WildFly releases. <br><br>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&#39;d prefer not to have that layer even be present in the EE 9 variant.<br><br>Although I&#39;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&#39;s important to point out that any EE 10 variant of WildFly may evolve quite significantly from what we&#39;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&#39;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. <br><br>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&#39;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&#39;s latest POC is able to provision a server that can pass a significant chunk of the WildFly testsuite. That&#39;s a good sign that it&#39;s time for this work to start surfacing in the main WildFly and WildFly Core repos.<br><br>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&#39;d love to hear your voices!<br><br>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&#39;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.<br><br>Best regards,<br>Brian<br><br><br>[1] <a href="https://twitter.com/JakartaEE/status/1273001150711844867">https://twitter.com/JakartaEE/status/1273001150711844867</a><br>[2] <a href="https://eclipse-ee4j.github.io/jakartaee-platform/jakartaee9/JakartaEE9ReleasePlan">https://eclipse-ee4j.github.io/jakartaee-platform/jakartaee9/JakartaEE9ReleasePlan</a><br></div></div>