From iris.clark at oracle.com  Wed Jun  1 20:23:33 2016
From: iris.clark at oracle.com (Iris Clark)
Date: Wed, 1 Jun 2016 13:23:33 -0700 (PDT)
Subject: Verona spec: Update "API" section to reflect changes in 8072379 and
	8144062
Message-ID: <833ee4a4-e78b-476b-a4b5-2c7c433cef6a@default>

Hi.

The "API" section of the JEP should be aligned with the implementation
of the jdk.Version API (8072379) and subsequent changes to move it to
java.lang.Runtime.Version (8144062).

The attached diffs will be applied to the JEP shortly.

Thanks,
Iris

-----
253c253
< strings will be defined:
---
> strings will be defined ([8072379][8072379], [8144062][8144062]):
255c255,258
<     package jdk;
---
> [8072379]: https://bugs.openjdk.java.net/browse/JDK-8072379
> [8144062]: https://bugs.openjdk.java.net/browse/JDK-8144062
>
>     package java.lang;
259,261c262,268
<     public class Version
<         implements Comparable<Version>
<     {
---
>     public class Runtime {
>
>         public static Version version();
>
>         public static class Version
>             implements Comparable<Version>
>         {
263c270,271
<         public static Version parse(String);
---
>             public static Version parse(String);
>             public static Version current();
265,267c273,275
<         public int major();
<         public int minor();
<         public int security();
---
>             public int major();
>             public int minor();
>             public int security();
269,272c277,280
<         public List<Integer> version();
<         public Optional<String> pre();
<         public Optional<Integer> build();
<         public Optional<String> optional();
---
>             public List<Integer> version();
>             public Optional<String> pre();
>             public Optional<Integer> build();
>             public Optional<String> optional();
274,275c282,283
<         public int compareTo(Version o);
<         public int compareToIgnoreOpt(Version o);
---
>             public int compareTo(Version o);
>             public int compareToIgnoreOpt(Version o);
277,278c285,286
<         public boolean equals(Object o);
<         public boolean equalsIgnoreOpt(Object o);
---
>             public boolean equals(Object o);
>             public boolean equalsIgnoreOpt(Object o);
280,281c288,290
<         public String toString();
<         public int hashCode();
---
>             public String toString();
>             public int hashCode();
>         }

From iris.clark at oracle.com  Wed Jun  1 21:18:58 2016
From: iris.clark at oracle.com (Iris Clark)
Date: Wed, 1 Jun 2016 14:18:58 -0700 (PDT)
Subject: Verona spec: Update "Version numbers" and "Version string" sections
Message-ID: <c62ff3eb-f3e5-4c67-9dde-273999c3a9c7@default>

Hi.

The "Version numbers" and "Version string" sections of the JEP should be
aligned with the specification of java.lang.Runtime.Version (8144062). And the original jdk.Version specification (8072379).  Changes include the following:

    - Eliminate use of "JDK" when describing a Java SE API
    - Clarifications related to zeros (trailing vs. internal components),
      Comparisons, and the definition of short version strings
    - Small typographical and grammatical enhancements

The attached diffs will be applied to the JEP shortly.

Thanks,
Iris

-----
4c4
< Revise the JDK's version-string scheme so that it is easier to
---
> Revise the Java SE Platform's version-string scheme so that it is easier to
81,86c81,89
< A _version number_, `$VNUM`, is a non-empty sequence of non-negative integer
< numerals, without leading or trailing zeroes, separated by period characters
< (U+002E); _i.e._, it matches the regular expression
< `^[1-9][0-9]*(((\.0)*\.[1-9][0-9]*)*)*$`. The sequence may be of arbitrary
< length but the first three elements are assigned specific meanings, as
< follows:
---
> A _version number_, `$VNUM`, is a non-empty sequence of elements separated
> by period characters (U+002E).  An element is either zero, or an unsigned
> integer numeral without leading zeros.  The final element in a version
> number must not be zero.  The format is:
>
>     ^[1-9][0-9]*(((\.0)*\.[1-9][0-9]*)*)*$
>
> The sequence may be of arbitrary length but the first three elements are
> assigned specific meanings, as follows:
97c100,101
<     was `8`; the `$MAJOR` version number of JDK&nbsp;9 will be `9`.
---
>     is `8`; the `$MAJOR` version number of JDK&nbsp;9 is `9`.  When
>     `$MAJOR` is incremented, all subsequent elements are removed.
107,108c111
<     collectors, and ports to new hardware architectures.  `$MINOR` is
<     reset to zero when `$MAJOR` is incremented.
---
>     collectors, and ports to new hardware architectures.
114,115c117,118
<     those necessary to improve security.  `$SECURITY` is reset to zero
<     **only** when `$MAJOR` is incremented.  A higher value of `$SECURITY`
---
>     those necessary to improve security.  `$SECURITY` is **not** reset to
>     zero when `$MINOR` is incremented.  A higher value of `$SECURITY`
131,133c134,137
< `9.10.0`.  If one sequence is shorter than another then the missing
< elements of the shorter sequence are considered to be zero; _e.g._,
< `9.1.2` is equal to `9.1.2.0` but less than `9.1.2.1`.
---
> `9.10.3`.  If one sequence is shorter than another then the missing
> elements of the shorter sequence are considered to be less than the
> corresponding elements of the longer sequence; _e.g._, `9.1.2` is less than
> `9.1.2.1`.
138,140c142,144
< A _version string_ `$VSTR` consists of a version number `$VNUM`, as described
< above, optionally followed by pre-release and build information, in the
< format
---
> A _version string_, `$VSTR`, consists of a version number `$VNUM`, as
> described above, optionally followed by pre-release and build information,
> in the format
142c146
<     $VNUM(-$PRE)?(\+$BUILD)?(-$OPT)?
---
>     $VNUM(-$PRE)?(\+($BUILD)?(-$OPT)?)?
155c159,160
<     Numeric identifiers have lower precedence than non-numeric identifiers.
---
>     Numeric identifiers are considered to be less than non-numeric
>     identifiers.
170,171c175,182
<     When comparing two version strings the value of `$OPT`, if present,
<     is always ignored.
---
>     When comparing two version strings the value of `$OPT`, if present, may
>     or may not be significant depending on the chosen comparison method.
>
> A version number `10-ea` matches `$VNUM = "10"` and `$PRE = "ea"`.  The
> version number `10+-ea` matches `$VNUM = "10"` and `$OPT = "ea"`.
>
> A _short version string_, (`$SVSTR`), often useful in less formal contexts,
> is a version number optionally followed by a pre-release identifier:
173,174c184
< A _short version string_ (`$SVSTR`), often useful in less formal contexts, is
simply
< `$VNUM` optionally ended with `-$PRE`.
---
>     $VNUM(-$PRE)?

From volker.simonis at gmail.com  Tue Jun 28 15:29:33 2016
From: volker.simonis at gmail.com (Volker Simonis)
Date: Tue, 28 Jun 2016 17:29:33 +0200
Subject: RFR(XXS): 8149519: Investigate implementation of
	java.specification.version
In-Reply-To: <b50fdaa4-7522-4d69-823c-b4a8b5fe6ba9@default>
References: <CA+3eh11sHh_zntW7A=wLdTpc+PURedLuKL5mvCMnwS1nqcf4Ug@mail.gmail.com>
	<CA+3eh11YnmDSQ+-eeCD-GZM5XEW1srSWF5NSgxEe9Msn=1-A5g@mail.gmail.com>
	<ba4f74ec-4fb4-4cd7-80e2-45af28d9dd3e@default>
	<CA+3eh10r0hr=ydwK0nqkHxxUDnYgqUxkA3RjD_b8fYRj_ddsyA@mail.gmail.com>
	<CA+3eh10ud2-wEn46Di_momsk67QwXC1Z8sPt+WvBpvw1R8du-A@mail.gmail.com>
	<b50fdaa4-7522-4d69-823c-b4a8b5fe6ba9@default>
Message-ID: <CA+3eh11Ht3aNM8ZsUsM0YDNHzrdv1MoT5HVgAwSdmWgMMEZaQg@mail.gmail.com>

Hi,

what about this bug?
It is still assigned to me and I would be happy to fix it as proposed in:

http://cr.openjdk.java.net/~simonis/webrevs/2016/8149519
https://bugs.openjdk.java.net/browse/JDK-8149519

If anybody has better ideas I'm open to transfer the bug to him :)

But I still think this should be fixed before JDK 9 will be shipped.
It's simply not right if 'java.specification.version' equals to
'java.version'.

Regards,
Volker

On Thu, Apr 28, 2016 at 6:34 AM, Iris Clark <iris.clark at oracle.com> wrote:
> Hi, Volker.
>
> Sorry for the delay.
>
>> Ping - shouldn't we fix this issue before JDK 9 Feature Complete?
>
> Ideally, yes.  I am hoping to get this resolved in the next few weeks.
>
> My first priority for Verona is JDK-8144062 which moves jdk.Version into a standard API (Alan mentioned this bugid earlier in this thread).  That absolutely must be completed before Feature Complete next month.
>
> Thanks,
> iris
>
> -----Original Message-----
> From: Volker Simonis [mailto:volker.simonis at gmail.com]
> Sent: Wednesday, April 27, 2016 1:28 AM
> To: Iris Clark
> Cc: Java Core Libs; verona-dev at openjdk.java.net; Alex Buckley; Kumar Srinivasan; Marvin Ma
> Subject: Re: RFR(XXS): 8149519: Investigate implementation of java.specification.version
>
> Ping - shouldn't we fix this issue before JDK 9 Feature Complete?
>
> Could you please also comment on my remarks regarding the relation of
> java.lang.Package.getSpecificationVersion() to JEP and 223 and and my question why the Version class is not in a standard java package.
>
> Thank you and best regards,
> Volker
>
>
> On Thu, Apr 7, 2016 at 12:11 PM, Volker Simonis <volker.simonis at gmail.com> wrote:
>> On Wed, Apr 6, 2016 at 8:28 PM, Iris Clark <iris.clark at oracle.com> wrote:
>>> Hi, Volker.
>>>
>>> Sorry for the delay.  I agree that the old implementation isn't quite correct.  I can't see us potentially having a JCP MR for a security or patch release (9.0.0.X and 9.0.X respectively).
>>>
>>> I could see a MR for an very unusual minor release (9.X).  If we had an MR there's no guarantee that we'd need to change the java.specification.version system property.   However, in the event that we did need to change the java.specification.version, it should match that release's $MAJOR.$MINOR, even if it meant that we had a sequence of specification version numbers with gaps.
>>>
>>> As an example, let's say that JDK 9 is released via umbrella JSR with java.specification.value of "9".  The system property would remain at "9" for all releases regardless of type until we choose to have a MR.  Should that MR occur while we're working on minor release 9.3.X and there is a need to change the value of java.specification.value, it would become "9.3" and would remain so in every release until the next MR.
>>>
>>> While we haven't changed the system property recently, I think that we need to future-proof ourselves a little bit for MRs as described above.
>>>
>>> Assuming that we change the syntax of java.specification.version to
>>> $MAJOR.$MINOR (zeros truncated, value dependent on JCP) then we need
>>> to make a similar change to the syntax of
>>> java.vm.specification.version.  [ Note that in the current
>>> implementation, I believe that the values of
>>> java.specification.version and java.vm.specification.version are tied
>>> to each other. ]
>>>
>>> Changing the syntax of java{.vm}?specification.version requires a CCC which I will file once we have agreement on the necessary changes.
>>>
>>
>> Hi Iris,
>>
>> thanks for your comments. I don't think that using $MAJOR.$MINOR for
>> java.specification.version is a good solution. As far as I understand,
>> JEP 223 (i.e. the new version scheme) is an Oracle/OpenJDK
>> implementation detail. There is no JSR for this and it won't be
>> enforced trough a JCK/TCK test (please correct me if I'm wrong). The
>> new versioning schema references the JCP in that is says that the
>> $MAJOR number corresponds to the "Java SE Platform Specification"
>> number as specified by the JCP in the corresponding JSR. But not vice
>> versa - i.e. there's no JSR referencing JEP 223.
>>
>> JEP 223 also says that the $MINOR number will be increased if this is
>> mandated by a Maintenance Release of the relevant Platform
>> Specification (by the JCP). But as you correctly noticed, in reality,
>> $MINOR is expected to be increased frequently compared to the number
>> of Java SE Maintenance Releases (if there will be any at all). So if
>> the JCP should decide to publish a Maintenance Release, why should it
>> name if after the then actual $MINOR update release number of the
>> Oracle/OpenJDK. I think a natural choice for such a MR would be "9.1",
>> no difference at which update release version Oracle/OpenJDK will be
>> at that time.
>>
>> So I think it would be best to decouple java.specification.version
>> from the Java versioning schema. We can start with
>> java.specification.version == $MAJOR. If there should be a MR
>> sometimes in the future, we can just set java.specification.version to
>> the version number of that MR, whatever that will be. That's exactly
>> what this change is about.
>>
>> Regarding the value of java.vm.specification.version I'm not sure what
>> it actually means at all. Until Java 1.6,
>> java.vm.specification.version has always been "1.0", while
>> java.specification.version has changed from 1.4, to 1.5 and 1.6
>> (notice that java.specification.version has never been changed to
>> 1.4.2, it was 1.4 for Java 1.4.0 as well as for 1.4.2). Starting with
>> Java 7, java.vm.specification.version is the same like
>> java.specification.version (i.e. 1.7 and 1.8) but I'm not sure if that
>> is mandated by JCP and if it will be possible that these numbers will
>> diverge for a Java release. I.e. will it be possible to have a new
>> Java version (say Java 10) where the VM specification (and thus
>> java.vm.specification.version) will remain unchanged (say "9")? From
>> my understanding, that should be possible. Especially for a MR, it
>> seems highly probable to me that the java.specification.version will
>> be increased, but the VM specification (and thus
>> java.vm.specification.version) will remain unchanged.
>>
>> So again, I think we shouldn't tie java.vm.specification.version to
>> java.specification.version and simply start with
>> java.vm.specification.version == $MAJOR. The current implementation
>> already does this correctly. While the java.specification.version
>> property comes from VERSION_SPECIFICATION in
>> common/autoconf/spec.gmk.in and it is being set in
>> jdk/src/java.base/share/native/libjava/System.c the
>> java.vm.specification.version property is set being in
>> hotspot/src/share/vm/runtime/arguments.cpp directly to the major Java
>> version number. Because of this difference, there are currently no
>> problems with the java.vm.specification.version property caused by the
>> new versioning schema.
>>
>> As a side note: while I wrote all this down, I realized that we have
>> java.lang.Package.getSpecificationVersion() in the class library which
>> returns the specification version of a specific package. But this API
>> is not mentioned anywhere in JEP 223. Shouldn't the output of
>> java.lang.Package.getSpecificationVersion() be aligned with JEP 223
>> and java.vm.specification.version as well?
>>
>> And a final question. Why did we put jdk.Version into the jdk package?
>> As far as I know, jdk is not a standard Java package and thus not
>> enforced by the Java standard (please correct me if I'm wrong).
>> Shouldn't the Version class be in a standard Java package such that
>> it's implementation will be mandatory for all Java implementations?
>>
>> Regards,
>> Volker
>>
>>> Regards,
>>> Iris
>>>
>>> -----Original Message-----
>>> From: Volker Simonis [mailto:volker.simonis at gmail.com]
>>> Sent: Tuesday, April 05, 2016 10:26 AM
>>> To: Java Core Libs
>>> Cc: verona-dev at openjdk.java.net
>>> Subject: Re: RFR(XXS): 8149519: Investigate implementation of
>>> java.specification.version
>>>
>>> Hi,
>>>
>>> can somebody please review this trivial change?
>>>
>>> Regards,
>>> Volker
>>>
>>>
>>> On Mon, Apr 4, 2016 at 6:47 PM, Volker Simonis <volker.simonis at gmail.com> wrote:
>>>> Hi,
>>>>
>>>> can I please have a review for this small fix:
>>>>
>>>> http://cr.openjdk.java.net/~simonis/webrevs/2016/8149519
>>>> https://bugs.openjdk.java.net/browse/JDK-8149519
>>>>
>>>> Currently the value of the java.specification.version property comes
>>>> from VERSION_SPECIFICATION in common/autoconf/spec.gmk.in. It is
>>>> currently set to VERSION_NUMBER which is the same value which is
>>>> also used for the java.version property.
>>>>
>>>> This is a bad idea, because VERSION_NUMBER is a dot separated
>>>> sequence of numbers (e.g. 9.0.1) which is expected to change frequently (i.e.
>>>> for every build and/or update version). If we are configuring with
>>>> "--with-version-patch=1" for example, VERSION_NUMBER and
>>>> java.version will be "9.0.0.1". But it makes no sense that
>>>> VERSION_SPECIFICATION and java.specification.version have the same,
>>>> dotted value. And it breaks a lot of legacy applications which parse
>>>> java.specification.version as a float number. That code would still
>>>> work if java.specification.version would be a concrete number (e.g.
>>>> '9' or '10').
>>>>
>>>> I suggest to set VERSION_SPECIFICATION to VERSION_MAJOR in
>>>> common/autoconf/spec.gmk.in. This should be the "right value" until
>>>> we get a specification change during a major release which hasn't
>>>> happened for quite some time now.
>>>>
>>>> Regards,
>>>> Volker