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 …
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.
Now, lets take a more detailed look into the Windows versions which should definitely give some food for thought:
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.
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:
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.
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.
Bulletproof Java Code: A Practical Strategy for Developing Functional, Reliable, and Secure Java Code
Use Java? If you do, you know that Java software can be used to drive application logic of Web services or Web applications. Perhaps you use it for desktop applications? Or, embedded devices? Whatever your use of Java code, functional errors are the enemy!
To combat this enemy, your team might already perform functional testing. Even so, you're taking significant risks if you have not yet implemented a comprehensive team-wide quality management strategy. Such a strategy alleviates reliability, security, and performance problems to ensure that your code is free of functionality errors.Read this article to learn about this simple four-step strategy that is proven to make Java code more reliable, more secure, and easier to maintain.