[a-zA-Z0-9]+))?";
---
>     private static final String PRE      = "(?:-(?[a-zA-Z0-9]+))?";

$ diff Basic.java~ Basic.java
88a89
>       tryCatch("9:-ea", IAE);

> You might also want to update the class' Javadoc regexes to be consistent 
> with the code (i.e. the same changes as you're planning to do in the JEP 
> in JDK-8148822):

JDK-8148822 covers the javadoc.  I've updated the bug's description to make
this more clear.  I need a different bugid to submit a new CCC.  (The one
for this bug has already been approved.)

I don't need a bug to update the JEP.

Thanks,
iris

-----Original Message-----
From: Anthony Vanelverdinghe [mailto:anthony.vanelverdinghe at gmail.com] 
Sent: Tuesday, February 02, 2016 3:31 AM
To: Iris Clark; verona-dev at openjdk.java.net
Subject: Re: RFR: 8072379: Implement jdk.Version and jdk.OracleVersion

Hi Iris

There's a typo at the start of PRE (line 168), where "(:?" should be "(?:", which causes "9:-ea" to be parsed successfully.

You might also want to update the class' Javadoc regexes to be consistent with the code (i.e. the same changes as you're planning to do in the JEP in JDK-8148822):
on line 48, ^[1-9][0-9]*((\.0)*\.[1-9][0-9]*)*$ instead of ^[1-9][0-9]*(((\.0)*\.[1-9][0-9]*)*)*$
on line 130, [-a-zA-Z0-9.] instead of [-a-zA-Z0-9\.]

Kind regards,
Anthony

On 2/02/2016 6:51, iris.clark at oracle.com (Iris Clark) wrote:
> Hi, Hong.
>
> Thanks again for looking closely at the regular expression and 
> providing comments.
>
>> - The outer most quantifier in (((\.0)*\.[1-9][0-9]*)*)* is redundant
>>    and a source of catastrophic backtracking. You only need
>>    ((\.0)*\.[1-9][0-9]*)*.
>> - The outside - in PRE part (\-([a-zA-Z0-9]+))? doesn't need escaping.
>>    Simplify it to (-([a-zA-Z0-9]+))?
> Both done.
>
>> - Do you want to allow only a plus without the number in the BUILD
> ?   part? Why do you capture the +? ((\+)(0|[1-9][0-9]*)?)?
>
> I need to capture the plus to distinguish between cases where an empty 
> build is allowed (e.g. "9+-foo") and when it is not ("9+").
> See code in Version.java, line 226-230 and in Basic.java, line 98, 
> 107-109.  (Note that we use the empty "+" to distinguish "9-foo" from
> "9+-foo".)
>
>> - Dot loses meaning in the character class, and hyphen loses meaning 
>> at the beginning or at the end of the character class. You can 
>> simplify the OPT part to (-([-a-zA-Z0-9.]+))?
> Done.
>
>> - You might want to consider using named-capturing groups instead of 
>> numbered capturing groups.  Also, consider using non-capturing groups 
>> for groups you don't need to extract.
> Done.
>
> This is the (hopefully) final version of the webrev and javadoc for 
> the initial implementation of this API:
>
>    http://cr.openjdk.java.net/~iris/verona/8072379/webrev.3/index.html
>    
> http://cr.openjdk.java.net/~iris/verona/8072379/doc.3/jdk/Version.html
>
> I've filed the following bug to update the spec:
>
>      8148822: (spec) Regex in jdk.Version and JEP 223 should match
>      https://bugs.openjdk.java.net/browse/JDK-8148822
>
> These are the corresponding changes to the JEP which I'll apply in the 
> next day or so:
>
> $ diff jep-open-mr11.md jep-open-mr12.md
> 84c84
> < `^[1-9][0-9]*(((\.0)*\.[1-9][0-9]*)*)*$`. The sequence may be of 
> arbitrary
> ---
>> `^[1-9][0-9]*((\.0)*\.[1-9][0-9]*)*$`. The sequence may be of 
>> arbitrary
> 166c166
> <   -  $OPT, matching `([-a-zA-Z0-9\.]+)` --- Additional
> ---
>>    -  $OPT, matching `([-a-zA-Z0-9.]+)` --- 
>> Additional
> Thanks again for the recommendations.
>
> Regards,
> iris
>
> -----Original Message-----
> From: Thanh Hong Dai [mailto:hdthanh at tma.com.vn]
> Sent: Wednesday, January 13, 2016 7:53 PM
> To: Iris Clark; Alan Bateman; core-libs-dev at openjdk.java.net; 
> verona-dev at openjdk.java.net
> Subject: RE: RFR: 8072379: Implement jdk.Version and jdk.OracleVersion
>
> Hi,
>
> Some comment on the regex (and also the JEP):
>
> ([1-9][0-9]*(((\.0)*\.[1-9][0-9]*)*)*)(\-([a-zA-Z0-9]+))?((\+)(0|[1-9][0-9]*)?)?(-([\-a-zA-Z0-9\.]+))?
>
> - The outer most quantifier in (((\.0)*\.[1-9][0-9]*)*)* is redundant and a source of catastrophic backtracking. You only need ((\.0)*\.[1-9][0-9]*)*.
> - The outside - in PRE part (\-([a-zA-Z0-9]+))? doesn't need escaping. Simplify it to (-([a-zA-Z0-9]+))?
> - Do you want to allow only a plus without the number in the BUILD part? Why do you capture the +? ((\+)(0|[1-9][0-9]*)?)?
> - Dot loses meaning in the character class, and hyphen loses meaning at the beginning or at the end of the character class. You can simplify the OPT part to (-([-a-zA-Z0-9.]+))?
> - You might want to consider using named-capturing groups instead of numbered capturing groups. Also, consider using non-capturing groups for groups you don't need to extract.
>
> Best regards,
> Hong Dai Thanh.
>
> -----Original Message-----
> From: core-libs-dev [mailto:core-libs-dev-bounces at openjdk.java.net] 
> On Behalf Of Iris Clark
> Sent: Thursday, 14 January, 2016 4:55 AM
> To: Alan Bateman ; core-libs-dev at 
> openjdk.java.net; verona-dev at openjdk.java.net
> Subject: RE: RFR: 8072379: Implement jdk.Version and jdk.OracleVersion
>
> Hi, Alan.
>
> Thanks for looking at this (hopefully) one last time.
>
>> It can't be java.base (see design principles in JEP 200).
>> If it's going into java.base temporarily then the top-level 
>> modules.xml will need to be updated to export the "jdk" package.
> This diff has been applied to modules.xml:
>
> diff -r 6fefc5bce180 modules.xml
> --- a/modules.xml       Wed Jan 13 13:56:19 2016 +0000
> +++ b/modules.xml       Wed Jan 13 13:46:56 2016 -0800
> @@ -205,6 +205,9 @@
>         javax.security.cert
>       
>       
> +      jdk
> +    
> +    
>         jdk.net
>       
>       
>
> It essentially reverts your 8049422 change [0] to that file. I will not re-add jdk to the javadoc bundle for javac trees API since that is not an appropriate location. I filed the following bug to track publication of jdk.Version:
>
>      8144069: Determine correct publication for jdk.Version API
>      https://bugs.openjdk.java.net/browse/JDK-8144069
>
> When this came up earlier, I filed this bug to track finding a more appropriate module for jdk.Version:
>
>      8144062: Determine appropriate module for jdk.Version
>      https://bugs.openjdk.java.net/browse/JDK-8144062
>
> Thanks,
> iris
>
> [0] http://hg.openjdk.java.net/jdk9/dev/rev/1bee5efa73e3
>
> -----Original Message-----
> From: Alan Bateman
> Sent: Tuesday, January 12, 2016 7:41 AM
> To: Iris Clark; core-libs-dev at openjdk.java.net; verona-dev at 
> openjdk.java.net
> Subject: Re: RFR: 8072379: Implement jdk.Version and jdk.OracleVersion
>
> On 11/01/2016 21:44, Iris Clark wrote:
>> Hi, Joe, Roger, Alan, Magnus, and Mandy.
>>
>> At the end of December (shortly before the Christmas/Winter break and 
>> my vacation), I provided responses to your messages and an updated
>> webrev:
>>
>>     http://cr.openjdk.java.net/~iris/verona/8072379/webrev.2/
>>
>> I didn't hear from anybody, so I'd like to optimistically assume that 
>> you were satisfied.  Is that correct?
>>
>> For you convenience, here's a reference to the December and November
>> threads:
>>
>>       
>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-December/03
>> 7
>> 062.html
>>       
>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-November/03
>> 6
>> 904.html
>>
>> I'd like to wrap up this work for the initial implementation of 
>> jdk.Version soon.
>>
> I think this looks good but we'll to decide which module to put this in.
> It can't be java.base (see design principles in JEP 200). If it's going into java.base temporarily then the top-level modules.xml will need to be updated to export the "jdk" package.
>
> -Alan
>
>

