RE: RFR [9] 8150162: Move sun.misc.Version to a truly internal package

[Iris Clark]

Hi,Chris.

>  http://cr.openjdk.java.net/~chegar/8150162.01/

Looks good to me.

Regards,
iris

-Original Message-
From: Chris Hegarty 
Sent: Monday, February 29, 2016 1:05 AM
To: Mandy Chung; Iris Clark
Cc: core-libs-dev
Subject: Re: RFR [9] 8150162: Move sun.misc.Version to a truly internal package

Updated webrv:
  http://cr.openjdk.java.net/~chegar/8150162.01/

The *{Major,Minor,...}Version(), and supporting, methods have been removed. As 
well as the native methods that support their implementation.  Further, 
additional, clean up, on the hotspot side, can be done as a follow up.

-Chris.

Note: test/sun/misc/Version/Version.java is no longer interesting as it asserts 
the values returned by the *{Major,Minor,...}Version() methods, which no longer 
exist.

Re: RFR [9] 8150162: Move sun.misc.Version to a truly internal package

[Chris Hegarty]

Updated webrv:
  http://cr.openjdk.java.net/~chegar/8150162.01/

The *{Major,Minor,...}Version(), and supporting, methods have been removed. As 
well
as the native methods that support their implementation.  Further, additional, 
clean up,
on the hotspot side, can be done as a follow up.

-Chris.

Note: test/sun/misc/Version/Version.java is no longer interesting as it asserts 
the values
returned by the *{Major,Minor,...}Version() methods, which no longer exist.

On 19 Feb 2016, at 19:05, Mandy Chung <mandy.ch...@oracle.com> wrote:

> 
>> On Feb 19, 2016, at 10:59 AM, Iris Clark <iris.cl...@oracle.com> wrote:
>> 
>> Hi, Mandy.
>> 
>>> Before Verona, sun.misc.Version was generated at build time and was 
>>> intended to set up the system properties about “java.version”, 
>>> “java.runtime.version”, “java.runtime.name”.  Did Verona change the logic 
>>> such that this class is no longer needed?
>> 
>> Verona did not change logic for VM initialization, we just updated it to 
>> reflect differences in naming.  The class is still needed to handle VM 
>> initialization and to print out version information (see lines 67-124 [0]). 
> 
> Thanks for confirming that.
> 
>> 
>> Recommendations for deprecation/removal were in reference to the static 
>> methods, *{Major,Minor,...}Version() beginning at new line 127 which appear 
>> to simply retrieve portions of the system properties.
>> 
> 
> Good.  Those methods were added for internal use for HS express era 
> (supporting VM of different versions that is gone for long).  It’s time to 
> remove them.
> 
> Mandy
> 
> 
>> Thanks,
>> Iris
>> 
>> [0] 
>> http://cr.openjdk.java.net/~chegar/8150162/jdk/src/java.base/share/classes/java/lang/Version.java.template.html
>> 
>> -Original Message-
>> From: Mandy Chung 
>> Sent: Friday, February 19, 2016 10:48 AM
>> To: Iris Clark
>> Cc: Mandy Chung; Chris Hegarty; core-libs-dev
>> Subject: Re: RFR [9] 8150162: Move sun.misc.Version to a truly internal 
>> package
>> 
>> 
>>> On Feb 19, 2016, at 9:52 AM, Iris Clark <iris.cl...@oracle.com> wrote:
>>> 
>>> Hi, Chris.
>>> 
>>>>> I'm not the code maintainer, but I'd consider deprecating them.
>>> 
>>>> Or just removing them.
>>> 
>>> Agreed.
>> 
>> Before Verona, sun.misc.Version was generated at build time and was intended 
>> to set up the system properties about “java.version”, 
>> “java.runtime.version”, “java.runtime.name”.  Did Verona change the logic 
>> such that this class is no longer needed?
>> 
>> On the other hand, I agree that the static methods getting the version 
>> numbers should be removed as they are replaced by the new Version API.
>> 
>> As for the webrev, moving to java.lang as a package-private type is fine.  I 
>> suggest to rename it to avoid any confusion with the new Version API such as 
>> VersionProps (or something better)?
>> 
>> Mandy
>> 
> 

Re: RFR [9] 8150162: Move sun.misc.Version to a truly internal package

[David Holmes]

Hi Chris,

Hotspot and JDK changes seem fine to me.

Thanks,
David

On 19/02/2016 1:52 AM, Chris Hegarty wrote:

