On 2015-12-28 13:03, Alan Bateman wrote:
Has there been any discussion in Project Verona about the native
interfaces? I don't see anything in JEP 223 on this topic.
I have not seen it being discussed either. I believe it just haven't
occurred to anyone that there was yet another place were the version
number was hiding.
I think it is very reasonable to align JNI and JVMTI version numbering
to Verona standard. This is, after all, our one chance to get all
versioning to a sane and consistent standard.
/Magnus
In Project Jigsaw / JPMS then we need to update both JNI and the JVM
Tool Interface for modules. Traditionally then whoever does the first
update in a major release has the pleasure of rev'ing the version
number and it looks like we're "it" this time.
The JNI version is currently JNI_VERSION_1_8 (0x00010008). This is the
version number that GetVersion returns, it's the highest version
number that can be specified to JNI_CreateJavaVM, and the highest
version that can be returned by a library's JNI_OnLoad implementation.
Any concerns with moving to JNI_VERSION_9 (0x00090000)? Clearly code
calling GetVersion and treating the value as a pair of 16-bit values
may be surprised by a minor version number of 0 but this seems not too
different to the compatibility issues with changing the values of the
java.version or java.specification.version properties.
Is rev'ing the JNI version something that JEP 223 should document?
JVM TI is less obvious. Historically it hasn't been tied to the Java
SE version (I think this was to allow for implementations on J2ME
profiles). The version number is currently 1.2.3, defined as:
JVMTI_VERSION = 0x30000000 + (1 * 0x10000) + (2 * 0x100) + 3 /*
version: 1.2.3 */
0x30000000 serves as a base value to separate it from JNI version
numbers. This is needed because JVM TI environments are obtained via
the JNI GetEnv function.
JVM TI defines a GetVersion function to return the JVM TI version. It
also defines shift and mask values to aid extracting the major, minor
and micro versions. If we moved to 0x30000000 + (9 * 0x10000) then
these would continue to work, it just might be a surprise to agents
that expect the major number to be 1 and/or the minor number to be >=
some value.
Any thoughts on the JVM TI version? Dropping the major version as
proposed by JEP 223 seems like the opportunity to do this one time
change and get the JVM TI version number aligned. On the other hand,
it's not important and shouldn't be an issue to continue its existing
version scheme.
-Alan