From iris.clark at oracle.com  Wed Feb  3 03:17:30 2016
From: iris.clark at oracle.com (Iris Clark)
Date: Tue, 2 Feb 2016 19:17:30 -0800 (PST)
Subject: RFR: 8072379: Implement jdk.Version and jdk.OracleVersion
In-Reply-To: <7ca276d8-5e4f-4da2-a1a9-999a0cac9f57@default>
References: <50765a19-34e4-4115-a32d-cea84c25394e@default>
	<38DD183B-1D89-4C6F-B759-3F4512656F77@oracle.com>
	<565628C5.1040905@oracle.com>
	<92b9301d-2418-4618-b877-b13c88216520@default>
	<7ca276d8-5e4f-4da2-a1a9-999a0cac9f57@default>
Message-ID: <2f3ec2a8-4488-4c21-ae79-01c4599d5121@default>

Hi, Mandy.

Thanks so much for pushing the changeset for the initial implementation
of jdk.Version!

Regards,
iris

-----Original Message-----
From: Iris Clark 
Sent: Monday, January 11, 2016 1:45 PM
To: Iris Clark; Joe Darcy; Mandy Chung; Magnus Ihse Bursie; Roger Riggs; Alan Bateman
Cc: core-libs-dev at openjdk.java.net; verona-dev at openjdk.java.net
Subject: RE: RFR: 8072379: Implement jdk.Version and jdk.OracleVersion

Hi, Joe, Roger, Alan, Magnus, and Mandy.

At the end of December (shortly before the Christmas/Winter break and my vacation), I provided responses to your messages and an updated webrev:

  http://cr.openjdk.java.net/~iris/verona/8072379/webrev.2/

I didn't hear from anybody, so I'd like to optimistically assume that you were satisfied.  Is that correct? 

For you convenience, here's a reference to the December and November
threads:

    http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-December/037062.html
    http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-November/036904.html

I'd like to wrap up this work for the initial implementation of jdk.Version soon.  

Regards,
iris

-----Original Message-----
From: Iris Clark
Sent: Friday, December 18, 2015 1:55 PM
To: Joe Darcy; Mandy Chung
Cc: core-libs-dev at openjdk.java.net; verona-dev at openjdk.java.net
Subject: RE: RFR: 8072379: Implement jdk.Version and jdk.OracleVersion

Hi, Joe.

Thanks for the review comments.

>>>     http://cr.openjdk.java.net/~irisa/verona/8072379/webrev.1/

> Is the intention that downstream JDK distributions, such as IcedTea, 
> whether based on OpenJDK or otherwise, would provide their own 
> specialization of the jdk.Version class?

No.  Downstream users may provide their own specialization, but there is no requirement that they must do so. 

jdk.OracleVersion has been removed.  The functionality it provided, access to the fourth element of the version number, is trivially accessed by existing methods in jdk.Version.

I've filed the following bug to address the more general use case:

    8145793:  Provide vendor-specific interpretation of a JDK version string
    https://bugs.openjdk.java.net/browse/JDK-8145793

> The equals / hashCode behavior of Version and OracleVersion is bit 
> surprising and I think somewhat underspecified given the possibility 
> of defining subclasses.

Given the above regarding downstream use, I've make jdk.Version final and the constructor is now private.  Oracle or any other JDK distribution wishing to impose additional semantics to the version string interpretation will need to do so via encapsulation rather than inheritance.

> How is this API supposed to behave if the component version strings 
> have a numerical value greater than Integer.MAX_VALUE?

>From the specification of the only instance method, Version.parse():

     * @throws  NumberFormatException 
     *          If an element of the version number or the build number cannot
     *          be represented as an {@link Integer}

> Was using Longs to record numerical versions rather than Integers 
> considered?

Yes.  In an informal poll conducted during implementation, it was thought that 2^32 bits would be more than sufficient to represent the components of typical version numbers.

An updated webrev is forthcoming.

Thanks,
iris

PS:  I believe that we are both out the week of 21 December, so I don't expect to hear back from you until the New Year.

