Most popular Java environments

February 27, 2013 by Vladimir Šor

We have now been discovering leaks for more than a year with Plumbr. Throughout this time we have gathered anonymous statistics from the free Plumbr installations out there. And as we are good guys, we decided to share our discoveries with you.

The post is going to be the first in the forthcoming series. We start with the environments used: if you are interested which is the most popular JVM vendor or JVM version, whether 32bit is more popular architecture than 64bit or whether Windows 8 is more popular than Windows XP – this will all be covered in our post. In the next series we are analyzing the application server market shares and different configuration settings on the JVMs.

The data we analyzed originates from 1,024 different environments we have collected during the past six months. On some metrics we are missing subset of those – on those circumstances the report just did not contain this information. The data was reported by the System.getProperty() calls parametrized with os.arch, os.version, java.version, etc.

But let us start. First stop – machine architecture. And first surprises along the way with 508 machines reporting themselves as being based on amd64. Have we missed something and has AMD pushed Intel off the throne? But apparently this is the architecture for example all the 64-bit Linux boxes report independent of who actually shipped the chipset. So we cannot really distinguish between AMD64 and EM64T (as Intel named its 64-bit counterpart). Indeed we can just say that 63% of the platforms used are running on 64-bit and 37% on 32-bit x86 architectures. And that we had two SPARC environments correlating nicely to the SPARC diminishing market share …

Platform architectures

Next comes the operating system. First in an aggregated format demonstrating that out of the reported OS, 60% are different Windows boxes (actually, nine different flavours of them) , 25% were Linux distros and 15% were running on Mac OS X. Plus two SunOS installations.

OS vendors

Now, lets take a more detailed look into the Windows versions which should definitely give some food for thought:

Windows versions

Apparently at least in the engineering world the Windows 7 has quickly gained the ground and claiming 70% of all the Windows installations out there. But Windows 8 has not yet picked up the pace with only ten installations in our sample. As opposed to the 12-year old XP which still refuses to let go of its 13% in Windows installation base. The archeologists among us also have a reason to cheer – indeed you can spot a Windows NT installation still going strong.

Next stop drags us a bit closer to the Java world. Namely – JVM vendors. And we can see that the long-gone Sun is still going strong. As opposed to the another forgotten JVM vendor BEA Systems. But lets look at the numbers and try to understand what is actually happening.

JVM vendors

So first of all, why on earth is 56% of the environments running on Sun JVM? After all, it’s now three years since Oracle acquisition. But looking into details of actual JVM versions we see the answer. Namely – the java.vendor parameter was not changed until the JDK 1.6.0_21 release. So every JVM released until that point is still hoping that the Sun Microsystems is doing just well. As we see from the later statistics then – all the JVM’s released before the mid 2010 are still labeling themselves as Sun’s. But the other end of the spectrum is also interesting. We have 12% of Apple JVMs which are no longer even supported – you can only download Cupertino – vendored JDK until the JDK 6 latest releases, but starting from the JDK 7 you are limited to Redwood. And we had just four BEA jRockit and six IBM JVM environments. With jRockit merged into Hotspot it is understandable. But the IBM or actually the lack of IBM definitely gives us a food for thought.

Next we have the JVM versions lined up. Again surprises in a form which makes us consider dropping JDK 1.5 support at all:

JVM versions

Mere 1% of JDK 1.5 users. And all the effort we have thrown in to support it in Plumbr. Kinda makes me want to cry. But what is also interesting is the pace at which companies are switching to JDK 1.7. 29% of the user base is already on JDK 7. 70% still on JDK 6. And we have a brave early adopter on a JDK 8 development build.

But what is also interesting is a look into the different Java 6 updates used.

Java 6 updates

The part I find intriguing here is that out of 685 Java 6 configurations nearly half are more than a year old releases (pre 1.6.0_30). Are you aware that the number of security bugs fixed since then is larger than 100? And the whopping 11% of the JDK 6 users are stuck on a pre-2010 release. I do get it that on a large enterprise major upgrade such as migrating from JDK 6 to JDK 7 takes time. But why are you making the things hard for yourself by running on a JDK released in 2007?

From the aforementioned data I guess it is fair that we have an archetype for the most typical Java runtime environment used. It is an outdated Java 1.6 Hotspot build running on a 64-bit Windows 7 machine.

Take this archetype with a grain of salt though – this “most typical configuration” is still used only in 10.3% of the cases. Which, if put differently – if you support only the most common stack you end up losing 90% of your potential users. So you still have to keep supporting your complex testing infrastructure.

If you read the post until this point, then you should consider following us on Twitter to be notified on our next posts in the same series about application server and JVM configuration statistics.

Can't figure out what causes your OutOfMemoryError? Read more

ADD COMMENT

COMMENTS

OpenJDK comes in where ? under Oracle?

Neil S

Yes, OpenJDK reports “Oracle Corporation” as its vendor

iNikem

Great stats & surprised to see java stack fare well on windows

Vinod Shintre

Can't figure out what causes your OutOfMemoryError? Read more

Latest
Recommended
You cannot predict the way you die
When debugging a situation where systems are failing due to the lack of resources, you can no longer count on anything. Seemingly unrelated changes can trigger completely different messages and control flows within the JVM. Read more
Tuning GC - it does not have to be that hard
Solving GC pauses is a complex task. If you do not believe our words, check out the recent LinkedIn experience in garbage collection optimization. It is a complex and tedious task, so we are glad to report we have a whole lot simpler solution in mind Read more
Building a nirvana
We have invested a lot into our continuous integration / delivery infrastructure. As of now we can say that the Jenkins-orchestrated gang consisting of Ansible, Vagrant, Gradle, LiveRebel and TestNG is something an engineer can call a nirvana. Read more
Creative way to handle OutOfMemoryError
Wish to spend a day troubleshooting? Or make enemies among sysops? Registering pkill java to OutOfMemoryError events is one darn good way to achieve those goals. Read more