sun.misc.Version is the core libraries part of a private interface with the
JVM to query and set specific JVM version and capabilities, as well as
being responsible for setting the system properties for  "java.version”,
"java.runtime.version", and "java.runtime.name" ( which are generated
during the build ).

It is not a "Critical API", as defined by JEP 260, so should be moved
out of sun.misc and placed into a more appropriate package where it
can be encapsulated.

Version is only used by j.l.System during initialization, so I’ve taken the
liberty of moving it into java.lang as package-private. It could, however,
be placed in jdk.internal.misc, if it is more generally useful. That said,
most other usages should be able to use the JDK specific Version API.

http://cr.openjdk.java.net/~chegar/8150162/
https://bugs.openjdk.java.net/browse/JDK-8150162

-Chris.

P.S. 8150163 & 8150168 are in progress to replace unnecessary usages
of sun.misc.Version with the JDK specific Version.

Re: RFR [9] 8150162: Move sun.misc.Version to a truly internal package

[Mandy Chung]

> On Feb 19, 2016, at 10:59 AM, Iris Clark <iris.cl...@oracle.com> wrote:
> 
> Hi, Mandy.
> 
>> Before Verona, sun.misc.Version was generated at build time and was intended 
>> to set up the system properties about “java.version”, 
>> “java.runtime.version”, “java.runtime.name”.  Did Verona change the logic 
>> such that this class is no longer needed?
> 
> Verona did not change logic for VM initialization, we just updated it to 
> reflect differences in naming.  The class is still needed to handle VM 
> initialization and to print out version information (see lines 67-124 [0]). 

Thanks for confirming that.

> 
> Recommendations for deprecation/removal were in reference to the static 
> methods, *{Major,Minor,...}Version() beginning at new line 127 which appear 
> to simply retrieve portions of the system properties.
> 

Good.  Those methods were added for internal use for HS express era (supporting 
VM of different versions that is gone for long).  It’s time to remove them.

Mandy


> Thanks,
> Iris
> 
> [0] 
> http://cr.openjdk.java.net/~chegar/8150162/jdk/src/java.base/share/classes/java/lang/Version.java.template.html
> 
> -Original Message-
> From: Mandy Chung 
> Sent: Friday, February 19, 2016 10:48 AM
> To: Iris Clark
> Cc: Mandy Chung; Chris Hegarty; core-libs-dev
> Subject: Re: RFR [9] 8150162: Move sun.misc.Version to a truly internal 
> package
> 
> 
>> On Feb 19, 2016, at 9:52 AM, Iris Clark <iris.cl...@oracle.com> wrote:
>> 
>> Hi, Chris.
>> 
>>>> I'm not the code maintainer, but I'd consider deprecating them.
>> 
>>> Or just removing them.
>> 
>> Agreed.
> 
> Before Verona, sun.misc.Version was generated at build time and was intended 
> to set up the system properties about “java.version”, “java.runtime.version”, 
> “java.runtime.name”.  Did Verona change the logic such that this class is no 
> longer needed?
> 
> On the other hand, I agree that the static methods getting the version 
> numbers should be removed as they are replaced by the new Version API.
> 
> As for the webrev, moving to java.lang as a package-private type is fine.  I 
> suggest to rename it to avoid any confusion with the new Version API such as 
> VersionProps (or something better)?
> 
> Mandy
> 

RE: RFR [9] 8150162: Move sun.misc.Version to a truly internal package

[Iris Clark]

Hi, Mandy.

> Before Verona, sun.misc.Version was generated at build time and was intended 
> to set up the system properties about “java.version”, “java.runtime.version”, 
> “java.runtime.name”.  Did Verona change the logic such that this class is no 
> longer needed?

Verona did not change logic for VM initialization, we just updated it to 
reflect differences in naming.  The class is still needed to handle VM 
initialization and to print out version information (see lines 67-124 [0]). 

Recommendations for deprecation/removal were in reference to the static 
methods, *{Major,Minor,...}Version() beginning at new line 127 which appear to 
simply retrieve portions of the system properties.

Thanks,
Iris

[0] 
http://cr.openjdk.java.net/~chegar/8150162/jdk/src/java.base/share/classes/java/lang/Version.java.template.html

-Original Message-
From: Mandy Chung 
Sent: Friday, February 19, 2016 10:48 AM
To: Iris Clark
Cc: Mandy Chung; Chris Hegarty; core-libs-dev
Subject: Re: RFR [9] 8150162: Move sun.misc.Version to a truly internal package


