Jakarta EE Survey 2020/2021 - results

Last September we conducted our 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 October, after which we got about 500 responses. The survey was left alone for the next months, until a little promotion was done in February, resulting in about 100 extra responses. In total we ended up with 684 respondents in total, which is down from the 1054 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 (OmniFaces) reach. These are our own website, our Twitter account, the Jakarta EE news section, etc. The results may therefore be biased towards the more active OSS developer.

Overview of questions

1. Which versions of Java EE/Jakarta EE have you recently used?
2. Which application servers have you recently used?
3. How would you rate the application servers that you've used?
4. Which Java EE/Jakarta EE APIs have you used recently?
5. Have you used a (standalone) Servlet container recently?
6. Which Servlet containers have you used recently?
7. Which additional Java EE/Jakarta EE libraries do you use with your Servlet container?
8. On average, how many Java EE/Jakarta EE libraries do you add when using a Servlet container?
9. Have you used MicroProfile APIs recently?
10. Which MicroProfile products have you used recently?
11. Which MicroProfile APIs have you used recently?
12. What's your preferred situation regarding MicroProfile vs Jakarta EE?
13. What Jakarta EE and MicroProfile products do you prefer?
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?
15. What would be the ideal cadence (time between major releases) for Jakarta EE?
16. Knowing that Jakarta EE 9 contains only the javax to jakarta namespace change, do you:
17. Which APIs would you most like to see updated in the next version of Jakarta EE?
18. How important are the following general options to improve Jakarta EE?
19. How important are the following more specific options to improve Jakarta EE?
20. Do you have any final comments on how Jakarta EE can be improved in the future?

Let's take a look at the results from this year with the first question:

Question 1 - Which versions of Java EE/Jakarta EE have you recently used?

We previewed this question recently. Compared to then the percentages didn't change:

In the 2018 survey we asked a very similar question "Which versions of Java EE have you recently (last couple of months) used?"

Not entirely surprisingly but still good to see confirmed is that Jakarta EE 8 and Java EE 8 usage has gone up, with Java EE 7 usage decreased. Considering that Jakarta EE 8 and Java EE 8 are functionality identical it's interesting to see that they both add up to 74% (taking into accounts duplicates). With Java EE 7 at 35% in 2020, it means Java EE and "EE 8" have almost exactly swapped places.

Question 2 - Which application servers have you recently used?

We see here that Red Hat's WildFly is head and shoulders above the competition. Payara Server is however coming in at the second place among the developers in our target audience. GlassFish comes in at the third place.

It must be noted that Payara Server is a fork of GlassFish, and despite Payara slowly putting more distance between itself and GlassFish (by for instance using a different embedded database, a different default clustering solution, and incorporating their own developed MP components) they still share an overwhelming amount of code. Essentially Payara Server and GlassFish are in the same family.

Additionally, though marketed as two products, WildFly and JBoss EAP share the same codebase and are technically more or less identical (representing different points in time on the overal line of code).

The above means that TomEE as a server family comes in third. Here too, we asked a similar question in 2018. Then the results were as follows:

We see here that WildFly and JBoss EAP are now mostly at the same position as they were in 2018, but relatively speaking lost a little bit of ground. GlassFish however lost a lot of ground, going from 37% to 22%. Payara Server stayed exactly where it was 2~3 years ago, at 27%.

Once the two most dominant application servers, WebLogic and Websphere have gone back further to 10% resp. 8%. Open Liberty gained almost exactly what Websphere has lost, going from 8% to 11%. Though we can't tell from this survey, it's not unthinkable an amount of WebSphere users moved from WebSphere to Open Liberty as those two are both from IBM.

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". The outcome has different aspects that we'll be looking at individually. Note that the servers that weren't effectively used by anyone are left out.

As the chart with all results in it looks rather crowded, let's first take a look at one with the two extreme emotions "Love it" and "Hate it" in it. The "Like it" is also added for connection with the next graph.

Here too WildFly wins the popular vote, with 33% of its users in our survey claiming to love it. Payara Server is close on its heels though with 31% of its users loving it. Note that the percentage is relative to the server in question. Since WildFly is more used than Payara Server, the absolute amount of people loving WildFly is about double that of those loving Payara Server.

