Hi Chris,
Thank you for the review!
Yes, it is fixed now:
----------System.out:(27/1669)----------
vmOpts: ''
javaOpts: ''
JVM version:13-internal
JDI version: 13.0
JVM description: Java Debug Interface (Reference Implementation) version
13.0
Java Debug Wire Protocol (Reference Implementation) version 13.0
JVM Debug Interface version 13.0
JVM version 13-internal (Java HotSpot(TM) 64-Bit Server VM, mixed mode,
sharing)
Howdy!
Visible variables at this point are:
I think, it is Okay to print JVM version as it is now (13-internal).
Thanks,
Serguei
On 5/8/19 19:10, Chris Plummer wrote:
Hi Serguei,
Changes look good. Can you verify that the .jtr file for com/sun/jdi
tests has all the versions updated? For example, you will currently see:
JVM version:13-ea
JDI version: 11.0
JVM description: Java Debug Interface (Reference Implementation)
version 11.0
Java Debug Wire Protocol (Reference Implementation) version 11.0
JVM Debug Interface version 11.0
JVM version 13-ea (Java HotSpot(TM) 64-Bit Server VM, mixed mode,
sharing)
I think your intent is for all of these to be updated from 11 to 13.
thanks,
Chris
On 5/8/19 3:57 PM, [email protected] wrote:
Please, review a fix for the task:
https://bugs.openjdk.java.net/browse/JDK-8219023
Webrev:
http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8219023-svc-version.1/
Summary:
By design as we have never bumped the JVMTI version unless
there were spec changes for that release. Now we want to sync
the JVMTI version with the JDK version regardless of whether
or not spec changes have occurred in that release.
Also, we want it automatically set by the build system so that
no manual updates are needed for each release.
The jvmti.h and jvmti.html (JVMTI spec) are generated from
the jvmti.xsl with the XSLT scripts now. So, the fix removes
hard coded major, minor and micro versions from the jvmti.xml
and passes major and minor parameters with the -PARAMETER
to the XSL transformation.
Another part of the fix is in the JDI which starts using JDK
versions now instead of maintaining its own, and in the JDWP
agent which is using the JVMTI versions instead of its own.
Testing:
Generated docs and jvmti.h and checked the versions are correct.
One could ask if we have to use same or similar approach for
other API's and tools, like JNI, JMX and so on.
But these are not areas of my expertise or responsibility.
It just feels like there is some room for unification here.
Thanks,
Serguei
