By charliebrown on Nov 17, 2008
I have been doing some extensive performance testing with recent JDK's and HotSpot versions, (more on the details of this performance activity in a latter blog entry). Notice I make a distinction between JDK version and HotSpot version? You may have observed when you do a "java -version" on a recent JDK / JRE you see a "Java" version such as "build 1.6.0_10-b33" and a "Java HotSpot" version such as "build 11.0-b15". The distinction here is really the integration of a Java SE class library build with an underlying HotSpot JVM build which makes a JDK/JRE distribution and the underlying HotSpot JVM version. In other words, in the following output from "java -version", a JDK class library build and HotSpot JVM build is integrated together into a JDK version called 1.6.0_10, which happens to be build 33 of that integration. The underlying HotSpot JVM build version in this 1.6.0_10 build 33, is HotSpot version 11, build 15.
$ java -version
java version "1.6.0_10"
Java(TM) Platform, Standard Edition for Business (build 1.6.0_10-b33)
Java HotSpot(TM) Server VM (build 11.0-b15, mixed mode)
If you have explored OpenJDK, you may have noticed the Java SE class libraries and HotSpot JVM sources reside in two distinct areas. The Java SE class libraries source code reside in the "jdk" area and HotSpot source code resides in the "hotspot" area. Each area can be built independent of each other.
The HotSpot version from "java -version" tells us the version of the underlying HotSpot JVM. It is probably not very obvious outside Java SE engineering there is a rather clear distinction and separation between what is known as the Java SE class library and underlying HotSpot JVM. Yet to the outside world most everyone looks at the JDK or JRE as a single entity rather than two distinct components assembled together to comprise a JDK / JRE, (there are other components too such as CORBA which can also be built independently).