Jakarta EE 9 and the Road to Jakarta EE 10
As we get closer to our target mid-year timeframe for the Jakarta EE 9 release, I want to update you on our progress and some of the challenges we’re working through. I also want to review some of the considerations for developers who are wondering whether they should adopt Jakarta EE 9. Finally, I want to explain why now is the right time for everyone in the community to start thinking about Jakarta EE 10 and the new features they would like it to include.
Jakarta EE 9: Certifying Compatibility Is Complicated
By now, everyone knows that Jakarta EE 9 is a tooling release that’s focused on updating specifications to the new Jakarta EE 9 namespace, jakarta.*, and removing Jakarta EE 8 specifications that are no longer relevant. It’s not full of exciting new features — and I say that as a developer who is working on the release — but Jakarta EE 9 is an important and necessary step on the road to further innovation using cloud native technologies for Java.
We’ve completed the namespace changes in all of the Jakarta EE APIs and the release candidates are available on maven central. However, the challenges and complexity increased significantly when we started certifying the first Jakarta EE 9-compatible product.
To release Jakarta EE 9, we must verify that one compatible product successfully implements the Jakarta EE 9 APIs. As in Jakarta EE 8, the product leading the way at Eclipse is the Eclipse GlassFish application server. However, because GlassFish code depends on namespace updates in code developed by other community members, such as IBM and Red Hat, we need to take a step-by-step approach to the implementation.
To further complicate the requirement, the companies and code we’re dependent on have their own namespace dependencies that must also be addressed. In some cases, the dependencies run five or six layers deep. The namespace changes must be made in each project, in the right order, before we can successfully build a Jakarta EE 9-compatible version of GlassFish. Needless to say, certifying GlassFish compatibility has been very slow going, but we have now completed the bulk of the work and GlassFish is compiling without errors in the new namespace.
I’ve had a number of discussions about how the community can help to accelerate Jakarta EE 9. Unfortunately, the intertwined nature of the updates that need to be made mean there are many tasks that are either very difficult, or impossible, to complete in parallel. However, community members can help by updating the specification documents to the new namespace. You can find information about the different ways to stay connected with the Jakarta EE community and get involved here.
Jakarta EE 9 Targets Infrastructure Developers
In many cases, developers who are creating applications for Jakarta EE 8 or Java EE 8 have no reason to move to Jakarta EE 9 because there’s no new functionality in the release. They can wait for Jakarta EE 10 and adopt the new namespace along with the enhanced functionality this release will include. Of course, application developers can always move their application to the new namespace before Jakarta EE 10 to ensure there are no surprises down the road, but it’s not required.
On the other hand, developers who create tools, libraries, and other infrastructure that are based on Jakarta EE technologies will want to move to Jakarta EE 9. These infrastructure developers are the primary target for Jakarta EE 9.
The Jakarta EE APIs are foundational across the industry and are used in many popular runtime frameworks, web servers, and other tools. Spring Boot, Apache Tomcat, and Dropwizard are just three examples. Infrastructure developers will want to ensure their tools and libraries implement the new namespace so they can be used by application developers who adopt Jakarta EE 10.
In some cases, application developers may not realize the infrastructure tools they rely on are based on Jakarta EE or Java EE APIs and will require the namespace change. As I’ve been working on the GlassFish compatibility certification, I’ve certainly been surprised at how far and wide the namespace change extends. To ensure you’re able to move your application forward, I recommend taking a close look at your infrastructure tools and asking the providers when they’re moving to Jakarta EE 9.
Start Sharing Your Ideas for Jakarta EE 10 Now
Jakarta EE 10 will be a much more exciting release for application developers than Jakarta EE 9 because we can include features and functionality that will really help the community start delivering on the potential of cloud native technologies for Java.
There’s no overall theme for Jakarta EE 10 at this point, but as a Jakarta EE Steering Committee member, some of the key areas where I would like to see community input and ideas include:
- How we align the platform around Contexts and Dependency Injection (CDI), which is one of the foundational aspects of Jakarta EE.
- How we can improve Jakarta EE messaging and take advantage of new messaging technologies, such as Apache Kafka, and cloud technologies.
- How we can improve individual Jakarta EE projects, such as Jakarta Concurrency.
I strongly encourage the entire community to start putting forward their ideas for Jakarta EE 10 immediately. There are two main ways to do this:
- Subscribe to Jakarta EE project mailing lists and get involved in Jakarta EE 10 discussions.
- Raise enhancement requests on the GitHub repository for an Eclipse Enterprise for Java (EE4J) project. You can find the complete list of EE4J projects here.
About the Author
