It’s been more than two years since it took over the Java EE baton from the Eclipse Foundation, which had to create a new namespace, Jakarta, because Oracle refused to hand over the rights to the JavaX namespace. By official standards, the battle has been fruitful. The Eclipse Foundation has now completed the release of Jakarta8,9. Many of the frameworks in its associated community (RedHat,JBoss) are overdone

Jakarta8(+)

In the Java EE release and the original Jakarta EE 8 release, Oracle took the lead in driving the specification, the GlassFish implementation, and the TCK technology, while in Jakarta EE 9, these roles were played by Kevin Sutter (Platform Specification), Steve Millidge leads. (GlassFish) and Scott Marlow (TCK) have made significant contributions to the wider Jakarta EE community.

Jakarta9(+)

Jakarta EE 9 is the result of an open, community-driven, vendor-neutral process. Jakarta EE 9 will use javax.
The use of the namespace is converted to Jakarta.Namespaces to enable future innovations in the specification.

Jakarta EE 9 is Released

A: Servlet container /EE application server

1. Tomcat

Tomcat 10 uses Jakarta EE and is currently in beta. 9 is the version of JavaX. Official Address:

2. Jetty

Eclipse funds its own Servlet container. So the transition has been done. Jetty 11 has been released using Jakarta EE. Jetty 10 is a version of JavaX. The official address: https://www.eclipse.org/jetty/download.php

3. Undertow

JBoss community developed the Servlet container, the network spread is by far the best performance of one. This is also the built-in container that SpringBoot supports. There are several versions of Jakarta EE available on GitHub. The official address: https://github.com/undertow-io/undertow

4. GlassFish

The authority to develop and maintain it was handed over to the Eclipse Foundation. This is the implementation reference of the EE standard. The last version available for javax is 5.0. Jakarta EE has been released in several versions. The official address: https://javaee.github.io/glassfish/

5. WildFly

Formerly known as JBoss, it is now an EE application server owned by Red Hat Fund. The built-in Servlet container is Undertow, and the last version available for Javax is 20.0.0.final. Jakarta EE has been released in several versions. The official address: https://www.wildfly.org/downloads/

6. WebLogic(*)