Like in 2018, there's little hate for most servers, with the notable exception of WebSphere and to some lesser degree WebLogic. Maybe it's not a coincidence that those two are the only closed source servers used.

Let't take a quick look at the 2018 "Love it" results again to compare:

We see that WildFly has stayed about as popular among its own users, with only a small decline. Payara Server however saw a large decline from 46% of its users loving it, to 31%. Still a good number, but clearly less. TomEE has declined somewhat, with GlassFish staying about the same, declining only a single percentage point. Surprisingly, the only server gaining in love has been JBoss EAP, going from 18% to 22%.

Let's now take a look at the graph with the less extreme emotions "Like it" and "Don't like it" and the neutral "Does the job".

For the top 3 here it's almost a draw for the "Like it" category, with Payara taking a small 1% point lead. For the "Don't like" category it's WildFly however taking that same small 1% point lead with only 3% of its own users don't liking it, compared to 4% for Payara Server. When it comes to the neutral "Does the job" category GlassFish scores the highest, followed by WebLogic and closely followed by TomEE.

Let't take a look at the 2018 "Like it" results to compare:

Here we see WildFly has declined somewhat, going from 47% to 44%. As we've seen from the previous charts these percentage points didn't go into extra love. Payara Server on its turn gained a few percentage points, going from 39% to 44%. As we saw from the previous charts, some of these percentage points came from the "Love it" category. TomEE stayed at exactly the same percentage; 40% of its users liked it in 2018, and 40% still like it in 2020. WebLogic and WebSphere declined a little bit further among its users in our target audience, next to losing some points in the "Love it" category, they both lost about as much in the "Like it" category as well.

Question 4 - Which Java EE/Jakarta EE APIs have you used recently?

The outcome of which APIs are most often used is not that surprising, or maybe in a way it is. Jakarta Persistence (JPA) leads the pack. This is itself not surprising, but what may be surprising is that this is so despite the fact that Jakarta EE and its offspring doesn't really focus on Jakarta Persistence at all. Its most well known implementation, Hibernate, is very active, but the Jakarta Persistence spec/API project is not active at all.

Comparing this outcome with the 2018 result doesn't really show any major differences:

When we divide this chart into 3 sections from top to bottom, and consider each section an unordered bag, there's virtually no change at all:

Popular

{Persistence, CDI, REST, Faces, Enterprise Beans, Servlet, Transactions, Bean Validation}

Neutral

{Expression Language, JNDI, XML Binding, Mail, JSON Binding, XML Web Services, Messaging, Security, JSON Processing, WebSocket}

Not so popular

{Pages/Tags, Concurrency, Batch, Connectors, Authentication, Authorization}

We essentially only see Jakarta Transactions having switched from being in the second group in 2018, to being in the first group in 2020, swapping places with JNDI. Likewise Jakarta JSON Binding swapped groups with Pages/Tags.

It must be noted that Authentication and Authorization are SPIs, and as such not so much intended to be used directly by the average Jakarta developer. These are used however internally by Jakarta Security, and depending on the server or runtime by the Jakarta Servlet implementation as well. Because their standalone usage is so low, it's been proposed to fold them into Jakarta Security at some point.

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).

Comparing this outcome with 2018 shows yes and no have swapped places, but it's still quite close.

Which Servlet containers have you used recently?

Hardly surprising to those in the industry, Tomcat leads the pack with 80% of respondents who used a standalone Servlet container claiming to have used Tomcat.

Comparing this with 2018 we see both Jetty and Undertow have gained a few percentage points of popularity, while Tomcat has lost about as much:

Question 7 - Which additional Java EE/Jakarta EE libraries do you use with your Servlet container?

E.g by adding them to your .war. Note this question only concerns implementations of Java/Jakarta EE specs, not other libraries like Spring, PrimeFaces, OmniFaces, DeltaSpike, etc

Corresponding to most people saying that they use Jakarta Persistence (JPA), when it comes to Servlet users over 2/3 of them add Hibernate to their war archive, while an additional 22% adds EclipseLink, and 7% adds OpenJPA. We're also happy to see that the person who asked us to include DataNucleus in the choices has likely participated again, and was this time able to choose that option. Rounded up it represents another 1%.

