> On Jun 28, 2016, at 7:57 AM, Volker Simonis <volker.simo...@gmail.com> 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 >
+1 > 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’. Iris and I both have asked to verify the builds with --with-version-patch. Claes - did you see the exception during your verification? > 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 brought up similar question on the testing side. Automatic builds configured to build different version number could catch this and should be considered to do. Mandy > 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