This is an EE application server owned by Oracle. Jakarta EE release version 8:14.1.1.0 (https://jakarta.ee/compatibility/download/).

7. WebSphere(*)

This is an EE application server owned by IBM. Jakarta EE release version 8:20.0.0.3 (https://jakarta.ee/compatibility/download/)

Conclusion:

Look at the Servlet container and the application server. The ecology of Jakarta Ee is now intact. But development projects look beyond the deployed containers and servers to the application framework.

B: The application framework

1. Spring Framework

Spring Framework Issues: Support for Jakarta EE 9 (Annotations and interfaces in Jakarta.* namespace)

We have no immediate plans to make such a switch, and also no plans for an early access branch. Our upcoming Spring Framework 5.3 generation will be compatible with Java 8+ and based on the javax-namespaced EE 8 APIs still, for immediate use in current production environments. Beyond that, Spring Framework 6 is likely to adopt the jakarta namespace at a later point.

The jakarta-namespaced APIs are not final yet and we expect a long time to go by before all major providers support them in production releases. We not only need Tomcat, Jetty and Undertow but also EclipseLink, Hibernate ORM and Hibernate Validator to provide major releases here, plus several special-purpose providers and libraries, before we can consider a version of Spring based on jakarta-namespaced APIs. Since there is no relevant value add in EE 9’s namespace change per se, backwards compatibility with existing application servers and persistence providers through the javax namespace is more important to us.

That said, if you have a production-targeting stack scenario where our continued use of the javax namespace is an issue, please elaborate. We are aware that the upcoming Tomcat 10 cannot be supported quite yet and recommend sticking with Tomcat 9.0.x (which is feature-equivalent with Tomcat 10, just still based on the javax namespace) for the time being.

One sentence summary:

We may support Jakarta EE in 6. Reason: We can’t integrate until we have exhausted all the frameworks we rely on

2. Struts

Jakarta EE support is not available from the official download address. The official address: https://struts.apache.org/download.cgi. Jakarta EE supports a new specification, Jakarta MVC, that makes the front end of these frameworks a bit awkward.

@Path("hello") public class HelloController { @Inject private User user; @GET @Controller public String hello(@QueryParam("name") String name) { user.setName(name); return "hello.jsp"; }}

Maven depends on:

< the dependency > < groupId > Jakarta. MVC < / groupId > < artifactId > Jakarta. MVC - API < / artifactId > < version > 2.0.0 < / version > </dependency>

3. JPA specification (Jakarta EE8/JPA2.2; The Jakarta EE9 / JPA3.0) :

3.1 the Hibernate (*)

JPA support is still in use of JavaX. The official address: https://github.com/hibernate/hibernate-orm

3.2 EclipseLink

3.0 support the Jakarta JPA: Jakarta. Persistence. EntityManager. The official address: https://github.com/eclipse-ee4j/eclipselink/releases

4. Bean Validation Specification (Jakarta EE9/JPA3.0):

4.1 the Hibernate Validator

When migrating to Jakarta EE 9, it is recommended to upgrade to Hibernate Validator 7, which supports Jakarta Bean Validation 3.0. The official address: http://hibernate.org/validator/releases/7.0/

5. IOC/DI specification (Jakarta EE8/2.0; The Jakarta EE9/3.0) :

5.1 HK2

The Jakarta address: https://github.com/eclipse-ee4j/glassfish-hk2, javax.mail address: https://github.com/javaee/hk2

6. A RESTful WebService (Jakarta EE8/2.1; The Jakarta EE9/3.0) :

6.1 the Jersey

3. X supports Jakarta EE9. 2. X and used to be Java. Official address: https://eclipse-ee4j.github.io/jersey/

6.2 Apache CXF (*)

Currently only JavaX is supported. Official address: https://cxf.apache.org/

7. JMS Messaging Service (Jakarta EE8/2.0; The Jakarta EE9/3.0) :

7.1 ActiveMQ

Currently only supports JMS 1.1 and 2.0. The official address: https://activemq.apache.org/

7.2 RocketMQ (*)

Specific version of the official didn’t check to support JMS The official address: http://rocketmq.apache.org/

8. JSON Processing (Jakarta EE8/1.1; The Jakarta EE9/2.0); JSON Binding (Jakarta EE8/1.0; The Jakarta EE9/2.0); XML Binding (Jakarta EE9/3.0)

8.1 the Eclipse Yasson

Yasson is a Java framework which provides a standard binding layer between Java classes and JSON documents. This is similar to what JAXB is doing in the XML world. Yasson is an official reference implementation of JSON Binding (JSR-367). The official address: https://github.com/eclipse-ee4j/yasson

8.2 Apache Johnzon

Apache Johnzon is a Top Level Project at the Apache Software Foundation (ASF). It fully implements the JSON-P_1 (JSR-353) and JSON-B_1.0 (JSR-367) specifications: Apache JohnZon is a project providing an implementation of specifications: JSR-353 and JSON-B_1.0 (JSR-367 JsonProcessing (aka JSR-353) and a set of useful extension for this specification like an Object mapper, some JAX-RS providers and a WebSocket module provides a basic integration with Java WebSocket API (JSR-356). The official address: https://johnzon.apache.org/

8.3 EclipseLink MOXy

Enables Java developers to efficiently bind Java classes to XML Schemas. MOXy implements JAXB allowing developers to provide their mapping information through annotations as well as providing support for storing the mappings in XML format. The many advanced mappings enable developers to handle the complex XML structures without having to mirror the schema in their Java class model. The official address: https://www.eclipse.org/eclipselink/

8.4 Jackson

https://github.com/FasterXML/jackson

8.5 Gson

https://github.com/google/gson

Conclusion:

Jackson and Gson are not the implementation framework for the JSR specification. Jackson has an extension: Jackson-Datatype-JSR353: support for JSON-P (“Java JSON API”) types (specifically its tree model objects)