Jakarta Java, formally Jakarta EE, is the successor to Java EE, and the defining change is that the entire enterprise API moved from the javax.* package namespace to jakarta.*, which creates a real security decision: the old javax libraries are increasingly unmaintained. Teams that stay on the legacy namespace to avoid a migration are, over time, choosing to run code that no longer receives security patches.
This guide explains what Jakarta Java is, why the namespace changed, and the concrete security implications of being on either side of that line.
From Java EE to Jakarta EE
Java Enterprise Edition (Java EE) was Oracle's platform of server-side APIs: Servlets, JPA for persistence, JAX-RS for REST, JMS for messaging, and more. In 2017 Oracle transferred the platform to the Eclipse Foundation, where it was renamed Jakarta EE because Oracle retained the "Java" trademark.
For a few releases nothing dramatic happened to the code. Jakarta EE 8 was essentially Java EE 8 under a new name, still using the javax.* packages. The break came with Jakarta EE 9, which performed the "big bang" rename: every API package moved from javax to jakarta.
// Java EE / Jakarta EE 8 and earlier
import javax.servlet.http.HttpServlet;
import javax.persistence.Entity;
// Jakarta EE 9 and later
import jakarta.servlet.http.HttpServlet;
import jakarta.persistence.Entity;
That looks like a trivial find-and-replace, and mechanically it often is, but the security consequences of doing it (or not) are what matter.
Why the Namespace Change Is a Security Issue
The javax namespace is frozen. New development, new features, and critically, ongoing security maintenance happen in the jakarta namespace. A library published under javax.* will not receive a version that fixes a newly discovered vulnerability, because active maintainers have moved their releases to jakarta.*.
This turns an inventory question into a risk question. Every javax.* enterprise dependency in your build is a candidate for going stale: if a vulnerability is found in it, the fix will likely only appear in the jakarta-namespaced successor, and you cannot consume that fix without migrating. The longer you wait, the wider the gap between the code you run and the code that is maintained.
The whole modern Java server ecosystem reflects this cutover. Spring Framework 6 and Spring Boot 3 require Jakarta EE APIs and dropped javax. Tomcat 10 moved to the jakarta namespace, so a WAR built for the old namespace will not run on it unmodified. Application servers, ORM providers like Hibernate, and validation libraries all made the same jump. Staying on javax means staying on older major versions of all of them, which compounds the maintenance debt.
The Migration Path and Its Pitfalls
The migration itself is well-trodden. Tools like the Eclipse Transformer and the OpenRewrite recipes for Jakarta rewrite imports, descriptors, and even bytecode from javax to jakarta. For most applications the process is: bump the platform version, run the transformer, update the dependencies to their jakarta-namespaced releases, and fix the handful of spots the tools cannot resolve automatically.
The security-relevant pitfalls are worth calling out.
Mixed namespaces. A partially migrated application with both javax and jakarta on the classpath is a common intermediate state, and it can behave unpredictably. Two servlet APIs, or two validation APIs, in one runtime is a source of subtle bugs, some with security consequences. Finish the migration; do not linger in the mixed state.
Transitive stragglers. Your direct dependencies may migrate cleanly while a transitive one still drags in a javax API. Because that transitive library is the stale one, it is exactly where an unpatched vulnerability can hide. Resolving the full tree is the only way to find these.
Assuming the rename is the whole job. Some APIs changed more than their package name across major versions. Read the migration notes for anything you use heavily, especially persistence and security-related APIs, rather than assuming a pure rename.
Auditing Your Jakarta Java Dependencies
The practical security task is to find every enterprise API in your build and classify it as maintained (jakarta) or frozen (javax), then check both against known vulnerabilities.
# See which enterprise APIs are on the classpath and their namespace
mvn dependency:tree | grep -iE "javax|jakarta"
That gives you the namespace picture. It does not tell you which of those artifacts have known vulnerabilities, and a stale javax artifact three levels down is precisely the case a manual read misses. An SCA scanner such as Safeguard resolves the transitive Maven tree and flags vulnerable components regardless of namespace, which is how you find the frozen library that quietly went unpatched. Our SCA product page covers that transitive analysis, and the Jackson databind security guide is a good companion for one of the most common Java dependency risks.
The honest bottom line: migrating to the jakarta namespace is not just modernization for its own sake. It is how you keep receiving security fixes. A codebase stuck on javax is on a slow path to running unmaintained enterprise APIs, and that is a risk that only grows.
FAQ
What is the difference between Java EE and Jakarta Java?
Jakarta EE is the same platform under new stewardship. Oracle moved Java EE to the Eclipse Foundation, which renamed it Jakarta EE and, starting with Jakarta EE 9, changed the API package namespace from javax to jakarta.
Why did the packages change from javax to jakarta?
Oracle retained the "Java" trademark when it transferred the platform, so the Eclipse Foundation could not keep publishing new APIs under javax. Jakarta EE 9 renamed every package to jakarta to move forward under a namespace the foundation controls.
Is it a security risk to stay on the javax namespace?
Yes, over time. Active maintenance and security fixes now target the jakarta namespace, so frozen javax libraries increasingly go unpatched. Staying on them means a newly discovered vulnerability may have a fix only in the jakarta successor.
How do I migrate from javax to jakarta safely?
Use tooling like the Eclipse Transformer or OpenRewrite to rewrite imports and descriptors, upgrade dependencies to their jakarta releases, and avoid lingering in a mixed-namespace state. Scan the full transitive dependency tree afterward to catch any stale javax library that remains.