JNI and JVM TI version numbers

[Alan Bateman]

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 (0x0009)? 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 = 0x3000 + (1 * 0x1) + (2 * 0x100) + 3  /* 
version: 1.2.3 */


0x3000 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 0x3000 + (9 * 0x1) 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

hg: jigsaw/jake/jdk: Temporarily exclude tests broken by recent changes

[alan . bateman]

Changeset: aa701826525c
Author:alanb
Date:  2015-12-28 17:37 +
URL:   http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/aa701826525c

Temporarily exclude tests broken by recent changes

! test/ProblemList.jake.txt
! 
test/java/util/ResourceBundle/modules/visibility/src/exported.named.bundles/module-info.java

Re: Round #1: RFR: 8049365 - Update JDI and JDWP for modules

[serguei.spit...@oracle.com]

Alan,

Thank you for the review!

Just wanted to notify you that I'm officially on vacation this week as 
all US employees.

But I'm at home so that I can participate in the email discussions.
The next week I'm on vacation as well and will be out of town with 
limited access to the internet.


Please, see my comments below.


On 12/28/15 08:22, Alan Bateman wrote:

On 23/12/2015 06:24, serguei.spit...@oracle.com wrote:

Please, review this initial fix for the Jigsaw Bill milestone task:
https://bugs.openjdk.java.net/browse/JDK-8049365


Jdk webrev:
http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/jdk/8049365-Jigsaw-jdk.1/


Hotspot webrev:
http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8049365-Jigsaw-hs.1/


Summary:
  This round includes most of the changes suggested or discussed by 
Alan in the round #0:

- The version 1.9 is replaced version
- The Module interface is replaced with the ModuleReference 
interface that extends the ObjectReference.
- The argument name "target" in the CanRead is replaced with 
"source" to make it consistent with

   the class java.lang.reflect.Module.
- The public field TRACE_MODULES has been removed.
- Some other small changes.
   I hope, all comments are addressed. But, please, let me know 
if anything is missed.



  This round does not include the corresponding update of the SA-JDI.
  I'm suggesting to separate and postpone this part for now to speed 
up the main part.
  Another reason for it is that the SA-JDI update depends on possible 
VM changes.


  This round adds new capability "can_get_modules_info" that is 
appeared on all levels:

 JVMTI, JDWP and JDI.
No problem updating SA-JDI at a later time, we just need to make sure 
it builds without issues.


Good.
I'll open a task for that.



I looked through the updated webrevs and it looks quite good. A few 
comments:


It's not clear to me that a new JVM TI capability is required. I agree 
that JDWP and JDI need a canXXX command/method but if we rev JVM TI to 
version 9 then the VM supports modules and so a capability shouldn't 
be needed.


It would be nice to get rid of this JVM TI capability.
But my question is if new JVMTI functionality is mandatory for all VM's 
out there.






The JDWP command is currently "canGetModulesInfo", it might be better 
as "canGetModuleInfo". Ditto for the method on VirtualMachine.


Taken.
I was also thinking if this can be better..




The JDWP agent uses JNI to upcall to Module::getClassLoader and 
Module::canRead, we might consider adding JNI or JVM TI functions in 
the future and avoid this.


I was thinking about the same.
My preference would be to add new JVM TI functions.




VirtualMachine::allModules - there's a spurious  in the javadoc.


Will check and clean it up.




ModuleReference javadoc currently contains ".. has a read edge with 
the source ModuleReference". We'll need to do a bit of wordsmithing on 
the javadoc but for this one then starting out with " .. if the module 
reads the source module" would be clearer.


Taken.
Thank you for the correction.




InvalidModuleException - the copyright date says 1998 :-)


Strange.
I've already fixed that. :)



I see you have a basic test. The checkClassLoader method needs 
comments as it's not clear what it is testing. We'll need to add 
further tests to cover all the scenarios, the unnamed module case for 
example.


Yes, of course.
I'll try to enhance the test case.


Thanks!
Serguei




-Alan