[8u60] Request for review and approval: JDK-8074523: Windows native binaries have inconsistent "Product version"

[Tim Bell]

Hi Erik:

> I still need an 8u reviewer, anyone?

Line 534 in jdk-options.m4 needs to line up with the following comment 
lines.  Otherwise, this looks good.  No need to respin the webrev after 
fixing the white space.

Tim


> On 2015-05-27 16:05, Magnus Ihse Bursie wrote:
>> On 2015-05-26 12:24, Erik Joelsson wrote:
>>> Any chance I could get a review on this?
>>
>> Yeah, if you ask nicely, with sugar on top. ;-)
>>
>> Fix looks good to me. Thanks for taking care of this.
>>
>> /Magnus
>>
>>>
>>> /Erik
>>>
>>> On 2015-05-20 16:09, Erik Joelsson wrote:
>>>> Thanks, changed to: Windows native binaries have inconsistent 
>>>> "Product version"
>>>>
>>>> Changed the label.
>>>>
>>>> /Erik
>>>>
>>>> On 2015-05-20 14:49, Seán Coffey wrote:
>>>>> It might be good to edit the bug synopsis before pushing the 
>>>>> change. I don't think this issue is specific to java.net bundles. 
>>>>> Might also be useful to use the noreg-sqe label rather than 
>>>>> noreg-build given that SQE team do appear to have test code for 
>>>>> this area.
>>>>>
>>>>> Approved pending code review.
>>>>>
>>>>> Regards,
>>>>> Sean.
>>>>>
>>>>> On 20/05/15 13:32, Erik Joelsson wrote:
>>>>>> Please review and approve this fix for 8u60.
>>>>>>
>>>>>> On windows, native libraries and executables have version numbers 
>>>>>> embedded into them. These can be seen when right-clicking the 
>>>>>> binary in explorer, on the Details tab, as "Product version". 
>>>>>> Currently in 8 update releases, these versions strings are 
>>>>>> inconsistent. An example:
>>>>>>
>>>>>> in 8u45 b09 we have:
>>>>>>
>>>>>> bin\client\jvm.dll: 8.0.0.9
>>>>>> bin\decora_sse.dll: 8.0.45.09
>>>>>> bin\deploy.dll: 8.0.450.9
>>>>>> bin\java.exe: 8.0.45.9
>>>>>>
>>>>>> These differences fall into 4 different categories.
>>>>>>
>>>>>> 1. jvm.dll in hotspot is not picking up the update version at 
>>>>>> all. This is due to a bug in the build-infra makefile rewrite 
>>>>>> that wasn't discovered in JDK 8 because it didn't have an update 
>>>>>> version.
>>>>>>
>>>>>> 2. decora_sse.dll is part of javafx. Fixing their version scheme 
>>>>>> is out of scope of this fix. A separate bug for javafx would be 
>>>>>> needed.
>>>>>>
>>>>>> 3. deploy.dll is actually the correct one. Historically we have 
>>>>>> encoded the update version with an extra digit for a potential 
>>>>>> letter at the end of the string.
>>>>>>
>>>>>> 4. java.exe, and the rest of the binaries from the jdk repository 
>>>>>> lost their extra 0 in the build-infra makefile rewrite and it 
>>>>>> wasn't discovered in JDK 8.
>>>>>>
>>>>>> Since we no longer use letters in update version strings, we 
>>>>>> could fix this by removing the extra 0. However, we have already 
>>>>>> released 8 updates where some binaries have the extra 0. Removing 
>>>>>> it would mean releasing 8u60 with binaries having version numbers 
>>>>>> lower than previous updates. For this reason I propose fixing 
>>>>>> this by adding the 0 for JDK and Hotspot binaries again, and of 
>>>>>> course by supplying the correct variable to the hotspot makefiles 
>>>>>> so that it even gets the update version in there. For clarity, 
>>>>>> with this patch, the above will log like this:
>>>>>>
>>>>>> bin\client\jvm.dll: 8.0.450.9
>>>>>> bin\decora_sse.dll: 8.0.45.09
>>>>>> bin\deploy.dll: 8.0.450.9
>>>>>> bin\java.exe: 8.0.450.9
>>>>>>
>>>>>> Note that in JDK 9, the version number scheme is being completely 
>>>>>> reworked so this will not be an issue.
>>>>>>
>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8074523
>>>>>> Webrev: 
>>>>>> http://cr.openjdk.java.net/~erikj/8074523/webrev.01/index.html
>>>>>>
>>>>>> /Erik
>>>>>
>>>>
>>>
>>
>