Introduction
For those of you who have not dealt with the subject since JEE 8, a short introduction to the topic, to better understand the current position of Jakarta EE. This can be skipped if you are already familiar with the history of Jakarta EE 8. Java Enterprise Edition (JEE or formerly J2EE) was created in 1999 [1] as a collection of specifications for developing enterprise applications in the Java environment. This was done under the leadership of Oracle Corporation until 2017. Accordingly, all rights of JEE were held by Oracle.
In 2017, further, development was handed over to the Eclipse Foundation. However, since Oracle wanted to retain the naming rights, JEE is being further developed under a new name – Jakarta EE. The first Jakarta EE release (Jakarta EE 8) was announced in January 2019. However, this was a purely technical release (data was migrated from Oracle to the Eclipse Foundation) and hardly differed from its historical predecessor Java EE 8. The specifications did not change in this release, only the process behind it [2]. The first new features were thus not expected until Jakarta EE 9.
Now it was finally so far. After several postponements, Jakarta EE 9 was released at the end of 2020. I would like to give you an overview of the current situation (half a year after the release). Is there anything exciting new? What has changed? And were the expectations met?
Status Quo
At first glance, a lot seems to have changed, because all specifications are now one major version higher [3]. But the first glance is deceptive – unfortunately.
The single major version updates come from the “Big Bang”. Due to Oracle’s insistence on the naming rights, the Eclipse Foundation has to migrate all package namespaces from javax.* to jakarta.* at great expense [4]. These migrated specifications represent the respective new major release.
A serious consequence of this is that Jakarta EE 9 is thus no longer backward compatible! Neither with Java EE 8 nor with Jakarta EE 8.
This seemingly simple change, which does not seem to be so bad, makes however larger expenditure, and not only the life of the Eclipse Foundation team heavily but also of all JEE product developers! Consequently, not only JEE 8 is no longer upward compatible, but also all JEE 8 projects or products!
Thus, there are currently hardly any compatible application servers [6]. Only the “reference implementation” Eclipse GlassFish and Open Liberty Beta (from IBM) currently meet the full specifications. This does not seem to change in the near future.
Among others, the company “Red Hat” (developer of the WildFly Application Server) commented on this in a blog entry [7]. Where possible, “native” EE 9 implemented libraries were used (Weld, Hibernate Validator, Jakarta EL … ), but the WildFly – just like most other application servers – still relies on many EE 8 APIs. To work around this problem, these are temporarily made accessible via “byte code transformation”. For this purpose, the Eclipse Foundation has created a special project, Eclipse Transformer [8], to make the adaptation to EE 9 easier.
With this, WildFly version 23.0.1.Final could now comply with the Jakarta EE 9 Web Profile.
Another change is the deletion of irrelevant specifications [5]. These include:
– XML Registries 1.0
– XML RPC 1.1
– Deployment 1.7
– Management 1.1
– Distributed Interoperability
In addition, there is a small name change of the Java API “RESTful Web Services” (JAX-RS) to “Jakarta Restful Web Services” (Jakarta REST).
Outlook
The slow progress may cause some people to worry whether this will really change in the near future. Therefore, now an outlook on the upcoming changes and what we know about it.
For as long as may not even have to wait for a new Jakarta EE, a minor release (Jakarta 9.1) is already waiting around the next corner [9] (17.05.2021 [10][11]). With this update, the long-awaited support for Java 11 should come. The support of Java 8 still remains. Also in the 9.1 release, no functional updates will be included. More details can be found here. As things stand, all milestones are slightly behind schedule and have been postponed once by one month.
The NoSQL API originally planned for JEE 9 is now to come with Jakarta EE 10 [12].
tl;dr
Jakarta EE 9
– Changes of the package namespace from javax.* to jakarta.*
– Removal of irrelevant specifications
– JDK 8 support
– JAX-RS is now called Jakarta REST
Jakarta EE 9.1
– Jakarta EE 9.1 focus is on JDK 11 support
– CORBA is not developed further (removed from Java SE 11)
– XML Binding, XML Web Services, Web Services Metadata, SOAP will not be developed further (removed from Java SE 11)
Jakarta EE 10
– Jakarta NoSQL only with Jakarta 10
Sources:
[1] https://en.wikipedia.org/wiki/Jakarta_EE
[2] https://jakarta.ee/about/jesp/
[3] https://jakarta.ee/specifications/platform/9/
[4] https://eclipse-foundation.blog/2020/12/08/jakarta-ee-9-delivers-the-big-bang/
[5] https://jakarta.ee/specifications/platform/9/jakarta-platform-spec-9.html#a2333
[6] https://jakarta.ee/compatibility/#tab-9
[7] https://www.wildfly.org/news/2020/11/12/Jakarta-EE-9-with-WildFly-Preview/
[8] https://projects.eclipse.org/projects/technology.transformer
[9] https://eclipse-ee4j.github.io/jakartaee-platform/jakartaee9/JakartaEE9.1ReleasePlan
[10] https://eclipse-ee4j.github.io/jakartaee-platform/jakartaee9/JakartaEE9.1#:~:text=Jakarta%20EE%209.1%20Release%20Plan,-The%20Jakarta%20EE&text=On%20Feb%209%2C%202021%2C%20it,the%20Jakarta%20EE%20Steering%20Committee
[11] https://projects.eclipse.org/projects/ee4j.glassfish/releases/6.1.0
[12] https://jakarta.ee/specifications/nosql/
[13] https://eclipse-ee4j.github.io/jakartaee-platform/jakartaee9/JakartaEE9.1ReleasePlan