Understanding Jakarta EE 9

Posted on October 12, 2020 by Jan

Overview

Java Enterprise Edition, or Java EE, is a set of standards defined to be used in an enterprise environment, implemented by a set of Java EE compatible application servers. Java Enterprise Edition or JEE (formerly Java 2 Enterprise Edition, or J2EE) is being developed for more than a decade, starting with the first J2EE 1.2 release in 1999. In 2017-2018, the entire Java EE was contributed to the Eclipse Foundation, and it is known as Jakarta EE now.

There are 3 known releases of Jakarta EE, each with a different variation of maven coordinates and java package name. The first has been announced in January 2019. It was a technical release, almost identical to Java EE 8, and it was marked by a code name EE4J_8 (every Jakarta EE/EE4J project used to have a git branch with this code name). It was a release to prove that the Java EE contributed code is complete. This release was not Jakarta EE release, yet. The APIs used javax maven coordinates (for instance javax.ws.rs:javax.ws.rs-api:2.1.1) and javax java package name (for instance javax.ws.rs.core).

The second release is known as Jakarta EE 8 release. The APIs in Jakarta EE 8 use jakarta maven coordinates (for instance jakarta.ws.rs:jakarta.ws.rs-api:2.1.6), but the javax java package name (javax.ws.rs.core). Jakarta EE 8 is (99.9%) backward compatible with Java EE 8.

The third, very soon upcoming release, is known as Jakarta EE 9. The APIs in Jakarta EE 9 use jakarta maven coordinates (for instance jakarta.ws.rs:jakarta.ws.rs-api:3.0.0), but the java package name has been changed to jakarta (jakarta.ws.rs.core).

Jakarta EE 9 hence is NOT BACKWARD COMPATIBLE with Java EE 8!

Consequences

  • Every API needs to transition the java package from javax to jakarta.
  • Every Specification needs to get updated to reflect the new API changes.
  • Every implementation of a respective Specification needs to be adjusted to handle the new APIs.
  • New versions of application servers need to be released. Many Specifications are involved for instance with the Servlet container and/or CDI and therefore the new implementations won’t work on the old (Java EE-based) application servers, and the old implementations won’t work on the new (Jakarta EE 9-based) application servers.
Jersey 3 needs Jakarta EE 9-based server, such as Glassfish 6, Jetty 11, Tomcat 10!
Jersey 2 needs Java EE 8/Jakarta EE 8-based server, such as Glassfish 5, Jetty 9/10, Tomcat 9!
  • For the java package name change, Jakarta EE 8 API does not work with Jakarta EE 9 implementation and vice versa.
  • In cases, when both the Java EE API would be needed (such as when using JAX-B API with Jackson), and Jakarta EE 9 API would be needed (for other JAX-B usages), mixing Jakarta EE 8 and Jakarta EE 9 API would cause issues with maven (since both use the same maven coordinates). Instead of Jakarta EE 8 jars, the older Java EE 8 jars would better be used.
Do not mix Jakarta EE 8 and Jakarta EE 9 artifacts!

Jakarta EE 9 / EE4_J artifacts

It is not very easy to recognize Jakarta EE9 APIs and compatible implementations. It’s the artifact versions that matter. To name some:

  • jakarta.activation:jakarta.activation-api:2.0.0 + com.sun.activation:jakarta.activation:2.0.0
  • jakarta.annotation:jakarta.annotation-api:2.0.0
  • jakarta.authentication:jakarta.authentication-api:2.0.0
  • jakarta.authorization:jakarta.authorization-api:2.0.0
  • jakarta.batch:jakarta.batch-api:2.0.0 + com.ibm.jbatch:*:2.0.0
  • jakarta.ejb:jakarta.ejb-api:4.0.0
  • jakarta.enterprise:jakarta.enterprise.cdi-api:3.0.0 + org.jboss.weld.se:*:4.0.0
  • jakarta.enterprise.concurrent:jakarta.enterprise.concurrent-api:2.0.0
  • jakarta.el:jakarta.el-api:4.0.0
  • jakarta.faces:jakarta.faces-api:3.0.0 + org.glassfish:jakarta.faces:3.0.0
  • jakarta.inject:jakarta.inject-api:2.0.0
  • jakarta.interceptor:jakarta.interceptor-api:2.0.0
  • jakarta.jms.jakarta.jms-api: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.jws:jakarta.jws-api:3.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.servlet:jakarta.servlet-api:5.0.0
  • jakarta.servlet.jsp:jakarta.servlet.jsp-api:3.0.0
  • jakarta.servlet.jsp.jstl:jakarta.servlet.jsp.jstl-api:2.0.0
  • jakarta.transaction:jakarta.transaction-api: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

The list goes on, especially for every Jakarta EE 9 compatible implementation from various vendors.

The artifacts are not available in maven central

The artifacts are not available in maven central, yet. Some of them are, in the milestone version (Jersey 3.0.0-M6), some in Alpha, or Beta (Bean Validation implementation, Weld), some in release candidate versions (EJB API), some in the final version (CDI API) but one day, it will all be there.

The final versions of the APIs/Specifications go through so-called ballots, and once the ballot is approved, it can be released to maven central. Then, when other technologies have all the dependencies gone through the ballots, they can go through the ballots as well. The ballots are processed in waves, and October 2020 is the most active month regarding the ballots to get Jakarta EE 9 released on November 20.

Jakarta EE 9 is finishing to be released on November 20.

The progress on Jakarta EE 9 can be viewed by observing Glassfish 6 weekly builds. While the Jakarta EE 9 bits may not be available in maven central, yet, Glassfish 6 may already integrate them. For Jersey and Tyrus, the milestone versions are available in maven central, since all used dependencies are available in maven central, too. Glassfish contains release candidates, that are not available in maven central, yet, and they will get there once the dependencies are there. We mark them as release candidates since the final version of the Jakarta Restful Web Services API / Jakarta WebSocket API is referenced. As soon as all the TCKs are passing, the release candidate of Glassfish is planned. The Glassfish is not tested on JDK 11, or newer, yet.

The initial Jakarta EE 9 is required just to work on JDK 8.

Jakarta EE 9.1 is planned very soon after the initial release, and it will be compatible with JDK 11 (as well as with JDK 8).

What happened with JAX-RS acronym

Java API for RESTful Web Services (JAX-RS) continues as Jakarta Restful Web Services. To distinguish between Java EE and Jakarta EE, Jakarta Restful Web Services stopped using the JAX-RS acronym. The acronym is no longer used in the Specification document, nor in the API, nor the TCK document. The full Jakarta Restful Web Services name is used there instead. The discussion about a better acronym/abbreviation did not find a final replacement, yet. The most favorable seems to be Jakarta REST, but people keep using the JAX-RS acronym during a discussion.

The full Jakarta Restful Web Services name is prefered over JAX-RS acronym for the time being to distinguish between Java EE and Jakarta EE.
This entry was posted in Jakarta EE, Jersey. Bookmark the permalink.