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.cl...@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.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