From mandy.chung at oracle.com  Wed Feb  3 03:19:35 2016
From: mandy.chung at oracle.com (Mandy Chung)
Date: Tue, 2 Feb 2016 19:19:35 -0800
Subject: RFR: 8072379: Implement jdk.Version and jdk.OracleVersion
In-Reply-To: <2f3ec2a8-4488-4c21-ae79-01c4599d5121@default>
References: <50765a19-34e4-4115-a32d-cea84c25394e@default>
	<38DD183B-1D89-4C6F-B759-3F4512656F77@oracle.com>
	<565628C5.1040905@oracle.com>
	<92b9301d-2418-4618-b877-b13c88216520@default>
	<7ca276d8-5e4f-4da2-a1a9-999a0cac9f57@default>
	<2f3ec2a8-4488-4c21-ae79-01c4599d5121@default>
Message-ID: 

Sure thing.  Glad to see this going in.

Mandy

> On Feb 2, 2016, at 7:17 PM, Iris Clark  wrote:
> 
> Hi, Mandy.
> 
> Thanks so much for pushing the changeset for the initial implementation
> of jdk.Version!
> 
> Regards,
> iris
> 
> -----Original Message-----
> From: Iris Clark 
> Sent: Monday, January 11, 2016 1:45 PM
> To: Iris Clark; Joe Darcy; Mandy Chung; Magnus Ihse Bursie; Roger Riggs; Alan Bateman
> Cc: core-libs-dev at openjdk.java.net; verona-dev at openjdk.java.net
> Subject: RE: RFR: 8072379: Implement jdk.Version and jdk.OracleVersion
> 
> Hi, Joe, Roger, Alan, Magnus, and Mandy.
> 
> At the end of December (shortly before the Christmas/Winter break and my vacation), I provided responses to your messages and an updated webrev:
> 
>  http://cr.openjdk.java.net/~iris/verona/8072379/webrev.2/
> 
> I didn't hear from anybody, so I'd like to optimistically assume that you were satisfied.  Is that correct? 
> 
> For you convenience, here's a reference to the December and November
> threads:
> 
>    http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-December/037062.html
>    http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-November/036904.html
> 
> I'd like to wrap up this work for the initial implementation of jdk.Version soon.  
> 
> Regards,
> iris
> 
> -----Original Message-----
> From: Iris Clark
> Sent: Friday, December 18, 2015 1:55 PM
> To: Joe Darcy; Mandy Chung
> Cc: core-libs-dev at openjdk.java.net; verona-dev at openjdk.java.net
> Subject: RE: RFR: 8072379: Implement jdk.Version and jdk.OracleVersion
> 
> Hi, Joe.
> 
> Thanks for the review comments.
> 
>>>>    http://cr.openjdk.java.net/~irisa/verona/8072379/webrev.1/
> 
>> Is the intention that downstream JDK distributions, such as IcedTea, 
>> whether based on OpenJDK or otherwise, would provide their own 
>> specialization of the jdk.Version class?
> 
> No.  Downstream users may provide their own specialization, but there is no requirement that they must do so. 
> 
> jdk.OracleVersion has been removed.  The functionality it provided, access to the fourth element of the version number, is trivially accessed by existing methods in jdk.Version.
> 
> I've filed the following bug to address the more general use case:
> 
>    8145793:  Provide vendor-specific interpretation of a JDK version string
>    https://bugs.openjdk.java.net/browse/JDK-8145793
> 
>> The equals / hashCode behavior of Version and OracleVersion is bit 
>> surprising and I think somewhat underspecified given the possibility 
>> of defining subclasses.
> 
> Given the above regarding downstream use, I've make jdk.Version final and the constructor is now private.  Oracle or any other JDK distribution wishing to impose additional semantics to the version string interpretation will need to do so via encapsulation rather than inheritance.
> 
>> How is this API supposed to behave if the component version strings 
>> have a numerical value greater than Integer.MAX_VALUE?
> 
> From the specification of the only instance method, Version.parse():
> 
>     * @throws  NumberFormatException 
>     *          If an element of the version number or the build number cannot
>     *          be represented as an {@link Integer}
> 
>> Was using Longs to record numerical versions rather than Integers 
>> considered?
> 
> Yes.  In an informal poll conducted during implementation, it was thought that 2^32 bits would be more than sufficient to represent the components of typical version numbers.
> 
> An updated webrev is forthcoming.
> 
> Thanks,
> iris
> 
> PS:  I believe that we are both out the week of 21 December, so I don't expect to hear back from you until the New Year.

From Alan.Bateman at oracle.com  Wed Feb  3 08:52:51 2016
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 3 Feb 2016 08:52:51 +0000
Subject: RFR: 8072379: Implement jdk.Version and jdk.OracleVersion
In-Reply-To: <2f3ec2a8-4488-4c21-ae79-01c4599d5121@default>
References: <50765a19-34e4-4115-a32d-cea84c25394e@default>
	<38DD183B-1D89-4C6F-B759-3F4512656F77@oracle.com>
	<565628C5.1040905@oracle.com>
	<92b9301d-2418-4618-b877-b13c88216520@default>
	<7ca276d8-5e4f-4da2-a1a9-999a0cac9f57@default>
	<2f3ec2a8-4488-4c21-ae79-01c4599d5121@default>
Message-ID: <56B1BFE3.1010201@oracle.com>

On 03/02/2016 03:17, Iris Clark wrote:
> Hi, Mandy.
>
> Thanks so much for pushing the changeset for the initial implementation
> of jdk.Version!
>
Good to have this in but now we need to decide on where it should live. 
It's JDK-specific so we'll need it exported by a JDK module rather than 
java.base.

-Alan

From iris.clark at oracle.com  Wed Feb  3 17:48:57 2016
From: iris.clark at oracle.com (Iris Clark)
Date: Wed, 3 Feb 2016 09:48:57 -0800 (PST)
Subject: RFR: 8072379: Implement jdk.Version and jdk.OracleVersion
In-Reply-To: <56B1BFE3.1010201@oracle.com>
References: <50765a19-34e4-4115-a32d-cea84c25394e@default>
	<38DD183B-1D89-4C6F-B759-3F4512656F77@oracle.com>
	<565628C5.1040905@oracle.com>
	<92b9301d-2418-4618-b877-b13c88216520@default>
	<7ca276d8-5e4f-4da2-a1a9-999a0cac9f57@default>
	<2f3ec2a8-4488-4c21-ae79-01c4599d5121@default>
	<56B1BFE3.1010201@oracle.com>
Message-ID: 

Hi, Alan.

> Good to have this in but now we need to decide on where it 
> should live.  It's JDK-specific so we'll need it exported 
> by a JDK module rather than java.base.

8144062 was next on my list.

Do you have any suggestions for the module?  

Of the existing modules in the jdk repository, jdk.dev seems 
to have the most appropriate name.  It appears to only contain 
jimage so I'm not sure about that module's charter.  

