PPS Perhaps this is already planned as future work, but it might be a
kindness to those analyzing JDK version strings if there was a class
that did a "best effort" at understanding Sun and Oracle JDK version
strings pre-Verona to those post-Verona. In other words, a version class
where
new JdkVersion("1.8.0_25")
would have major() == 8 and minor() == 25, but have the specified
meaning for strings for Verona strings where the first group was
numerically 9 or larger.
Cheers,
-Joe
On 11/25/2015 3:57 PM, joe darcy wrote:
PS If the concepts the two classes Version and OracleVersion are
trying to capture is a "Vendor-Version" then perhaps that can be
surfaced more directly in the API. That is, if the basic notion is to
interpret a version string in a way appropriate to and specialized for
a given vendor of the JDK (a la the java.vendor system property), then
perhaps a type like
// API sketch
public final class VendorVersion {
public VendorVersion(String vendor, Version version,
Comparator<Version> versionComp>) { ...}
@Override
public boolean equals(VendorVersion vv) {
// Usual instance of checks
return Objects.equals(vendor, vv.vendor()) &&
versionComp.version(), vv.version());
}
int compareVersion(VendorVersion vv) {
if (!vendor.equals(vv.vendor()))
// throw an exception
return versionComp(version, vv.version);
}
// ...
}
might serve the purposes at hand.
HTH,
-Joe
On 11/25/2015 1:31 PM, joe darcy wrote:
Hello,
On 11/25/2015 8:48 AM, Mandy Chung wrote:
On Nov 24, 2015, at 5:54 PM, Iris Clark <iris.cl...@oracle.com> wrote:
Hi.
Please review the new classes jdk.Version and jdk.OracleVersion.
These are
simple Java APIs to parse, validate, and compare version numbers.
Webrev
http://cr.openjdk.java.net/~irisa/verona/8072379/webrev.1/
This looks good to me. Alan raises a good question whether
jdk.OracleVersion is intended to be pushed to OpenJDK.
I share the concerns that have been raised about the naming and
placement of a class named "OracleVersion".
Is the intention that downstream JDK distributions, such as IcedTea,
whether based on OpenJDK or otherwise, would provide their own
specialization of the jdk.Version class?
If so, should there be some kind of provider interface to find
system's the version interpreter?
For example, what class, if any would be expected to provide detailed
analysis of the version string emitted by, say, a OpenJDK build used
as the reference implementation of Java SE 9?
The equals / hashCode behavior of Version and OracleVersion is bit
surprising and I think somewhat underspecified given the possibility
of defining subclasses.
The (overridable) equals method in Version says "Two Versions are
equal if and only if they represent the same version string." If that
is interpreted to mean the Versions are equal if their toString
output is equal, the toString spec says "Returns a string
representation of this version." and the (overridable) implementation
in Version looks at versions, pre, build, and optional.
Since OracleVersion does not override equals, a plain Version object
and an OracleVersion object can compare as equal. Additionally, a
VersionWithDifferentToStringOutput("1.2.3") object which overrides
toString would not be semantically equivalent to a Version("1.2.3")
object. Worse, there could be a non-communicability behavior in the
equals method since
(new Version("1.2.3")).equals(new
VersionWithDifferentToStringOutput("1.2.3"))
could return "true" while
(new VersionWithDifferentToStringOutput("1.2.3")).equals(new
Version("1.2.3"))
could easily and legitimately return "false" by the specification.
How is this API supposed to behave if the component version strings
have a numerical value greater than Integer.MAX_VALUE?
Was using Longs to record numerical versions rather than Integers
considered?
Thanks,
-Joe
