Java EE Survey 2018 - results
In the 2018 edition, there were 4 categories of questions:
- Current usage of Java EE
- Servlet containers
- APIs related to Java EE
- The future of Java EE / Jakarta EE
Jakarta EE provides the opportunity to revitalise and modernise Java EE, but in order to do that it's more important than ever that we know what matters to all of its users out there.
We started the survey the 15th of March, 2018. Unfortunately a small barrage of other surveys would soon follow, among others the Eclipse Jakarta EE Survey, the Jakarta EE Logo selection, and the Baeldung survey. Despite all those other surveys going on at the same time we still managed to get 1054 respondents. Not as much as we hoped for, but still enough to have some idea of what's important to the community.
It must be noted that OmniFaces is a JSF utility library, so the public we attract is naturally more interested in JSF than the primary public of the many parallel surveys that were going on. We did track where the respondents originated from, and 344 of them took the survey directly on the omnifaces.org website.
It must also be disclosed that one of the OmniFaces members (the writer, Arjan), works for Payara. Payara however was in no way involved with either the creation of the survey or the report. Payara did tweet about the survey a couple of times.
Let's take a look at the outcome now.
Question 1 - Which versions of Java EE have you (historically) used?
This question was about which version of Java EE people have ever used, and hopefully will give us some idea of how much experience our audience has and how long they've been using Java EE.
It appears though that most of our respondents haven't used the older versions so much. Far less than half of the respondents has ever used Java EE 5. On the other hand, there's still a relatively big proportion of respondents that have used the precursor technologies of Java EE (the ones older than J2EE 1.2).
Question 2 - Which versions of Java EE have you recently (last couple of months) used?
Looking at what people have recently been working on we see that J2EE 1.3 and J2EE 1.4 is almost non-existent. The response for those is well within the error margin. There's still a number of people working on Java EE 5 applications though, which is now more than a decade old! Not surprisingly, most people are working with Java EE 7, for which all currently active vendors have a supported version out.
Maybe somewhat surprisingly is that 36% of the respondents are already using Java EE 8, given that not all vendors have a fully supported version out or have even implemented all Java EE 8 APIs yet. Of course, this can also mean respondents are using parts of Java EE 8. WildFly 12 for instance supports most Java EE 8 APIs, except for EE Security (which will come in WildFly 13).
Question 3 - Which application servers have you recently used?
Looking at which (Java EE) application servers are most frequently used there's a very clear winner, and that's RedHat's WildFly. More than half of the respondents have recently used this server. Trailing a good deal behind at the second place is Oracle's GlassFish. Despite being largely abandoned by Oracle and not supported, still 37% of responds use this. Payara Server and TomEE share the third place.
A slew of servers had so few respondents that taking the error margin into account qualifies them as practically unused by our respondents. This included Geronimo, the once promising server from Apache that silently and without any notice stopped, Resin, a very promising Web Profile implementation back then with its own CDI implementation (CanDI), which however never managed to get passed Java EE 6, and JOnAS, the mostly French server which had a number of its own unique component implementations as well, but like Geronimo just silently stopped at some point. Following is a number of mostly Korean, Japanese and Chinese servers. These servers are mostly used in their respective countries, and seemingly English language surveys are not (much) picked up by the users of these servers.
Question 4 - 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.
Love it
The first aspect we'll be looking at is a ranking of all servers that got the maximum appreciation: "Love it". Here we see Payara Server is the winner. Almost half of the people who used Payara said they loved it. At the second place we see WildFly again, where over a third of the respondents who use WildFly said they loved it. Do note that since WildFly is used much more than Payara Server, in absolute numbers more respondents from this survey loved WildFly. Statistics can be a tricky thing.
Quite interesting is that Liberty is relatively much loved and enters at the third place. Liberty is IBM's still relatively new server that does many things right compared to its older sibling WebSphere. Also interesting to see is the stark difference in love between Payara Server and GlassFish. Payara Server is directly based on GlassFish, but with many extra bug fixes and features.
Like it
In the "Like it" category we see WildFly and JBoss EAP topping the chart. Note that these too are largely the same server, with JBoss EAP essentially a kind of "LTS" of a specific WildFly version with the option to get a support subscription and extra bug fixes. With the exception of WebLogic and WebSphere, the servers are quite close together in this category.
Hate it
Skipping the neutral and dislike categories (they'll be included in the final score though), let's take a look at the hate category. Overal we see that there's relatively little hate among the respondents. Liberty, JBoss EAP, TomEE, GlassFish, Payara Server and WildFly all have very small percentages of hate. The only real exception is WebSphere here, and to a lesser degree WebLogic. In the case of WebSphere, it's perhaps not a surprise. Only its installer is already larger than many complete servers (around the 100MB), and it downloads in excess of 2GB of "stuff". Even in 2018 that's still excessive. After that an actual server needs to be created taking another 200MB or so. This and a number of other issues (e.g. not being able to run on macOS) doesn't make it much popular. Of course IBM recognised this long ago, and all new development is on Liberty, which is essentially everything that WebSphere is not.
Total score
For the total score we used a weighted sum, with the weights (factors) being -3 for "Hate it", -2 for "Don't like it", 1 for "It does the job, but that's all", 2 for "Like it" and 3 for "Love it". For this total score we see Payara Server still wins, but now it's only a small margin with WildFly, which is very close. This seems mainly attributed to WildFly having many more points in the "Like it" category. In the next group we see Liberty, TomEE, JBoss EAP and GlassFish all scoring quite close to each other. All the way at bottom we find WebLogic and WebSphere. WebLogic just about manages to get a positive score, but WebSphere's is deeply negative.
Question 5 - Which Java EE APIs have you used recently?
When looking at the Java EE APIs that people use most, JPA is the overal winner. This is interesting, since in recent years efforts for the JPA spec have been minimised, even to the point that one not rarely hears that JPA is "done" and people have moved on to e.g. MongoDB. Looking at the outcome of this survey this doesn't seem to be exactly the case. CDI follows close and lands at the second place. This is probably no surprise, as since its inception in 2009 CDI has rapidly increased in performance and is now for many cases the default type of bean to use.
Initially somewhat surprising is JSF scoring so high here, and landing just above JAX-RS at the 3rd place. This is surprising since there's a quite vocal community out there proclaiming the era of server side rendering frameworks has come to an end, and the future belongs to the client. For obvious reasons we at OmniFaces don't fully agree with that, but we're also not entirely blind to the fact that the client has indeed taken a large bite out of the total web framework market. As mentioned in the beginning of this article, OmniFaces is a JSF utility library, so our audience likely has a more than average amount of JSF users among it.
Truly surprising though is the high score of EJB, which is often cited as having its name tainted by the complexities of EJB 2 and never quite recovered. Even though EJB 3 is very usable, in Java EE 7 and above CDI can be used instead for quite a lot of cases. It could of course be that EJB is only used for a few small things such as its timer service, but this would need more research and possibly a follow-up survey to really get clear.
Java EE Security, a new spec in Java EE 8, is already used by 24% of the respondents. Given its young age this is quite a good outcome. JASPIC and JACC are both at the very bottom, but these APIs (SPIs actually) are not really aimed at application developers. They are used by higher level frameworks and vendors, e.g. the Java EE Security API strongly builds on JASPIC and will likely build more on JACC in a future release. So these APIs are being used, but just not directly by application developers. A somewhat similar thing also holds for JTA, which is mostly used under the covers by JPA and EJB, but is effectively used directly with the relatively new @Transactional and @TransactionScoped annotations.
Question 6 - Have you used a (standalone) Servlet container recently?
A standalone Servlet container is a server that supports at least the Servlet spec, and typically a number of strongly related specs such as the Servlet Container Profile of JASPIC (not full JASPIC), Expression Language, JNDI, JSP and WebSocket.
As it appears, about the half of the respondents have used such Servlet container, while the other half hasn't (and thus only used a full or web profile Java EE server).
Question 7 - Which Servlet containers have you used recently?
From the people who have used a Servlet container, the overwhelming majority used at least Tomcat. At 85% Tomcat largely dominates this segment. Still, 29% and 22% for Jetty and Undertow are nothing to sneeze at either, and seemingly a non-trivial amount of respondents use either Jetty or Undertow next to Tomcat (people could choose multiple servers).
Undertow's 22% is particularly impressive, as Undertow is not so much known as a standalone Servlet container but more as the Servlet container that Jboss EAP/WildFly uses. It's also relatively new, especially when compared to Tomcat and Jetty which both have existed since the dawn of times.
The "other" category was perhaps not entirely understood, as most respondents choosing this entered products that actually weren't standalone Servlet containers. WebLogic, GlassFish, Liberty and Payara certainly aren't. Grizzly and Netty come closer, but they actually are more akin to HTTP engines, and are themselves not Servlet compatible.
Other
Question 8 - Which additional Java EE libraries do you use with your Servlet container?
This question asked specifically about the Java EE libraries that people add to their Servlet containers. Java EE libraries here means an implementation of a Java EE spec, such as JPA and CDI, but not e.g. Guave, Spring, etc.
Consistent with the API usage outcome, JPA is added most often to a standalone Servlet container, followed by JSF, JAX-RS, Bean Validation and CDI. In this particular question though it was asked which exact implementation people add. As can be seen Hibernate wins hands down over EclipseLink (25%) and OpenJPA (7%). Likewise Mojarra (46%) wins over MyFaces (15%) and Jersey (45%) wins over RESTEasy (28%) and CFX (17%).
The EE Security API has only one standalone implementation yet, which is Soteria (there's another implementation by IBM, but it's embedded in Liberty and not suitable for standalone use). This one is quite new and only used by a couple of people, but it's nevertheless interesting that it is being used standalone.
The "Other" category wasn't entirely understood however. The idea was for other implementations of Java EE specs to be listed here, like e.g. Wink for JAX-RS, HornetQ, OpenMQ or JORAM for JMS, Narayana or JOTM for JTA, etc. None of these were mentioned though, and instead PrimeFaces, OmniFaces, DeltaSpike and Spring were mentioned, which aren't implementations of Java EE specs. Here it's probably the wording of the survey question that's to blame. One respondent did mention DataNucleus though, which is a JPA implementation, and suggested that the question is biased against it by not mentioning it. Given the importance of JPA this is indeed true, so we'll make sure to include DataNucleus next year.
Other
Question 9 - Have you used MicroProfile APIs recently?
MicroProfile is an industry effort to bring extra APIs into the EE fold for things which Java EE doesn't have an API now, such as configuration and metrics. At the same time MicroProfile is also a profile like WebProfile, where only those extra APIs are included as well as JAX-RS and CDI.
Despite all Java EE vendors, with the exception of Oracle, offering those extra APIs with their products, and some implementations being able to be used standalone as well, usage among the respondents was quite low. Only a little more over 15% said to have used MicroProfile APIs recently.
This may have to do with all of those APIs being still very young and haven't established themselves yet. Another reason could be that most vendors by default promote MicroProfile as its own isolated product and not as an extra set of APIs to be used together with the main Java EE ones (Payara is the only notable exception here). As most people would use for example the regular WildFly server (as opposed to the spin-off product WildFly Swarm), which doesn't have the MicroProfile APIs out of the box, this could be a potential barrier.
Question 10 - Which MicroProfile products have you used recently?
Looking at which server product those relatively few people that use MicroProfile APIs use it's again WildFly that tops the charts here, with more than 50% of respondents using this variation of the WildFly main server. Payara Micro follows closely with 45%. Compared to the (Java EE) server product the gap between WildFly and Payara is much smaller here. Payara also has all the MicroProfile APIs included out of the box with the EE Server product, and in this variation Liberty and Payara are used exactly as much. There are various other MicroProfile products, but they are not (yet) so popular (specifically when taking into account only a small proportion of respondents said to be using MicroProfile in the first place)
Seeing that Payara Micro is more used for MicroProfile APIs than Payara Server, one may come to the conclusion that the fact that most MicroProfile vendors don't support these APIs out of the box on their server product doesn't matter that much. While this may be true, it could also be that many users aren't quite aware Payara Server supports these APIs.
Question 11 - Which MicroProfile APIs have you used recently?
Config was the first MicroProfile API and arguably one of the APIs that's most missed in Java EE. A Java EE Configuration API was in the works, but it never materialised. It's perhaps no surprise that config is thus the most used API from the MicroProfile. Health, Metrics and JWT Authentication follow with some distance. Open API, Open Tracing and the Type-safe rest client are all quite new and haven't been implemented by all vendors yet, so it's not a big surprise these aren't used that much yet.
Question 12 - Which Java EE specific extension libraries have you used recently?
This question was specifically about Java EE extension libraries, meaning libraries that one can only use with Java EE. This mostly means libraries that extend or are plug-ins for JSF, CDI, JCA, etc. PrimeFaces is the clear winner here, followed with some distance by OmniFaces (but keep the bias in account, since the survey was promoted via the OmniFaces account and website). Given the popularity that Seam once had, and DeltaSpike being its spiritual successor, just over 20% feels a bit on the low side. DeltaSpike is certainly worth looking at though. Once one of the most frequently used JSF component libraries, RichFaces after being sunset by Red Hat has been reduced to only 13% usage, while newcomer BootsFaces has climbed up to that same percentage.
As far as the "Other" response goes, "MyFaces" was mentioned a lot, but this of course isn't a Java EE Extension library, but a Java EE Implementation library (it implements JSF, as mentioned in a previous question). Tobago, ButterFaces, IceFaces and PrettyFaces are indeed all Java EE extension libraries. Oracle ADF is too, although this is a somewhat specific one (it practically only really works on WebLogic). It's a question if one can really count Spring as a Java EE extension framework. Technically it is, but at the same time it mostly positions itself as an independent full stack framework.
So again, for next year we could do with an explicit definition of "Java EE specific extension library".
Other
Question 13 - Which APIs would you most like to see updated in the next version of Java EE (Jakarta EE)?
When asked which API (spec) people like to see updated, a natural instinct might be to say "all of them". Perhaps not including the ones they hate, or maybe even those so that they can be hated a little less. With only a finite amount of resources this is not always an option, so that's why this question specifically asks respondents to rank the available APIs.
We take a look at the results in three different ways; the amount of people who put an API on the number one position, the amount of people who put an API on the number two position, and finally the total weighted score per API.
APIs at number 1 of the ranking
As can be seen none of the APIs had a really absolute majority. The highest score here was JSF with just over 20%. The question is, did JSF score so (relatively) high here because the potential bias, or do many people see JSF as something that has potential but *really* could do with some desperately needed improvements? CDI and JPA are high on this list too, which matches the outcome of which APIs people use most. Java EE Security is somewhat of an outlier. Being a new spec in Java EE 8 it isn't used that much yet, but already people want to see it improved. As a side-note, Java EE Security 1.0 could only address some of the basics (the low hanging fruit). More was planned for 1.0, but a lack of resources prevented many of those other planned things (such as security interceptors, evens and custom authorization rules) to be actually included.
APIs at number 2 of the ranking
In the number 2 list we see some more variety in the category of APIs having more than 2% of the respondents choosing them, although we do largely see the same APIs again in the top tier. CDI now takes the lead, moving up one place from the number 1 list, and JAX-RS moves up 3 places. JPA is again at number 3, while JSF is at 4 now.
Total score
When we take a look at the total score, we see that the top tier is formed of JPA, CDI and JAX-RS, which is basically identical to the top tier of question 5, which asked what APIs people have used recently. Clearly, people like to see APIs that they actually use improve. In the total score ranking too, EE Security is the exception. It lands on the 4th place, just an inch away from JAX-RS. Interestingly though, JASPIC and JACC end at the last places. As mentioned above, it's likely not common knowledge that these two APIs are the foundation of EE Security.
JavaMail and JDNI are both two examples of APIs that are used more than that people want to have them improved. Likely they just do the job (sending mails resp. looking up resources) and people don't see much need for further improvements there.
Question 14 - What do you think about these options to improve Java EE / Jakarta EE?
This question asked for a variety of broad, somewhat cross-cutting concerns to improve Java EE overall (the potentially improved Java EE will be called Jakarta EE then). The choices with their keys in the graph were:
- CDI rebase - Rebase most Java EE APIs on CDI (remove JSF @ManagedBeans, remove JAX-RS @Context, ...)
- Remove deprecated - Aggressively remove everything that is already @Deprecated (e.g. getServlet() in ServletContext)
- Deprecate legacy - Aggressively deprecate and remove legacy features (e.g. JSP support in JSF)
- Add MP APIs - Add equivalents of some or all MicroProfile APIs to Java EE (e.g. Config, JWT, ...)
- Deployment models - Officially add alternative deployment models (Uberjar, run .war from command line, etc)
- Add JCache - Add JCache to Java EE so that both applications and internal components (such as JPA) can use it
- Rebase on Concurrency - Rebase most Java EE APIs that use threading to use Concurrency Utils thread pools
- Cloud connectors - Add more connectors to cloud services (e.g. Amazon SQS, MQTT, Apache Kafka)
- Security connectors - Add more connectors to security services (e.g. OAuth2, SAML, OpenID, Yubikey)
We'll be looking at two graphs for this one; the one which shows the options for which respondents choose "Please do this!", and the one with the weighted outcome (using the same weights as in question 4).
Please do this!
Of all the options presented, rebasing most Java EE APIs on CDI is the one that most people really want to see. It's followed closely by more security connectors (authentication mechanisms). Clearly the ones that currently ship by default with Java EE, namely FORM (+ custom form), BASIC, DIGEST and CERT aren't enough anymore. MicroProfile recognised this too and therefor added a JWT authentication mechanism as one of the initial new APIs.
Weighted score
When looking at the weighted score, we see that all options presented have community support. Security connectors though have the most support, followed with some distance by adding JCache. Rebasing on CDI and Concurrency Utils, which could indirectly be taken as a wish to have a better integrated platform, has much support as well. At the bottom of the graph we see "Remove deprecated" and "Deprecate legacy". Seemingly people support removing some of the cruft that's in Java EE, but they are not overly concerned about this.
It's interesting to see that the alternative "Deployment models", which according to some vocal voices is *the* reason Java EE has been losing ground (the AS model is allegedly outdated), doesn't bother our respondents that much either. A reason is perhaps that with popular tools such as docker it doesn't matter so much whether you put an AS in it, or an uberjar. The AS might be known outside Java EE as a super large monolith, but actual Java EE users probably know that a modern AS is ~70 to 100mb and starts between 1 and about 3 seconds, while an uberjar can easily be around that same size too and starts in about the same time as well.
Question 15 - Do you have any final comments on how Java EE / Jakarta EE can be improved in the future?
The final question was a fully open question where people could comment whatever they wanted. 179 respondents left a comment, which is about 16% of the total number of respondents. Overal the quality of the comments was quite good. We'll provide a few of them here:
"Take good care of it, don't leave legacy behind. But still move it forward. by all means remove already deprecated stuff. I feel things can often be don the old and the new way.. And the support forums are full of good recomendations on both old and new. And it's sometimes confusing not being an expert."
"Please, single set of bean annotations. Not mixture of CDI, EJB and JSF"
"Externalize configuration for both AS domain and the app for all configurable properties. - All AS settings must be configurable via command line."
"Make it easier to have something between a full application server and just a few features (i.e. I only need JSF, JAX-WS, JavaMail, and DB, but not JPA and EJB, etc.) so they don't have to be manually added in the app or grafted into the servlet container in some non-standard way. Also, I'd prefer to be able to easily choose which technologies (JSF: Mojarra vs MyFaces, JAX-WS: Metro vs Apache CXF, etc.). Just a general thing to watch out for: Don't assume all users will want to use Maven; be sure you provide another way to download."
Tag cloud
goooooooooddddddd!!!!!!!!!!!!!!!
ReplyDeletegood post!
ReplyDelete