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

Iris Clark iris.clark at oracle.com
Thu Jul 28 07:17:59 UTC 2016


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.

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.

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.

-----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



More information about the build-dev mailing list