JNI and JVM TI version numbers

[Daniel D. Daugherty]

I've heard rumblings about the need to make JVM/TI changes due to
JigSaw so it makes sense the change the JVM/TI version number at
the same time. As Alan mentioned, JVM/TI versions weren't tied
to JDK releases so changing the major version from '1' to '9'
could be done at this time if we feel that aligning the JVM/TI
version number with the new Verona scheme has some value.

IMHO, I don't think we need to match the new Verona scheme for
JVM/TI since it has historically been independent of JDK release
numbers.

As for JNI version numbers, I don't think we've been consistent
about setting the version number to match the current JDK release,
but when we do update it we try to match the current JDK release
that contains the motivating API change...

$ grep JNI_VERSION 1.[5678].0/latest/binaries/solaris-sparcv9/include/jni.h
1.5.0/latest/binaries/solaris-sparcv9/include/jni.h:#define 
JNI_VERSION_1_1 0x00010001
1.5.0/latest/binaries/solaris-sparcv9/include/jni.h:#define 
JNI_VERSION_1_2 0x00010002
1.5.0/latest/binaries/solaris-sparcv9/include/jni.h:#define 
JNI_VERSION_1_4 0x00010004

1.6.0/latest/binaries/solaris-sparcv9/include/jni.h:#define 
JNI_VERSION_1_1 0x00010001
1.6.0/latest/binaries/solaris-sparcv9/include/jni.h:#define 
JNI_VERSION_1_2 0x00010002
1.6.0/latest/binaries/solaris-sparcv9/include/jni.h:#define 
JNI_VERSION_1_4 0x00010004
1.6.0/latest/binaries/solaris-sparcv9/include/jni.h:#define 
JNI_VERSION_1_6 0x00010006

1.7.0/latest/binaries/solaris-sparcv9/include/jni.h:#define 
JNI_VERSION_1_1 0x00010001
1.7.0/latest/binaries/solaris-sparcv9/include/jni.h:#define 
JNI_VERSION_1_2 0x00010002
1.7.0/latest/binaries/solaris-sparcv9/include/jni.h:#define 
JNI_VERSION_1_4 0x00010004
1.7.0/latest/binaries/solaris-sparcv9/include/jni.h:#define 
JNI_VERSION_1_6 0x00010006

1.8.0/latest/binaries/solaris-sparcv9/include/jni.h:#define 
JNI_VERSION_1_1 0x00010001
1.8.0/latest/binaries/solaris-sparcv9/include/jni.h:#define 
JNI_VERSION_1_2 0x00010002
1.8.0/latest/binaries/solaris-sparcv9/include/jni.h:#define 
JNI_VERSION_1_4 0x00010004
1.8.0/latest/binaries/solaris-sparcv9/include/jni.h:#define 
JNI_VERSION_1_6 0x00010006
1.8.0/latest/binaries/solaris-sparcv9/include/jni.h:#define 
JNI_VERSION_1_8 0x00010008

Dan



On 1/5/16 4:34 PM, Iris Clark wrote:
> Hi, Alan.
>
> JNI and JVM TI version numbers weren’t considered.
>
> Updating the JNI version to drop the "1" similar to what we've done for other parts of the system seems like an obvious change we should make.
>
> I'll propose text for the JEP.  I assume that you'll handle the necessary code and other JNI spec updates for this change similar to the JDK 8 change in 8005716.
>
> I really like the idea of aligning the JVM TI version number, particularly since we need to update it anyway; however, I cannot properly judge the impact.  If it's no greater than what we've observed for the system properties, then we should do it now.
>
> If you and other JVM TI experts believe it is reasonable to update this version number, I'll take care of the JEP addition.  (It looks like it was changed to the present value in JDK 8 bug 8014135.)
>
> Thanks,
> iris
>
> -----Original Message-----
> From: Alan Bateman
> Sent: Monday, December 28, 2015 4:04 AM
> To: verona-dev at openjdk.java.net
> Cc: jigsaw-dev
> Subject: JNI and JVM TI version numbers
>
>
> Has there been any discussion in Project Verona about the native interfaces? I don't see anything in JEP 223 on this topic.
>
> 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