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-...@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
