From iris.clark at oracle.com  Fri May 13 23:20:23 2016
From: iris.clark at oracle.com (Iris Clark)
Date: Fri, 13 May 2016 16:20:23 -0700 (PDT)
Subject: RFR: 8144062: Move jdk.Version to java.lang.Runtime.Version
Message-ID: <bff10acf-1bc3-4439-a664-6b0fc439ff0d@default>

Hi.

Reviving this work from a few months back.

Please review the following changes to move jdk.Version to 
jdk.lang.Runtime.Version.

Bug

    8144062: Move jdk.Version to java.lang.Runtime.Version
    https://bugs.openjdk.java.net/browse/JDK-8144062

webrev

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

When jdk.Version was initially pushed in jdk-9+1-5, it was
Improperly exported by java.base.  After exploring a few
options, the best choice was to move jdk.Version to 
java.lang.Runtime.Version (a nested class of Runtime).  By 
making Version an SE API, it may be exported by the java.base 
module.

As part of the move, a limited number of chnages were 
made to the Version class:

  - Change package name and class declaration (to static)
  - Eliminate use of "JDK" when describing a Java SE API
  - Initial clarifications related to zeros (trailing vs.
    Internal components)
  - Small typographical and grammatical enhancements
  - Indentation

The complete Runtime.Version specification is available here:

  http://cr.openjdk.java.net/~iris/verona/8144062/doc.1/java/lang/Runtime.Version.html

The old jdk.Version.current() was replaced with
Runtime.version().

In System.getProperties(), we indicate which version-related
system properties may be supported by Runtime.Version.

The remaining jdk and langtools file changes are all 
side-effects of changing jdk.Version.current() to
Runtime.version().

Thanks,
Iris

From forax at univ-mlv.fr  Fri May 13 23:31:36 2016
From: forax at univ-mlv.fr (Remi Forax)
Date: Sat, 14 May 2016 01:31:36 +0200 (CEST)
Subject: RFR: 8144062: Move jdk.Version to java.lang.Runtime.Version
In-Reply-To: <bff10acf-1bc3-4439-a664-6b0fc439ff0d@default>
References: <bff10acf-1bc3-4439-a664-6b0fc439ff0d@default>
Message-ID: <1554585217.477366.1463182296059.JavaMail.zimbra@u-pem.fr>

Hi Iris,
is there a way to avoid to use regex when parsing the version ?

java.lang.Runtime.Version is used during the boot process, so now every Java programs loads a bunch of classes related to java.util.regex even if they do not use any regex or use another regex engine (like Nashorn or JRuby).

regards,
R?mi

----- Mail original -----
> De: "Iris Clark" <iris.clark at oracle.com>
> ?: "Java Core Libs" <core-libs-dev at openjdk.java.net>, compiler-dev at openjdk.java.net
> Cc: verona-dev at openjdk.java.net
> Envoy?: Samedi 14 Mai 2016 01:20:23
> Objet: RFR: 8144062: Move jdk.Version to java.lang.Runtime.Version
> 
> Hi.
> 
> Reviving this work from a few months back.
> 
> Please review the following changes to move jdk.Version to
> java.lang.Runtime.Version.
> 
> Bug
> 
>     8144062: Move jdk.Version to java.lang.Runtime.Version
>     https://bugs.openjdk.java.net/browse/JDK-8144062
> 
> webrev
> 
>     http://cr.openjdk.java.net/~iris/verona/8144062/webrev.1/
> 
> When jdk.Version was initially pushed in jdk-9+1-5, it was
> Improperly exported by java.base.  After exploring a few
> options, the best choice was to move jdk.Version to
> java.lang.Runtime.Version (a nested class of Runtime).  By
> making Version an SE API, it may be exported by the java.base
> module.
> 
> As part of the move, a limited number of chnages were
> made to the Version class:
> 
>   - Change package name and class declaration (to static)
>   - Eliminate use of "JDK" when describing a Java SE API
>   - Initial clarifications related to zeros (trailing vs.
>     Internal components)
>   - Small typographical and grammatical enhancements
>   - Indentation
> 
> The complete Runtime.Version specification is available here:
> 
>   http://cr.openjdk.java.net/~iris/verona/8144062/doc.1/java/lang/Runtime.Version.html
> 
> The old jdk.Version.current() was replaced with
> Runtime.version().
> 
> In System.getProperties(), we indicate which version-related
> system properties may be supported by Runtime.Version.
> 
> The remaining jdk and langtools file changes are all
> side-effects of changing jdk.Version.current() to
> Runtime.version().
> 
> Thanks,
> Iris
> 

