RFR(XS): 8160457: VersionProps.versionNumbers() is broken

[Claes Redestad]

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 at 9.0.0.1-internal/NumberFormatException.java:65)
>          at java.lang.Integer.parseInt(java.base at 9.0.0.1-internal/Integer.java:791)
>          at java.lang.VersionProps.versionNumbers(java.base at 9.0.0.1-internal/VersionProps.java:76)
>          at java.lang.Runtime.version(java.base at 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