Hi, Joe.
It is not the intention that all JDK distributions must provide their own
specializations of jdk.Version. However, downstream users may wish to provide
additional semantics to the version string via encapsulation rather than
inheritance. In order to facilitate this, the following bug has been filed to
consider that case:
8145793: Provide vendor-specific interpretation of a JDK version string
https://bugs.openjdk.java.net/browse/JDK-8145793
Thanks,
iris
-----Original Message-----
From: joe darcy
Sent: Wednesday, November 25, 2015 3:58 PM
To: Mandy Chung; Iris Clark
Cc: [email protected]; [email protected]
Subject: Re: RFR: 8072379: Implement jdk.Version and jdk.OracleVersion
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
