JDK-8149519 : Set java.specification.version to the MAJOR java version
  • Type: Bug
  • Component: other-libs
  • Affected Version: 9
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2016-02-10
  • Updated: 2018-11-29
  • Resolved: 2016-07-29
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 9
9 b130Fixed
Related Reports
Relates :  
JDK-8162686 - (spec) java.{vm.}?specification is independent of java.version
Relates :  
JDK-8061493 - JEP 223: New Version-String Scheme
Relates :  
JDK-8162687 - java.{vm.}?specification.version is always set to the Java major version
Relates :  
JDK-8150632 - jdk.jshell.TaskFactory should use jdk.Version to check for java.specification.version
Description
It has been observed that java.specification.version is identical to java.version.  Since java.specification.version should only be incremented as part of a JSR or subsequent MR, the value should not automatically change.

java.specification.version should be only loosely tied to java.version.
Comments
I agree with Volker that the initial values for java.*.specification.version should be $MAJOR. How and when they get updated after that is a separate issue, but we certainly do not want them auto-updated with each minor release.
27-07-2016
I don't think that using $MAJOR.$MINOR forjava.specification.version is a good solution. As far as Iunderstand, JEP 223 (i.e. the new version scheme) is anOracle/OpenJDK implementation detail. There is no JSR for thisand it won't be enforced trough a JCK/TCK test (please correct meif I'm wrong). The new versioning schema references the JCP inthat is says that the $MAJOR number corresponds to the "Java SEPlatform Specification" number as specified by the JCP in thecorresponding JSR. But not vice versa - i.e. there's no JSRreferencing JEP 223. JEP 223 also says that the $MINOR number will be increased if this ismandated by a Maintenance Release of the relevant PlatformSpecification (by the JCP). But as you correctly noticed, in reality,$MINOR is expected to be increased frequently compared to the numberof Java SE Maintenance Releases (if there will be any at all). So ifthe JCP should decide to publish a Maintenance Release, why should itname if after the then actual $MINOR update release number of theOracle/OpenJDK. I think a natural choice for such a MR would be "9.1",no difference at which update release version Oracle/OpenJDK will beat that time. So I think it would be best to decouple java.specification.versionfrom the Java versioning schema. We can start withjava.specification.version == $MAJOR. If there should be a MRsometimes in the future, we can just set java.specification.version tothe version number of that MR, whatever that will be. That's exactlywhat this change is about. Regarding the value of java.vm.specification.version I'm not sure whatit actually means at all. Until Java 1.6,java.vm.specification.version has always been "1.0", whilejava.specification.version has changed from 1.4, to 1.5 and 1.6(notice that java.specification.version has never been changed to1.4.2, it was 1.4 for Java 1.4.0 as well as for 1.4.2). Starting withJava 7, java.vm.specification.version is the same likejava.specification.version (i.e. 1.7 and 1.8) but I'm not sure if thatis mandated by JCP and if it will be possible that these numbers willdiverge for a Java release. I.e. will it be possible to have a newJava version (say Java 10) where the VM specification (and thusjava.vm.specification.version) will remain unchanged (say "9")? Frommy understanding, that should be possible. Especially for a MR, itseems highly probable to me that the java.specification.version willbe increased, but the VM specification (and thusjava.vm.specification.version) will remain unchanged. So again, I think we shouldn't tie java.vm.specification.version tojava.specification.version and simply start withjava.vm.specification.version == $MAJOR. The current implementationalready does this correctly. While the java.specification.versionproperty comes from VERSION_SPECIFICATION incommon/autoconf/spec.gmk.in and it is being set injdk/src/java.base/share/native/libjava/System.c thejava.vm.specification.version property is set being inhotspot/src/share/vm/runtime/arguments.cpp directly to the major Javaversion number. Because of this difference, there are currently noproblems with the java.vm.specification.version property caused by thenew versioning schema.
07-04-2016
I agree that the old implementation isn't quite correct. I can't see us potentially having a JCP MR for a security or patch release (9.0.0.X and 9.0.X respectively). I could see a MR for an very unusual minor release (9.X). If we had an MR there's no guarantee that we'd need to change the java.specification.version system property. However, in the event that we did need to change the java.specification.version, it should match that release's $MAJOR.$MINOR, even if it meant that we had a sequence of specification version numbers with gaps. While we haven't changed the system property recently, I think that we need to future-proof ourselves a little bit for MRs as described above. Assuming that we change the syntax of java.specification.version to $MAJOR.$MINOR (zeros truncated, value dependent on JCP) then we need to make a similar change to the syntax of java.vm.specification.version.
06-04-2016
Currently java.specification.version 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 java.version. 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. fr 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.
04-04-2016