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

[David Holmes]

Hi Serguei,

On 9/05/2019 8:57 am, 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.

This all seems reasonable (though I'm no expert on working with XSL etc).

One thing I am unclear of is why you bother with using VERSION_INTERIM 
when the actual version check will only consider VERSION_FEATURE (aka 
major). Couldn't you just leave the "minor" part 0 the same as the 
"micro" part?

For the record I considered whether this needs a CSR request and 
concluded it did not as it doesn't involve changing any actual 
specifications.

Thanks,
David

> 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