Jakarta EE Survey 2020

At OmniFaces we poll the community from time to time about Java EE (now Jakarta EE) and related technologies. With the transfer of Java EE to Jakarta EE now almost completed, people are now starting to think about Jakarta EE 10 , the first Jakarta EE release after Java EE 8 having new featues. As such it's a good time to poll the community again. In the 2020 edition, there are 4 categories of questions again: Current usage of Java EE / Jakarta EE Servlet containers APIs related to Java EE / Jakarta EE The future of Jakarta EE Compared to 2018, we simplified some of the questions somewhat, omitting some of the less popular options to make it more manageable. We added questions about the future of Jakarta EE and MP together, the preferred Jakarta EE cadence, and generally updated the choices (such as adding Quarkus , which wasn't quite on the radar in 2018 and our own Piranha Cloud ). Jakarta EE provides the opportunity to revitalise and modernise Java EE, but i

Implementation components used by Jakarta EE servers

A while ago we looked at which implementation components the various Java EE servers were using. At the time this concerned mostly Java EE 6 servers, with a few Java EE 7 ones thrown in for good measure.

Fast forward 6 years, and we have arrived at Jakarta EE 8 essentially (a re-licensing of Java EE 8). Most servers from the previous instalment have Jakarta EE 8 versions out. WebLogic has its Java EE 8 version officially out, with a Jakarta EE 8 version coming soon (there is no technical difference between these two really). TomEE has started to implement Java EE 8 and in its latest version has gotten quite far, but is not there yet. Resin remained at Java EE 6 with seemingly no plans to update these. JOnAS has disappeared off the face of the earth, and so has Geronimo as server (though as a provider of APIs and their implementations it has stayed alive).

Without further ado, here's the matrix of Java EE 8/Jakarta EE 8 implementation components used by Java EE/Jakarta EE servers:

Vendor Red Hat Eclipse Oracle Apache IBM TMax
AS WildFly GlassFish WebLogic TomEE+ Open Liberty JEUS
Spec/Version 19 5.1 14.1.1 8.0.1 20.0.0.4 8-b266
Servlet Undertow Servlet 2.0.30
source
Tomcat derivative & Grizzly Nameless internal Tomcat WAS WebContainer (part of open liberty)
8.1 / 1.0.39.cl200420200401-1714
source
JEUS Servlet (part of JEUS)
8.0.0.2
Enterprise Beans Nameless internal Nameless internal (EJB-container) Nameless internal OpenEJB Nameless internal Nameless internal
Connectors IronJacamar 1.4.20 Nameless internal (Connectors-runtime) Nameless internal Geronimo Connector 3.1.4
source
Nameless internal
source
Nameless internal
Authentication Part of Elytron
1.11.2
source
Jaspic provider framework (part of GlassFish) Part of WebLogic Security Part of Tomcat Nameless internal
source
Nameless internal
Transactions Narayana
source
Nameless internal Nameless internal Geronimo Transaction 3.1.4
source
Nameless internal JEUS Transaction Manager (part of JEUS)
8.0.0.2
Messaging ActiveMQ Artemis 2.10.1
source
OpenMQ
5.1.4
source
WebLogic JMS
ActiveMQ Classic 5.15.10
source
Liberty messaging (part of open liberty)
1.0.39.cl200420200401-1714
source
JEUS JMS (part of JEUS)
3.0.0
Concurrency Concurrency RI
1.1.1
source
Concurrency RI
1.1.1
source
Nameless Internal (WebLogic concurrent) Nameless Internal (part of OpenEJB-Core)
source
Nameless Internal
source
JEUS Concurrent (part of JEUS)
8.0.0.2
WebSocket Undertow WebSockets JSR
2.0.30
source
Tyrus
1.15
source
Tyrus
1.15
source
Tomcat WebSocket (part of Tomcat)
9.0.30
source
Liberty WebSocket (part of Open Liberty)
1.0.39.cl200420200401-1714
source
JEUS WebSocket (part of JEUS)
8.0.0.2
CDI Weld
3.1.3
source
Weld
3.0.0
source
Weld
3.1.0
source
Open WebBeans
2.0.12
source
Weld
3.1.1
source
Weld
3.1.2
source
Validation Hibernate Validator
6.0.18
source
Hibernate Validator
6.0.10
source
Hibernate Validator 6.0.16
source
BVal
2.0.3
source
Hibernate Validator
6.1.1
source
Hibernate Validator
6.1.0
source
Persistence Hibernate
5.3.5.15
source
Eclipselink
2.7.4
source
Eclipselink
2.7.6
source
OpenJPA
3.1.0
source
Eclipselink
2.7.6
source
Eclipselink
2.7.5
source
REST RESTEasy
3.11
source
Jersey
2.28
source
Jersey
2.29
source
CXF
3.3.4
source
CXF
3.3.3
source
Jersey
2.29.1
source
Faces Mojarra
2.3.9.SP06
source
Mojarra
2.3.9
source
Mojarra
2.3.14
source
MyFaces
2.3.6
source
MyFaces
2.3.6
source
Mojarra
2.3.9
source
JSON Binding Yasson 1.0.5
source
Yasson 1.0.3
source
Yasson 1.0.3
source
Johnzon 1.1.13
source
Yasson 1.0.6
source
Yasson 1.0.6
source
Expression Language EL RI
3.0.3.jbossorg-2
source
EL RI
3.0.2
source
EL RI
3.0.2
source
Jasper EL 9.0.30 (part of Tomcat)
source
Jasper EL 3.0.16(?)
source
EL RI
3.0.0
source
Mail Jakarta Mail Impl
1.6.4
source
Jakarta Mail Impl
1.6.3
source
Jakarta Mail Impl
1.6.2
source
Geronimo JavaMail Jakarta Mail Impl
1.6.2
source
Jakarta Mail Impl
1.6.2
source
Security Soteria
1.0.1-jbossorg-1
source
Soteria
1.0
source
Soteria
1.0
source
[not implemented] Nameless Internal
source
Soteria
1.1-b01-SNAPSHOT (modified)
source
Batch JBeret
1.3.5
source
jbatch FRI
1.0.3
source
jbatch FRI
1.0.3
source
Geronimo BatchEE
0.5-incubating
source
jBatch FRI
1.0.16 (internal copy)
source
jbatch FRI
1.1-SNAPSHOT
source

