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

[Erik Joelsson]

Any chance I could get a review on this?

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