Why Jakarta EE Renamed Java EE Specs and What It Means for Developers

The Eclipse Foundation recently renamed each specification of the Java EE standard, clarifying the future role of each specification within the Jakarta EE platform.

Jakarta EE is the second renaming of Java EE. In May 2006, the term “J2EE” was abandoned in favor of Java EE. When YouTube was still an independent company, the digit 2 disappeared from the name, and at that time Pluto was still considered a planet. Similarly, the digit 2 was removed from J2SE as part of Java SE 5 (2004), before Google went public.

Because the javax namespace can no longer be used, Jakarta EE provides a clear dividing line.

Jakarta 9 (2019 and later) uses the jakarta namespace.

Java EE 5 (2005) to Java EE 8 (2017) use the javax namespace.

Java EE 4 uses the javax namespace.

Eclipse Foundation market manager Wayne Beaton explained the way the specifications themselves were renamed. In addition to replacing “Java” with “Jakarta,” each specification name now gains consistency and clarity; for example, the redundant word “API” is no longer needed in API specification names.

The specification renaming has not standardized the package names of dependencies. For example, the newly renamed specification Jakarta Mail (formerly Java Mail) has the groupId com.sun.mail and the artifactId jakarta.mail. Jakarta RESTful Web Services (formerly JAX‑RS) has the groupId jakarta.ws.rs and the artifactId jakarta.ws.rs-api.

Some frameworks, such as MicroProfile, are using parts of Jakarta EE, or are being used by other parts of Jakarta EE. John Clingan clarified in a post that MicroProfile is not equivalent to Jakarta EE. Other frameworks, such as Quarkus, combine with Jakarta EE to create a hybrid approach, allowing developers to choose the most suitable tools for their problems.

Developers may not notice the renaming at the project level because they invoke application libraries at the code level. When porting legacy applications, developers want to use Jakarta EE‑compatible application servers or servlet containers and ensure their dependencies use the new groupId and artifactId.