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

[Volker Simonis]

On Thu, Jul 28, 2016 at 9:17 AM, Iris Clark <iris.clark at oracle.com> wrote:
> Hi, Volker.
>
> Thanks for your patience.
>
> I think that the solution that you've provided solves the immediate problem, the java.specification.version number is incorrectly set to be identical to java.version.  The java.{vm.}?specification.version system properties should be independent of java.version and are determined by the JCP (either a JSR or an Maintenance Release).  If there's ever an MR against JSR 379 (Java SE 9 Release Contents) the value may need to be updated to something besides $MAJOR.
>
> Let's go with what you've got now.  Before you commit, I recommend that you update the title of 8149519 to describe either the problem or the solution.  Something like "Set java.specification.version to $MAJOR" would be appropriate.
>

Done. I've only left out the '$' as this my cause trouble on the command line.

> I've filled the following two follow-on bugs:
>
> 8162686 is a Java SE 9 spec bug against myself to update the spec of java.{vm.}?specification.version system properties as described above.  I'll also modify the Verona JEP to adjust the syntax of these system properties.
>
> I've also filed build bug (8162687) referencing 8145919 and 8162686.

I suppose you wanted to refer to "java.vm.specification.version" in
"8162687: ava.specification.version is always set to $MAJOR at build
time" because "java.vm.specification.version" is actually being set in
the code snippet you reference in the bug. Also, this is done at
run-time, during HotSpot initialization and not at build time.
Finally, I think this is more of a HotSpot issue and not a build
issue.

So I've changed the bug accordingly. If you think I've misunderstood
something, please feel free to change it back.

>
> Regards,
> Iris
>
> For the build team's bug, I'll reference 8145919 and the spec bug.  I suspect that they won't feel compelled to fix it for 9, but I leave it to them to determine how to best handle the issue.  I think it would be reasonable for them to decline to add complexity to the build without any current need for such a feature.

See above. I think this is something the HotSpot team should care
about because they should know which specification version their VM
implements.

Regards,
Volker

>
> -----Original Message-----
> From: Volker Simonis [mailto:volker.simonis at gmail.com]
> Sent: Tuesday, July 26, 2016 5:20 AM
> To: build-dev
> Subject: RFR(XXS): 8149519: Investigate implementation of java.specification.version
>
> 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