Perfectly corresponding with the APIs that people use in general, CDI is at the second place of things people add. 46% of them add Weld, while 6% adds OpenWebBeans.

As for Jakarta REST (JAX-RS) it's interesting to see that Jersey and RESTEasy are added about as often. Comparing with 2018 again, we see a few things:

CDI (Weld) usage has clearly gone up, while Jersey is added a lot less and RestEasy a lot more. Combining those two makes that Jakarta REST (JAX-RS) is probably used about as often with a Servlet container as before.

Soteria, a Jakarta Security implementation has gone up quite a bit as well, relatively speaking. This is interesting. Soteria was particularly designed to be usable on multiple servers and runtimes, but until recently there were some practical issues with Soteria on Tomcat, and this has only been truly fixed after the survey started.

For the "Other" category, people mentioned Spring, PrimeFaces, OmniFaces and DeltaSpike, perhaps not unsurprisingly.

Question 8 - On average, how many Java EE/Jakarta EE libraries do you add when using a Servlet container?

E.g by adding them to your .war. Note this question only concerns implementations of Java EE/Jakarta EE specs, not other libraries like Spring, PrimeFaces, OmniFaces, DeltaSpike, etc

Not asked, but deduced from the total amount of people who said to use a Servlet container, and the amount of people answering this question, there were around 8% of people not adding any Jakarta EE libraries to their war archive.

We see here that 37% of users of a Servlet container in our target audience add more than 4 Jakarta EE libraries to their war archive. Adding exactly 3 was another popular choice, though interestingly enough adding exactly 4 was quite a bit less popular. Of course our target audience consists of users particularly interested in Jakarta EE, so the above absolutely does not men 37% of all Servlet container users add so many libraries.

Question 9 - 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.

Lets right away compare the 2020 result to the 2018 one:

In 2018 MicroProfile was still relatively new, and hence only 16% had used any of its APIs. In 2020 the situation is quite different. MicroProfile is now much more established, and in percentage points its usage has doubled.

Question 10 - Which MicroProfile products have you used recently?

As can be seen the popularity of MicroProfile products largely mirrors the popularity of Jakarta EE products. Red Hat's offerings are squarely on top, followed by Payara with some distance, followed by IBM's Open Liberty and then Oracle's Helidon.

Interestingly, when it comes to MicroProfile, the Jakarta EE products of Red Hat and Payara are used approximately as often as their non-Jakarta EE products, with only a small edge for the non-Jakarta EE versions. It must me realised though that even though Quarkus and Payara Micro are not EE certified, they both contain many EE components.

Payara Micro is actually very close to Payara Server, with only a few EE components removed (like a Jakarta Messaging broker). Quarkus is more difficult to qualify in terms of EE. Via its app generator one can see it supports a bewildering amount of different components, and there's no explicit mention of EE. Eagle eyed readers however would be quick to recognise a multitude of components which are in fact originating from, based on, or used for Jakarta EE.

Something particular noteworthy is that this list doesn't really contain any "pure" MicroProfile implementation. With that we mean an implementation that only implements MicroProfile and nothing else. Somewhat ironically given the history, Helidon maybe comes closest to that, although it also integrates Jakarta Persistence and Jakarta Transactions, as well as Jakarta WebSockets.

We're particularly happy to see that Piranha Cloud has a small amount of users already. Piranha Cloud is our own platform. At the moment of writing it's still in development and not fully production ready yet. Comparing with the 2018 results shows many differences:

The biggest change is clearly that Red Hat has stopped development for WildFly Swarm, and has folded it into regular WildFly and its new Quarkus. WildFly Swarm initially had strongly integrated, non-reusable MP implementation components, but later in its life these had been refactored into the reusable component set called SmallRye. SmallRye is occasionally mistaken for a MicroProfile product/server itself, but it's not. It's a collection of implementations, e.g. for MP JWT, that can be used by any server or platform.

Payara Micro and Open Liberty both saw a rather big decline in usage. Hammock unfortunately stopped its development, although it still has a 1% user base left from its initial 3%.

Question 11 - Which MicroProfile APIs have you used recently?

There's clearly 3 groups of popularity here. Config and Rest Client are in top group, Health, Metric, and Open API make up the second group, and the last group is JWT, Open Tracing and Fault Tolerance. Comparing with the 2018 results shows some differences:

