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

Wed May 27 14:05:15 UTC 2015

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