[8u66] RFR 8079410: Hotspot version to share the same update and build version from JDK
Alejandro E Murillo
alejandro.murillo at oracle.com
Tue Jul 21 02:09:26 UTC 2015
On 7/20/2015 7:01 PM, David Holmes wrote:
> Hi Alejandro,
> On 21/07/2015 10:45 AM, Alejandro E Murillo wrote:
>> Please review the following change that allows setting
>> the Hotspot minor version and build number to that
>> of the "--with-update-version" and "--with-build-number"
>> configure parameters when provided. 8u builds only.
cut from the wrong tab, here you go:
> That location is not available externally.
>> Background (since bug was originally filed as internal):
>> Currently, for 8u builds and earlier, the hotspot version looks like
>> (remnant from the hotspot express days):
>> Java HotSpot(TM) Client VM (build 25.66-b00, mixed mode, sharing)
>> By convention, minor version (66 above) always matches the JDK update
>> and hotspot build number is managed independently of the JDK build
>> Both values are defined by default in "hotspot/make/hotspot_version".
>> With this change they can now be setup using the corresponding JDK
>> configure parameters.
>> (1) For promoted and other milestone builds, the hotspot minor version
>> will corresponds to the JDK update version and the hotspot build number
>> will match the JDK build number.
>> (2) Hotspot snapshots will no longer need to change the hotspot build
>> as that will be set at promotion time (matching the JDK build number).
>> Since this is stored in the file mentioned above, a repo push
>> (and the corresponding bug) was required to change it.
>> That will no longer be necessary.
>> (3) Since JPRT configures both the update and build numbers,
>> when building via JPRT, the hotspot build number for those builds
>> will always be 'b00' (matching the JDK build number). The Hotspot
>> minor version will match the update version defined in
>> java version "1.8.0_66-internal"
>> # Java(TM) SE Runtime Environment (build
>> # Java HotSpot(TM) Client VM (build 25.66-b00, mixed mode, sharing)
>> (4) Since the version string is not actually changing, I do not expect
>> this to have
>> any impact on external tools or apps, but let me know if so.
More information about the build-dev