Hi Magnus, thanks for the background information! It's always the smallest issues which take the most time and the longest discussions. I'm just happy that we have no line-endings in the version string :)
Regards, Volker On Thu, Jul 28, 2016 at 11:30 PM, Magnus Ihse Bursie <magnus.ihse.bur...@oracle.com> wrote: > Some background on this: > > I initially introduced VERSION_SPECIFICATION as VERSION_MAJOR but had to > revert it in the Verona branch since I was told that the specification number > should be identical to the release version. My initial reaction was the same > as yours, that the specification would match only the major part. > > I see now that Iris support this change, so I hope the old rationale for > having the specification in lockstep with the release is no longer valid. > > /Magnus > >> 26 juli 2016 kl. 14:26 skrev Alan Bateman <alan.bate...@oracle.com>: >> >> This looks right but I'm curious why it was initially implemented to use >> VERSION_NUMBER. >> >> -Alan >> >> >>> On 26/07/2016 13:20, Volker Simonis wrote: >>> >>> Forwarding to build-dev in the hope to get a review there :) >>> More details can be found in the bug description. >>> >>> Thank you and best regards, >>> Volker >>> >>> >>> ---------- Forwarded message ---------- >>> From: Volker Simonis <volker.simo...@gmail.com> >>> Date: Mon, Apr 4, 2016 at 6:47 PM >>> Subject: RFR(XXS): 8149519: Investigate implementation of >>> java.specification.version >>> To: Java Core Libs <core-libs-...@openjdk.java.net> >>> Cc: verona-...@openjdk.java.net >>> >>> >>> Hi, >>> >>> can I please have a review for this small fix: >>> >>> http://cr.openjdk.java.net/~simonis/webrevs/2016/8149519 >>> https://bugs.openjdk.java.net/browse/JDK-8149519 >>> >>> Currently the value of the java.specification.version property comes >>> from VERSION_SPECIFICATION in common/autoconf/spec.gmk.in. It is >>> currently set to VERSION_NUMBER which is the same value which is also >>> used for the java.version property. >>> >>> This is a bad idea, because VERSION_NUMBER is a dot separated sequence >>> of numbers (e.g. 9.0.1) which is expected to change frequently (i.e. >>> for every build and/or update version). If we are configuring with >>> "--with-version-patch=1" for example, VERSION_NUMBER and java.version >>> will be "9.0.0.1". But it makes no sense that VERSION_SPECIFICATION >>> and java.specification.version have the same, dotted value. And it >>> breaks a lot of legacy applications which parse >>> java.specification.version as a float number. That code would still >>> work if java.specification.version would be a concrete number (e.g. >>> '9' or '10'). >>> >>> I suggest to set VERSION_SPECIFICATION to VERSION_MAJOR in >>> common/autoconf/spec.gmk.in. This should be the "right value" until we >>> get a specification change during a major release which hasn't >>> happened for quite some time now. >>> >>> Regards, >>> Volker >>