In 2018 Rest Client was still rather new and wasn't used much then (to be fair, it wasn't even implemented by all vendors at that point). Config, which was already at the top in 2018, has seen even more usage in 2020. Incidentally, Config was initially planned for Java EE 8 under the name of Java EE 8 Configuration. Via projects like DeltaSpike this type of configuration has been used in EE applications since around 2010. It's not surprisingly then that Config is proposed to be moved in some way to Jakarta EE, or that Jakarta EE in some way imports Config.

Question 12 - What's your preferred situation regarding MicroProfile vs Jakarta EE?

There have been some teething issues regarding the alignment between EE and MP, which are now both at the Eclipse foundation, and being worked on by mostly the same people. 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 can be seen, at 61% there's strong support for MicroProfile joining up with Jakarta EE, although the 31% who like to see them as separate frameworks is certainly not a small group either. There were some interesting comments:

"There should be a common base - config + injection that both should use. Whether it is Jakarta or MP or both is not that significant I think"

"Microprofile as Cutting Edge Jakarta EE standardizing after things are well established "

"Having more than one standard is going to cause more confusion "

"Using MP as incubator for Jakarta EE but use the jakarta namespace also for MP. So the users will not need to migrate once the MP Apis are moved to Jakarata EE "

Question 13 - What Jakarta EE and MicroProfile products do you prefer?

Separate products: A product implements only the EE APIs (like e.g. GlassFish or WebLogic), or only the MP APIs (like e.g. Helidon)
Single product: A product implements both the EE and MP APIs and fully allows them to be used together (like e.g. Payara or recent WildFly releases) 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

In broad lines the outcome here mirrors that of the previous question. The presence of a "Don't care" option did influence both the "together" and "separate" results, but "separate" more so than "together".

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?

Note that this question only asks if you have heard of these. Whether you actually used them or not doesn't matter.

Only 36% of the respondents answered this question, so we'll mention two percentages here: the first the percentage relative to the total number of respondents, the second number relative to those who answered the question.

Not surprisingly, Helidon is most well known among respondents. 27% of all respondents claims to have heard of it. We're also happy to see that 16% has heard about Piranha Cloud already :)

Question 15 - What would be the ideal cadence (time between major releases) for Jakarta EE?

Now that Jakarta EE has moved to the Eclipse foundation, and the work for Jakarta EE 10 is about to begin (and in some cases has already begun), the question is what the release cadence should be. For Java EE under the JCP this greatly varied but was on average about 3 years.

Here we see that there's strong support for a yearly cadence under our respondents. Taking twice as much time (and hence including more per release), or taking half of that time (and thus including less per release) are about as populair. The existing cadence of 3 years did not appear to be very popular at all.

Some of the comments:

"LTS every 2 years, minor releases every year, bugfixes evey 6 months "

"Feature releases and LTS like Java SE does it for stability and innovation balance "

"Hard to say but 6 months would definitively be too short for us. We have many small applications with only a few releases each year (~ 1 to 4 releases). "

Question 16 - Knowing that Jakarta EE 9 contains only the javax to jakarta namespace change, do you:

1. Migrate to Jakarta EE 9 as soon as your favourite server (e.g. Wildly) comes out with an EE 9 version
2. Wait for Jakarta EE 10 with actual new features
3. Other

There's not a strong support for any specific option here. A slim majority of respondents claims to wait for Jakarta EE 10, but it's really a slim margin.

Some of the comments:

"Wait to give my other dependencies time to catch up on EE9 "

"We will try to migrate to jakarta EE 9 once tomee implementation is based on jakarta, without bytecode transformation and other libraries are migrated as well (logback, javamelody,etc). We think it will be a very painful task "

"Migrate as soon as all the (many) internal dependencies update "

"Depends on when my cloud service provider offers it"

"Do new development on the leading edge; migrate others as we go. "

Question 17 - Which APIs would you most like to see updated in the next version of Jakarta EE?

For this question respondents were asked to rank the Jakarta EE APIs. From this ranking a total score was calculated, based on a combination of how often something is at position 1 (max points) how often something is at position 2 (little less than max points) etc.

