RFR 8043541: 'fastdebug' is printed twice in java -version

[Alejandro E Murillo]

Thanks David!
Alejandro

On 6/19/2014 9:08 PM, David Holmes wrote:
> Looks good to me.
>
> Thanks,
> David
>
> On 19/06/2014 3:39 PM, Alejandro E Murillo wrote:
>> Can I get a review for this change?
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8043541
>> webrev: http://cr.openjdk.java.net/~amurillo/9/8043541/
>>
>> Note that this was discovered through nightly testing, but is not per se
>> causing
>> any failures. It only affects full non product JDK builds. It does not
>> affect hotspot
>> only builds.
>>
>> The bug was initially filed as confidential, it's a p4, if you can't see
>> the description, here it is:
>> "After the format of the hotspot version string was changed  now
>> 'fastdebug' is showing twice
>> in the hotspot version output of  'java -version' ONLY on Full non
>> product JDK builds as shown below:
>>
>> java version "1.9.0-ea-fastdebug"
>> Java(TM) SE Runtime Environment (build 1.9.0-ea-fastdebug-b14)
>> Java HotSpot(TM) Server VM (build 1.9.0-ea-fastdebug-b14-fastdebug,
>> mixed mode)
>> -----------------------------------------------------------------------^^^^^^^^^^--------^^^^^^^^^ 
>>
>>
>>
>> Background about the fix:
>> In a nutshell, with this fix, the build target is added to
>> HOTSPOT_RELEASE_VERSION,
>> on hotspot/make/defs.make,  and on Hotspot ONLY builds, instead of
>> passing it to
>> vm_version.cpp through HOTSPOT_TARGET_BUILD.
>>
>> HOWEVER, given the way the project to build hotspot (only) with Visual
>> Studio is created,
>> it is not possible to add that (HOTSPOT_TARGET_BUILD) to
>> HOTSPOT_RELEASE_VERSION
>> when the VS  project is created, so HOTSPOT_TARGET_BUILD is still passed
>> to vm_version.cpp,
>> on windows builds, but only appended to HOTSPOT_RELEASE_VERSION when
>> building
>> with Visual studio. Building windows with gnu make (as jprt does) will
>> work as in other platforms.
>>
>> I wanted to to get rid of passing HOTSPOT_TARGET_BUILD to vm_version.cpp
>> altogether, but I suspect it
>> was done that way to append the target build on non product builds when
>> using Visual studio.
>> If someone is familiar with the VS create.bat script and visual studio
>> in general, please
>> take a look and see if there's a way to pass that info at project
>> creation time, so that
>> we can completely get rid of  passing HOTSPOT_TARGET_BUILD to
>> vm_version.cpp.
>> Please file an RFE  if necessary.
>>
>> With this solution:
>> (a) For FULL JDK builds,  'fastdebug' will not be duplicated (bug being
>> fixed) on those builds.
>> (b) And for JUST hotspot only, non product builds, the output format for
>> the hotspot
>> version will  slightly change from (see ^^^^^^ below):
>>
>> java version "1.9.0-ea-fastdebug"
>> Java(TM) SE Runtime Environment (build 1.9.0-ea-fastdebug-b18)
>> Java HotSpot(TM) Server VM (build
>> 1.9.0-internal-201406172327.amurillo.jdk9-8043340-HSJOB-fastdebug, mixed
>> mode)
>> ------------------------------------------------------------------------------------------^^^^^^^^^ 
>>
>>
>>
>> TO:
>>
>> java version "1.9.0-ea-fastdebug"
>> Java(TM) SE Runtime Environment (build 1.9.0-ea-fastdebug-b16)
>> Java HotSpot(TM) Server VM (build
>> 1.9.0-fastdebug-internal-201406130717.amurillo.jdk9-8043541-HSJOB, mixed
>> mode)
>> ----------------------------------------^^^^^^^^^---------------------------------------------------- 
>>
>>
>>
>>
>> Basically 'fastdebug' is now added right after the jdk version, before
>> 'internal',
>>   in the hotspot portion, instead of at the end. Product builds are not
>> affected at all.
>> note, those are outputs from hs only JPRT builds. Non JPRT hs only
>> builds may not have
>> anything after 'internal' (by default).
>>
>> thanks
>>

-- 
Alejandro