Evolving Jakarta EE

In the second of my additional blogs triggered by the recent javax announcement, let's look at another of the options I mentioned for moving forward. If we decide not to pursue the option to freeze Jakarta EE for stability and focus our combined innovative efforts on MicroProfile, but instead agree to innovate within Jakarta EE then what do we need to do to succeed with the alternative, i.e., what do we need to do to make Jakarta EE successful? Well let's first start with the understanding that to go down route we must therefore believe Jakarta EE is the best place to innovate for cloud-native enterprise Java and no place else. Splitting efforts doesn't help at this stage in the history of the ecosystem: we need the community to coalesce and collaborate on this.

With that in mind we, and by that I mean existing vendors, the communities of users and contributors, partners, etc., have to get far more involved in Jakarta EE than many have with Java EE to date and particularly of late. We need evangelists, we need developers, we need testers, we need writers, we need so much more to fill in the gaps left by previous individuals or vendors who cannot be expected to put in as much time and effort as they have in the past. And critically we need this to happen in order to convince the industry that there's a groundswell of support and investment behind Jakarta EE which makes them stand up and take notice.

The Eclipse Foundation needs investment too and it can't all be on the original main vendors to provide. Because Jakarta EE is now at the Eclipse Foundation this makes that kind of participation possible because there are no barriers to active involvement as perhaps there were when Java EE was in the JCP. Those old reasons (dominated by a single vendor, trademark concerns, not all things open source) go away. That's good because there's a lot going on within Jakarta EE and some of the specifications definitely should be evolved whereas others should probably be deprecated. Furthermore, new specifications need defining, implementing, testing (for compliance with a TCK) and including within subsequent releases. That's effort which has to be shared and this time the community must get involved. If the future of Jakarta EE relies solely on the same vendors and individuals as Java EE then we have failed in one of the most basic of reasons for moving to the Eclipse Foundation.

There's another reason we would need to come together behind Jakarta EE innovation and that's related to the shadow the recent javax announcement has likely cast over things. No matter how positively we want to spin things there will no doubt be some tarnishing of the image which could turn people away or even convince them to leave. If we (the community) can do all of this together then any possible tarnishing of the Jakarta EE brand could well be polished away and perhaps Jakarta EE can have a bright future.