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
