RFR (S): 8219023: Investigate syncing JVMTI spec version with JDK version

[serguei.spitsyn at oracle.com]

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, serguei.spitsyn at oracle.com 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
>
>
>