[8u60] Request for review and approval: JDK-8074523: Java.net bundle has incorrect file version for jre/jdk

[Seán Coffey]

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