Thanks,
iris

-----Original Message-----
From: Alan Bateman 
Sent: Wednesday, February 03, 2016 12:53 AM
To: Iris Clark; Mandy Chung
Cc: verona-dev at openjdk.java.net; core-libs-dev at openjdk.java.net
Subject: Re: RFR: 8072379: Implement jdk.Version and jdk.OracleVersion

On 03/02/2016 03:17, Iris Clark wrote:
> Hi, Mandy.
>
> Thanks so much for pushing the changeset for the initial 
> implementation of jdk.Version!
>
Good to have this in but now we need to decide on where it should live. 
It's JDK-specific so we'll need it exported by a JDK module rather than java.base.

-Alan

From goetz.lindenmaier at sap.com  Tue Feb  9 20:58:52 2016
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Tue, 9 Feb 2016 20:58:52 +0000
Subject: Version special case '9'
Message-ID: 

Hi,

could somebody please comment on this issue?

Thanks,
  Goetz

From: Lindenmaier, Goetz
Sent: Dienstag, 26. Januar 2016 17:13
To: hotspot-dev at openjdk.java.net; 'verona-dev at openjdk.java.net' 
Subject: Version special case '9'

Hi,

We appreciate the new version scheme introduced with JEP 223.
It simplifies the versioning and we agree that it is to it's best
downward compatible.

Unfortunately there is one exception to this.
The initial version of a new major release skips the minor and
security digits. This makes parsing the string unnecessarily
complicated, because the format is not predictable.

In this, the JEP also is inconsistent.
In chapter "Dropping the initial 1 element from version numbers"
it is argued that comparing "9.0.0" to "1.8.0" by digit will show that
9 is newer than 8. But there is no such version as 9.0.0.

This is stated in chapter "Version numbers": "The version number does
not include trailing zero elements; i.e., $SECURITY is omitted if it
has the value zero, and $MINOR is omitted if both $MINOR and $SECURITY
have the value zero."

Our BussinessObjects applications parse the option string
by Float.parseFloat(System.getProperty("java.version").substring(0,3))
This delivers 1.7 for Java 7, but currently crashes for jdk9, as it tries to
parse "9-i" from 9-internal.  With trailing .0.0, this would see 9.0 and
could parse the Java version until Java 99.

As a workaround for this, we are now configuring with --with-version-patch=1
which results in version string 9.0.0.1-internal.

At another place, we use split() to analyse the version.

