Last year we started a survey about Jakarta EE.
In this survey we asked several questions about Jakarta EE, what people use exactly, and what they would like to see next. The survey was promoted in September 2022. The survey was left alone for the next months, until a little promotion was done towards the end of the year. In total we ended up with 720 respondents in total, which is slightly up from the 684 we got last time.
Looking at the results we must keep in mind that surveys like this are by definition biased; the respondents are self-selected, and come from the pool of places that we (OmniFish and OmniFaces) reach. These are our own website, our OmniFaces and OmniFish twitter accounts etc. The results may therefore be biased towards the more active OSS developer. Additionally notice that while OmniFish technically supports any Jakarta EE server or runtime, we mostly focus on GlassFish and Piranha, so there’s some conflict with asking questions about other servers. For this reason we will do the next version of this survey in cooperation with the Eclipse Foundation.
Question 1 – Which versions of Java EE/Jakarta EE have you recently used?
Compared to the previous edition, Java EE 8 and Jakarta EE 8 are still the most used versions. However, Jakarta EE 8 usage is now much closer to Java EE 8, and Java EE 7 and Java EE 6 have become much smaller. A truly surprising result is to see the very rapid adoption of Jakarta EE 10, given this version was released not that long ago, and at the moment of writing Open Liberty and TomEE have not implemented this version yet. Likewise, the adoption of Jakarta EE 9.x, which was mostly meant as a tooling release useful for vendors of tools and libraries to prepare for the javax to jakarta namespace change, is quite high as well.
Question 2 – Which application servers have you recently used?
The usage share of the application servers is nearly identical to that of the last edition. Red Hat’s WildFly remains the dominant application server, with Payara and GlassFish following with some distance.
As we noted last time, WildFly and JBoss EAP are essentially the same software, with the main difference the support subscription. Payara Server and GlassFish are largely identical; Payara Server started as a fork of GlassFish and still copies and incorporates code from GlassFish. However, Payara Server and GlassFish have also diverged quite a bit in various areas.
WebLogic and WebSphere have again lost a few percentage points of usage compared to last time, but not that much. The products seem to be largely branded as legacy by their vendors, with Helidon respectively Open Liberty as their replacements.
Question 3 – How would you rate the application servers that you’ve used?
For this question respondents could rate the servers they’ve used using 5 categories. There were two negative ones: “Hate it” and “Don’t like it”, a neutral one: “It does the job, but that’s all”, and two positive ones “Like it” and “Love it”. Note that the servers that weren’t effectively used by anyone are left out.
Servers that are more appreciated would have the bottom bars higher than the upper bars in the graphs shown above, and servers that are less appreciated the other way around. As it appears, the rating of the servers pretty much follows the usage pattern. WildFly has the least hate and the most love, although the peak is at “like it”. Payara Server is close to WildFly with only a little bit more hate, and a tiny bit less love. At the bottom are WebSphere and WebLogic again, with a graph that’s basically the inverse of that of WildFly.
Question 4 – Which Java EE/Jakarta EE APIs have you used recently?
As can be seen, there are various categories of API usage. The top tier consists of Persistence, CDI, REST and Faces, which are all used by more than 60% of our respondents. Do note again that OmniFaces is a utility library for Faces, which likely introduces a bias for the Faces usage here. Remarkable is that Persistence is again the most widely used API, yet is also the API that only sees a modest amount of updates.
Servlet, Validation, Transactions and Enterprise Beans are all used by about as much respondents, which we can roughly group together with Expression Language, JAXB, JSON, Mail and and JNDI in the 30% to 60% tier. In this tier its remarkable that Enterprise Beans, an API which is destined to be deprecated, is still used quite a lot.
The rest of the APIs are used significantly less, with specifically Batch and Connectors having a low amount of users.
Question 5 – Have you used a (standalone) Servlet container recently?
A standalone Servlet container is a server that supports at least the Servlet API, and typically a number of strongly related APIs such as the Servlet Container Profile of Jakarta Authentication, Jakarta Expression Language, JNDI, Jakarta Pages and Jakarta WebSocket.
As it appears, about half of the respondents have used such Servlet container, while the other half hasn’t (and thus only used something like a full or web profile Jakarta EE server). This year it’s almost exactly 50/50, while last time “yes” was slightly lower at 49%.
Question 6 – Which Servlet containers have you used recently?
Like the application servers, Serlet container usage has barely changed compared to the last edition of this survey. Tomcat is by far the most frequently used container, with Jetty and Undertow trailing behind. New in this edition is Piranha Cloud, which is a new Servlet container written from scratch. As its not yet production ready and not yet fully certified (it’s at around 97% compliant) is interesting that it has a tiny amount of usage.
Question 7 – Which additional Java EE/Jakarta EE libraries do you use with your Servlet container?
Hibernate clearly remains the most popular implementation of a Jakarta EE specification that our respondents add to a Servlet container. Together with EclipseLink and OpenJPA, nearly 100% of Servlet Container users in our survey add a Jakarta Persistence implementation. One would almost say Jakarta Persistence could just as well be included by default with Servlet Containers.
Hibernate Validator (Validation) and Weld (CDI) are additional very popular choices. Compared to the previous survey, Soteria (Jakarta Security) has somewhat increased.
Remarkable is that the Other category contained a lot of “PrimeFaces” entries. While PrimeFaces is a great library to add, it’s not an implementation of a Jakarta EE specification. Why people keep entering this is a small mystery. In the Other category a few respondents did mention Exousia; which is an implementation of Jakarta Authorization. Jakarta Security depends on Jakarta Authorization, and none of the existing Servlet Containers include an implementation of this, so it’s indeed a logical library to add.
Question 8 – Have you used MicroProfile APIs recently?
MicroProfile is an industry effort to bring extra APIs into the EE fold for things which Jakarta EE doesn’t have an API now, such as configuration and metrics. At the same time MicroProfile is also a little like a profile such as WebProfile, where only those extra APIs are included as well as Jakarta REST, Jakarta JSON and CDI.
Like other years, only a minority have used MicroProfile APIs, but the percentage that does use those APIs grows every year. In 2018 it was 16%, in 2020 32%, and in 2022/2023 it’s 36%.
Question 9 – Which MicroProfile products have you used recently?
Compared to the previous edition we do see some changes here. Quarkus being somewhat new still in 2020, has now established itself as THE platform that dominates MicroProfile, and in a way Jakarta EE. In 2020 Quarkus and WildFly were used about as much, but this time Quarkus is the clear winner.
Open Liberty is used about as much as last time, but Payara, both its server and micro versions, is used quite a bit less. Because of that Open Liberty has gone up in ranking from the 5th place last time to the 3rd place this time around. There’s a similar story for Helidon MP; WildFly Swarm/Thorntail is used less, so even though Helidon is used about as much as last time, it went up in the ranking too.
Question 10 – Which platform MicroProfile APIs have you used recently?
Clearly the two most popular APIs are Config and Rest Client, just like in the previous edition. Config however is an API that’s not necessarily tied to micro-services, and as such is a candidate for Jakarta EE. Rest Client on its turn is perhaps also not micro-services specific, and should perhaps better be at home with Jakarta REST.
JWT is near the bottom of this list, but at well over 30% it’s still used relatively much. This holds even more so since JWT is practically just an authentication mechanism, of which there are quite a number of other choices. JWT is a candidate to be included in Jakarta Security.
Question 11 – Which extra MicroProfile APIs have you used recently?
Next to the APIs that are part of the MicroProfile platform, there are a number of extra APIs. Those don’t seem to be particularly popular though, as this question was skipped a lot; only 80 respondents selected anything here. Of those, Reactive Messaging was used most.
Question 12 – What’s your preferred situation regarding MicroProfile vs Jakarta EE?
The alignment between EE and MP is not entirely optimal. They have both been at the Eclipse foundation for some time, are being worked on by mostly the same people and increasingly depend on each other. We therefor asked what users like to see regarding alignment:
1. MicroProfile joining up with Jakarta EE
2. MicroProfile and Jakarta EE being two separate frameworks
As last time most respondents prefer MicroProfile and Jakarta EE joining up. The support for this option has even increased somewhat.
In the other category, some of the suggestions were:
“Both technologies should be compatible with each other and preferrable composable.”
“Deprecate both, just choose a la carte libraries for the APIs you need.“
And several variations of:
“Make MP as a Jakarta EE sandbox, adopting more possible ideas from community and create a MVP project by community developers, if something is mature and start a vote by community, and decide to move to Jakarta EE.“
Question 13 – What Jakarta EE and MicroProfile products do you prefer?
Another question about the alignment, now from a product perspective, with the following options:
1. Separate products for the EE and MP APIs
2. Single product for both the EE and MP APIs
3. Don’t care
The outcome of this question largely mirrors that of the previous question, although remarkably, support for the single product has fallen a bit from 56% last time, to just 50% this time. The support for the separate product option remained about the same though, so the decrease for the single product option is because of the increase of respondents who just don’t care about this.
Question 14 – Which of the following products that support one or more Jakarta EE APIs, but are not traditional or certified EE application servers, have you heard of?
Almost half of the respondents (330) answered this question. Of them, nearly 80% had heard of Helidon. Piranha Cloud (our own server) has also become much more known compared to last time. Of course we again have to take a bias into account here, as the respondents mostly came from our own channels.
Question 15 – What would be the ideal cadence (time between major releases) for Jakarta EE?
With only a single “real” (feature) release out, a cadence still has not been established for Jakarta EE releases. Like last time however, most respondents still prefer a yearly cadence. While 2 years and 6 months were about as popular in the previous edition of the survey, 2 years is now clearly more popular.
Some of the responses in the Other category:
“LTS and innovation, like Java SE”
“Align with Long Term Support releases of Java SE as long as those are every 2 years or less. Otherwise 18 months.”
Question 16 – Which APIs would you most like to see updated in the next version of Jakarta EE?
Respondents like to see Rest, Persistence and CDI updated about as much. Last time the order was CDI, Persistence, Rest. So while there has been some shift in priorities, the top 3 of what respondents want to see updated is essentially still the same. The next 3 APIs that respondents like to see updated are Faces, Security and Servlet. This is again largely the same as last time, with Faces and Security having swapped places.
Question 17 – How important are the following general options to improve Jakarta EE?
For this question people could “buy” features for Jakarta EE using 100 points that they could spend at will.
The features were as follows:
1. Aligning specifications and features to take better advantage of CDI, making CDI truly the central component model for Jakarta EE
2. Aggressively deprecate and remove legacy features
3. Officially add alternative deployment models such as the Uberjar, run .war from command line, etc.
4. Aligning specifications and features to take better advantage of Java SE innovations
5. Including more commonly used features that are vendor-specific today or available outside Jakarta EE technologies
Again, making CDI the central component model was the thing that respondents saw as most important. This is a process that started in Java EE 7 with @Transactional, but already in Java EE 7 should have been taken much further. For Jakarta EE 11 this should really become the top priority. The process is inevitable, but has been dragged out for way too long already.
Question 18 – How important are the following more specific options to improve Jakarta EE?
Like the previous question, people could buy features again using 100 points. This time they were:
@Service CDI stereotype that seeks to deprecate EJB @Stateless
CDI friendly equivalents for @RolesAllowed and @RunAs
CDI friendly equivalent for @Lock
CDI friendly equivalent for @MessageDriven
Add more SQL features to JPQL and the Criteria API such as sub-selects
Make REST (JAX-RS) resources fully CDI beans, deprecate @Context
Make Servlets fully CDI beans (in Jakarta EE only, allows for scopes and interceptors)
Have Servlet and REST (JAX-RS) share a common HTTP engine
JWT authentication mechanism in Jakarta Security (maybe based on MP JWT)
Authorization rules in Jakarta Security
The difference in support between the various options appeared to be relatively minor. The exception is mostly in the support for the “Add more SQL features to JPQL and the Criteria API such as sub-selects” and “Make REST (JAX-RS) resources fully CDI beans, deprecate @Context” options, which were quite strong, and the “CDI friendly equivalent for @Lock” option, which was somewhat weaker.
Question 19 – How important are the following new specs to be added to Jakarta EE?
For this question we asked about several new APIs to be potentially added to Jakarta EE:
Caching (maybe based on JCache)
Configuration (maybe based on MP Config)
Compatibility API to run existing EJB apps on CDI
Basic HTTP spec (maybe based on Netty or Grizzly)
NoSQL
Data
Commons
Standard API for starting/stopping server and for deploying/undeploying app
The configuration API clearly had the most support, with the compatibility API for EJB apps on CDI a strong second.
The support for NoSQL and the Basic HTTP was the weakest. At OmniFish we do strongly believe in the virtue of the basic HTTP spec; mostly because it would be much easier to support e.g. Jakarta Security (which is now mostly Servlet based) in the Core Profile and the Micro Profile (which are REST based). Because REST officially doesn’t support Servlet, this creates several problems. A common / basic HTTP spec could unite Servlet and REST.
Question 20 – Do you have any final comments on how Jakarta EE can be improved in the future?
As an open question, people could leave a comment on what they thought about improving Jakarta EE. A selection of those comments:
“Don’t let this important project go to waste. Many companies and developers love Java/Jakarta EE.”
“It would be great to improve testing (api to control server could help). If EJB is going to be deprecated, CDI should provide one annotation for @Stateless replacement (transactions, security, etc.), the same for JMS.”
“1) Increase innovation pace
2) Simplify dev life … reduce the number of subprojects
3) Better support for Servlet containers
4) Remove support for old technologies”
“Remove EJB, the name alone scares away any potential new user, as many have been “traumatized” by the old EJB days.”
“Combine the json spec as one, with a json class simple to use as in vertx
One annotation scanner to improve loading time
Simpler and easy unit testing for ejb relatef stuff testing”
“CDI alternative for EJB Timers.
Alternative LRA annotations that can be used in a service layer as opposed to the REST layer.”
“A big thank you to all the Jakarta EE contributors”
“Consider something similar to querydsl project into Jakarta Data.
Include a native Mock implementation of CDI and FacesContext to run tests”
“It would be great to get rid of the following so we only have @inject for dependency injection: @context & @resource
It would be good if the entity manager had a few methods on it to help with common ORM debugging. For instance if i need to get a list of entities currently managed by the container (to debug an issue) I have to unwrap the entity manage to get the hibernate session. Other nice debugging functions would be how many queries have been run in the the Transaction / how many rows have been returned (to identify cross product issues or n+1 issues).
More control over transaction would be nice such as being able to set a timeout (wildfly offers additional annotations to do this but it would be nice to be in the spec)
Remove how to perform method matching resolution on jax-rs from the spec. The algorithm that is in the spec is not intuitive. From my recollection rest easy made a better matching algorithm but had to revert it due to the spec. This feels like something that should be implementation specific”
“Increase friendliness for new developers. Maybe take a page out of the Quarkus playbook with regard to documentation and tooling.”
“Merge specs like CDI ,DI, interceptor into one. Authz,Authn and security into one. Removed EJB in never release by adding equipment CDI. One year release cadence. Align with Java 21 on Jakarta EE 11.”