To blog |

Java version and vendor data analyzed: 2016 edition

April 12, 2016 by Nikita Salnikov-Tarnovski Filed under: Java

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);
  • how the landscape has changed over time.

This year our 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..

Java versions used in 2016

Java major version got close to confirming the Java 8 being the most popular environment. But 2016 is still the year of Java 7 in the lead with Java 8 trailing behind with just 0.17% less deployments:

java versions used in 2016

in 2016 we saw no ancient Java 5 versions nor was there any early Java 9 builds.

Java versions in use during 2013 – 2016

The picture looks more interesting if we look at the trends over the four years. Presenting the same data over the period from 2013 to 2016 where we have analyzed the same data, we see the following:

java market share between versions 2013 2016

The trends visible above expose the pace older Java versions are making room for new. Java 5 remains dead and Java 6 deployment base shrinks 2x each year. It is also clear that Java 7 deployment base has peaked and is now in decline, giving room for Java 8 to take over.

JVM vendors in 2016

Next analysis opens up the different JVM vendors in regards of deployment market share. If you wonder about the concept then – Java declares a standard any vendor can decide to implement when building a Java Virtual Machine. In theory we should thus have a multitude of different JVM vendors, but in practice we have the following:
JVM vendors openjdk hotspot

No matter how you would interpret the data, the conclusion is the same: there are just two JVMs out there, Hotspot and OpenJDK. The promise of Java spec with multiple vendors does not really hold and we have the choice of between the Hotspot and OpenJDK.

The “Other” category consisted of five different JVMs vendors, each represented by less than five JVMs in the dataset. These vendors included Oracle JRockit, IBM J9, SAP Java Server VM, Zing and DCEVM.

If you found the data interesting, you are likely to enjoy our next week post about Java EE container statistics as well. To be notified on time, subscribe either to our Twitter or RSS feed.



Thanks for continuing this. It is VERY useful for me as a developer.


The OpenJDK JVM is Hotspot. There is really only one JVM – Hotspot!



B. Traversat

You are correct to the extent that the commercial Oracle JVM is more or less a superset of OpenJDK. Calling these two JVM flavors equal is however not correct. I do agree that our naming is somewhat ambiguous.

The irony is that this is what the JVMs identify themselves via system property. Asking this property from different JVMs will result in “Java HotSpot(TM) 64-Bit Server VM” and “OpenJDK Server VM” being reported as the JVM name.

But this asides, what is the real industry name for these different JVMs? Oracle JVM and Open JVM? As weird as it is, I can not really find the definitive answer …

Ivo Mägi

As of java 8 the vm is essentially the same between openjdk and oracle java. The hotspot compiler is present in openjdk as well and both jdks follow the same versioning and release schedule. However, there are a lot of different variants of openjdk based on who packaged it, built it and tested the resulting package. Zulu is a niche player here that does some good work packaging and certifying OpenJdk, whereas your mileage may vary with different linux vendors and the amount of testing they do on their builds of openjdk, and in some cases the modifications they make to openjdk. This is a big reason for people preferring Oracle JDK for deployment.

Jilles van Gurp