Looking at the total ranking we see the most desire for updates is in CDI, followed by Jakarta Persistence (JPA) and Jakarta Rest (JAX-RS). These three largely follow from what people actually use. Jakarta Security stands out here: respondents relatively speaking more often want to see it improved compared to how often they are using it. Jakarta Mail (JavaMail) is the opposite here. It's used more often compared to how often people like to see it improved.

This may be explained by Jakarta Security being a small and new API. Introduced in Java EE 8, it only covers the basics. Advanced features were initially left for Java EE 9, but then the entire transition to Eclipse started. Jakarta Mail likely simply does what it needs to do: send email. There's not that much demand for anything else there, it's a stable and fairly complete API.

Comparing with the 2018 results we don't see a lot of differences (note that for the 2020 question we folded several highly dependent APIs, such as all the Security APIs, into one):

The fact that we don't see a lot of differences may be some kind of validation for the numbers. Functionally nothing has changed since 2018, as only the migration to Eclipse / Jakarta has taken place. The wishes people had for Java EE (now Jakarta EE) in 2018 still hold for today.

Question 18 - 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:

• Aligning specifications and features to take better advantage of CDI, making CDI truly the central component model for Jakarta EE
• Aligning specifications and features to take better advantage of Java SE innovations
• Including more commonly used features that are vendor-specific today or available outside Jakarta EE technologies
• Officially add alternative deployment models  such as the Uberjar, run .war from command line, etc.
• Aggressively deprecate and remove legacy features
• Aggressively remove everything that is already @Deprecated but still there

Under our respondents there's a very clear winner here. "CDI as the central component model". This is good news, as this is indeed the direction Jakarta EE is going in. For instance, Jakarta REST has a clear plan to rebase on CDI, and there's several plans to move Enterprise Beans features to CDI versions in the Concurrency API.

Taking advantage of new Java SE innovations is high on the list as well. This could include for instance fairly old things that have still not been fully utilised such as lambdas, or things that are theoretically old, but practically still very new too many people, such as modules. Records, and in the future light-weight user mode threads (aka fibers) could have a massive impact on some APIs.

Alternative deployment models were less popular among our respondents, although that could just mean people don't see a point in standardising them and using them in a vendor specific way is enough.

Removing and/or deprecating things ranked lowest. Perhaps this is somewhat surprising, as at the same time people ask to reduce the cognitive load in Jakarta EE, for which removing legacy things should surely help.

Question 19 - 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:

• Add more SQL features to JPQL and the Criteria API such as sub-selects
• Make REST (JAX-RS) resources fully CDI beans, deprecate @Context
• CDI friendly equivalents for @Asynchronous, @Schedule and @Lock
• REST friendly, extensionless URLs for Faces (JSF)
• @Service CDI stereotype that seeks to deprecate EJB @Stateless
• Have Servlet and REST (JAX-RS) share a common HTTP engine
• Make Servlets fully CDI beans (in Jakarta EE only, allows for scopes and interceptors)
• CDI friendly, modernized equivalents for @RolesAllowed and @RunAs
• CDI friendly equivalent for @MessageDriven
• @ManagedExecutorServiceDefinition annotation for more portably defining managed executors

For this list of more specific features there's one big winner, and that's adding more SQL features to Jakarta Persistence. This corresponds pretty well with people liking to see improvements in Jakarta Persistence.

At the second place we see REST resources becoming fully CDI, and the CDI equivalents for @Asynchronous, @Schedule and @Lock, which corresponds well to the improvements for REST and the CDI alignment that people like to see at a more general level. REST URLs for Faces scores quite high as well. For this JSF 2.3 did important foundational work, but it's still a bit of a hassle to actually use it. For Faces 4.0 we are targeting a simple option to activate this, as well as a new action lifecycle.

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:

"Jpa criteria is terrible to use. It would be good have an alternative "lite" criteria in jpa similar to hibernate one."

"JPA really is complex to use with the cloning; as long as you are in a request-response setting it is ok, but with a more long lived fat client it's complex. May introduce a mode where no clones are used."

"JNoSQL should align with the forthcoming ISO GQL rather than tying to TinkerPop."

"Standarize the jpa data repository abstraction (à la spring boot / micronaut data / quarkus panache). Merge MP config , fault tolerant, health check, rest client to Jakarta EE with the jakarta namespace. Make Jakarta Messaging support Kafka and standard messaging protocols... DEprecate ejb and move its APis to other corresponding specs Ahead of time CDI processing. Modularize the platforme (use some sort of starter instead of profiles) ... And we're good :)"

