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

[Volker Simonis]

Thanks, David!


On Wed, Jul 27, 2016 at 4:22 AM, David Holmes <david.holmes at oracle.com> wrote:
> +1 from me. Does the Verona JEP say anything about this? I certainly do not
> expect the specification version number of differ from the major release
> number.
>
> David
>
>
> On 26/07/2016 10:26 PM, Alan Bateman wrote:
>>
>> 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
>>
>>
>