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