if (Integer.parseInt(System.getProperty("java.version").split("\\.")[1]) > 7)) { ...

If there are always 3 numbers, this could be fixed to:

if (Integer.parseInt(System.getProperty("java.version").split("\\.")[0]) > 7) ||
    Integer.parseInt(System.getProperty("java.version").split("\\.")[1]) > 7)) { ...

which was probably in mind when the

But with omitting the .0.0, we must also split at '-' and '+':

String[] version_elements = System.getProperty("java.version").split("\\.|-|+");
if (Integer.parseInt(version_elements[0]) > 7) ||
    Integer.parseInt(version_elements[1]) > 7)) { ...

If you want to check for a version > 9.*.22 it's even more complicated:

String[] version_elements = System.getProperty("java.version").split("+|-")[0].split("\\.");
if (Integer.parseInt(version_elements[0]) > 9 ||
    (Integer.parseInt(version_elements[0]) == 9 &&
     version_elements.length >= 3 &&
     Integer.parseInt(version_elements[2]) >  22)) { ...

So we would appreciate if the JEP was enhanced to always guarantee three
version numbers 'x.y.z'.

Further, version number 9.0.0.1 breaks the jck test api/java_lang/System/index.html#GetProperty.
It fails with: "getJavaSpecVersion0001: Failed. System property 'java.specification.version' does not corresponds to the format 'major.minor.micro'".
Maybe a fix of this test is already worked on, we are using jck suite from 9.9.15.

Best regards,
  Goetz.

From iris.clark at oracle.com  Wed Feb 10 05:27:55 2016
From: iris.clark at oracle.com (Iris Clark)
Date: Tue, 9 Feb 2016 21:27:55 -0800 (PST)
Subject: Version special case '9'
In-Reply-To: <4295855A5C1DE049A61835A1887419CC41F20DD2@DEWDFEMB12A.global.corp.sap>
References: <4295855A5C1DE049A61835A1887419CC41F20DD2@DEWDFEMB12A.global.corp.sap>
Message-ID: 

Hi, Goetz.

Sorry for the delayed response.  I've been thinking about your situation.

I don't think that we can add back the trailing zeros.  The JEP inconsistency needs to be addressed.  The intent for the "Dropping the initial 1 element..." section is intended to describe a comparison algorithm, not guarantee the presence of trailing zeros.  This comparison has been implemented in jdk.Version.compareTo() which was pushed in this changeset (expected in jdk=9+105):

    http://hg.openjdk.java.net/jdk9/dev/jdk/rev/7adef1c3afd5

I haven't determined the feasibility of this quite yet, but I suspect that a reasonable solution to your version comparison problem for earlier releases such as 8u and 7u would be to add a similar implementation of jdk.Version.compareTo() to those releases.  Given the format of our previous release strings, this wouldn't be a straight backport of the JDK 9 jdk.Version, it would have to be a subset.  This would allow you to use the same methods on jdk.Version across a wider range of releases.  

Would that be helpful?

I haven't looked closely at the code, but I wonder whether the jck test has found a bug in the java.specification.version implementation?  Historically, the only time we increment that system property is as part of a JSR or a MR.  I've filed the following bug to investigate:

    8149519: Investigate implementation of java.specification.version
    https://bugs.openjdk.java.net/browse/JDK-8149519

Thanks,
iris

-----Original Message-----
From: Lindenmaier, Goetz [mailto:goetz.lindenmaier at sap.com] 
Sent: Tuesday, January 26, 2016 8:13 AM
To: hotspot-dev at openjdk.java.net; verona-dev at openjdk.java.net
Subject: Version special case '9'

Hi,

We appreciate the new version scheme introduced with JEP 223.
It simplifies the versioning and we agree that it is to it's best downward compatible.

Unfortunately there is one exception to this.
The initial version of a new major release skips the minor and security digits. This makes parsing the string unnecessarily complicated, because the format is not predictable.

In this, the JEP also is inconsistent.
In chapter "Dropping the initial 1 element from version numbers"
it is argued that comparing "9.0.0" to "1.8.0" by digit will show that
9 is newer than 8. But there is no such version as 9.0.0.

This is stated in chapter "Version numbers": "The version number does not include trailing zero elements; i.e., $SECURITY is omitted if it has the value zero, and $MINOR is omitted if both $MINOR and $SECURITY have the value zero."

Our BussinessObjects applications parse the option string by Float.parseFloat(System.getProperty("java.version").substring(0,3))
This delivers 1.7 for Java 7, but currently crashes for jdk9, as it tries to parse "9-i" from 9-internal.  With trailing .0.0, this would see 9.0 and could parse the Java version until Java 99.

As a workaround for this, we are now configuring with --with-version-patch=1 which results in version string 9.0.0.1-internal.

At another place, we use split() to analyse the version.

if (Integer.parseInt(System.getProperty("java.version").split("\\.")[1]) > 7)) { ...

If there are always 3 numbers, this could be fixed to:

if (Integer.parseInt(System.getProperty("java.version").split("\\.")[0]) > 7) ||
    Integer.parseInt(System.getProperty("java.version").split("\\.")[1]) > 7)) { ...

which was probably in mind when the

But with omitting the .0.0, we must also split at '-' and '+':

String[] version_elements = System.getProperty("java.version").split("\\.|-|+");
if (Integer.parseInt(version_elements[0]) > 7) ||
    Integer.parseInt(version_elements[1]) > 7)) { ...

If you want to check for a version > 9.*.22 it's even more complicated:

String[] version_elements = System.getProperty("java.version").split("+|-")[0].split("\\.");
if (Integer.parseInt(version_elements[0]) > 9 ||
    (Integer.parseInt(version_elements[0]) == 9 &&
     version_elements.length >= 3 &&
     Integer.parseInt(version_elements[2]) >  22)) { ...

So we would appreciate if the JEP was enhanced to always guarantee three version numbers 'x.y.z'.

Further, version number 9.0.0.1 breaks the jck test api/java_lang/System/index.html#GetProperty.
It fails with: "getJavaSpecVersion0001: Failed. System property 'java.specification.version' does not corresponds to the format 'major.minor.micro'".
Maybe a fix of this test is already worked on, we are using jck suite from 9.9.15.

Best regards,
  Goetz.

From goetz.lindenmaier at sap.com  Wed Feb 10 06:10:21 2016
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Wed, 10 Feb 2016 06:10:21 +0000
Subject: Version special case '9'
In-Reply-To: 
References: <4295855A5C1DE049A61835A1887419CC41F20DD2@DEWDFEMB12A.global.corp.sap>

Message-ID: <57a697ee95a243d1aed272c540131600@DEWDFE13DE09.global.corp.sap>

Hi Iris,

thanks for your response!

> such as 8u and 7u would be to add a similar implementation of

> jdk.Version.compareTo() to those releases.  Given the format of our

Hmm, it would be great if old software would run out-of-the box with

Jdk 9.  If you add some utility classes, one still has to change Java code

to use these new classes.  It's a bit more convenient, but the code still

has to be changed.

Skipping the .0.0 in the version really breaks _all_ old code.  So fixing that

would be most helpful.  And it would fix the inconsistency in the JEP text.

> I don't think that we can add back the trailing zeros.

Why not?  Java 9 is not yet released, is it?  When else would you

fix something like that?  Anyways, what is the reason for skipping

the two zeroes?

Thanks and best regards,

  Goetz.

> -----Original Message-----

> From: Iris Clark [mailto:iris.clark at oracle.com]

> Sent: Mittwoch, 10. Februar 2016 06:28

> To: Lindenmaier, Goetz ; hotspot-

> dev at openjdk.java.net; verona-dev at openjdk.java.net

> Subject: RE: Version special case '9'

>

> Hi, Goetz.

>

> Sorry for the delayed response.  I've been thinking about your situation.

>

> I don't think that we can add back the trailing zeros.  The JEP inconsistency

> needs to be addressed.  The intent for the "Dropping the initial 1 element..."

> section is intended to describe a comparison algorithm, not guarantee the

> presence of trailing zeros.  This comparison has been implemented in

> jdk.Version.compareTo() which was pushed in this changeset (expected in

> jdk=9+105):

>

>     http://hg.openjdk.java.net/jdk9/dev/jdk/rev/7adef1c3afd5

>

> I haven't determined the feasibility of this quite yet, but I suspect that a

> reasonable solution to your version comparison problem for earlier releases

> such as 8u and 7u would be to add a similar implementation of

> jdk.Version.compareTo() to those releases.  Given the format of our

> previous release strings, this wouldn't be a straight backport of the JDK 9

> jdk.Version, it would have to be a subset.  This would allow you to use the

> same methods on jdk.Version across a wider range of releases.

>

> Would that be helpful?

>

> I haven't looked closely at the code, but I wonder whether the jck test has

> found a bug in the java.specification.version implementation?  Historically,

> the only time we increment that system property is as part of a JSR or a MR.

> I've filed the following bug to investigate:

>

>     8149519: Investigate implementation of java.specification.version

>     https://bugs.openjdk.java.net/browse/JDK-8149519

>

> Thanks,

> iris

>

> -----Original Message-----

> From: Lindenmaier, Goetz [mailto:goetz.lindenmaier at sap.com]

> Sent: Tuesday, January 26, 2016 8:13 AM

> To: hotspot-dev at openjdk.java.net; verona-dev at openjdk.java.net

> Subject: Version special case '9'

>

> Hi,

>

> We appreciate the new version scheme introduced with JEP 223.

> It simplifies the versioning and we agree that it is to it's best downward

> compatible.

>

> Unfortunately there is one exception to this.

> The initial version of a new major release skips the minor and security digits.

> This makes parsing the string unnecessarily complicated, because the format

> is not predictable.

>

> In this, the JEP also is inconsistent.

> In chapter "Dropping the initial 1 element from version numbers"

> it is argued that comparing "9.0.0" to "1.8.0" by digit will show that

> 9 is newer than 8. But there is no such version as 9.0.0.

>

> This is stated in chapter "Version numbers": "The version number does not

> include trailing zero elements; i.e., $SECURITY is omitted if it has the value

> zero, and $MINOR is omitted if both $MINOR and $SECURITY have the value

> zero."

>

> Our BussinessObjects applications parse the option string by

> Float.parseFloat(System.getProperty("java.version").substring(0,3))

> This delivers 1.7 for Java 7, but currently crashes for jdk9, as it tries to parse

> "9-i" from 9-internal.  With trailing .0.0, this would see 9.0 and could parse the

> Java version until Java 99.

>

> As a workaround for this, we are now configuring with --with-version-

> patch=1 which results in version string 9.0.0.1-internal.

>

> At another place, we use split() to analyse the version.

>

> if (Integer.parseInt(System.getProperty("java.version").split("\\.")[1]) > 7)) {

> ...

>

> If there are always 3 numbers, this could be fixed to:

>

> if (Integer.parseInt(System.getProperty("java.version").split("\\.")[0]) > 7)

> ||

>     Integer.parseInt(System.getProperty("java.version").split("\\.")[1]) > 7)) {

> ...

>

> which was probably in mind when the

>

> But with omitting the .0.0, we must also split at '-' and '+':

>

> String[] version_elements = System.getProperty("java.version").split("\\.|-

> |+");

> if (Integer.parseInt(version_elements[0]) > 7) ||

>     Integer.parseInt(version_elements[1]) > 7)) { ...

>

> If you want to check for a version > 9.*.22 it's even more complicated:

>

> String[] version_elements = System.getProperty("java.version").split("+|-

> ")[0].split("\\.");

> if (Integer.parseInt(version_elements[0]) > 9 ||

>     (Integer.parseInt(version_elements[0]) == 9 &&

>      version_elements.length >= 3 &&

>      Integer.parseInt(version_elements[2]) >  22)) { ...

>

> So we would appreciate if the JEP was enhanced to always guarantee three

> version numbers 'x.y.z'.

>

> Further, version number 9.0.0.1 breaks the jck test

> api/java_lang/System/index.html#GetProperty.

> It fails with: "getJavaSpecVersion0001: Failed. System property

> 'java.specification.version' does not corresponds to the format

> 'major.minor.micro'".

> Maybe a fix of this test is already worked on, we are using jck suite from

> 9.9.15.

>

> Best regards,

>   Goetz.

From iris.clark at oracle.com  Thu Feb 11 17:13:14 2016
From: iris.clark at oracle.com (Iris Clark)
Date: Thu, 11 Feb 2016 09:13:14 -0800 (PST)
Subject: RFR: 8149601 Update references from "1.9" to "9"
Message-ID: <808e959b-aa71-4eec-a056-cb6e08f6d251@default>

Hi.

Please review the following changes to the jaxp and jdk 
repositories to fix a few additional references to "1.9".

Bug

  8149601 Update references from "1.9" to "9"
  https://bugs.openjdk.java.net/browse/JDK-8149601

Webrev

  http://cr.openjdk.java.net/~iris/verona/8149601/webrev/

This is a follow-up to JDK-8136494 which changed "@since 1.9" 
to "@since 9" matching java.specification.version.

Thanks,
iris

From chris.hegarty at oracle.com  Thu Feb 11 17:35:54 2016
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Thu, 11 Feb 2016 17:35:54 +0000
Subject: RFR: 8149601 Update references from "1.9" to "9"
In-Reply-To: <808e959b-aa71-4eec-a056-cb6e08f6d251@default>
References: <808e959b-aa71-4eec-a056-cb6e08f6d251@default>
Message-ID: 

On 11 Feb 2016, at 17:13, Iris Clark  wrote:

> Hi.
> 
> Please review the following changes to the jaxp and jdk 
> repositories to fix a few additional references to "1.9".
> 
> Bug
> 
>  8149601 Update references from "1.9" to "9"
>  https://bugs.openjdk.java.net/browse/JDK-8149601
> 
> Webrev
> 
>  http://cr.openjdk.java.net/~iris/verona/8149601/webrev/

Looks fine.

-Chris.

From iris.clark at oracle.com  Thu Feb 11 19:06:40 2016
From: iris.clark at oracle.com (Iris Clark)
Date: Thu, 11 Feb 2016 11:06:40 -0800 (PST)
Subject: RFR: 8149601 Update references from "1.9" to "9"
In-Reply-To: <808e959b-aa71-4eec-a056-cb6e08f6d251@default>
References: <808e959b-aa71-4eec-a056-cb6e08f6d251@default>
Message-ID: <1191cdc7-6751-425b-b430-4a6d86c809e1@default>

Hi.

A private review comment as noted that I missed a few files in the jaxp repository.

The webrev has been updated in place.

Thanks,
iris

-----Original Message-----
From: Iris Clark 
Sent: Thursday, February 11, 2016 9:13 AM
To: core-libs-dev at openjdk.java.net; verona-dev at openjdk.java.net
Cc: Iris Clark; Kumar Srinivasan
Subject: RFR: 8149601 Update references from "1.9" to "9"

Hi.

Please review the following changes to the jaxp and jdk repositories to fix a few additional references to "1.9".

Bug

  8149601 Update references from "1.9" to "9"
  https://bugs.openjdk.java.net/browse/JDK-8149601

Webrev

  http://cr.openjdk.java.net/~iris/verona/8149601/webrev/

This is a follow-up to JDK-8136494 which changed "@since 1.9" 
to "@since 9" matching java.specification.version.

Thanks,
iris

From iris.clark at oracle.com  Thu Feb 11 19:07:43 2016
From: iris.clark at oracle.com (Iris Clark)
Date: Thu, 11 Feb 2016 11:07:43 -0800 (PST)
Subject: RFR: 8149601 Update references from "1.9" to "9"
In-Reply-To: 
References: <808e959b-aa71-4eec-a056-cb6e08f6d251@default>

Message-ID: 

Hi, Chris.

>>  http://cr.openjdk.java.net/~iris/verona/8149601/webrev/
>
> Looks fine.

Thanks for the Review.

Regards,
Iris

From huizhe.wang at oracle.com  Thu Feb 11 19:17:24 2016
From: huizhe.wang at oracle.com (huizhe wang)
Date: Thu, 11 Feb 2016 11:17:24 -0800
Subject: RFR: 8149601 Update references from "1.9" to "9"
In-Reply-To: <1191cdc7-6751-425b-b430-4a6d86c809e1@default>
References: <808e959b-aa71-4eec-a056-cb6e08f6d251@default>
	<1191cdc7-6751-425b-b430-4a6d86c809e1@default>
Message-ID: <56BCDE44.9040700@oracle.com>

Hi Iris,

The change looks good.

Two of the previously included classes appeared twice in the webrev 
index page :-)

Thanks,
Joe

On 2/11/2016 11:06 AM, Iris Clark wrote:
> Hi.
>
> A private review comment as noted that I missed a few files in the jaxp repository.
>
> The webrev has been updated in place.
>
> Thanks,
> iris
>
> -----Original Message-----
> From: Iris Clark
> Sent: Thursday, February 11, 2016 9:13 AM
> To: core-libs-dev at openjdk.java.net; verona-dev at openjdk.java.net
> Cc: Iris Clark; Kumar Srinivasan
> Subject: RFR: 8149601 Update references from "1.9" to "9"
>
> Hi.
>
> Please review the following changes to the jaxp and jdk repositories to fix a few additional references to "1.9".
>
> Bug
>
>    8149601 Update references from "1.9" to "9"
>    https://bugs.openjdk.java.net/browse/JDK-8149601
>
> Webrev
>
>    http://cr.openjdk.java.net/~iris/verona/8149601/webrev/
>
> This is a follow-up to JDK-8136494 which changed "@since 1.9"
> to "@since 9" matching java.specification.version.
>
> Thanks,
> iris

From iris.clark at oracle.com  Fri Feb 12 17:57:57 2016
From: iris.clark at oracle.com (Iris Clark)
Date: Fri, 12 Feb 2016 09:57:57 -0800 (PST)
Subject: RFR: 8149601 Update references from "1.9" to "9"
In-Reply-To: <56BCDE44.9040700@oracle.com>
References: <808e959b-aa71-4eec-a056-cb6e08f6d251@default>
	<1191cdc7-6751-425b-b430-4a6d86c809e1@default>
	<56BCDE44.9040700@oracle.com>
Message-ID: <9f2996c9-d7a3-41e2-8dea-fd6a875b0006@default>

Hi, Joe.

Thanks for the review.

Regards,
iris

-----Original Message-----
From: huizhe wang 
Sent: Thursday, February 11, 2016 11:17 AM
To: Iris Clark
Cc: core-libs-dev at openjdk.java.net; verona-dev at openjdk.java.net
Subject: Re: RFR: 8149601 Update references from "1.9" to "9"

Hi Iris,

The change looks good.

Two of the previously included classes appeared twice in the webrev index page :-)

Thanks,
Joe

On 2/11/2016 11:06 AM, Iris Clark wrote:
> Hi.
>
> A private review comment as noted that I missed a few files in the jaxp repository.
>
> The webrev has been updated in place.
>
> Thanks,
> iris
>
> -----Original Message-----
> From: Iris Clark
> Sent: Thursday, February 11, 2016 9:13 AM
> To: core-libs-dev at openjdk.java.net; verona-dev at openjdk.java.net
> Cc: Iris Clark; Kumar Srinivasan
> Subject: RFR: 8149601 Update references from "1.9" to "9"
>
> Hi.
>
> Please review the following changes to the jaxp and jdk repositories to fix a few additional references to "1.9".
>
> Bug
>
>    8149601 Update references from "1.9" to "9"
>    https://bugs.openjdk.java.net/browse/JDK-8149601
>
> Webrev
>
>    http://cr.openjdk.java.net/~iris/verona/8149601/webrev/
>
> This is a follow-up to JDK-8136494 which changed "@since 1.9"
> to "@since 9" matching java.specification.version.
>
> Thanks,
> iris

From iris.clark at oracle.com  Fri Feb 12 21:47:36 2016
From: iris.clark at oracle.com (Iris Clark)
Date: Fri, 12 Feb 2016 13:47:36 -0800 (PST)
Subject: RFR: 8149601 Update references from "1.9" to "9"
In-Reply-To: <808e959b-aa71-4eec-a056-cb6e08f6d251@default>
References: <808e959b-aa71-4eec-a056-cb6e08f6d251@default>
Message-ID: <81dd015c-6738-496e-9bee-79811d3f8fbc@default>

Hi, Kumar.

Thank you so much for pushing changesets to fix this bug.

Regards,
iris

-----Original Message-----
From: Iris Clark 
Sent: Thursday, February 11, 2016 9:13 AM
To: core-libs-dev at openjdk.java.net; verona-dev at openjdk.java.net
Cc: Iris Clark; Kumar Srinivasan
Subject: RFR: 8149601 Update references from "1.9" to "9"

Hi.

Please review the following changes to the jaxp and jdk repositories to fix a few additional references to "1.9".

Bug

  8149601 Update references from "1.9" to "9"
  https://bugs.openjdk.java.net/browse/JDK-8149601

Webrev

  http://cr.openjdk.java.net/~iris/verona/8149601/webrev/

This is a follow-up to JDK-8136494 which changed "@since 1.9" 
to "@since 9" matching java.specification.version.

Thanks,
iris

From iris.clark at oracle.com  Thu Feb 25 05:59:20 2016
From: iris.clark at oracle.com (Iris Clark)
Date: Wed, 24 Feb 2016 21:59:20 -0800 (PST)
Subject: RFR: 8144062: Determine appropriate module for jdk.Version
In-Reply-To: 
References: <50765a19-34e4-4115-a32d-cea84c25394e@default>
	<38DD183B-1D89-4C6F-B759-3F4512656F77@oracle.com>
	<565628C5.1040905@oracle.com>
	<92b9301d-2418-4618-b877-b13c88216520@default>
	<7ca276d8-5e4f-4da2-a1a9-999a0cac9f57@default>
	<2f3ec2a8-4488-4c21-ae79-01c4599d5121@default>
	<56B1BFE3.1010201@oracle.com>

Message-ID: <86a4690e-7a83-4bc4-9c3a-9d617475f3bb@default>

Hi, Alan, Mandy, and Mark.

After exploring a few module options (jdk.Version, jdk.dev [0]), 
it looks like the best choice is to move jdk.Version to 
java.lang.Runtime.Version (a nested class of Runtime).  It supports 
the values returned by the java.{vm.}?version and 
java.{vm.}?specification.version system properties.  By making 
Version an SE API, it may be exported by the java.base module.

Please review the following changes to move jdk.Version to 
jdk.lang.Runtime.Version.  Note that beyond the package name and
class declaration (to static), the only other changes in Version
are related to indentation.

Bug

    8144062: Determine appropriate module for jdk.Version
    https://bugs.openjdk.java.net/browse/JDK-8144062

webrev

    http://cr.openjdk.java.net/~iris/verona/8144062/webrev.0/

Additionally, the following changes to JEP 223 [1] (modulo indentation)
will be made:

252,253c252,253
< A simple JDK-specific Java API to parse, validate, and compare version
< strings will be defined:
---
> A simple Java API to parse, validate, and compare version strings will be
> defined as a nested class of Runtime:
255c255
<     package jdk;
---
>     package java.lang;
258a259
>     public class Runtime {
283a285
>     }
309a312,315
>
> The existing specification for the above properties in
> `System.getProperties()` will be modified to indicate that the return values
> for these properties may be interpreted as a `java.lang.Runtime.Version`.

Thanks,
Iris

[0] jdk.dev renamed to jdk.jlink in jigsaw/jake.
[1] http://openjdk.java.net/jeps/223

From Alan.Bateman at oracle.com  Thu Feb 25 08:06:43 2016
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 25 Feb 2016 08:06:43 +0000
Subject: RFR: 8144062: Determine appropriate module for jdk.Version
In-Reply-To: <86a4690e-7a83-4bc4-9c3a-9d617475f3bb@default>
References: <50765a19-34e4-4115-a32d-cea84c25394e@default>
	<38DD183B-1D89-4C6F-B759-3F4512656F77@oracle.com>
	<565628C5.1040905@oracle.com>
	<92b9301d-2418-4618-b877-b13c88216520@default>
	<7ca276d8-5e4f-4da2-a1a9-999a0cac9f57@default>
	<2f3ec2a8-4488-4c21-ae79-01c4599d5121@default>
	<56B1BFE3.1010201@oracle.com>

	<86a4690e-7a83-4bc4-9c3a-9d617475f3bb@default>
Message-ID: <56CEB613.8060207@oracle.com>

On 25/02/2016 05:59, Iris Clark wrote:
> Hi, Alan, Mandy, and Mark.
>
> After exploring a few module options (jdk.Version, jdk.dev [0]),
> it looks like the best choice is to move jdk.Version to
> java.lang.Runtime.Version (a nested class of Runtime).  It supports
> the values returned by the java.{vm.}?version and
> java.{vm.}?specification.version system properties.  By making
> Version an SE API, it may be exported by the java.base module.
>
> Please review the following changes to move jdk.Version to
> jdk.lang.Runtime.Version.  Note that beyond the package name and
> class declaration (to static), the only other changes in Version
> are related to indentation.
>
This looks good. We should probably change the synopsis on the JIRA 
issue to make it clearer that it is promoting Version to a standard API.

Once this is in then the multi-release JAR file patch can be updated to 
make use of this.

-Alan.

From paul.sandoz at oracle.com  Thu Feb 25 09:14:43 2016
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Thu, 25 Feb 2016 10:14:43 +0100
Subject: RFR: 8144062: Determine appropriate module for jdk.Version
In-Reply-To: <56CEB613.8060207@oracle.com>
References: <50765a19-34e4-4115-a32d-cea84c25394e@default>
	<38DD183B-1D89-4C6F-B759-3F4512656F77@oracle.com>
	<565628C5.1040905@oracle.com>
	<92b9301d-2418-4618-b877-b13c88216520@default>
	<7ca276d8-5e4f-4da2-a1a9-999a0cac9f57@default>
	<2f3ec2a8-4488-4c21-ae79-01c4599d5121@default>
	<56B1BFE3.1010201@oracle.com>

	<86a4690e-7a83-4bc4-9c3a-9d617475f3bb@default>
	<56CEB613.8060207@oracle.com>
Message-ID: 

> On 25 Feb 2016, at 09:06, Alan Bateman  wrote:
> 
> On 25/02/2016 05:59, Iris Clark wrote:
>> Hi, Alan, Mandy, and Mark.
>> 
>> After exploring a few module options (jdk.Version, jdk.dev [0]),
>> it looks like the best choice is to move jdk.Version to
>> java.lang.Runtime.Version (a nested class of Runtime).  It supports
>> the values returned by the java.{vm.}?version and
>> java.{vm.}?specification.version system properties.  By making
>> Version an SE API, it may be exported by the java.base module.
>> 
>> Please review the following changes to move jdk.Version to
>> jdk.lang.Runtime.Version.  Note that beyond the package name and
>> class declaration (to static), the only other changes in Version
>> are related to indentation.
>> 
> This looks good. We should probably change the synopsis on the JIRA issue to make it clearer that it is promoting Version to a standard API.
> 

Dunno if the following was discussed for the review of internal impl.

I think it would be better to internally maintain an int[] for the version numbers rather than List, that is more efficient in terms of space and comparing/equality (you can even use the new array comparison methods, thus the compareVersion becomes a one-liner).

It?s ok to take the hit for returning List a simple AbstractList wrapper (also implementing RandomAccess) will suffice [*].

> Once this is in then the multi-release JAR file patch can be updated to make use of this.
> 

And since this will now be part of SE it might be possible to revisit (as a follow on issue) the definition and use of the JarFile.Release enum by MR-JARs.

Paul.

[*]
public List version() {
    class VersionList extends AbstractList implements RandomAccess {
        @Override
        public Integer get(int index) {
            return version[index];
        }

        @Override
        public int size() {
            return version.length;
        }
    }
    return new VersionList();
}

From mandy.chung at oracle.com  Thu Feb 25 18:49:48 2016
From: mandy.chung at oracle.com (Mandy Chung)
Date: Thu, 25 Feb 2016 10:49:48 -0800
Subject: RFR: 8144062: Determine appropriate module for jdk.Version
In-Reply-To: <86a4690e-7a83-4bc4-9c3a-9d617475f3bb@default>
References: <50765a19-34e4-4115-a32d-cea84c25394e@default>
	<38DD183B-1D89-4C6F-B759-3F4512656F77@oracle.com>
	<565628C5.1040905@oracle.com>
	<92b9301d-2418-4618-b877-b13c88216520@default>
	<7ca276d8-5e4f-4da2-a1a9-999a0cac9f57@default>
	<2f3ec2a8-4488-4c21-ae79-01c4599d5121@default>
	<56B1BFE3.1010201@oracle.com>

	<86a4690e-7a83-4bc4-9c3a-9d617475f3bb@default>
Message-ID: 

> On Feb 24, 2016, at 9:59 PM, Iris Clark  wrote:
> 
> Hi, Alan, Mandy, and Mark.
> 
> After exploring a few module options (jdk.Version, jdk.dev [0]), 
> it looks like the best choice is to move jdk.Version to 
> java.lang.Runtime.Version (a nested class of Runtime).  It supports 
> the values returned by the java.{vm.}?version and 
> java.{vm.}?specification.version system properties.  By making 
> Version an SE API, it may be exported by the java.base module.
> 
> Please review the following changes to move jdk.Version to 
> jdk.lang.Runtime.Version.  Note that beyond the package name and
> class declaration (to static), the only other changes in Version
> are related to indentation.
> 
> Bug
> 
>    8144062: Determine appropriate module for jdk.Version
>    https://bugs.openjdk.java.net/browse/JDK-8144062
> 
> webrev
> 
>    http://cr.openjdk.java.net/~iris/verona/8144062/webrev.0/

942      * A representation of the JDK version-string

version string for the runtime instead of JDK

One suggestion is to move the details about fourth and later elements to @implSpec or @implNote.

Have you considered moving the static Version::current method to Runtime::version?

Mandy