> On Feb 19, 2016, at 10:59 AM, Iris Clark <[email protected]> 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 <[email protected]> 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
> 

Reply via email to