To blog Previous post | Next post
Most popular Java application servers: 2016 edition
This is now fourth year when we publish statistics about the Java landscape. Every year, during springtime, we dig into the data that we have gathered from the JVMs Plumbr Agents have monitored, and find out about:
- which Java versions are used (Java 6 vs Java 7 vs Java 8);
- which JVMs are used (Oracle Hotspot vs OpenJDK vs Rest Of The World);
- Which application servers are most frequently deployed in the infrastructure;
- how the landscape has changed over time.
Last week we exposed the data about Java versions and vendors. This week we are exposing the state in the application server market.
The following conclusions are based on 1,240 different JVMs that Plumbr monitored for performance during February and March 2016. The data has been gathered from within the JVM via System.getProperty() calls with os.arch, os.version, java.version etc.
Which Java application server is the most widely used in 2016?
From the 1,240 deployments we gathered the data from, we were able to identify the container vendor on 862 occasions, or in around 70% of the environments. These container vendors distributed as follows:
Tomcat installation base exceeded the 50% threshold for the second year in a row. The 58.22% share of the pie left no question about the winner. In addition to Tomcat, next four vendors having significant deployment base are:
- JBoss/WildFly installations, having 20.22% of the market share
- Jetty, with 10.67% of the market
- GlassFish, having another 5.56% of the pie
- Oracle WebLogic deployments with 2.44% of the installations
The “Other” category represented less than 2.5% of the installations. This consisted of Resin, Orion, OC4J, SAP NetWeaver and IBM WebSphere deployments, all detected in less than five deployments.
The remaining JVMs where we failed to detect a Java application servers were mostly either
- desktop applications using Swing or AWT;
- dynamic language runtimes (such as Scala or Groovy);
- containerless server software (Elasticsearch, TIBCO, etc);
- making use of Netty (Play Framework) ;
- or hidden into development environment launchers (Maven,sbt, IDEA, Eclipse, etc).
Java application servers in use 2013 – 2016
Presenting the same data over the period from 2013 to 2016 where we have analyzed the same data, we see the following:
There is a grain of salt one should interpret these changes over time. The reason why Jetty dropped to just third of its former glory on 2015 is likely caused by Plumbr transforming from a development tool to a monitoring solution. Instead of the developer-friendly Jetty the production deployments with other Java application servers took its share of the deployments.
Of the changes in 2015 it is interesting to see Oracle Weblogic being spotted three times less frequently. Whether it is a symptom of companies migrating away from the particular vendor or whether it is due to different type of companies using Plumbr is not fully clear.
One thing that is clear is that for two years in a row Tomcat deployments represent close to 60% of all the JVMs on the field. It is an amazing result, considering that Tomcat was originally designed only as a reference implementation and the amount of energy different vendors have put into promoting their containers.
If you found the data interesting, you are likely to enjoy our regular posts on Java & performance monitoring. To stay tuned, subscribe either to our Twitter or RSS feed.
Comments
Why IBM Webshpere is missing here? Any reasons?
It’s because of tomcat’s lovely admin UI… 🙁
If you want admin UI and open source, too bad Geronimo is dead, but Glassfish is not quite dead http://www.payara.fish/
I am not working for IBM. But IBM WebSphere is <2% says most of its implementation that public data collector are not able to collect, which is also saying JVM is in the intranet. For example, large banks, Insurance companies and highly confidential systems. So this table chart is not a actuate table.
We have been fully open in how the dataset was collected and have not claimed that the on premise deployments are among the results. Your claim however is based on the assumption that the JVMs hiding behind firewalls are lot more likely running IBM Websphere deployments than anything else. This might well be the case, but there is zero evidence confirming this.
Hi it’s sems you would have a sample problem not seing IBM WebSphere in the 2% others seem’s wrong. This Gartner article give a better picture of the market.
Gartner:Market Guide: On-Premises Application Platforms
http://www.gartner.com/document/3172019
I am afraid I do not have access to the content you are referring to as it seems to require credentials. Can you specify what is stated in the URL you are referring to?
I am not saying that we do not have a sample bias. We expose the data from our customer base and of course it can represent only the environment we are deployed in.
But I do expect the referred Gartner materials not being based from actual data from actual JVMs. Instead I do believe these materials to be based upon surveys, which would be a completely different source for harvesting the data for market analysis with its own weaknesses.
Feel free to correct me – as said, you are referring to materials not present in the public domain.
This metric is sooo wrong. Listing Tomcat as a Java EE container??? Bullshit. TomEE plus is one. But Tomcat is just a servlet container, so as Jetty.
So, you are falsifying the statistics, by listing them. 🙁
You concern is something we have heard numerous times over the years when publishing the results. Already in 2013 we covered the issue in a separate post which you can find from https://plumbr.eu/blog/java/there-is-no-application-server. Hopefully after reading it you will agree with us that there is no official definition for an application server. Skipping by far the biggest part of the Java EE deployment base from the study thanks to a missing (or ambiguous) definition would be falsifying statistics, if I would fall back to the terminology you used.
But if we are just weak at finding the trustworthy definition which excludes Tomcat from the application servers, we are thankful in advance if you can refer us towards one.
Note, the title of the article is “Java EE Application Server”, not “Application Server”.
The definition of Java EE is both trustworthy and quite clear:
https://jcp.org/aboutJava/communityprocess/mrel/jsr342/index.html
To claim Java EE compatibility, a project/product must pass the Java EE CTS.
The Java EE specification does not actually define either “application server” nor “Java EE application server” as such. It uses such terms, but instead of defining the term, it uses terms as “container”, “server” and “profile” in the definition section.
But John, if you have a clear reference to a definition in the spec and I am somehow just missing it, I will immediately make the adjustment in terminology …
The specification defines what Java EE is and the collection of APIs that must be implemented.
From the specification:
“… Java EE achieves these benefits by defining a standard architecture with the following elements:
• Java EE Platform – A standard platform for hosting Java EE applications.
• Java EE Compatibility Test Suite – A suite of compatibility tests for verifying that a Java EE platform product complies with the Java EE platform standard.
…
This document is the Java EE platform specification. It sets out the
requirements that a Java EE platform product must meet.”
Tomcat / Jetty do not include the JAX-RS, JSF, Bean Validation APIs. This is the work, for example, that vendors/project do to claim Java EE compatibility (like TomiTribe does for TomEE) . There is A LOT of work that both open source communities and vendors do prove Java EE compatibility beyond being primarily servlet containers. Please respect that effort.
Feel free to call Tomcat and Jetty application servers, but please do not call them “Java EE application servers”.
OK. Even though I still think the definition is still clearly presented in the spec, I changed the title and post to speak about “Java application servers” and removed the “EE” part across the board.
Thank you.
No way, tomcat is not an java ee application server, neithger an application server. Please make the analisys again, and include ibm websphere
Can you pinpoint me to a location in text where we call Tomcat a Java EE application server?
Also, the IBM websphere is included. It is just used so infrequently you might have missed it from “Others” section. Also, pay in mind we have not based this on survey, this data is from actual Java application servers out there.
Are you stupid or what?
Tomcat is fully valid Java EE container for Web Profile EE. Just not suitable for full EE specification…