> On Feb 19, 2016, at 9:52 AM, Iris Clark <iris.cl...@oracle.com> wrote:
> 
> Hi, Chris.
> 
>>> I'm not the code maintainer, but I'd consider deprecating them.
> 
>> Or just removing them.
> 
> Agreed.

Before Verona, sun.misc.Version was generated at build time and was intended to 
set up the system properties about “java.version”, “java.runtime.version”, 
“java.runtime.name”.  Did Verona change the logic such that this class is no 
longer needed?

On the other hand, I agree that the static methods getting the version numbers 
should be removed as they are replaced by the new Version API.

As for the webrev, moving to java.lang as a package-private type is fine.  I 
suggest to rename it to avoid any confusion with the new Version API such as 
VersionProps (or something better)?

Mandy

Re: RFR [9] 8150162: Move sun.misc.Version to a truly internal package

[Mandy Chung]

> On Feb 19, 2016, at 9:52 AM, Iris Clark  wrote:
> 
> Hi, Chris.
> 
>>> I'm not the code maintainer, but I'd consider deprecating them.
> 
>> Or just removing them.
> 
> Agreed.

Before Verona, sun.misc.Version was generated at build time and was intended to 
set up the system properties about “java.version”, “java.runtime.version”, 
“java.runtime.name”.  Did Verona change the logic such that this class is no 
longer needed?

On the other hand, I agree that the static methods getting the version numbers 
should be removed as they are replaced by the new Version API.

As for the webrev, moving to java.lang as a package-private type is fine.  I 
suggest to rename it to avoid any confusion with the new Version API such as 
VersionProps (or something better)?

Mandy

Re: RFR [9] 8150162: Move sun.misc.Version to a truly internal package

[Alan Bateman]

On 18/02/2016 15:52, Chris Hegarty wrote:

sun.misc.Version is the core libraries part of a private interface with the
JVM to query and set specific JVM version and capabilities, as well as
being responsible for setting the system properties for  "java.version”,
"java.runtime.version", and "java.runtime.name" ( which are generated
during the build ).

It is not a "Critical API", as defined by JEP 260, so should be moved
out of sun.misc and placed into a more appropriate package where it
can be encapsulated.

Version is only used by j.l.System during initialization, so I’ve taken the
liberty of moving it into java.lang as package-private. It could, however,
be placed in jdk.internal.misc, if it is more generally useful. That said,
most other usages should be able to use the JDK specific Version API.

http://cr.openjdk.java.net/~chegar/8150162/
https://bugs.openjdk.java.net/browse/JDK-8150162

This looks okay although I expect we will need to change VersionTest 
again soon to not use @run main/bootclasspath.


-Alan

Re: RFR [9] 8150162: Move sun.misc.Version to a truly internal package

[Roger Riggs]

Hi Chris,

Looks fine.  (As a package private class in java.lang)

Roger


On 2/18/2016 10:52 AM, Chris Hegarty wrote:

sun.misc.Version is the core libraries part of a private interface with the
JVM to query and set specific JVM version and capabilities, as well as
being responsible for setting the system properties for  "java.version”,
"java.runtime.version", and "java.runtime.name" ( which are generated
during the build ).

It is not a "Critical API", as defined by JEP 260, so should be moved
out of sun.misc and placed into a more appropriate package where it
can be encapsulated.

Version is only used by j.l.System during initialization, so I’ve taken the
liberty of moving it into java.lang as package-private. It could, however,
be placed in jdk.internal.misc, if it is more generally useful. That said,
most other usages should be able to use the JDK specific Version API.

http://cr.openjdk.java.net/~chegar/8150162/
https://bugs.openjdk.java.net/browse/JDK-8150162

-Chris.

P.S. 8150163 & 8150168 are in progress to replace unnecessary usages
of sun.misc.Version with the JDK specific Version.

RE: RFR [9] 8150162: Move sun.misc.Version to a truly internal package

[Iris Clark]

Hi, Chris.

>> I'm not the code maintainer, but I'd consider deprecating them.

> Or just removing them.

Agreed.

iris

-Original Message-
From: Chris Hegarty 
Sent: Friday, February 19, 2016 9:43 AM
To: Iris Clark
Cc: core-libs-dev
Subject: Re: RFR [9] 8150162: Move sun.misc.Version to a truly internal package

On 19 Feb 2016, at 17:40, Iris Clark <iris.cl...@oracle.com> wrote:

