RFR: JDK-8085822 JEP 223: New Version-String Scheme (initial integration)

[A. Sundararajan]

+1 on Nashorn changes.

-Sundar


On Monday 08 June 2015 06:07 PM, Magnus Ihse Bursie wrote:
>> 8 jun 2015 kl. 11:34 skrev Alan Bateman <Alan.Bateman at oracle.com>:
>>
>>> On 05/06/2015 15:07, Magnus Ihse Bursie wrote:
>>> This review request covers the main part of the work for JEP-223, the new version string format [1]. Basically, we'll call this release Java "9", instead of Java "1.9.0".
>>>
>>> This patch is a folding of all work that has been done so far in the branch JEP-223-branch in jdk9/sandbox. As you can see, it mostly covers build changes, with some code changes in hotspot, jdk, nashorn and langtools that either are corresponding changes in the product code due to the compiler define flags changing from the build, or follow-up changes to handle the new format.
>>>
>>> The JEP-223 work is not finished by this patch. In fact, there are known issues remaining even after this patch, typically by code that reads the "java.version" property and tries to parse it. However, this patch is not directly destined for jdk9/dev, but will go into the special verona/stage forest. As for all patches destined for verona/stage it will be code reviewed as if going to jdk9/dev. Once in verona/stage it will bide its time, and it will be complemented with follow-up patches to address remaining issues. When all such issues are resolved and JEP-223 is fully implemented, all changes will be pushed at once (without further code reviews) into jdk9/dev.
>>>
>>> This patch has been contributed by Magnus Ihse Bursie, Kumar Srinivasan and Alejandro Murillo.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8085822
>>> WebRev: http://cr.openjdk.java.net/~ihse/JDK-8085822-JEP-223-initial-patch/webrev.01
>> I looked through the code changes, skipping most of the make files :-)
>>
>> 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?
>>
>> Will the update_version and special_update_version fields eventually be dropped from the jvm_version_info stricture? Related, there seems to be a typo in the comment in jdk_util.c where it has "specia_update_version".
>>
>> The webrev shows a change to this comment in jvm.h:
>> "Third, this file contains various I/O and network operations needed by the standard Java I/O and network APIs."
>> I think this comment can be removed because those JVM_* functions were removed some time ago.
>>
>> Otherwise looks okay to me.
> The API functions in Version.java and jvm.h are not finished. The specification in the JEP talks about a java.util.Version, that I presume will replace the sun.misc.Version, and that will fully implement an API to access the version string and all it's parts, according to the JEP definition. Also, the native interface will have to be changed to accommodate a version number with an arbitrarily number of dot separated parts. These changes will be done later on in the verona/stage forest.
>
> Are you ok with addressing these concerns at such a later time?
>
> /Magnus
>
>> -Alan.