On 5/7/20 4:09 PM, Severin Gehwolf wrote:
> jvm_version_info.jvm_version currently holds this quadruplet:
>
> Most significant 8 bits => major version, followed by 8 bits => minor
> version, followed by 8 bits => micro version, followed by 8 bits =>
> build version. Note that JVM minor version represents the update
> version as passed in via configure and the micro version is currently
> not used (always 0). See vm_version.cpp lines 100-102 where only major,
> minor and build number are ever been set. Knowing this, we can still
> preserve the same behavior after patch by defining JVM_VERSION_MICRO to
> 0 for any version.
This is tricky. JVM_GetVersionInfo is a function exported by
libjvm.so, and the version is simply encoded as
unsigned int Abstract_VM_Version::jvm_version() {
return ((Abstract_VM_Version::vm_major_version() & 0xFF) << 24) |
((Abstract_VM_Version::vm_minor_version() & 0xFF) << 16) |
(Abstract_VM_Version::vm_build_number() & 0xFF);
}
I guess we could argue that this is for JVM-JDK internal use only, and
no-one else cares.
Or we could encode it in a different way such that at least we have a
jvm_version that is monotonically increasing, perhaps by (ab)using the
lower 8 bits of the version, the vm_build_number. But I guess I'm
being paranoid, and no tools are going to care about minor versions
anyway,even if they do call JVM_GetVersionInfo.
--
Andrew Haley (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