Each color a component has reflects the vendor with that color in the header. Essentially there's four vendors creating separate and re-usable Jakarta EE components:

Red Hat
Eclipse
Apache
IBM

Oracle and TMaxSoft do create components that implement Jakarta EE APIs, but only use them within their own server products. Things are however not that clear cut. As can be seen in the previous instalment, all the components that are now Eclipse components were Oracle components before. This is because Oracle donated all of its reusable components to the Eclipse Foundation. Although IBM only directly produces one reusable component (jBatch FRI), it did not too long ago acquire Red Hat. This means all Red Hat components are essentially IBM components now, just as when the Sun components became Oracle components after Oracle acquired Sun.

If we look at the servers itself, we see that only TomEE exclusively uses components from a single vendor; its own vendor Apache. WildFly uses many components from its own vendor Red Hat, but uses components for Faces, JSON, Concurrency and Security among others from Eclipse. WildFly uses a single Apache component, namely ActiveMQ Artemis. This however used to be Red Hat's own component, HornetQ, which it donated to Apache in order to merge the existing ActiveMQ and HornetQ communities and together work on the next generation message broker.

GlassFish uses most components from Eclipse, its own vendor, two from Red Hat and one from IBM. This is however not randmom. As the former RI (reference implementation) of Java EE, it incorporated all the RI components. Since Red Hat was leading two specs, and IBM one, it used the components from those spec leaders. In Jakarta EE the concept of the RI has been done away with and has been replaced by compatible implementations, of which there always needs to be at least one. Since GlassFish is no longer an RI, its community could potentially develop Eclipse implementations of CDI, Validation and Batch. At least for the former a development that could lead to this is being considered by Payara.

Derivative servers were not included in the table, as they have the same components as the server they are derived from (albeit these components could be in different versions). This includes Payara and Cosminexus (Hitachi Application Server), and JBoss EAP. It's perhaps interesting to note that Payara and Hitachi are joint co-leaders of the GlassFish project and devote a significant amount of resources to further the upstream GlassFish project together with former owner Oracle.

Also excluded is our own Jakarta EE runtime, Piranha. This is because at the time of writing Piranha is far from ready. Via the OmniFaces project Piranha does introduce new reusable Jakarta EE components; for Jakarta Authentication and Jakarta Authorization, which until so far hadn't been produced by anyone (JOnAS however once did start development for a reusable Jakarta Authentication/JASPIC component).

Arjan Tijms

Comments

Post a Comment

Popular posts from this blog

JSF 2.3 released!

Dynamic beans in CDI 2.0

Dynamically adding an interceptor to a build-in CDI bean