JDK-8087203 : Adapt Version.java.template to the JEP-223 new version string format
  • Type: Sub-task
  • Component: core-libs
  • Affected Version: 9-repo-verona
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2015-06-11
  • Updated: 2015-12-01
  • Resolved: 2015-09-17
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 9
9Fixed
Related Reports
Duplicate :  
JDK-8087202 - Add support for PATCH field and remove unused fields of new version string
Description
This is a follow-up fix for issues pointed out in the code review for JDK-8085822. Since that changeset went into verona/stage, the problems pointed out by the code review should be resolved in verona/stage before pushing to mainline.

Alan Bateman:
Version.java.template - the comment in jvmSecurityVersion() still talks about 1.6 and newer. Can this be replaced to just say that it returns the security version?

Daniel D. Daugherty:
jdk/src/java.base/share/classes/sun/misc/Version.java.template
    L149:      * Returns the security version of the running JVM if it's 1.6 or newer
        This JavaDoc update is wrong, but it might not be important
        if sun.misc.Version class is going away. 

David Holmes:
jdk/src/java.base/share/classes/sun/misc/Version.java.template
  This comment is nonsensical:
      /**
!      * Returns the security version of the running JVM if it's 1.6 or newer
       * or any RE VM build. It will return 0 if it's an internal 1.5 or
       * 1.4.x build.
       * @since 1.6
       */
  as security version does not exist pre 9. Normally you should be adding a new method and deprecating the old one. The new one is @since 9.

     /**
!      * Returns the security version of the running JDK.
       * @since 1.6
       */
  Ditto: @since 9 (but again old should be deprecated and new method added)

 253     /**
 254      * Returns the build number of the running JDK if it's a RE build
 255      * It will return 0 if it's an internal build.
  As with jvm.h this seems obsolete commentary these days - not only RE builds define a build number.
Comments
Regarding the *UpdateVersion() methods. I agree, with Alejandro's earlier comment from a few days ago. They should just be removed. This is an unsupported API. There is no evidence that it is used outside of the JDK. It will almost certainly be unavailable once Jigsaw modules are enabled.
14-09-2015
I'm going to use this to modify the @tags for the security methods in the java.template class
14-09-2015
The bug description lists five concerns by various reviewers. Four out of the five comments deal with the new security version methods, which still claim they are @since 1.6, when it's new in JDK9. Also, the most important issue was raised by David Holmes. This is not just about the javadoc tag. The proper way to handle this would be to deprecate the old jvmMicroVersion() and jdkMicroVersion() (which indeed *were* @since 1.6) and give proper recognition to jvmSecurityVersion() and jdkSecurityVersion() as new methods (which are @since 9). Neither of this has been addressed in JDK-8087202.
11-09-2015
The same concern made by several people does not convert that to "several concerns". That description needs some factorization. Having said that, yes, the security related javadocs comments should be fixed to say from 9. I read the concerns, but didn't double check the code (I thought it had been done). My bad. Regarding the important issue, not sure how you can deprecate the micro version related methods if the value for that does not exist anymore. what would you return? So don't think it makes sense to deprecate, but I might be wrong.
10-09-2015
I believe the changes to address those concerns were integrated with jdk-8087202, and those were also reviewed by the above reviewers. Which specific concerns were left out?
09-09-2015
JDK-8087202 did not address all of the concerns of the code reviewers.
04-09-2015
The fix for this bug was included in the fix for 8087202
03-09-2015
I will cleanup these as part of the hotspot follow up changes (see 8087202)
15-06-2015
Also note that currently the two copies of jvm.h in hotspot/src/share/vm/prims/jvm.h and jdk/src/java.base/share/native/include/jvm.h has drifted apart. They should be identical, which means that either one (or both) of them must be updated.
11-06-2015