RFR: 8160000: Runtime.version() cause startup regressions in 9+119

[Claes Redestad]

Hi Iris,

I've configured and run with various alternative build numbers, such as 
--with-version-patch=5, which produces 9.0.0.5, and verified it works.

There was a bug in webrev.4 and earlier versions where a + 1 had slipped 
out of the loop, fixed in the latest webrev[1].

What other concerns...? :-)

Thanks!

/Claes

[1] http://cr.openjdk.java.net/~redestad/8160000/webrev.5/

On 2016-06-27 20:51, Iris Clark wrote:
> Hi, Claes.
>
> http://cr.openjdk.java.net/~redestad/8160000/webrev.4/
>
> Overall, this change looks good.  I just have a few concerns.
>
> Have you built this forcing alternative build numbers?  I
>
>
> -----Original Message-----
> From: Claes Redestad
> Sent: Sunday, June 26, 2016 12:56 PM
> To: core-libs-dev Libs; build-dev
> Subject: RFR: 8160000: Runtime.version() cause startup regressions in 9+119
>
> Hi,
>
> 9+119 changed java.util.regex to initialize java.lang.invoke early,
> causing a number of easily reproducible startup regressions.
>
> This patch uses the fact that we already maintain the version string
> constituents during build time to simplify creation of the
> java.lang.Runtime.version().
>
> Webrev: http://cr.openjdk.java.net/~redestad/8160000/webrev.3/
> Bug: https://bugs.openjdk.java.net/browse/JDK-8160000
>
> Since getting Runtime.version() now does not have to touch
> java.util.regex classes we end up slightly ahead of previous builds for
> applications which does not use regular expressions.
>
> Thanks!
>
> /Claes
>