Version special case '9'

[Lindenmaier, Goetz]

Hi Iris,



thanks for your response!



> such as 8u and 7u would be to add a similar implementation of

> jdk.Version.compareTo() to those releases.  Given the format of our

Hmm, it would be great if old software would run out-of-the box with

Jdk 9.  If you add some utility classes, one still has to change Java code

to use these new classes.  It's a bit more convenient, but the code still

has to be changed.

Skipping the .0.0 in the version really breaks _all_ old code.  So fixing that

would be most helpful.  And it would fix the inconsistency in the JEP text.



> I don't think that we can add back the trailing zeros.

Why not?  Java 9 is not yet released, is it?  When else would you

fix something like that?  Anyways, what is the reason for skipping

the two zeroes?



Thanks and best regards,

  Goetz.









> -----Original Message-----

> From: Iris Clark [mailto:iris.clark at oracle.com]

> Sent: Mittwoch, 10. Februar 2016 06:28

> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; hotspot-

> dev at openjdk.java.net; verona-dev at openjdk.java.net

> Subject: RE: Version special case '9'

>

> 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<mailto:hotspot-dev at openjdk.java.net>; verona-dev at openjdk.java.net<mailto: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("\\.<file:///\\.>")[1]) > 7)) {

> ...

>

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

>

> if (Integer.parseInt(System.getProperty("java.version").split("\\.<file:///\\.>")[0]) > 7)

> ||

>     Integer.parseInt(System.getProperty("java.version").split("\\.<file:///\\.>")[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("\\.|-<file:///\\.|-|+>

> |+<file:///\\.|-|+>");

> 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("\\.<file:///\\.>");

> 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.