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

Tue Jun 28 15:29:33 UTC 2016

Hi,

what about this bug?
It is still assigned to me and I would be happy to fix it as proposed in:

http://cr.openjdk.java.net/~simonis/webrevs/2016/8149519
https://bugs.openjdk.java.net/browse/JDK-8149519

If anybody has better ideas I'm open to transfer the bug to him :)

But I still think this should be fixed before JDK 9 will be shipped.
It's simply not right if 'java.specification.version' equals to
'java.version'.

Regards,
Volker

On Thu, Apr 28, 2016 at 6:34 AM, Iris Clark <iris.clark at oracle.com> wrote:
> Hi, Volker.
>
> Sorry for the delay.
>
>> Ping - shouldn't we fix this issue before JDK 9 Feature Complete?
>
> Ideally, yes.  I am hoping to get this resolved in the next few weeks.
>
> My first priority for Verona is JDK-8144062 which moves jdk.Version into a standard API (Alan mentioned this bugid earlier in this thread).  That absolutely must be completed before Feature Complete next month.
>
> Thanks,
> iris
>
> -----Original Message-----
> From: Volker Simonis [mailto:volker.simonis at gmail.com]
> Sent: Wednesday, April 27, 2016 1:28 AM
> To: Iris Clark
> Cc: Java Core Libs; verona-dev at openjdk.java.net; Alex Buckley; Kumar Srinivasan; Marvin Ma
> Subject: Re: RFR(XXS): 8149519: Investigate implementation of java.specification.version
>
> 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