From volker.simonis at gmail.com Mon Apr 4 16:47:38 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 4 Apr 2016 18:47:38 +0200 Subject: RFR(XXS): 8149519: Investigate implementation of java.specification.version Message-ID: 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 From volker.simonis at gmail.com Tue Apr 5 17:25:33 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 5 Apr 2016 19:25:33 +0200 Subject: RFR(XXS): 8149519: Investigate implementation of java.specification.version In-Reply-To: References: Message-ID: Hi, can somebody please review this trivial change? Regards, Volker On Mon, Apr 4, 2016 at 6:47 PM, Volker Simonis 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 From volker.simonis at gmail.com Wed Apr 6 08:55:20 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 6 Apr 2016 10:55:20 +0200 Subject: Build jigsaw ans jdk9 ea builds with '--with-version-patch=1' Message-ID: Hi, I would highly recommend to build the jigsaw andjdk9 ea builds with '--with-version-patch=1'. This will result in a java.version of the form "9.0.0.1-..." and give people a chance to "really" test the new Java versioning scheme. Otherwise they will only detect potential problems with the first update version, which will be the first one to have a more complex version number. Currently, the Java version is simply "9" which is the short hand form of "9.0.0.0" and people are only testing their old code with this simplified version number. But you don't see problems like for example "8149519: Investigate implementation of java.specification.version" [1] as long as we only use the simplified version scheme. Regards, Volker [1] https://bugs.openjdk.java.net/browse/JDK-8149519 From iris.clark at oracle.com Wed Apr 6 18:28:12 2016 From: iris.clark at oracle.com (Iris Clark) Date: Wed, 6 Apr 2016 11:28:12 -0700 (PDT) Subject: RFR(XXS): 8149519: Investigate implementation of java.specification.version In-Reply-To: References: Message-ID: 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. 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 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 From volker.simonis at gmail.com Thu Apr 7 10:11:09 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 7 Apr 2016 12:11:09 +0200 Subject: RFR(XXS): 8149519: Investigate implementation of java.specification.version In-Reply-To: References: Message-ID: On Wed, Apr 6, 2016 at 8:28 PM, Iris Clark 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 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 From volker.simonis at gmail.com Wed Apr 27 08:28:11 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 27 Apr 2016 10:28:11 +0200 Subject: RFR(XXS): 8149519: Investigate implementation of java.specification.version In-Reply-To: References: Message-ID: 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 wrote: > On Wed, Apr 6, 2016 at 8:28 PM, Iris Clark 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 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 From Alan.Bateman at oracle.com Wed Apr 27 09:15:17 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 27 Apr 2016 10:15:17 +0100 Subject: RFR(XXS): 8149519: Investigate implementation of java.specification.version In-Reply-To: References: Message-ID: <57208325.6080907@oracle.com> On 27/04/2016 09:28, Volker Simonis wrote: > 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. > One thing to be aware of is that specification for legacy java.lang.Package has been significantly overhauled as part of updating the platform to support modules. The javadoc to read is the updated class description where it specifies the properties of Packages automatically created for types in named modules, also the API note in the 8-parameter ClassLoader.definePackage method. The TL;DR summary is that getSpecificationVersion() will return null when invoking on Package objects for any types in any of the system module (or any of the modules on the module path too). So I don't think JEP 223 needs to be concerned with it. JDK-8144062 is tracking the replacement of jdk.Version with a standard API. -Alan. From volker.simonis at gmail.com Wed Apr 27 09:54:05 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 27 Apr 2016 11:54:05 +0200 Subject: RFR(XXS): 8149519: Investigate implementation of java.specification.version In-Reply-To: <57208325.6080907@oracle.com> References: <57208325.6080907@oracle.com> Message-ID: On Wed, Apr 27, 2016 at 11:15 AM, Alan Bateman wrote: > > On 27/04/2016 09:28, Volker Simonis wrote: >> >> 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. >> > One thing to be aware of is that specification for legacy java.lang.Package > has been significantly overhauled as part of updating the platform to > support modules. The javadoc to read is the updated class description where > it specifies the properties of Packages automatically created for types in > named modules, also the API note in the 8-parameter > ClassLoader.definePackage method. The TL;DR summary is that > getSpecificationVersion() will return null when invoking on Package objects > for any types in any of the system module (or any of the modules on the > module path too). So I don't think JEP 223 needs to be concerned with it. > Thanks for the clarification. As far as I can see, this updated javadoc is still only in the jigsaw repo so I didn't read it before. > JDK-8144062 is tracking the replacement of jdk.Version with a standard API. > Thanks for providing the link. I wasn't aware of it. Yet another bug to follow on JBS :) Volker > -Alan. From Alan.Bateman at oracle.com Wed Apr 27 10:01:42 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 27 Apr 2016 11:01:42 +0100 Subject: RFR(XXS): 8149519: Investigate implementation of java.specification.version In-Reply-To: References: <57208325.6080907@oracle.com> Message-ID: <57208E06.2060809@oracle.com> On 27/04/2016 10:54, Volker Simonis wrote: > : > Thanks for the clarification. As far as I can see, this updated > javadoc is still only in the jigsaw repo so I didn't read it before. > It's in JDK 9 since jdk-9+111. I just checked the online/browsable docs [1] and it's there. -Alan [1] http://download.java.net/java/jdk9/docs/api/index.html From martinrb at google.com Wed Apr 27 11:26:25 2016 From: martinrb at google.com (Martin Buchholz) Date: Wed, 27 Apr 2016 04:26:25 -0700 Subject: RFR(XXS): 8149519: Investigate implementation of java.specification.version In-Reply-To: <57208E06.2060809@oracle.com> References: <57208325.6080907@oracle.com> <57208E06.2060809@oracle.com> Message-ID: I think the jdk9 docs have moved (again, grrrr - I complain about this sort of thing every release) and so a google search for "package class se 9" only finds the old one +104 at http://download.java.net/jdk9/docs/api/java/lang/Package.html Why can't there be a redirect instead of leaving the old docs in place? On Wed, Apr 27, 2016 at 3:01 AM, Alan Bateman wrote: > On 27/04/2016 10:54, Volker Simonis wrote: >> >> : >> Thanks for the clarification. As far as I can see, this updated >> javadoc is still only in the jigsaw repo so I didn't read it before. >> > It's in JDK 9 since jdk-9+111. I just checked the online/browsable docs [1] > and it's there. > > -Alan > > [1] http://download.java.net/java/jdk9/docs/api/index.html From Alan.Bateman at oracle.com Wed Apr 27 12:16:27 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 27 Apr 2016 13:16:27 +0100 Subject: RFR(XXS): 8149519: Investigate implementation of java.specification.version In-Reply-To: References: <57208325.6080907@oracle.com> <57208E06.2060809@oracle.com> Message-ID: <5720AD9B.8070708@oracle.com> On 27/04/2016 12:26, Martin Buchholz wrote: > I think the jdk9 docs have moved (again, grrrr - I complain about this > sort of thing every release) and so a google search for "package class > se 9" only finds the old one +104 at > http://download.java.net/jdk9/docs/api/java/lang/Package.html > Why can't there be a redirect instead of leaving the old docs in place? > Yeah, a number of us noticed that recently too. Chasing the folks that publish these builds to get this fixed ... -Alan From volker.simonis at gmail.com Wed Apr 27 12:23:08 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 27 Apr 2016 14:23:08 +0200 Subject: RFR(XXS): 8149519: Investigate implementation of java.specification.version In-Reply-To: References: <57208325.6080907@oracle.com> <57208E06.2060809@oracle.com> Message-ID: Yes, this was the version I've looked to as well. Thanks for pointing this out. On Wed, Apr 27, 2016 at 1:26 PM, Martin Buchholz wrote: > I think the jdk9 docs have moved (again, grrrr - I complain about this > sort of thing every release) and so a google search for "package class > se 9" only finds the old one +104 at > http://download.java.net/jdk9/docs/api/java/lang/Package.html > Why can't there be a redirect instead of leaving the old docs in place? > > On Wed, Apr 27, 2016 at 3:01 AM, Alan Bateman wrote: >> On 27/04/2016 10:54, Volker Simonis wrote: >>> >>> : >>> Thanks for the clarification. As far as I can see, this updated >>> javadoc is still only in the jigsaw repo so I didn't read it before. >>> >> It's in JDK 9 since jdk-9+111. I just checked the online/browsable docs [1] >> and it's there. >> >> -Alan >> >> [1] http://download.java.net/java/jdk9/docs/api/index.html From iris.clark at oracle.com Thu Apr 28 04:34:11 2016 From: iris.clark at oracle.com (Iris Clark) Date: Wed, 27 Apr 2016 21:34:11 -0700 (PDT) Subject: RFR(XXS): 8149519: Investigate implementation of java.specification.version In-Reply-To: References: Message-ID: 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 wrote: > On Wed, Apr 6, 2016 at 8:28 PM, Iris Clark 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 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 From Alan.Bateman at oracle.com Fri Apr 29 08:57:05 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 29 Apr 2016 09:57:05 +0100 Subject: RFR(XXS): 8149519: Investigate implementation of java.specification.version In-Reply-To: References: <57208325.6080907@oracle.com> <57208E06.2060809@oracle.com> Message-ID: <572321E1.2030702@oracle.com> On 27/04/2016 12:26, Martin Buchholz wrote: > I think the jdk9 docs have moved (again, grrrr - I complain about this > sort of thing every release) and so a google search for "package class > se 9" only finds the old one +104 at > http://download.java.net/jdk9/docs/api/java/lang/Package.html > Why can't there be a redirect instead of leaving the old docs in place? > The infrastructure that publishes the builds and docs on java.net is several steps removed from most of us here but from what I understand, the stale docs have been purged and a redirect from the old location to the new location is in place. When I search for "jdk 9 docs" now then Google serves up this link http://download.java.net/jdk9/docs/api/index.html?help-doc.html and I get redirected to the docs at: http://download.java.net/java/jdk9/docs/api/index.html -Alan From martinrb at google.com Fri Apr 29 20:03:44 2016 From: martinrb at google.com (Martin Buchholz) Date: Fri, 29 Apr 2016 13:03:44 -0700 Subject: RFR(XXS): 8149519: Investigate implementation of java.specification.version In-Reply-To: <572321E1.2030702@oracle.com> References: <57208325.6080907@oracle.com> <57208E06.2060809@oracle.com> <572321E1.2030702@oracle.com> Message-ID: Today, I tried google-searching for "LinkedList se 9" which sent me to http://download.java.net/jdk9/docs/api/java/util/LinkedList.html?is-external=true which gives me 404. That's an improvement on the stale +104 docs, and should prod Google's engine into learning about better docs, but it may still take a while. Redirection could be improved. I tried "binging" "LinkedList se 9" and it gave me the same result. Like I always say, populate the final jdk 9 docs directory from the very first EA build! On Fri, Apr 29, 2016 at 1:57 AM, Alan Bateman wrote: > > On 27/04/2016 12:26, Martin Buchholz wrote: >> >> I think the jdk9 docs have moved (again, grrrr - I complain about this >> sort of thing every release) and so a google search for "package class >> se 9" only finds the old one +104 at >> http://download.java.net/jdk9/docs/api/java/lang/Package.html >> Why can't there be a redirect instead of leaving the old docs in place? >> > The infrastructure that publishes the builds and docs on java.net is several > steps removed from most of us here but from what I understand, the stale > docs have been purged and a redirect from the old location to the new > location is in place. > > When I search for "jdk 9 docs" now then Google serves up this link > http://download.java.net/jdk9/docs/api/index.html?help-doc.html > > and I get redirected to the docs at: > http://download.java.net/java/jdk9/docs/api/index.html > > -Alan From Alan.Bateman at oracle.com Fri Apr 29 21:51:17 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 29 Apr 2016 22:51:17 +0100 Subject: RFR(XXS): 8149519: Investigate implementation of java.specification.version In-Reply-To: References: <57208325.6080907@oracle.com> <57208E06.2060809@oracle.com> <572321E1.2030702@oracle.com> Message-ID: <5723D755.6060409@oracle.com> On 29/04/2016 21:03, Martin Buchholz wrote: > Today, I tried google-searching for "LinkedList se 9" which sent me to > http://download.java.net/jdk9/docs/api/java/util/LinkedList.html?is-external=true > which gives me 404. That's an improvement on the stale +104 docs, and > should prod Google's engine into learning about better docs, but it > may still take a while. Redirection could be improved. > I tried "binging" "LinkedList se 9" and it gave me the same result. > > Like I always say, populate the final jdk 9 docs directory from the > very first EA build! > I completely agree that is poor form to change location. From what I can tell, they've put a redirect from the top level directory to the new location. This should at least keep bookmarks working. Also the stale docs are removed so I assume the search engines will eventually discard their memory of the old locations. -Alan