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.simo...@gmail.com] Sent: Wednesday, April 27, 2016 1:28 AM To: Iris Clark Cc: Java Core Libs; verona-...@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.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
