EVALUATION
The JDK has a native interface that the VM calls at startup to get the version, that was added in 1.6/6.0. In versions before that once the libraries are initialized, the VM gets the version through checking known classes that exist in the JDK.
void *lib_handle = os::native_java_library();
jdk_version_info_fn_t func = CAST_TO_FN_PTR(jdk_version_info_fn_t,
os::dll_lookup(lib_handle, "JDK_GetVersionInfo0"));
In the case of error handling, this is relatively safe. Using the same mechanism that the launcher use to print out : java -version initializes the class /sun/misc/Version and calls the print function. This seems less safe both to add to startup time (for performance and in the case of an unstable VM) and can't be called at error printing time.
The JDK_Version information that we have has less information than the java -version but I think it should be used instead. Eg:
ruger% java -version
java version "1.6.0_06-p"
Java(TM) SE Runtime Environment (build 1.6.0_06-p-b04)
Java HotSpot(TM) Server VM (build 13.0-b03, mixed mode)
vs.
ruger% gamma Queens
# To suppress the following error report, specify this argument
# after -XX: or in .hotspotrc: SuppressErrorAt=/interpreterRuntime.cpp:79
#
# A fatal error has been detected by the Java Runtime Environment:
#
# Internal Error
<made up assertion>
#
# JRE version: 6.0_06-b04
# Java VM: Java HotSpot(TM) Client VM (14.0-b09-6689685_1208_1554-jvmg mixed mode solaris-x86 )
# An error report file with more information is saved as:
# /net/philli/scratch1/coleenp/hg/6689685/make/solaris/solaris_i486_compiler1/jvmg/hs_err_pid8483.log
...
|