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

Wed Apr 27 08:28:11 UTC 2016

Ping - shouldn't we fix this issue before JDK 9 Feature Complete?

Could you please also comment on my remarks regarding the relation of
java.lang.Package.getSpecificationVersion() to JEP and 223 and and my
question why the Version class is not in a standard java package.

Thank you and best regards,
Volker

On Thu, Apr 7, 2016 at 12:11 PM, Volker Simonis
<volker.simonis at gmail.com> wrote:
> On Wed, Apr 6, 2016 at 8:28 PM, Iris Clark <iris.clark at oracle.com> wrote:
>> Hi, Volker.
>>
>> Sorry for the delay.  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.
>>
>> As an example, let's say that JDK 9 is released via umbrella JSR with java.specification.value of "9".  The system property would remain at "9" for all releases regardless of type until we choose to have a MR.  Should that MR occur while we're working on minor release 9.3.X and there is a need to change the value of java.specification.value, it would become "9.3" and would remain so in every release until the next MR.
>>
>> 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.  [ Note that in the current implementation, I believe that the values of java.specification.version and java.vm.specification.version are tied to each other. ]
>>
>> Changing the syntax of java{.vm}?specification.version requires a CCC which I will file once we have agreement on the necessary changes.
>>
>
> Hi Iris,
>
> thanks for your comments. I don't think that using $MAJOR.$MINOR for
> java.specification.version is a good solution. As far as I understand,
>  JEP 223 (i.e. the new version scheme) is an Oracle/OpenJDK
> implementation detail. There is no JSR for this and it won't be
> enforced trough a JCK/TCK test (please correct me if I'm wrong). The
> new versioning schema references the JCP in that is says that the
> $MAJOR number corresponds to the "Java SE Platform Specification"
> number as specified by the JCP in the corresponding JSR. But not vice
> versa - i.e. there's no JSR referencing JEP 223.
>
> JEP 223 also says that the $MINOR number will be increased if this is
> mandated by a Maintenance Release of the relevant Platform
> Specification (by the JCP). But as you correctly noticed, in reality,
> $MINOR is expected to be increased frequently compared to the number
> of Java SE Maintenance Releases (if there will be any at all). So if
> the JCP should decide to publish a Maintenance Release, why should it
> name if after the then actual $MINOR update release number of the
> Oracle/OpenJDK. I think a natural choice for such a MR would be "9.1",
> no difference at which update release version Oracle/OpenJDK will be
> at that time.
>
> So I think it would be best to decouple java.specification.version
> from the Java versioning schema. We can start with
> java.specification.version == $MAJOR. If there should be a MR
> sometimes in the future, we can just set java.specification.version to
> the version number of that MR, whatever that will be. That's exactly
> what this change is about.
>
> Regarding the value of java.vm.specification.version I'm not sure what
> it actually means at all. Until Java 1.6,
> java.vm.specification.version has always been "1.0", while
> java.specification.version has changed from 1.4, to 1.5 and 1.6
> (notice that java.specification.version has never been changed to
> 1.4.2, it was 1.4 for Java 1.4.0 as well as for 1.4.2). Starting with
> Java 7, java.vm.specification.version is the same like
> java.specification.version (i.e. 1.7 and 1.8) but I'm not sure if that
> is mandated by JCP and if it will be possible that these numbers will
> diverge for a Java release. I.e. will it be possible to have a new
> Java version (say Java 10) where the VM specification (and thus
> java.vm.specification.version) will remain unchanged (say "9")? From
> my understanding, that should be possible. Especially for a MR, it
> seems highly probable to me that the java.specification.version will
> be increased, but the VM specification (and thus
> java.vm.specification.version) will remain unchanged.
>
> So again, I think we shouldn't tie java.vm.specification.version to
> java.specification.version and simply start with
> java.vm.specification.version == $MAJOR. The current implementation
> already does this correctly. While the java.specification.version
> property comes from VERSION_SPECIFICATION in
> common/autoconf/spec.gmk.in and it is being set in
> jdk/src/java.base/share/native/libjava/System.c the
> java.vm.specification.version property is set being in
> hotspot/src/share/vm/runtime/arguments.cpp directly to the major Java
> version number. Because of this difference, there are currently no
> problems with the java.vm.specification.version property caused by the
> new versioning schema.
>
> As a side note: while I wrote all this down, I realized that we have
> java.lang.Package.getSpecificationVersion() in the class library which
> returns the specification version of a specific package. But this API
> is not mentioned anywhere in JEP 223. Shouldn't the output of
> java.lang.Package.getSpecificationVersion() be aligned with JEP 223
> and java.vm.specification.version as well?
>
> And a final question. Why did we put jdk.Version into the jdk package?
> As far as I know, jdk is not a standard Java package and thus not
> enforced by the Java standard (please correct me if I'm wrong).
> Shouldn't the Version class be in a standard Java package such that
> it's implementation will be mandatory for all Java implementations?
>
> Regards,
> Volker
>
>> Regards,
>> Iris
>>
>> -----Original Message-----
>> From: Volker Simonis [mailto:volker.simonis at gmail.com]
>> Sent: Tuesday, April 05, 2016 10:26 AM
>> To: Java Core Libs
>> Cc: verona-dev at openjdk.java.net
>> Subject: Re: RFR(XXS): 8149519: Investigate implementation of java.specification.version
>>
>> 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