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

[Erik Joelsson]

Thanks Magnus, but I still need an 8u reviewer, anyone?

/Erik

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
>>>>
>>>
>>
>