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: [email protected]
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