"I would like to see Jakarta EE 9 ASAP. At the moment I feel that there is an chaos and stagnation and more and more people are afraid to choose Java/Jakarta EE because they don't see the clear future."

"Release EE 10 ASAP, Spring is becoming de-facto standard "

"Remove EJB and include more security features of OAuth2, and other protocols. Also, make CDI very central to JakartaEE, and include latest Java SE features in future APIs of Jakarta EE. Also, let Jakarta EE support Java programming language exclusively, as primary and first class support. Other JVM languages should be given less preference over Java."

"There are 4 different annotations that 'inject' something: @Inject - inject a bean @Resource - inject a (typically) DataSource @EJB - inject an EJB @PersistenceContext - inject an EntityManager Wish it could all be just '@Inject' Also make sure works for constructor-injection as well as field-injection"

"Add Quarkus like build time optimizations, for example for CDI, Make the extensions API work in these environments, so these CDI implementations don't need a proprietary extension API"

"JEE was affected by seasonal fads, problems with updating and bureaucracy of big companies, I believe in the robustness, in the reliability for the craziest that the boys call me for continuing to start new projects my clients and I are very satisfied. Thank you for helping the community that is very strong and knows the power that the whole package has. As long as the JEE exists and I will use it."

"Make @DataSourceDefinition work with injected values vendor-neutral. Configuration in general across environments in a secure way."

"Get rid of legacy and complexity (focus on CDI) and get ready for cloud (MicroProfile)"

"I feel like MicroProfile born out of slow moving Java EE. Now both taking own route even though CN4J formed. May be once Jakarta 10 or 11 released. Make both Jakarta EE and MicroProfile under one brand. We already break namespace charge for Jakarta EE 9, not sure how many will upgrade for that immediately. Jakarta 10 might be good Candidate to remove some old or deprecated stuff, and then make Jakarta 11 naturally home for microphone. That's we taking of 2 years from now once Jakarta falls yearly release Cadence."

"Make every API based on CDI for consistency."

"Better specification related to microprofile and its interaction with Jakarta EE or its existing APIs like CDI or JAX-RS"

"make JEE and microprofile converge, I want to build a thin war and deploy it and needed resources from a simple command line that could be transformed into a systemd service or Podman container; hot reload on development mode."

A special mention for this comment, where the writer took quite a bit of effort: (we do wonder if this writer is familiar with Jakarta Security, or whether the security comment is refering to JASPIC/JACC and/or container specific/proprietary security):

" * first-class support for fully programmatic configuration and bootstrapping of all specs outside a JEE container. We should not need to use Arquillian, test modules from the spec vendors, or similar to write JUnit tests or to leverage our know-how with CDI, JPA, etc to write a non-server application.
* kill everything EJB with fire, nobody wants pooled beans with synchronization, wrapping of exceptions
* CDI annotations for calling a method periodically and on application startup.
* everything should be a CDI bean.
* OpenAPI support (contract-first development support by generating model, API interface from YAML, fully cover the spec when (de)serializing).
* JPA is a foot-cannon. Persistence as a side effect of in-memory object state is complex and thus unexpected behavior /mistake-prone and not worth the convenience. Also, mapping annotations are poorly thought out and can be contradictory (eg. a @XtoY can have both cascade and mappedBy set) or open to interpretation (eg should a @PrePersist work on an @Embeddable?). Vendors (at least Hibernate) don't fail on startup when annotations have contradictory settings but will have undefined behavior. Either create an alternative type-safe SQL building and ResultSet-to-Object mapper spec or refer users to Jooq, QueryDSL or similar.
* All the security stuff is awful, its much easier to write your own filter+interceptor for login and permission checking. Remove it
* Maybe support for working with AMQP, Kafka brokers (don't run them in the application server like JMS)
* It's probably all for nothing as Spring Boot has won and very few people will start a greenfield project in JEE."

P.s. we had a few users mention the many open PRs in the Mojarra project. Yes, we're aware, and hope to be able to look at them soon. Any help in doing reviews and/or tests is highly welcomed!