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
