Version special case '9'

[Iris Clark]

Hi, Goetz.

Sorry for the delayed response.  I've been thinking about your situation.

I don't think that we can add back the trailing zeros.  The JEP inconsistency needs to be addressed.  The intent for the "Dropping the initial 1 element..." section is intended to describe a comparison algorithm, not guarantee the presence of trailing zeros.  This comparison has been implemented in jdk.Version.compareTo() which was pushed in this changeset (expected in jdk=9+105):

    http://hg.openjdk.java.net/jdk9/dev/jdk/rev/7adef1c3afd5

I haven't determined the feasibility of this quite yet, but I suspect that a reasonable solution to your version comparison problem for earlier releases such as 8u and 7u would be to add a similar implementation of jdk.Version.compareTo() to those releases.  Given the format of our previous release strings, this wouldn't be a straight backport of the JDK 9 jdk.Version, it would have to be a subset.  This would allow you to use the same methods on jdk.Version across a wider range of releases.  

Would that be helpful?

I haven't looked closely at the code, but I wonder whether the jck test has found a bug in the java.specification.version implementation?  Historically, the only time we increment that system property is as part of a JSR or a MR.  I've filed the following bug to investigate:

    8149519: Investigate implementation of java.specification.version
    https://bugs.openjdk.java.net/browse/JDK-8149519

Thanks,
iris

-----Original Message-----
From: Lindenmaier, Goetz [mailto:goetz.lindenmaier at sap.com] 
Sent: Tuesday, January 26, 2016 8:13 AM
To: hotspot-dev at openjdk.java.net; verona-dev at openjdk.java.net
Subject: Version special case '9'

Hi,

We appreciate the new version scheme introduced with JEP 223.
It simplifies the versioning and we agree that it is to it's best downward compatible.

Unfortunately there is one exception to this.
The initial version of a new major release skips the minor and security digits. This makes parsing the string unnecessarily complicated, because the format is not predictable.

In this, the JEP also is inconsistent.
In chapter "Dropping the initial 1 element from version numbers"
it is argued that comparing "9.0.0" to "1.8.0" by digit will show that
9 is newer than 8. But there is no such version as 9.0.0.

This is stated in chapter "Version numbers": "The version number does not include trailing zero elements; i.e., $SECURITY is omitted if it has the value zero, and $MINOR is omitted if both $MINOR and $SECURITY have the value zero."

Our BussinessObjects applications parse the option string by Float.parseFloat(System.getProperty("java.version").substring(0,3))
This delivers 1.7 for Java 7, but currently crashes for jdk9, as it tries to parse "9-i" from 9-internal.  With trailing .0.0, this would see 9.0 and could parse the Java version until Java 99.

As a workaround for this, we are now configuring with --with-version-patch=1 which results in version string 9.0.0.1-internal.

At another place, we use split() to analyse the version.

if (Integer.parseInt(System.getProperty("java.version").split("\\.")[1]) > 7)) { ...

If there are always 3 numbers, this could be fixed to:

if (Integer.parseInt(System.getProperty("java.version").split("\\.")[0]) > 7) ||
    Integer.parseInt(System.getProperty("java.version").split("\\.")[1]) > 7)) { ...

which was probably in mind when the

But with omitting the .0.0, we must also split at '-' and '+':

String[] version_elements = System.getProperty("java.version").split("\\.|-|+");
if (Integer.parseInt(version_elements[0]) > 7) ||
    Integer.parseInt(version_elements[1]) > 7)) { ...

If you want to check for a version > 9.*.22 it's even more complicated:

String[] version_elements = System.getProperty("java.version").split("+|-")[0].split("\\.");
if (Integer.parseInt(version_elements[0]) > 9 ||
    (Integer.parseInt(version_elements[0]) == 9 &&
     version_elements.length >= 3 &&
     Integer.parseInt(version_elements[2]) >  22)) { ...

So we would appreciate if the JEP was enhanced to always guarantee three version numbers 'x.y.z'.

Further, version number 9.0.0.1 breaks the jck test api/java_lang/System/index.html#GetProperty.
It fails with: "getJavaSpecVersion0001: Failed. System property 'java.specification.version' does not corresponds to the format 'major.minor.micro'".
Maybe a fix of this test is already worked on, we are using jck suite from 9.9.15.

Best regards,
  Goetz.