Jakarta EE 12 Is Ready to Hit the Ground Running

Jakarta EE has been a massive undertaking since day one. From the initial code migration from the Java EE community to Jakarta EE and from the javax namespace to jakarta, a tremendous amount of effort has gone into laying the foundation for future work. 

Once that was out of the way, a new challenge emerged. The Java EE version that formed the basis of Jakarta EE, Java EE 8, was by then several years old. Over time, this had resulted in significant technical debt, and it became evident that Jakarta EE had, in many ways, fallen quite far behind.

That is, until now. Work continues apace on preparing the Jakarta EE 11 Platform for release. Part of that work over the last year has been a huge community effort to clean up much of the technical debt that had accumulated, though some of the work  happened in version 10. Most of the technical debt cleanup was in the Jakarta EE 11 Platform TCK. While this work continues, the clean-up has helped set the stage for the Jakarta EE 12 Platform to make even more significant changes. In a sense, a great deal of energy has been expended by a vigorous and enthusiastic community to get Jakarta EE to the starting line of modern Java. Now, it’s ready to start racing forward.

Component Specifications Are a Major Target of Development

While work has been ongoing to modernize and refactor the Jakarta EE 11 Platform TCK, the component specifications included in the Jakarta EE platform  have been mostly complete for the better part of a year. One of the major things we wanted to do for the Jakarta EE 12 Platform is get a plan set up for the next version of those specifications. Work has been ongoing to get the release plans for various specifications completed, and all have now completed their release plan ballots. 

According to the Jakarta EE Specification Process, release plans are created by the open source projects and voted on by the Specification Committee. It is an open collaboration requirement from top to bottom, where everything that gets done is driven by the community. 

One of the ongoing refinements we are making in Jakarta EE 12 is requiring the platform to specify minimum Java levels for component specifications, in this case Java 21 and 25. Component specifications will need to at least support these Java versions, though they can support older versions as well if they wish. This requirement is really an effort to incentivise the component specifications to take advantage of the latest features in Java. 

We’re all committed to the success of Java overall, in an era where the value of code itself is being questioned as AI plays a larger and larger role in the software development process. To demonstrate the value of the Java platform itself, component specifications need to take advantage of the latest features in Java SE. There’s tension here, of course. We’re an open source and open standard community. There’s also a lot of inertia among enterprises that want to stay on older versions of Java. This isn’t a new problem — it’s been around for 25 years — but one we need to try and tackle. 

Additionally, since older versions of Java (like Java 8 or 11) are expected to lose long-term support in the near future, it no longer makes sense to use them as the baseline for Jakarta EE 12. Setting minimum compatibility with more current Java versions ensures that version 12 has some longevity and the platform remains aligned with ongoing Java SE evolution.

Jakarta EE 12 Targeting Configuration and Consistency

While these ideas are all subject to change, with the ultimate release of Jakarta EE 12 still on the distant horizon, there are some broadly agreed-upon and established goals for the next version of the platform.

Something that Jakarta has been missing is external modification of configuration data for applications without the need to reconfigure the application. The reality is that the other dominant stack in the Java world, Spring, has had this capability for a long time. It’s something people expect, and reasonably so. 

We’re also working on developing a bit more consistency across different technologies in the Jakarta Platform. Jakarta Data, for example, has a query function that’s a subset of the Jakarta persistence query language (JPQL). Another specification, Jakarta NoSQL, which may be included in the platform as well, alsohas its own query language. Because there needs to be some consistency across these different languages to ensure interoperability, we’re looking to break out that particular part of those technologies into a separate specification. 

One new, though not yet formalized, idea for the Jakarta Platform is a proposal to create a Jakarta HTTP specification. This would create consistency across different web technologies, mostly notably the Jakarta RESTful Web Services and Jakarta Servlet specifications. That way we can have one consistent API to track HTTP-based request and response objects. 

Another target is deprecating the application client. It’s an older technology not used as often, so we’d like to deprecate the requirement to support it and potentially remove the requirement entirely in a later release. We’re also looking to remove any usage of the Java Security Manager by the APIs of the component specifications, as Java Security Manager is turned off by default in later versions of Java, including the minimum level we’ve set for the Jakarta EE 12 Platform.  Jakarta EE 11 removed the use of Java Security Manager, but this requirement cleans up the component APIs that were still using it.

Jakarta EE 11 Walked so That Jakarta EE 12 Can Run

While plans have been broadly set, there’s a great deal that could change over the next year. As the community sets to work, it will become more obvious what can and can’t be accomplished in our timeframe, and new ideas will occur to community members, which will be implemented into our overall plans. 

It’s an exciting time for the platform. Jakarta EE has always been a fascinating project, an alternative to a de-facto standard that underlies so much of modern development, open source and otherwise. And now, a lot of the heavy lifting has been done in terms of getting Jakarta EE ready to support innovation and advances in the enterprise Java ecosystem. There’s never been a better time to get in on the ground floor of the most innovative and forward-looking work happening in the Jakarta EE space. 

There are many ways to get involved. The Jakarta EE Ambassadors group is an excellent grassroots resource for learning how to get started. And whether you’re interested in a particular component specification or getting involved with the platform itself, there are plenty of opportunities to get involved with some of the most exciting things happening with Jakarta EE.