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.simo...@gmail.com> wrote:
> On Wed, Apr 6, 2016 at 8:28 PM, Iris Clark <iris.cl...@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.simo...@gmail.com]
>> Sent: Tuesday, April 05, 2016 10:26 AM
>> To: Java Core Libs
>> Cc: verona-...@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.simo...@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
