Some things never quite go the way you expect or the way you want. Sometimes that means you get a pleasant surprise. Sometimes it doesn’t. When Red Hat, IBM, Tomitribe and Oracle stood together on stage back in 2017 to announce we were working together on moving all of Java EE 8 to an independent foundation, I think we all believed this was the next chapter for Enterprise Java.  Oracle has made the decision to enable the wider ecosystem to build more freely on the work of so many individuals over the previous 15+ years. It was a risk for everyone on that stage but probably no more so than for Oracle as they, via Sun Microsystems before them, had invested so much into Java EE over the years.

As the work progressed and we chose the Eclipse Foundation, we found a lot of interest in the community and even vendors who had previously eschewed Java EE, such as Microsoft, joined the work. Collectively we created the logo, various working groups, the Steering Committee, and presentation after presentation at various conferences and workshops. It really did begin to feel that we were back when J2EE was young and there was huge interest in its direction.

However, through all of this what those outside the Steering Committee didn’t see (couldn’t see) was the intense effort going on between Oracle and the Eclipse Foundation around the transfer of IP such that we could all go and evolve specifications which Oracle, Sun or others had traditionally driven through the JCP. There were lots of questions and concerns the teams had to address, such as: Could we keep the names? Could we evolve the javax namespace? At times it seemed like progress was being made only for something else to come up which further delayed things.

In the end, as the reader is likely already aware if the above link was clicked, it has not been possible for Oracle and the Eclipse Foundation to come to an agreement on a seamless transition for beyond Jakarta EE 8. To say that I’m disappointed is an understatement. We came so close to enabling a seamless future for Jakarta EE only for it to be pulled from our collective grasp. I’m not going to lay any blame for this because that doesn’t get us anywhere. I do want to say thanks to the Oracle engineering and PM teams involved from the start. Without people like Will Lyons and Tom Snyder, to name but two from the many others involved, I’m sure we wouldn’t have gotten as far and as close as we did. They suffered a lot of frustrations from Red Hat and others, likely also from their own legal team. They were in the middle of things and stayed sane and cooperative throughout. I’m pretty sure this isn’t the outcome they had wanted or expected. And of course it would be remiss of me to ignore the Eclipse Foundation team for trying their hardest too and likely equally disappointed.

So what next? Well let’s not forget that we haven’t finished Jakarta EE 8 yet (which will remain using the javax namespace). Therefore, we’ve got more work to do to finalise that and get various implementations out, including our very own WildFly and EAP; Red Hat remains committed to this effort. Getting to a Jakarta EE 8 release is a fantastic and important accomplishment which will help the great many community members, vendors and users who have Java EE deployments. It will ensure that Java EE 8 and Jakarta EE 8 users can move between the two with ease.

However, what are the steps beyond Jakarta EE 8? There are a couple that I see and I’m sure there will be others:

• As a community of users and developers we could try to move Jakarta EE forward but it isn’t going to be as simple as we had originally hoped. We have to change the javax namespace, update implementations, TCK, change the names of specifications for anything that we want to evolve and clearly that is going to have an impact on compatibility. Then if we (the community) decided that is an investment worth making, we will have to determine whether we do that wholesale up front, i.e., change everything immediately after Jakarta EE 8 is out just to be over and done with it, or do it when and if changes are really needed. Each option has its pros and cons (exercise left to reader). Also, new specifications under a different namespace can be added to Jakarta EE moving forward if we decided not to evolve any of the current specifications.
• If we decided to evolve only those specifications, TCKs, RIs etc. when and if needed then a parallel question should be whether Jakarta EE is the right place to do it or should this be elsewhere? If it’s Jakarta EE then it needs the community to have agreed definitively that there is a future for Jakarta EE and the existing specifications it embodies which requires them to evolve, regardless of any potential impact from this recent announcement. If the community cannot make that agreement then perhaps component pieces, such as CDI or JAX-RS, have life beyond even if they also have to be changed - the assumption here would likely have to be that any re-coding around the javax namespace would have more limited impact due to the more focussed use cases. If that were to be the community’s choice then I believe Eclipse MicroProfile would be the right place because it’s already supported by a large and similar group of community and vendors.

Therefore, let’s not focus on the past or what could have been with Jakarta EE. Someone else may analyse the in’s and out’s of the work when they come to write the history of Enterprise Java in the future, but for now we’d be better off looking to that future and collaborating where it makes sense. The community now have a number of key questions to answer, including how do we move forward under the Eclipse Foundation banner and evolve cloud-native Java?