JNI and JVM TI version numbers

[Magnus Ihse Bursie]

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