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
