Understanding Jakarta EE 9
With the release of Jakarta EE 9 this month, there are a few key points about the release that developers should keep in mind as they work with the code.
One of the most important things to understand about the Jakarta EE 9 release is that it’s not backwards-compatible with Jakarta EE 8 or Java EE 8. To help you understand why this is, here’s a quick look at the three Jakarta EE releases so far. Note that each release has a different combination of Apache Maven coordinates and Java package name:
- The first Jakarta EE release was announced in January 2019. It was a technical release that was almost identical to Java EE 8, and it was code named EE4J_8. In fact, every Jakarta EE/EE4J project used to have a Git branch with this code name. This release proved that the Java EE code Oracle contributed to the Eclipse Foundation was complete. However, it was not a true Jakarta EE release. The APIs used the javax Maven coordinates (javax.ws.rs:javax.ws.rs-api:2.1.1, for example) and the javax Java package name (javax.ws.rs.core, for example).
- The second release is known as Jakarta EE 8. The APIs in Jakarta EE 8 use Jakarta EE Maven coordinates (jakarta.ws.rs:jakarta.ws.rs-api:2.1.6, for example), but the javax Java package name (javax.ws.rs.core, for example). Jakarta EE 8 is 99.9 percent backwards-compatible with Java EE 8.
- The third release is known as Jakarta EE 9. The APIs in Jakarta EE 9 use Jakarta EE Maven coordinates (jakarta.ws.rs:jakarta.ws.rs-api:3.0.0, for example), but the Java package name has been changed to jakarta (jakarta.ws.rs.core, for example).
The Jakarta Package Name Change Has Consequences
The shift to the jakarta package name has a number of consequences that are important for developers to understand:
- Every API must transition the Java package name from javax to jakarta.
- Every Jakarta EE specification must be updated to reflect the API changes.
- Every implementation of a specification must be adjusted to handle the new APIs.
- New versions of application servers must be released. The new implementations won’t work on Java EE-based application servers and the old implementations won’t work on Jakarta EE 9-based application servers.
- Jakarta EE 8 APIs do not work with Jakarta EE 9 implementations and vice versa.
- In cases where the Java EE API is needed, mixing Jakarta EE 8 and Jakarta EE 9 APIs will cause issues with Maven because they both use the same Maven coordinates. For example, this can occur when using the Java Architecture for XML Binding (JAXB) API with the Jackson XML Module and the Jakarta EE 9 API is needed for other JAX-B uses. In these cases, it’s better to use older Java EE 8 Java archive (JAR) files instead of Jakarta EE 8 files.
If you’re an Eclipse Jersey user, note that:
- Eclipse Jersey 3 needs a Jakarta EE 9-based server, such as Eclipse GlassFish 6, Eclipse Jetty 11, or Apache Tomcat 10.
- Eclipse Jersey 2 needs a Java EE 8 or Jakarta EE 8-based server, such as Eclipse GlassFish 5, Eclipse Jetty 9/10, or Apache Tomcat 9.
Don’t Mix Jakarta EE 8 and Jakarta EE 9 Artifacts
It’s not always easy to recognize Jakarta EE 9 APIs and compatible implementations. It’s the artifact versions that matter. I’ve listed some Jakarta EE 9 artifacts here, but there are many more, especially when you consider the Jakarta EE 9-compatible implementations from various vendors.
Jakarta EE 9 artifacts include:
- jakarta.activation:jakarta.activation-api:2.0.0 + com.sun.activation:jakarta.activation:2.0.0
- jakarta.batch:jakarta.batch-api:2.0.0 + com.ibm.jbatch:*:2.0.0
- jakarta.enterprise:jakarta.enterprise.cdi-api:3.0.0 + org.jboss.weld.se:*:4.0.0
- jakarta.faces:jakarta.faces-api:3.0.0 + org.glassfish:jakarta.faces:3.0.0
- jakarta.json:jakarta.json-api:2.0.0 + org.glassfish:jakarta.json:2.0.0
- jakarta.json:jakarta.json.bind-api:2.0.0 + org.eclipse:yasson:2.0.0
- jakarta.mvc.jakarta.mvc-api:2.0.0 + org.eclipse.krazo:*:2.0.0
- jakarta.persistence:jakarta.persistence-api:3.0.0 + org.eclipse.persistence:*:3.0.0
- jakarta.security.**:*:2.0.0 + org.glassfish.soteria:*:2.0.0
- jakarta.validation.jakarta.validation-api:3.0.0 + org.hibernate.validator:hibernate-validator:7.0.0
- jakarta.websocket:jakarta.websocket-api:2.0.0 + org.glassfish.tyrus:*:2.0.0
- jakarta.ws.rs:jakarta.ws.rs-api:3.0.0 + org.glassfish.jersey:*:3.0.0
- jakarta.xml.bind:jakarta.xml.bind-api:3.0.0 + com.sun.xml.bind:*:3.0.0
- jakarta.xml.ws:jakarta.xml.ws-api:3.0.0 + com.sun.xml.*:*:3.0.0
Note that some of the artifacts listed above had not been released yet when this article was written.
JAX-RS Is Now Jakarta Restful Web Services
To help distinguish between Java EE and Jakarta EE, the Java API for RESTful Web Services (JAX-RS) is now called Jakarta Restful Web Services. As a result, the acronym is no longer used in the specification document or the TCK document, and its use in the API javadoc is limited.
There are ongoing discussions about a new acronym or abbreviation that could be used for this technology, with the most favored suggestion being Jakarta REST. However, people continue to use the JAX-RS acronym in discussions.
To help avoid confusion between Java EE and Jakarta EE, the full Jakarta Restful Web Services name is preferred.
Jakarta EE 9.1 Will Quickly Follow Jakarta EE 9
Jakarta EE 9 is compatible with Java Development Kit (JDK) 8.
Jakarta EE 9.1 is planned for release very soon after Jakarta EE 9, and it will be compatible with JDK 11 as well as JDK 8.
Get the Latest Updates on Jakarta EE 9 and Beyond
The Jakarta EE community provides multiple information channels to keep you up-to-date on the latest happenings. To stay connected and join the conversation, click here.