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 <[email protected]>: > > 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 <[email protected]> >> Date: Mon, Apr 4, 2016 at 6:47 PM >> Subject: RFR(XXS): 8149519: Investigate implementation of >> java.specification.version >> To: Java Core Libs <[email protected]> >> Cc: [email protected] >> >> >> 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 >