From iris.clark at oracle.com  Mon May 16 17:52:33 2016
From: iris.clark at oracle.com (Iris Clark)
Date: Mon, 16 May 2016 10:52:33 -0700 (PDT)
Subject: RFR: 8144062: Move jdk.Version to java.lang.Runtime.Version
In-Reply-To: <1554585217.477366.1463182296059.JavaMail.zimbra@u-pem.fr>
References: <bff10acf-1bc3-4439-a664-6b0fc439ff0d@default>
	<1554585217.477366.1463182296059.JavaMail.zimbra@u-pem.fr>
Message-ID: <abc61aac-e80a-467d-a4ae-6acf3b9a4383@default>

Hi, Remi.

Thanks for taking the time to review this change.

> java.lang.Runtime.Version is used during the boot process

I don?t think that Runtime.Version is used during boot because
I'm not seeing it loaded with a small test program invoked with
"java -verbose:class Hi".  In fact, I'm not seeing a difference
in the number of loaded classes between promoted build 118 and
my build for 8144062 (based on jdk9/dev).  See appended stats.

If my test program is in a JAR file, then more classes are
loaded including Runtime.Version; however the equivalent number
of classes are loaded before my changes too.

The performance problem identified by the following bug should
resolve this issue:

  8150678: JarFile stream() and entries(0 methods need performance
    enhancement
  https://bugs.openjdk.java.net/browse/JDK-8150678

Regards,
Iris

-----
$ cat Hi.java
public class Hi {
    public static void main(String ... args) {
        System.out.println("hi");
        System.exit(42);
    }
$ wc Hi.ver*
   501   2000  39758 Hi.verbose-118
   576   2300  45915 Hi.verbose-118-jar
   501   2000  39734 Hi.verbose-8144062
   576   2300  45905 Hi.verbose-8144062-jar
  2154   8600 171312 total

-----Original Message-----
From: Remi Forax [mailto:forax at univ-mlv.fr] 
Sent: Friday, May 13, 2016 4:32 PM
To: Iris Clark
Cc: Java Core Libs; compiler-dev at openjdk.java.net; verona-dev at openjdk.java.net
Subject: Re: RFR: 8144062: Move jdk.Version to java.lang.Runtime.Version

Hi Iris,
is there a way to avoid to use regex when parsing the version ?

java.lang.Runtime.Version is used during the boot process, so now every Java programs loads a bunch of classes related to java.util.regex even if they do not use any regex or use another regex engine (like Nashorn or JRuby).

regards,
R?mi

----- Mail original -----
> De: "Iris Clark" <iris.clark at oracle.com>
> ?: "Java Core Libs" <core-libs-dev at openjdk.java.net>, 
> compiler-dev at openjdk.java.net
> Cc: verona-dev at openjdk.java.net
> Envoy?: Samedi 14 Mai 2016 01:20:23
> Objet: RFR: 8144062: Move jdk.Version to java.lang.Runtime.Version
> 
> Hi.
> 
> Reviving this work from a few months back.
> 
> Please review the following changes to move jdk.Version to 
> java.lang.Runtime.Version.
> 
> Bug
> 
>     8144062: Move jdk.Version to java.lang.Runtime.Version
>     https://bugs.openjdk.java.net/browse/JDK-8144062
> 
> webrev
> 
>     http://cr.openjdk.java.net/~iris/verona/8144062/webrev.1/
> 
> When jdk.Version was initially pushed in jdk-9+1-5, it was Improperly 
> exported by java.base.  After exploring a few options, the best choice 
> was to move jdk.Version to java.lang.Runtime.Version (a nested class 
> of Runtime).  By making Version an SE API, it may be exported by the 
> java.base module.
> 
> As part of the move, a limited number of chnages were made to the 
> Version class:
> 
>   - Change package name and class declaration (to static)
>   - Eliminate use of "JDK" when describing a Java SE API
>   - Initial clarifications related to zeros (trailing vs.
>     Internal components)
>   - Small typographical and grammatical enhancements
>   - Indentation
> 
> The complete Runtime.Version specification is available here:
> 
>   
> http://cr.openjdk.java.net/~iris/verona/8144062/doc.1/java/lang/Runtim
> e.Version.html
> 
> The old jdk.Version.current() was replaced with Runtime.version().
> 
> In System.getProperties(), we indicate which version-related system 
> properties may be supported by Runtime.Version.
> 
> The remaining jdk and langtools file changes are all side-effects of 
> changing jdk.Version.current() to Runtime.version().
> 
> Thanks,
> Iris
> 

From forax at univ-mlv.fr  Mon May 16 18:38:03 2016
From: forax at univ-mlv.fr (forax at univ-mlv.fr)
Date: Mon, 16 May 2016 20:38:03 +0200 (CEST)
Subject: RFR: 8144062: Move jdk.Version to java.lang.Runtime.Version
In-Reply-To: <abc61aac-e80a-467d-a4ae-6acf3b9a4383@default>
References: <bff10acf-1bc3-4439-a664-6b0fc439ff0d@default>
	<1554585217.477366.1463182296059.JavaMail.zimbra@u-pem.fr>
	<abc61aac-e80a-467d-a4ae-6acf3b9a4383@default>
Message-ID: <103793588.142588.1463423883417.JavaMail.zimbra@u-pem.fr>

----- Mail original -----
> De: "Iris Clark" <iris.clark at oracle.com>
> ?: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "Java Core Libs" <core-libs-dev at openjdk.java.net>, compiler-dev at openjdk.java.net, verona-dev at openjdk.java.net
> Envoy?: Lundi 16 Mai 2016 19:52:33
> Objet: RE: RFR: 8144062: Move jdk.Version to java.lang.Runtime.Version
> 
> Hi, Remi.

Hi Iris,

> 
> Thanks for taking the time to review this change.
> 
> > java.lang.Runtime.Version is used during the boot process
> 
> I don?t think that Runtime.Version is used during boot because
> I'm not seeing it loaded with a small test program invoked with
> "java -verbose:class Hi".  In fact, I'm not seeing a difference
> in the number of loaded classes between promoted build 118 and
> my build for 8144062 (based on jdk9/dev).  See appended stats.
> 
> If my test program is in a JAR file, then more classes are
> loaded including Runtime.Version; however the equivalent number
> of classes are loaded before my changes too.

I've double checked and yes, Runtime.Version is not loaded by default,
my bad on this, it's own runtime that has an indirect dependency on Runtime.Version.

> 
> The performance problem identified by the following bug should
> resolve this issue:
> 
>   8150678: JarFile stream() and entries(0 methods need performance
>     enhancement
>   https://bugs.openjdk.java.net/browse/JDK-8150678
> 
> Regards,
> Iris

regards,
R?mi

> 
> -----
> $ cat Hi.java
> public class Hi {
>     public static void main(String ... args) {
>         System.out.println("hi");
>         System.exit(42);
>     }
> $ wc Hi.ver*
>    501   2000  39758 Hi.verbose-118
>    576   2300  45915 Hi.verbose-118-jar
>    501   2000  39734 Hi.verbose-8144062
>    576   2300  45905 Hi.verbose-8144062-jar
>   2154   8600 171312 total
> 
> -----Original Message-----
> From: Remi Forax [mailto:forax at univ-mlv.fr]
> Sent: Friday, May 13, 2016 4:32 PM
> To: Iris Clark
> Cc: Java Core Libs; compiler-dev at openjdk.java.net;
> verona-dev at openjdk.java.net
> Subject: Re: RFR: 8144062: Move jdk.Version to java.lang.Runtime.Version
> 
> Hi Iris,
> is there a way to avoid to use regex when parsing the version ?
> 
> java.lang.Runtime.Version is used during the boot process, so now every Java
> programs loads a bunch of classes related to java.util.regex even if they do
> not use any regex or use another regex engine (like Nashorn or JRuby).
> 
> regards,
> R?mi
> 
> ----- Mail original -----
> > De: "Iris Clark" <iris.clark at oracle.com>
> > ?: "Java Core Libs" <core-libs-dev at openjdk.java.net>,
> > compiler-dev at openjdk.java.net
> > Cc: verona-dev at openjdk.java.net
> > Envoy?: Samedi 14 Mai 2016 01:20:23
> > Objet: RFR: 8144062: Move jdk.Version to java.lang.Runtime.Version
> > 
> > Hi.
> > 
> > Reviving this work from a few months back.
> > 
> > Please review the following changes to move jdk.Version to
> > java.lang.Runtime.Version.
> > 
> > Bug
> > 
> >     8144062: Move jdk.Version to java.lang.Runtime.Version
> >     https://bugs.openjdk.java.net/browse/JDK-8144062
> > 
> > webrev
> > 
> >     http://cr.openjdk.java.net/~iris/verona/8144062/webrev.1/
> > 
> > When jdk.Version was initially pushed in jdk-9+1-5, it was Improperly
> > exported by java.base.  After exploring a few options, the best choice
> > was to move jdk.Version to java.lang.Runtime.Version (a nested class
> > of Runtime).  By making Version an SE API, it may be exported by the
> > java.base module.
> > 
> > As part of the move, a limited number of chnages were made to the
> > Version class:
> > 
> >   - Change package name and class declaration (to static)
> >   - Eliminate use of "JDK" when describing a Java SE API
> >   - Initial clarifications related to zeros (trailing vs.
> >     Internal components)
> >   - Small typographical and grammatical enhancements
> >   - Indentation
> > 
> > The complete Runtime.Version specification is available here:
> > 
> >   
> > http://cr.openjdk.java.net/~iris/verona/8144062/doc.1/java/lang/Runtim
> > e.Version.html
> > 
> > The old jdk.Version.current() was replaced with Runtime.version().
> > 
> > In System.getProperties(), we indicate which version-related system
> > properties may be supported by Runtime.Version.
> > 
> > The remaining jdk and langtools file changes are all side-effects of
> > changing jdk.Version.current() to Runtime.version().
> > 
> > Thanks,
> > Iris
> > 
> 

From mandy.chung at oracle.com  Wed May 18 17:40:27 2016
From: mandy.chung at oracle.com (Mandy Chung)
Date: Wed, 18 May 2016 10:40:27 -0700
Subject: RFR: 8144062: Move jdk.Version to java.lang.Runtime.Version
In-Reply-To: <bff10acf-1bc3-4439-a664-6b0fc439ff0d@default>
References: <bff10acf-1bc3-4439-a664-6b0fc439ff0d@default>
Message-ID: <29AA7813-44E0-4BB1-937E-1BCAB46F9367@oracle.com>


> On May 13, 2016, at 4:20 PM, Iris Clark <iris.clark at oracle.com> wrote:
> 
> Hi.
> 
> Reviving this work from a few months back.
> 
> Please review the following changes to move jdk.Version to 
> jdk.lang.Runtime.Version.
> 
> Bug
> 
>    8144062: Move jdk.Version to java.lang.Runtime.Version
>    https://bugs.openjdk.java.net/browse/JDK-8144062
> 
> webrev
> 
>    http://cr.openjdk.java.net/~iris/verona/8144062/webrev.1/


The change looks fine.  Minor comments:

1178          * @throws  IllegalArgumentException
1179          *          If the given string cannot be interpreted as a valid
1180          *          version
1185          * @throws  NumberFormatException
1186          *          If an element of the version number or the build number
1187          *          cannot be represented as an {@link Integer}

It?s okay to specify @throws NumberFormatException while @throws IAE (merging the description) should be adequate (the implementation stays the same).  Something you can consider in the future.

1189          * @return  This version

It seems clearer to say "@return the Version of the given string? (this is a static method and no ?This version?)

Mandy

From jonathan.gibbons at oracle.com  Wed May 18 18:25:22 2016
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Wed, 18 May 2016 11:25:22 -0700
Subject: RFR: 8144062: Move jdk.Version to java.lang.Runtime.Version
In-Reply-To: <bff10acf-1bc3-4439-a664-6b0fc439ff0d@default>
References: <bff10acf-1bc3-4439-a664-6b0fc439ff0d@default>
Message-ID: <573CB392.9050301@oracle.com>

Langtools changes are OK, including the indirect use of the revised
Version in jar-fs.

-- Jon


On 05/13/2016 04:20 PM, Iris Clark wrote:
> Hi.
>
> Reviving this work from a few months back.
>
> Please review the following changes to move jdk.Version to
> jdk.lang.Runtime.Version.
>
> Bug
>
>      8144062: Move jdk.Version to java.lang.Runtime.Version
>      https://bugs.openjdk.java.net/browse/JDK-8144062
>
> webrev
>
>      http://cr.openjdk.java.net/~iris/verona/8144062/webrev.1/
>
> When jdk.Version was initially pushed in jdk-9+1-5, it was
> Improperly exported by java.base.  After exploring a few
> options, the best choice was to move jdk.Version to
> java.lang.Runtime.Version (a nested class of Runtime).  By
> making Version an SE API, it may be exported by the java.base
> module.
>
> As part of the move, a limited number of chnages were
> made to the Version class:
>
>    - Change package name and class declaration (to static)
>    - Eliminate use of "JDK" when describing a Java SE API
>    - Initial clarifications related to zeros (trailing vs.
>      Internal components)
>    - Small typographical and grammatical enhancements
>    - Indentation
>
> The complete Runtime.Version specification is available here:
>
>    http://cr.openjdk.java.net/~iris/verona/8144062/doc.1/java/lang/Runtime.Version.html
>
> The old jdk.Version.current() was replaced with
> Runtime.version().
>
> In System.getProperties(), we indicate which version-related
> system properties may be supported by Runtime.Version.
>
> The remaining jdk and langtools file changes are all
> side-effects of changing jdk.Version.current() to
> Runtime.version().
>
> Thanks,
> Iris


From iris.clark at oracle.com  Wed May 18 21:04:34 2016
From: iris.clark at oracle.com (Iris Clark)
Date: Wed, 18 May 2016 14:04:34 -0700 (PDT)
Subject: RFR: 8144062: Move jdk.Version to java.lang.Runtime.Version
In-Reply-To: <573CB392.9050301@oracle.com>
References: <bff10acf-1bc3-4439-a664-6b0fc439ff0d@default>
	<573CB392.9050301@oracle.com>
Message-ID: <0133a4b9-17cc-4ba9-96ce-ec4b523067af@default>

Hi, Jon.

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

> Langtools changes are OK, including the indirect use of the revised
> Version in jar-fs.

Thanks for the Review.

Regards,
Iris

From iris.clark at oracle.com  Wed May 18 21:52:49 2016
From: iris.clark at oracle.com (Iris Clark)
Date: Wed, 18 May 2016 14:52:49 -0700 (PDT)
Subject: RFR: 8144062: Move jdk.Version to java.lang.Runtime.Version
In-Reply-To: <29AA7813-44E0-4BB1-937E-1BCAB46F9367@oracle.com>
References: <bff10acf-1bc3-4439-a664-6b0fc439ff0d@default>
	<29AA7813-44E0-4BB1-937E-1BCAB46F9367@oracle.com>
Message-ID: <0452bb32-8bd4-4236-83e9-912f9055ddbc@default>

Hi, Mandy.

Thanks for taking the time to Review.

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

> The change looks fine.  Minor comments:
> 
> 1178          * @throws  IllegalArgumentException
> 1179          *          If the given string cannot be interpreted as a valid
> 1180          *          version
> 1185          * @throws  NumberFormatException
> 1186          *          If an element of the version number or the build number
> 1187          *          cannot be represented as an {@link Integer}
> 
> It?s okay to specify @throws NumberFormatException while @throws IAE (merging
> the description) should be adequate (the implementation stays the same).  
> Something you can consider in the future.

Sounds good as a future update.

> 1189          * @return  This version

> It seems clearer to say "@return the Version of the given string? (this is a
> static method and no ?This version?)

Nice catch.  Updated:

    1189c1189
    <          * @return  This version
    ---
    >          * @return  The Version of the given string

Thank you so much for volunteering to Sponsor this change for me.  I'll send you
the changesets as soon as I've finished testing my sync with jdk9/dev.

Regards,
Iris

From iris.clark at oracle.com  Thu May 19 19:42:53 2016
From: iris.clark at oracle.com (Iris Clark)
Date: Thu, 19 May 2016 12:42:53 -0700 (PDT)
Subject: RFR: 8144062: Move jdk.Version to java.lang.Runtime.Version
In-Reply-To: <0452bb32-8bd4-4236-83e9-912f9055ddbc@default>
References: <bff10acf-1bc3-4439-a664-6b0fc439ff0d@default>
	<29AA7813-44E0-4BB1-937E-1BCAB46F9367@oracle.com>
	<0452bb32-8bd4-4236-83e9-912f9055ddbc@default>
Message-ID: <54fe3060-f264-4cc1-8a5c-be0cc1b0f2d0@default>

Hi, Mandy.

Thank you so much for pushing the changesets [0,1] for this bug.

Regards,
Iris

[0]: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/3976fadb091d
[1]: http://hg.openjdk.java.net/jdk9/dev/langtools/rev/2a49d47a37d8