Jakarta EE 11: The First Big Leap for Jakarta

Up until now, the work on Jakarta EE has focused on establishing a framework and foundation for future innovation. From the initial lift and shift to the new namespace change in Jakarta EE 9, to the  simplification work done in Jakarta EE 10, a lot of effort has gone into making Jakarta EE a solid basis for open source developers to build on. 

With that done, there’s now the opportunity to start taking Jakarta EE beyond the Java EE era. With Java 21 on the horizon, there’s now the opportunity to make sure Jakarta EE is always leveraging the latest and greatest capabilities of the new Java version, build new specifications and further unify and simplify the platform.

The target release date for Jakarta EE 11 is the first quarter of 2024, roughly six months after the target release for Java 21. This should give projects enough time to build and test based on the latest Java version. And broadly, the Jakarta EE Steering Committee has given four major priority areas for projects: 

• Ease onboarding and community contribution
• Platform unification
• Bring in new specifications
• Leverage the newest Java 21 capabilities

It’s also worth noting that the hope is, assuming all goes to plan, we’ll be able to establish a regular cadence of Jakarta EE releases so that they’re always leveraging the newest Java version. 

Onboarding Is Essential to Jakarta EE’s Growth

At the most basic level, we want to make it easier for Eclipse community members to get involved in the development of Jakarta EE. In a nutshell, we need to simplify the process. 

I’ve been involved with Jakarta EE since the beginning of the project and, frankly, it’s complicated to get involved. There are committees, projects, different test suites, and things to run. So, the main goal as far as simplification goes is trying to introduce clearer signposts for where and when people can get involved. 

This takes a few forms. Part of it will be guidance from the steering committee and the platform about where to even go in the first place if you’re new to Jakarta EE. Then, guidance from each project about what contributions they’re looking for, how to contribute, how to build and run the tests, and so on. A major part of this will be standardization: making it so that the procedure is basically the same no matter which project a given contributor is interested in. There’s also a big push for documentation. 

Unification Will Enhance Usability

The next major priority area for projects is API unification. Jakarta EE and Java EE before it has been around for quite some time. As a result, there are a lot of different ways of doing things in different specifications. Take security, for example. The way you mark something as secure is different between specifications. That can come as a surprise to developers, which is not something we want.

Part of the unification process will involve building off the baseline of CDI. The unfortunate thing is that CDI came fairly late in the evolution of Java EE. So, there’ll be some work to be done for some APIs to use CDI as a foundation. 

It’s all about enhancing the developer experience. If developers are working on a business application, they don’t really want to know the ins and outs of whether one annotation works here with a given part of the specification, or read API specification documents to understand how to do something, or why something isn’t working. It should just work as expected. 

Bring in New Specifications for the First Time

The third major priority for the steering committee is about taking advantage of the stable base that’s been built for Jakarta EE. Now that all that hard work is done, there’s an opportunity to bring in new specifications. There are a few candidates, such as Jakarta Config and Jakarta Data, to name a few. It’s an opportunity to show that the Jakarta EE platform is growing, it’s innovating, and it’s bringing in new capabilities for modern application development. 

Leverage New Capabilities of Java 21

The fourth major priority of the steering committee is setting the baseline of Jakarta EE 11 on Java 21. This is to make sure that everything we’re working on is up-to-date and using the latest Java capabilities. So, for a specification like, say, Concurrency, that might mean using Project Loom and modernizing all the APIs. But it also might mean playing a bit of catchup. There are new capabilities that came in Java 17, like records, that we want to see projects taking advantage of and supporting. 

This captures the overall theme of Jakarta EE 11: it is a big leap forward. Now that we’ve laid the foundation, let’s start innovating, modernizing, and making things more consistent. 

Be a Part of Jakarta EE’s Biggest Changes

One of the advantages of moving Java EE from Oracle to the Eclipse Foundation was making it open source and open to anyone and everyone. This upcoming release is going to be the first one where members of the open source community can drive major changes about how the platform works and what it’s capable of doing.  

We’re putting in a lot of work to make it easy for the community to get involved because we really want them to. This is an exciting time to start commenting or contributing. A high-profile project like this is a great way to bootstrap your career, make an impact, and get noticed. 

If you’re interested in getting involved with Jakarta EE 11, check out our discussion document.