> Hi, Chris.
> 
>> http://cr.openjdk.java.net/~chegar/8150162/
> 
> From a versioning perspective, I think your changes are fine.  

Thanks Iris.

> Regarding the choice of package, I think a package-private class in java.lang 
> is reasonable.  Beyond initialization, I don't see any reason to use this 
> class.  The new jdk.Version API should be used in preference to these 
> *{Major,Minor,Security,...}Version() methods.

Yes, exactly. That was my thought too.

> I'm not the code maintainer, but I'd consider deprecating them.

Or just removing them.

Thanks,
-Chris

Re: RFR [9] 8150162: Move sun.misc.Version to a truly internal package

[Chris Hegarty]

On 19 Feb 2016, at 17:40, Iris Clark  wrote:

> Hi, Chris.
> 
>> http://cr.openjdk.java.net/~chegar/8150162/
> 
> From a versioning perspective, I think your changes are fine.  

Thanks Iris.

> Regarding the choice of package, I think a package-private class in java.lang 
> is reasonable.  Beyond initialization, I don't see any reason to use this 
> class.  The new jdk.Version API should be used in preference to these 
> *{Major,Minor,Security,...}Version() methods.

Yes, exactly. That was my thought too.

> I'm not the code maintainer, but I'd consider deprecating them.

Or just removing them.

Thanks,
-Chris

> Thanks,
> iris
> (not a Reviewer)
> 
> -Original Message-
> From: Chris Hegarty 
> Sent: Thursday, February 18, 2016 7:53 AM
> To: core-libs-dev; Iris Clark
> Subject: RFR [9] 8150162: Move sun.misc.Version to a truly internal package
> 
> sun.misc.Version is the core libraries part of a private interface with the 
> JVM to query and set specific JVM version and capabilities, as well as being 
> responsible for setting the system properties for  "java.version", 
> "java.runtime.version", and "java.runtime.name" ( which are generated during 
> the build ).
> 
> It is not a "Critical API", as defined by JEP 260, so should be moved out of 
> sun.misc and placed into a more appropriate package where it can be 
> encapsulated.
> 
> Version is only used by j.l.System during initialization, so I've taken the 
> liberty of moving it into java.lang as package-private. It could, however, be 
> placed in jdk.internal.misc, if it is more generally useful. That said, most 
> other usages should be able to use the JDK specific Version API.
> 
> http://cr.openjdk.java.net/~chegar/8150162/
> https://bugs.openjdk.java.net/browse/JDK-8150162
> 
> -Chris.
> 
> P.S. 8150163 & 8150168 are in progress to replace unnecessary usages of 
> sun.misc.Version with the JDK specific Version.

RE: RFR [9] 8150162: Move sun.misc.Version to a truly internal package

[Iris Clark]

Hi, Chris.

> http://cr.openjdk.java.net/~chegar/8150162/

>From a versioning perspective, I think your changes are fine.  

Regarding the choice of package, I think a package-private class in java.lang 
is reasonable.  Beyond initialization, I don't see any reason to use this 
class.  The new jdk.Version API should be used in preference to these 
*{Major,Minor,Security,...}Version() methods.  I'm not the code maintainer, but 
I'd consider deprecating them.

Thanks,
iris
(not a Reviewer)

-Original Message-
From: Chris Hegarty 
Sent: Thursday, February 18, 2016 7:53 AM
To: core-libs-dev; Iris Clark
Subject: RFR [9] 8150162: Move sun.misc.Version to a truly internal package

sun.misc.Version is the core libraries part of a private interface with the JVM 
to query and set specific JVM version and capabilities, as well as being 
responsible for setting the system properties for  "java.version", 
"java.runtime.version", and "java.runtime.name" ( which are generated during 
the build ).

It is not a "Critical API", as defined by JEP 260, so should be moved out of 
sun.misc and placed into a more appropriate package where it can be 
encapsulated.

Version is only used by j.l.System during initialization, so I've taken the 
liberty of moving it into java.lang as package-private. It could, however, be 
placed in jdk.internal.misc, if it is more generally useful. That said, most 
other usages should be able to use the JDK specific Version API.

http://cr.openjdk.java.net/~chegar/8150162/
https://bugs.openjdk.java.net/browse/JDK-8150162

-Chris.

P.S. 8150163 & 8150168 are in progress to replace unnecessary usages of 
sun.misc.Version with the JDK specific Version.