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.
