What Is New in Jakarta EE Platform 9
Jakarta EE 9 is a pivotal release focused on the foundational change of renaming all specifications from javax.* to jakarta.* namespace. This is the key step in the platform's evolution, enabling future innovation.
| Category | Description |
|---|---|
| Namespace Change | All API packages renamed from javax.* to jakarta.*. |
| Specifications | Includes 20+ updated specs under the new namespace, including Servlet, CDI, and JSON Processing. |
| Compatibility | Maintains source compatibility for applications, requiring only a change in imports for migration. |
| Foundation | Sets the stage for Jakarta EE 10 and beyond, removing the legacy constraints of the old namespace. |
Why did the package namespace change from javax to jakarta?
The move to jakarta.* was necessary to break free from the historical constraints of the javax.* namespace, which is owned by Oracle. This change, while significant, is a one-time effort that grants the Eclipse Foundation and the community full autonomy over the platform's future development.
In practice, this means we can now innovate faster without being tied to the old governance model. It's the essential groundwork that enables all the cool new features planned for Jakarta EE 10 and later versions.
What specifications were updated in Jakarta EE 9?
Jakarta EE 9 delivers updated versions of all core platform specifications under the new namespace. This isn't about adding new features; it's about aligning the entire ecosystem to the new jakarta.* foundation.
Key specs include Jakarta Servlet, Jakarta RESTful Web Services, Jakarta Contexts and Dependency Injection, Jakarta Persistence, and Jakarta Bean Validation. The full list encompasses over twenty specifications that have been consistently renamed.
How does this change affect my existing applications?
For developers, the primary impact is on your import statements. Code that previously used javax.servlet.* will now need to use jakarta.servlet.*. The APIs themselves remain functionally identical, preserving source compatibility.
The main challenge is updating your build tools and dependencies to use the new artifacts. This means ensuring your application server, libraries, and Maven/Gradle dependencies all align on the Jakarta EE 9 versions.
FAQ
Is Jakarta EE 9 a feature release?
No, its main purpose is the namespace migration. It intentionally avoids introducing new features to keep the migration path as straightforward as possible. The new functionality is coming in subsequent releases.
Can I run my Jakarta EE 8 application on a Jakarta EE 9 server?
No, not without modification. Because the package names are different, your application's imports must be changed from javax.* to jakarta.* to work on a Jakarta EE 9 runtime.
Are there any behavioral changes in the APIs?
The specifications aim for zero behavioral changes. The goal is purely a package rename, so your application logic should work exactly the same after the import updates are made.
What tools can help with the migration?
The Eclipse Transformer project provides tools to automatically convert application binaries and source code from javax.* to jakarta.*, which can significantly speed up the process.
Why should I upgrade to Jakarta EE 9 instead of waiting for a later version?
Upgrading now future-proofs your application. It's the necessary step to get on the path that will receive all new features and improvements in Jakarta EE 10 and beyond.