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

[Volker Simonis]

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