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

Volker Simonis volker.simonis at gmail.com
Tue Apr 5 17:25:33 UTC 2016


Hi,

can somebody please review this trivial change?

Regards,
Volker


On Mon, Apr 4, 2016 at 6:47 PM, Volker Simonis <volker.simonis at gmail.com> wrote:
> 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



More information about the core-libs-dev mailing list