Hi,
I'm terribly sorry, it seems this fell out from my patch to 8160000 as I
was juggling patches back and forth between my workstation and my
laptop. I did test manually with --with-version-patch for various
numbers and was certain this was in in the final version and didn't
re-test.
I'd do prevIndex = index + 1, since ++index mutates index for no reason,
but I'm good either way.
/Claes
On 2016-06-28 16:57, Volker Simonis wrote:
Hi,
can somebody please review this trivial fix:
http://cr.openjdk.java.net/~simonis/webrevs/2016/8160457/
https://bugs.openjdk.java.net/browse/JDK-8160457
The problem is that VersionProps.versionNumbers() incorrectly parses a
Java version string because it doesn't skip the separating dots. The
current version only works for one digit versions like "9" but will
fail for any longer version string like for example "9.0.0.1" with:
at
java.lang.NumberFormatException.forInputString(java.base@9.0.0.1-internal/NumberFormatException.java:65)
at
java.lang.Integer.parseInt(java.base@9.0.0.1-internal/Integer.java:791)
at
java.lang.VersionProps.versionNumbers(java.base@9.0.0.1-internal/VersionProps.java:76)
at
java.lang.Runtime.version(java.base@9.0.0.1-internal/Runtime.java:940)
This also breaks the build which uses a newly built jdk for
bootstrapping if we set '--with-version-patch=1' for example.
An can you PLEASE, PLEASE finally do your internal/early access builds
with '--with-version-patch=1'. It seems really careless to me that you
introduce a new, up to four digit versioning schema but only test the
shortcut version with one digit. I wouldn't be surprised if a version
like "9.0.0.1" breaks more Java applications than the sun.misc.Unsafe
removal :)
Thank you and best regards,
Volker
