RFR(XXS): 8149519: Investigate implementation of java.specification.version

[Magnus Ihse Bursie]

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.Bateman at 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.simonis at 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-dev at openjdk.java.net>
>> Cc: verona-dev at 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
>