From iris.clark at oracle.com Mon Jan 4 22:58:25 2016 From: iris.clark at oracle.com (Iris Clark) Date: Mon, 4 Jan 2016 14:58:25 -0800 (PST) Subject: Improve $OPT on current EA builds In-Reply-To: <567FBBC7.9060106@gmx.net> References: <567FBBC7.9060106@gmx.net> Message-ID: Hi Michael. Thanks for the report. I've created the following issue based on your message: https://bugs.openjdk.java.net/browse/JDK-8146428 Happy New Year! iris -----Original Message----- From: Michael Osipov [mailto:1983-01-06 at gmx.net] Sent: Sunday, December 27, 2015 2:22 AM To: verona-dev at openjdk.java.net Subject: Improve $OPT on current EA builds Hi folks, just tried Java 9 build 99 and noticed that $OPT of JEP 223 is not easily parseable/not a valid ISO date: java --version > Java(TM) SE Runtime Environment (build > 9-ea+99-2015-12-23-183325.javare.4146.nc) Can you kindly file an issue to make that a proper basic ISO datetime string? Date format would be here yyyyMMdd'T'HHmmss'Z' with timezone Etc/UTC as in DateTimeFormatter#basicDateTimeNoMillis. Michael From iris.clark at oracle.com Tue Jan 5 23:34:51 2016 From: iris.clark at oracle.com (Iris Clark) Date: Tue, 5 Jan 2016 15:34:51 -0800 (PST) Subject: JNI and JVM TI version numbers In-Reply-To: <5681252E.70407@oracle.com> References: <5681252E.70407@oracle.com> Message-ID: <73bd1e74-7db9-41d3-85f0-bb6e340a8fbd@default> Hi, Alan. JNI and JVM TI version numbers weren?t considered. Updating the JNI version to drop the "1" similar to what we've done for other parts of the system seems like an obvious change we should make. I'll propose text for the JEP. I assume that you'll handle the necessary code and other JNI spec updates for this change similar to the JDK 8 change in 8005716. I really like the idea of aligning the JVM TI version number, particularly since we need to update it anyway; however, I cannot properly judge the impact. If it's no greater than what we've observed for the system properties, then we should do it now. If you and other JVM TI experts believe it is reasonable to update this version number, I'll take care of the JEP addition. (It looks like it was changed to the present value in JDK 8 bug 8014135.) Thanks, iris -----Original Message----- From: Alan Bateman Sent: Monday, December 28, 2015 4:04 AM To: verona-dev at openjdk.java.net Cc: jigsaw-dev Subject: JNI and JVM TI version numbers Has there been any discussion in Project Verona about the native interfaces? I don't see anything in JEP 223 on this topic. In Project Jigsaw / JPMS then we need to update both JNI and the JVM Tool Interface for modules. Traditionally then whoever does the first update in a major release has the pleasure of rev'ing the version number and it looks like we're "it" this time. The JNI version is currently JNI_VERSION_1_8 (0x00010008). This is the version number that GetVersion returns, it's the highest version number that can be specified to JNI_CreateJavaVM, and the highest version that can be returned by a library's JNI_OnLoad implementation. Any concerns with moving to JNI_VERSION_9 (0x00090000)? Clearly code calling GetVersion and treating the value as a pair of 16-bit values may be surprised by a minor version number of 0 but this seems not too different to the compatibility issues with changing the values of the java.version or java.specification.version properties. Is rev'ing the JNI version something that JEP 223 should document? JVM TI is less obvious. Historically it hasn't been tied to the Java SE version (I think this was to allow for implementations on J2ME profiles). The version number is currently 1.2.3, defined as: JVMTI_VERSION = 0x30000000 + (1 * 0x10000) + (2 * 0x100) + 3 /* version: 1.2.3 */ 0x30000000 serves as a base value to separate it from JNI version numbers. This is needed because JVM TI environments are obtained via the JNI GetEnv function. JVM TI defines a GetVersion function to return the JVM TI version. It also defines shift and mask values to aid extracting the major, minor and micro versions. If we moved to 0x30000000 + (9 * 0x10000) then these would continue to work, it just might be a surprise to agents that expect the major number to be 1 and/or the minor number to be >= some value. Any thoughts on the JVM TI version? Dropping the major version as proposed by JEP 223 seems like the opportunity to do this one time change and get the JVM TI version number aligned. On the other hand, it's not important and shouldn't be an issue to continue its existing version scheme. -Alan From daniel.daugherty at oracle.com Wed Jan 6 19:23:14 2016 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 6 Jan 2016 12:23:14 -0700 Subject: JNI and JVM TI version numbers In-Reply-To: <73bd1e74-7db9-41d3-85f0-bb6e340a8fbd@default> References: <5681252E.70407@oracle.com> <73bd1e74-7db9-41d3-85f0-bb6e340a8fbd@default> Message-ID: <568D69A2.5000705@oracle.com> I've heard rumblings about the need to make JVM/TI changes due to JigSaw so it makes sense the change the JVM/TI version number at the same time. As Alan mentioned, JVM/TI versions weren't tied to JDK releases so changing the major version from '1' to '9' could be done at this time if we feel that aligning the JVM/TI version number with the new Verona scheme has some value. IMHO, I don't think we need to match the new Verona scheme for JVM/TI since it has historically been independent of JDK release numbers. As for JNI version numbers, I don't think we've been consistent about setting the version number to match the current JDK release, but when we do update it we try to match the current JDK release that contains the motivating API change... $ grep JNI_VERSION 1.[5678].0/latest/binaries/solaris-sparcv9/include/jni.h 1.5.0/latest/binaries/solaris-sparcv9/include/jni.h:#define JNI_VERSION_1_1 0x00010001 1.5.0/latest/binaries/solaris-sparcv9/include/jni.h:#define JNI_VERSION_1_2 0x00010002 1.5.0/latest/binaries/solaris-sparcv9/include/jni.h:#define JNI_VERSION_1_4 0x00010004 1.6.0/latest/binaries/solaris-sparcv9/include/jni.h:#define JNI_VERSION_1_1 0x00010001 1.6.0/latest/binaries/solaris-sparcv9/include/jni.h:#define JNI_VERSION_1_2 0x00010002 1.6.0/latest/binaries/solaris-sparcv9/include/jni.h:#define JNI_VERSION_1_4 0x00010004 1.6.0/latest/binaries/solaris-sparcv9/include/jni.h:#define JNI_VERSION_1_6 0x00010006 1.7.0/latest/binaries/solaris-sparcv9/include/jni.h:#define JNI_VERSION_1_1 0x00010001 1.7.0/latest/binaries/solaris-sparcv9/include/jni.h:#define JNI_VERSION_1_2 0x00010002 1.7.0/latest/binaries/solaris-sparcv9/include/jni.h:#define JNI_VERSION_1_4 0x00010004 1.7.0/latest/binaries/solaris-sparcv9/include/jni.h:#define JNI_VERSION_1_6 0x00010006 1.8.0/latest/binaries/solaris-sparcv9/include/jni.h:#define JNI_VERSION_1_1 0x00010001 1.8.0/latest/binaries/solaris-sparcv9/include/jni.h:#define JNI_VERSION_1_2 0x00010002 1.8.0/latest/binaries/solaris-sparcv9/include/jni.h:#define JNI_VERSION_1_4 0x00010004 1.8.0/latest/binaries/solaris-sparcv9/include/jni.h:#define JNI_VERSION_1_6 0x00010006 1.8.0/latest/binaries/solaris-sparcv9/include/jni.h:#define JNI_VERSION_1_8 0x00010008 Dan On 1/5/16 4:34 PM, Iris Clark wrote: > Hi, Alan. > > JNI and JVM TI version numbers weren?t considered. > > Updating the JNI version to drop the "1" similar to what we've done for other parts of the system seems like an obvious change we should make. > > I'll propose text for the JEP. I assume that you'll handle the necessary code and other JNI spec updates for this change similar to the JDK 8 change in 8005716. > > I really like the idea of aligning the JVM TI version number, particularly since we need to update it anyway; however, I cannot properly judge the impact. If it's no greater than what we've observed for the system properties, then we should do it now. > > If you and other JVM TI experts believe it is reasonable to update this version number, I'll take care of the JEP addition. (It looks like it was changed to the present value in JDK 8 bug 8014135.) > > Thanks, > iris > > -----Original Message----- > From: Alan Bateman > Sent: Monday, December 28, 2015 4:04 AM > To: verona-dev at openjdk.java.net > Cc: jigsaw-dev > Subject: JNI and JVM TI version numbers > > > Has there been any discussion in Project Verona about the native interfaces? I don't see anything in JEP 223 on this topic. > > In Project Jigsaw / JPMS then we need to update both JNI and the JVM Tool Interface for modules. Traditionally then whoever does the first update in a major release has the pleasure of rev'ing the version number and it looks like we're "it" this time. > > > The JNI version is currently JNI_VERSION_1_8 (0x00010008). This is the version number that GetVersion returns, it's the highest version number that can be specified to JNI_CreateJavaVM, and the highest version that can be returned by a library's JNI_OnLoad implementation. > > Any concerns with moving to JNI_VERSION_9 (0x00090000)? Clearly code calling GetVersion and treating the value as a pair of 16-bit values may be surprised by a minor version number of 0 but this seems not too different to the compatibility issues with changing the values of the java.version or java.specification.version properties. > > Is rev'ing the JNI version something that JEP 223 should document? > > > JVM TI is less obvious. Historically it hasn't been tied to the Java SE version (I think this was to allow for implementations on J2ME profiles). The version number is currently 1.2.3, defined as: > > JVMTI_VERSION = 0x30000000 + (1 * 0x10000) + (2 * 0x100) + 3 /* > version: 1.2.3 */ > > 0x30000000 serves as a base value to separate it from JNI version numbers. This is needed because JVM TI environments are obtained via the JNI GetEnv function. > > JVM TI defines a GetVersion function to return the JVM TI version. It also defines shift and mask values to aid extracting the major, minor and micro versions. If we moved to 0x30000000 + (9 * 0x10000) then these would continue to work, it just might be a surprise to agents that expect the major number to be 1 and/or the minor number to be >= some value. > > Any thoughts on the JVM TI version? Dropping the major version as proposed by JEP 223 seems like the opportunity to do this one time change and get the JVM TI version number aligned. On the other hand, it's not important and shouldn't be an issue to continue its existing version scheme. > > -Alan From iris.clark at oracle.com Thu Jan 7 04:29:51 2016 From: iris.clark at oracle.com (Iris Clark) Date: Wed, 6 Jan 2016 20:29:51 -0800 (PST) Subject: RFR: 8136494 Update "@since 1.9" to "@since 9" to match java.specification.version Message-ID: <8bb087f1-2969-49f1-8de8-1069a61e6306@default> Hi. In Verona (JEP 223: New Version-String Scheme[0]), the system property java.specification.version was updated from "1.9" to "9". @since tags for new JDK 9 APIs should be aligned with the new value. Please review the following changes to the jaxp, jaxws, jdk, langtools, and nashorn repositories. As usual with such changes, the patch file is the most helpful view of the changeset. Bug 8136494 Update "@since 1.9" to "@since 9" to match java.version.specification https://bugs.openjdk.java.net/browse/JDK-8136494 Webrev http://cr.openjdk.java.net/~iris/verona/8136594/webrev.0/ In addition to the changeset, I will update JEP 223 as follows: @since JavaDoc tag The value for the @since JavaDoc tag will continue to be aligned with the system property `java.specification.version`; hence, new JDK 9 APIs will be indicated by `@since 9`. Thanks, iris [0] http://openjdk.java.net/jeps/223 From iris.clark at oracle.com Thu Jan 7 04:33:16 2016 From: iris.clark at oracle.com (Iris Clark) Date: Wed, 6 Jan 2016 20:33:16 -0800 (PST) Subject: RFR: 8136494 Update "@since 1.9" to "@since 9" to match java.specification.version In-Reply-To: <8bb087f1-2969-49f1-8de8-1069a61e6306@default> References: <8bb087f1-2969-49f1-8de8-1069a61e6306@default> Message-ID: <5b78e36f-dc67-4bca-936f-f480f413bede@default> oops. The webrev link should be: http://cr.openjdk.java.net/~iris/verona/8136494/webrev.0/ Regards, iris -----Original Message----- From: Iris Clark Sent: Wednesday, January 06, 2016 8:30 PM To: jdk9-dev at openjdk.java.net Cc: Iris Clark; verona-dev at openjdk.java.net Subject: RFR: 8136494 Update "@since 1.9" to "@since 9" to match java.specification.version Hi. In Verona (JEP 223: New Version-String Scheme[0]), the system property java.specification.version was updated from "1.9" to "9". @since tags for new JDK 9 APIs should be aligned with the new value. Please review the following changes to the jaxp, jaxws, jdk, langtools, and nashorn repositories. As usual with such changes, the patch file is the most helpful view of the changeset. Bug 8136494 Update "@since 1.9" to "@since 9" to match java.version.specification https://bugs.openjdk.java.net/browse/JDK-8136494 Webrev http://cr.openjdk.java.net/~iris/verona/8136594/webrev.0/ In addition to the changeset, I will update JEP 223 as follows: @since JavaDoc tag The value for the @since JavaDoc tag will continue to be aligned with the system property `java.specification.version`; hence, new JDK 9 APIs will be indicated by `@since 9`. Thanks, iris [0] http://openjdk.java.net/jeps/223 From Alan.Bateman at oracle.com Thu Jan 7 11:40:45 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 7 Jan 2016 11:40:45 +0000 Subject: RFR: 8136494 Update "@since 1.9" to "@since 9" to match java.specification.version In-Reply-To: <5b78e36f-dc67-4bca-936f-f480f413bede@default> References: <8bb087f1-2969-49f1-8de8-1069a61e6306@default> <5b78e36f-dc67-4bca-936f-f480f413bede@default> Message-ID: <568E4EBD.3080600@oracle.com> On 07/01/2016 04:33, Iris Clark wrote: > oops. > > The webrev link should be: > > http://cr.openjdk.java.net/~iris/verona/8136494/webrev.0/ > I skimmed the patch and it looks good to me. -Alan From magnus.ihse.bursie at oracle.com Thu Jan 7 12:04:20 2016 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 7 Jan 2016 13:04:20 +0100 Subject: JNI and JVM TI version numbers In-Reply-To: <5681252E.70407@oracle.com> References: <5681252E.70407@oracle.com> Message-ID: <568E5444.1070105@oracle.com> On 2015-12-28 13:03, Alan Bateman wrote: > > Has there been any discussion in Project Verona about the native > interfaces? I don't see anything in JEP 223 on this topic. I have not seen it being discussed either. I believe it just haven't occurred to anyone that there was yet another place were the version number was hiding. I think it is very reasonable to align JNI and JVMTI version numbering to Verona standard. This is, after all, our one chance to get all versioning to a sane and consistent standard. /Magnus > > In Project Jigsaw / JPMS then we need to update both JNI and the JVM > Tool Interface for modules. Traditionally then whoever does the first > update in a major release has the pleasure of rev'ing the version > number and it looks like we're "it" this time. > > > The JNI version is currently JNI_VERSION_1_8 (0x00010008). This is the > version number that GetVersion returns, it's the highest version > number that can be specified to JNI_CreateJavaVM, and the highest > version that can be returned by a library's JNI_OnLoad implementation. > > Any concerns with moving to JNI_VERSION_9 (0x00090000)? Clearly code > calling GetVersion and treating the value as a pair of 16-bit values > may be surprised by a minor version number of 0 but this seems not too > different to the compatibility issues with changing the values of the > java.version or java.specification.version properties. > > Is rev'ing the JNI version something that JEP 223 should document? > > > JVM TI is less obvious. Historically it hasn't been tied to the Java > SE version (I think this was to allow for implementations on J2ME > profiles). The version number is currently 1.2.3, defined as: > > JVMTI_VERSION = 0x30000000 + (1 * 0x10000) + (2 * 0x100) + 3 /* > version: 1.2.3 */ > > 0x30000000 serves as a base value to separate it from JNI version > numbers. This is needed because JVM TI environments are obtained via > the JNI GetEnv function. > > JVM TI defines a GetVersion function to return the JVM TI version. It > also defines shift and mask values to aid extracting the major, minor > and micro versions. If we moved to 0x30000000 + (9 * 0x10000) then > these would continue to work, it just might be a surprise to agents > that expect the major number to be 1 and/or the minor number to be >= > some value. > > Any thoughts on the JVM TI version? Dropping the major version as > proposed by JEP 223 seems like the opportunity to do this one time > change and get the JVM TI version number aligned. On the other hand, > it's not important and shouldn't be an issue to continue its existing > version scheme. > > -Alan From lance.andersen at oracle.com Thu Jan 7 12:34:41 2016 From: lance.andersen at oracle.com (Lance Andersen) Date: Thu, 7 Jan 2016 07:34:41 -0500 Subject: RFR: 8136494 Update "@since 1.9" to "@since 9" to match java.specification.version In-Reply-To: <5b78e36f-dc67-4bca-936f-f480f413bede@default> References: <8bb087f1-2969-49f1-8de8-1069a61e6306@default> <5b78e36f-dc67-4bca-936f-f480f413bede@default> Message-ID: Hi Iris, I think the changes are OK. I would suggest making your description clear for your changes such as: ------ @@ -1019,7 +1019,7 @@ * may be controlled by the {@code -XX:AutoBoxCacheMax=} option. * During VM initialization, java.lang.Integer.IntegerCache.high property * may be set and saved in the private system properties in the - * jdk.internal.misc.VM class. + * sun.misc.VM class. */ ------- for your push? Best Lance On Jan 6, 2016, at 11:33 PM, Iris Clark wrote: > oops. > > The webrev link should be: > > http://cr.openjdk.java.net/~iris/verona/8136494/webrev.0/ > > Regards, > iris > > -----Original Message----- > From: Iris Clark > Sent: Wednesday, January 06, 2016 8:30 PM > To: jdk9-dev at openjdk.java.net > Cc: Iris Clark; verona-dev at openjdk.java.net > Subject: RFR: 8136494 Update "@since 1.9" to "@since 9" to match java.specification.version > > Hi. > > In Verona (JEP 223: New Version-String Scheme[0]), the system property java.specification.version was updated from "1.9" to "9". > @since tags for new JDK 9 APIs should be aligned with the new value. > > Please review the following changes to the jaxp, jaxws, jdk, langtools, and nashorn repositories. As usual with such changes, the patch file is the most helpful view of the changeset. > > Bug > > 8136494 Update "@since 1.9" to "@since 9" to match > java.version.specification > https://bugs.openjdk.java.net/browse/JDK-8136494 > > Webrev > > http://cr.openjdk.java.net/~iris/verona/8136594/webrev.0/ > > In addition to the changeset, I will update JEP 223 as follows: > > @since JavaDoc tag > > The value for the @since JavaDoc tag will continue to be > aligned with the system property `java.specification.version`; > hence, new JDK 9 APIs will be indicated by `@since 9`. > > Thanks, > iris > > [0] http://openjdk.java.net/jeps/223 Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From Alan.Bateman at oracle.com Thu Jan 7 13:27:34 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 7 Jan 2016 13:27:34 +0000 Subject: JNI and JVM TI version numbers In-Reply-To: <73bd1e74-7db9-41d3-85f0-bb6e340a8fbd@default> References: <5681252E.70407@oracle.com> <73bd1e74-7db9-41d3-85f0-bb6e340a8fbd@default> Message-ID: <568E67C6.2070208@oracle.com> On 05/01/2016 23:34, Iris Clark wrote: > Hi, Alan. > > JNI and JVM TI version numbers weren?t considered. > > Updating the JNI version to drop the "1" similar to what we've done for other parts of the system seems like an obvious change we should make. > > I'll propose text for the JEP. Thanks. In Dan Daugherty's mail then he notes that the JNI version was updated in Java SE 1.2, 1.4, 6 and 8. So one thing that would be useful to capture somewhere is whether the policy of not rev'ing it when there aren't any additions/changes should continue. So for example, suppose we don't touch JNI in Java SE 10 then would we we add JNI_VERSION_10 or not? > I assume that you'll handle the necessary code and other JNI spec updates for this change similar to the JDK 8 change in 8005716. Yes, we have a bug tracking it and I think Harold is going to get it into JDK 9 in advance of our additions. > > I really like the idea of aligning the JVM TI version number, particularly since we need to update it anyway; however, I cannot properly judge the impact. If it's no greater than what we've observed for the system properties, then we should do it now. > > If you and other JVM TI experts believe it is reasonable to update this version number, I'll take care of the JEP addition. (It looks like it was changed to the present value in JDK 8 bug 8014135.) > I like the idea of just doing this too but it's not critical. I see Dan's reply where he doesn't think we should but this is based on JVM TI being independent, something it realistically hasn't been for many years. Maybe it should be left as an open issue in the JEP until there is more input on this? We can start a discussion on serviceability-dev. -Alan From daniel.daugherty at oracle.com Thu Jan 7 14:47:47 2016 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 7 Jan 2016 07:47:47 -0700 Subject: JNI and JVM TI version numbers In-Reply-To: <568E67C6.2070208@oracle.com> References: <5681252E.70407@oracle.com> <73bd1e74-7db9-41d3-85f0-bb6e340a8fbd@default> <568E67C6.2070208@oracle.com> Message-ID: <568E7A93.5010609@oracle.com> On 1/7/16 6:27 AM, Alan Bateman wrote: > On 05/01/2016 23:34, Iris Clark wrote: >> Hi, Alan. >> >> JNI and JVM TI version numbers weren?t considered. >> >> Updating the JNI version to drop the "1" similar to what we've done >> for other parts of the system seems like an obvious change we should >> make. >> >> I'll propose text for the JEP. > Thanks. > > In Dan Daugherty's mail then he notes that the JNI version was updated > in Java SE 1.2, 1.4, 6 and 8. So one thing that would be useful to > capture somewhere is whether the policy of not rev'ing it when there > aren't any additions/changes should continue. So for example, suppose > we don't touch JNI in Java SE 10 then would we we add JNI_VERSION_10 > or not? > >> I assume that you'll handle the necessary code and other JNI spec >> updates for this change similar to the JDK 8 change in 8005716. > Yes, we have a bug tracking it and I think Harold is going to get it > into JDK 9 in advance of our additions. > >> >> I really like the idea of aligning the JVM TI version number, >> particularly since we need to update it anyway; however, I cannot >> properly judge the impact. If it's no greater than what we've >> observed for the system properties, then we should do it now. >> >> If you and other JVM TI experts believe it is reasonable to update >> this version number, I'll take care of the JEP addition. (It looks >> like it was changed to the present value in JDK 8 bug 8014135.) >> > I like the idea of just doing this too but it's not critical. I see > Dan's reply where he doesn't think we should but this is based on JVM > TI being independent, something it realistically hasn't been for many > years. Just an opinion. I don't have a strong preference either way. > Maybe it should be left as an open issue in the JEP until there is > more input on this? We can start a discussion on serviceability-dev. Getting the current Serviceability team's input would be good. Dan > > -Alan > From chris.hegarty at oracle.com Thu Jan 7 16:46:29 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 7 Jan 2016 16:46:29 +0000 Subject: RFR: 8136494 Update "@since 1.9" to "@since 9" to match java.specification.version In-Reply-To: <568E4EBD.3080600@oracle.com> References: <8bb087f1-2969-49f1-8de8-1069a61e6306@default> <5b78e36f-dc67-4bca-936f-f480f413bede@default> <568E4EBD.3080600@oracle.com> Message-ID: On 7 Jan 2016, at 11:40, Alan Bateman wrote: > On 07/01/2016 04:33, Iris Clark wrote: >> oops. >> >> The webrev link should be: >> >> http://cr.openjdk.java.net/~iris/verona/8136494/webrev.0/ >> > I skimmed the patch and it looks good to me. +1. Just to note there are a number of '@since 1.9? ?s in the langtools src [1], but I guess these can be done separately, if you like. -Chris. [1] * @since 1.9 ./langtools/src/java.compiler/share/classes/javax/tools/FileManagerUtils.java * @since 1.9 * @since 1.9 * @since 1.9 * @since 1.9 * @since 1.9 ./langtools/src/java.compiler/share/classes/javax/tools/StandardJavaFileManager.java * @since 1.9 ./langtools/src/java.compiler/share/classes/javax/lang/model/util/ElementScanner9.java * @since 1.9 ./langtools/src/java.compiler/share/classes/javax/lang/model/util/AbstractTypeVisitor9.java * @since 1.9 ./langtools/src/java.compiler/share/classes/javax/lang/model/util/AbstractAnnotationValueVisitor9.java * @since 1.9 ./langtools/src/java.compiler/share/classes/javax/lang/model/util/ElementKindVisitor9.java * @since 1.9 ./langtools/src/java.compiler/share/classes/javax/lang/model/util/SimpleElementVisitor9.java * @since 1.9 ./langtools/src/java.compiler/share/classes/javax/lang/model/util/SimpleAnnotationValueVisitor9.java * @since 1.9 ./langtools/src/java.compiler/share/classes/javax/lang/model/util/TypeKindVisitor9.java * @since 1.9 ./langtools/src/java.compiler/share/classes/javax/lang/model/util/AbstractElementVisitor9.java * @since 1.9 ./langtools/src/java.compiler/share/classes/javax/lang/model/SourceVersion.java * @since 1.9 ./langtools/src/jdk.compiler/share/classes/com/sun/source/util/TaskEvent.java * @since 1.9 * @since 1.9 * @since 1.9 * @since 1.9 * @since 1.9 * @since 1.9 ./langtools/src/jdk.compiler/share/classes/com/sun/source/util/DocTrees.java * @since 1.9 ./langtools/src/jdk.compiler/share/classes/com/sun/source/doctree/IndexTree.java * @since 1.9 ./langtools/src/jdk.compiler/share/classes/com/sun/source/doctree/DocCommentTree.java * @since 1.9 ./langtools/src/jdk.compiler/share/classes/com/sun/source/tree/PackageTree.java * @since 1.9 ./langtools/src/jdk.compiler/share/classes/com/sun/source/tree/CompilationUnitTree.java * @since 1.9 ./langtools/src/jdk.compiler/share/classes/com/sun/source/tree/Tree.java From jonathan.gibbons at oracle.com Thu Jan 7 16:52:48 2016 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 07 Jan 2016 08:52:48 -0800 Subject: RFR: 8136494 Update "@since 1.9" to "@since 9" to match java.specification.version In-Reply-To: References: <8bb087f1-2969-49f1-8de8-1069a61e6306@default> <5b78e36f-dc67-4bca-936f-f480f413bede@default> <568E4EBD.3080600@oracle.com> Message-ID: <568E97E0.5000301@oracle.com> On 01/07/2016 08:46 AM, Chris Hegarty wrote: > Just to note there are a number of '@since 1.9? ?s in the langtools > src [1], but I guess these can be done separately, if you like. > > -Chris. Chris, We did the langtools "@since 1.9" tags yesterday. http://hg.openjdk.java.net/jdk9/dev/langtools/rev/70ac078df098 -- Jon From chris.hegarty at oracle.com Thu Jan 7 16:52:52 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 7 Jan 2016 16:52:52 +0000 Subject: RFR: 8136494 Update "@since 1.9" to "@since 9" to match java.specification.version In-Reply-To: References: <8bb087f1-2969-49f1-8de8-1069a61e6306@default> <5b78e36f-dc67-4bca-936f-f480f413bede@default> <568E4EBD.3080600@oracle.com> Message-ID: On 7 Jan 2016, at 16:46, Chris Hegarty wrote: > > On 7 Jan 2016, at 11:40, Alan Bateman wrote: > >> On 07/01/2016 04:33, Iris Clark wrote: >>> oops. >>> >>> The webrev link should be: >>> >>> http://cr.openjdk.java.net/~iris/verona/8136494/webrev.0/ >>> >> I skimmed the patch and it looks good to me. > > +1. > > Just to note there are a number of '@since 1.9? ?s in the langtools > src [1], but I guess these can be done separately, if you like. Oops, it was pointed out to me that these were pushed to langtools yesterday. Ignore this comment, I need to refresh my forest more often. -Chris. > -Chris. > > [1] * @since 1.9 > ./langtools/src/java.compiler/share/classes/javax/tools/FileManagerUtils.java > * @since 1.9 > * @since 1.9 > * @since 1.9 > * @since 1.9 > * @since 1.9 > ./langtools/src/java.compiler/share/classes/javax/tools/StandardJavaFileManager.java > * @since 1.9 > ./langtools/src/java.compiler/share/classes/javax/lang/model/util/ElementScanner9.java > * @since 1.9 > ./langtools/src/java.compiler/share/classes/javax/lang/model/util/AbstractTypeVisitor9.java > * @since 1.9 > ./langtools/src/java.compiler/share/classes/javax/lang/model/util/AbstractAnnotationValueVisitor9.java > * @since 1.9 > ./langtools/src/java.compiler/share/classes/javax/lang/model/util/ElementKindVisitor9.java > * @since 1.9 > ./langtools/src/java.compiler/share/classes/javax/lang/model/util/SimpleElementVisitor9.java > * @since 1.9 > ./langtools/src/java.compiler/share/classes/javax/lang/model/util/SimpleAnnotationValueVisitor9.java > * @since 1.9 > ./langtools/src/java.compiler/share/classes/javax/lang/model/util/TypeKindVisitor9.java > * @since 1.9 > ./langtools/src/java.compiler/share/classes/javax/lang/model/util/AbstractElementVisitor9.java > * @since 1.9 > ./langtools/src/java.compiler/share/classes/javax/lang/model/SourceVersion.java > * @since 1.9 > ./langtools/src/jdk.compiler/share/classes/com/sun/source/util/TaskEvent.java > * @since 1.9 > * @since 1.9 > * @since 1.9 > * @since 1.9 > * @since 1.9 > * @since 1.9 > ./langtools/src/jdk.compiler/share/classes/com/sun/source/util/DocTrees.java > * @since 1.9 > ./langtools/src/jdk.compiler/share/classes/com/sun/source/doctree/IndexTree.java > * @since 1.9 > ./langtools/src/jdk.compiler/share/classes/com/sun/source/doctree/DocCommentTree.java > * @since 1.9 > ./langtools/src/jdk.compiler/share/classes/com/sun/source/tree/PackageTree.java > * @since 1.9 > ./langtools/src/jdk.compiler/share/classes/com/sun/source/tree/CompilationUnitTree.java > * @since 1.9 > ./langtools/src/jdk.compiler/share/classes/com/sun/source/tree/Tree.java From iris.clark at oracle.com Thu Jan 7 17:06:20 2016 From: iris.clark at oracle.com (Iris Clark) Date: Thu, 7 Jan 2016 09:06:20 -0800 (PST) Subject: RFR: 8136494 Update "@since 1.9" to "@since 9" to match java.specification.version In-Reply-To: References: <8bb087f1-2969-49f1-8de8-1069a61e6306@default> <5b78e36f-dc67-4bca-936f-f480f413bede@default> Message-ID: <80f56f2e-78b5-4b6e-a3ec-1f200ed2118b@default> Hi, Lance. Thanks for the review. I was a bit puzzled by the code you quoted back since it relates to the recent move of VM class, which I didn't touch. It appears that my forest was not sufficiently up-to-date with respect to dev when I did the webrev. The build I launched after I sent out the RFR failed. I'll fix the forest/webrev later today. Regards, iris From: Lance Andersen Sent: Thursday, January 07, 2016 4:35 AM To: Iris Clark Cc: jdk9-dev at openjdk.java.net; verona-dev at openjdk.java.net Subject: Re: RFR: 8136494 Update "@since 1.9" to "@since 9" to match java.specification.version Hi Iris, I think the changes are OK. I would suggest making your description clear for your changes such as: ------ @@ -1019,7 +1019,7 @@ * may be controlled by the {@code -XX:AutoBoxCacheMax=} option. * During VM initialization, java.lang.Integer.IntegerCache.high property * may be set and saved in the private system properties in the - * jdk.internal.misc.VM class. + * sun.misc.VM class. */ ------- for your push. Best Lance On Jan 6, 2016, at 11:33 PM, Iris Clark wrote: oops. The webrev link should be: http://cr.openjdk.java.net/~iris/verona/8136494/webrev.0/ Regards, iris -----Original Message----- From: Iris Clark Sent: Wednesday, January 06, 2016 8:30 PM To: HYPERLINK "mailto:jdk9-dev at openjdk.java.net"jdk9-dev at openjdk.java.net Cc: Iris Clark; HYPERLINK "mailto:verona-dev at openjdk.java.net"verona-dev at openjdk.java.net Subject: RFR: 8136494 Update "@since 1.9" to "@since 9" to match java.specification.version Hi. In Verona (JEP 223: New Version-String Scheme[0]), the system property java.specification.version was updated from "1.9" to "9". @since tags for new JDK 9 APIs should be aligned with the new value. Please review the following changes to the jaxp, jaxws, jdk, langtools, and nashorn repositories. As usual with such changes, the patch file is the most helpful view of the changeset. Bug 8136494 Update "@since 1.9" to "@since 9" to match java.version.specification https://bugs.openjdk.java.net/browse/JDK-8136494 Webrev http://cr.openjdk.java.net/~iris/verona/8136594/webrev.0/ In addition to the changeset, I will update JEP 223 as follows: @since JavaDoc tag The value for the @since JavaDoc tag will continue to be aligned with the system property `java.specification.version`; hence, new JDK 9 APIs will be indicated by `@since 9`. Thanks, iris [0] http://openjdk.java.net/jeps/223 http://oracle.com/us/design/oracle-email-sig-198324.gif HYPERLINK "http://oracle.com/us/design/oracle-email-sig-198324.gif" Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 HYPERLINK "mailto:Lance.Andersen at oracle.com"Lance.Andersen at oracle.com From iris.clark at oracle.com Thu Jan 7 17:06:57 2016 From: iris.clark at oracle.com (Iris Clark) Date: Thu, 7 Jan 2016 09:06:57 -0800 (PST) Subject: RFR: 8136494 Update "@since 1.9" to "@since 9" to match java.specification.version In-Reply-To: <568E4EBD.3080600@oracle.com> References: <8bb087f1-2969-49f1-8de8-1069a61e6306@default> <5b78e36f-dc67-4bca-936f-f480f413bede@default> <568E4EBD.3080600@oracle.com> Message-ID: Hi, Alan. Thanks for taking the time to review. Regards, iris -----Original Message----- From: Alan Bateman Sent: Thursday, January 07, 2016 3:41 AM To: Iris Clark; jdk9-dev at openjdk.java.net Cc: verona-dev at openjdk.java.net Subject: Re: RFR: 8136494 Update "@since 1.9" to "@since 9" to match java.specification.version On 07/01/2016 04:33, Iris Clark wrote: > oops. > > The webrev link should be: > > http://cr.openjdk.java.net/~iris/verona/8136494/webrev.0/ > I skimmed the patch and it looks good to me. -Alan From iris.clark at oracle.com Thu Jan 7 17:08:06 2016 From: iris.clark at oracle.com (Iris Clark) Date: Thu, 7 Jan 2016 09:08:06 -0800 (PST) Subject: RFR: 8136494 Update "@since 1.9" to "@since 9" to match java.specification.version In-Reply-To: References: <8bb087f1-2969-49f1-8de8-1069a61e6306@default> <5b78e36f-dc67-4bca-936f-f480f413bede@default> <568E4EBD.3080600@oracle.com> Message-ID: <59cd2988-4955-4041-93fa-71a7f31616ac@default> Hi, Chris. Thanks for reviewing. > Oops, it was pointed out to me that these were pushed to langtools yesterday. My mistake, I should have mentioned Jon's bug in my RFR. Regards, iris -----Original Message----- From: Chris Hegarty Sent: Thursday, January 07, 2016 8:53 AM To: Iris Clark Cc: jdk9-dev; verona-dev at openjdk.java.net Subject: Re: RFR: 8136494 Update "@since 1.9" to "@since 9" to match java.specification.version On 7 Jan 2016, at 16:46, Chris Hegarty wrote: > > On 7 Jan 2016, at 11:40, Alan Bateman wrote: > >> On 07/01/2016 04:33, Iris Clark wrote: >>> oops. >>> >>> The webrev link should be: >>> >>> http://cr.openjdk.java.net/~iris/verona/8136494/webrev.0/ >>> >> I skimmed the patch and it looks good to me. > > +1. > > Just to note there are a number of '@since 1.9' 's in the langtools > src [1], but I guess these can be done separately, if you like. Oops, it was pointed out to me that these were pushed to langtools yesterday. Ignore this comment, I need to refresh my forest more often. -Chris. > -Chris. > > [1] * @since 1.9 > ./langtools/src/java.compiler/share/classes/javax/tools/FileManagerUtils.java > * @since 1.9 > * @since 1.9 > * @since 1.9 > * @since 1.9 > * @since 1.9 > ./langtools/src/java.compiler/share/classes/javax/tools/StandardJavaFi > leManager.java > * @since 1.9 > ./langtools/src/java.compiler/share/classes/javax/lang/model/util/Elem > entScanner9.java > * @since 1.9 > ./langtools/src/java.compiler/share/classes/javax/lang/model/util/Abst > ractTypeVisitor9.java > * @since 1.9 > ./langtools/src/java.compiler/share/classes/javax/lang/model/util/Abst > ractAnnotationValueVisitor9.java > * @since 1.9 > ./langtools/src/java.compiler/share/classes/javax/lang/model/util/Elem > entKindVisitor9.java > * @since 1.9 > ./langtools/src/java.compiler/share/classes/javax/lang/model/util/Simp > leElementVisitor9.java > * @since 1.9 > ./langtools/src/java.compiler/share/classes/javax/lang/model/util/Simp > leAnnotationValueVisitor9.java > * @since 1.9 > ./langtools/src/java.compiler/share/classes/javax/lang/model/util/Type > KindVisitor9.java > * @since 1.9 > ./langtools/src/java.compiler/share/classes/javax/lang/model/util/AbstractElementVisitor9.java > * @since 1.9 > ./langtools/src/java.compiler/share/classes/javax/lang/model/SourceVersion.java > * @since 1.9 > ./langtools/src/jdk.compiler/share/classes/com/sun/source/util/TaskEvent.java > * @since 1.9 > * @since 1.9 > * @since 1.9 > * @since 1.9 > * @since 1.9 > * @since 1.9 > ./langtools/src/jdk.compiler/share/classes/com/sun/source/util/DocTree > s.java > * @since 1.9 > ./langtools/src/jdk.compiler/share/classes/com/sun/source/doctree/IndexTree.java > * @since 1.9 > ./langtools/src/jdk.compiler/share/classes/com/sun/source/doctree/DocC > ommentTree.java > * @since 1.9 > ./langtools/src/jdk.compiler/share/classes/com/sun/source/tree/PackageTree.java > * @since 1.9 > ./langtools/src/jdk.compiler/share/classes/com/sun/source/tree/CompilationUnitTree.java > * @since 1.9 > ./langtools/src/jdk.compiler/share/classes/com/sun/source/tree/Tree.ja > va From pbenedict at apache.org Mon Jan 11 20:47:55 2016 From: pbenedict at apache.org (Paul Benedict) Date: Mon, 11 Jan 2016 14:47:55 -0600 Subject: Version and Security Message-ID: I'd like to offer a suggestion. I am late to the game with this idea, but I think it's worth mentioning. Right now I think the proposed encoding is too complex and would like an alternative. I don't think the JDK version string should include any special encoding for security. I believe product versioning and security patch versioning should be made clear by 2 different system properties. There should be an additional "security patch level" property that corresponds to the version (or date) of either OpenJDK and/or Oracle for whatever their statuses are. Example strings: java.version=9.0.1 openjdk.java.security.level=2016-01-02 oracle.java.security.level=2016-01-11 How to interpret this example: Java 9.0.1 has all security patches from OpenJDK since 2016-01-02 and, because my example is using an Oracle JDK, it includes their own proprietary security patches up to 2016-01-11. Cheers, Paul From iris.clark at oracle.com Mon Jan 11 21:44:49 2016 From: iris.clark at oracle.com (Iris Clark) Date: Mon, 11 Jan 2016 13:44:49 -0800 (PST) Subject: RFR: 8072379: Implement jdk.Version and jdk.OracleVersion In-Reply-To: <92b9301d-2418-4618-b877-b13c88216520@default> References: <50765a19-34e4-4115-a32d-cea84c25394e@default> <38DD183B-1D89-4C6F-B759-3F4512656F77@oracle.com> <565628C5.1040905@oracle.com> <92b9301d-2418-4618-b877-b13c88216520@default> Message-ID: <7ca276d8-5e4f-4da2-a1a9-999a0cac9f57@default> Hi, Joe, Roger, Alan, Magnus, and Mandy. At the end of December (shortly before the Christmas/Winter break and my vacation), I provided responses to your messages and an updated webrev: http://cr.openjdk.java.net/~iris/verona/8072379/webrev.2/ I didn't hear from anybody, so I'd like to optimistically assume that you were satisfied. Is that correct? For you convenience, here's a reference to the December and November threads: http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-December/037062.html http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-November/036904.html I'd like to wrap up this work for the initial implementation of jdk.Version soon. Regards, iris -----Original Message----- From: Iris Clark Sent: Friday, December 18, 2015 1:55 PM To: Joe Darcy; Mandy Chung Cc: core-libs-dev at openjdk.java.net; verona-dev at openjdk.java.net Subject: RE: RFR: 8072379: Implement jdk.Version and jdk.OracleVersion Hi, Joe. Thanks for the review comments. >>> http://cr.openjdk.java.net/~irisa/verona/8072379/webrev.1/ > Is the intention that downstream JDK distributions, such as IcedTea, > whether based on OpenJDK or otherwise, would provide their own > specialization of the jdk.Version class? No. Downstream users may provide their own specialization, but there is no requirement that they must do so. jdk.OracleVersion has been removed. The functionality it provided, access to the fourth element of the version number, is trivially accessed by existing methods in jdk.Version. I've filed the following bug to address the more general use case: 8145793: Provide vendor-specific interpretation of a JDK version string https://bugs.openjdk.java.net/browse/JDK-8145793 > The equals / hashCode behavior of Version and OracleVersion is bit > surprising and I think somewhat underspecified given the possibility > of defining subclasses. Given the above regarding downstream use, I've make jdk.Version final and the constructor is now private. Oracle or any other JDK distribution wishing to impose additional semantics to the version string interpretation will need to do so via encapsulation rather than inheritance. > How is this API supposed to behave if the component version strings > have a numerical value greater than Integer.MAX_VALUE? >From the specification of the only instance method, Version.parse(): * @throws NumberFormatException * If an element of the version number or the build number cannot * be represented as an {@link Integer} > Was using Longs to record numerical versions rather than Integers > considered? Yes. In an informal poll conducted during implementation, it was thought that 2^32 bits would be more than sufficient to represent the components of typical version numbers. An updated webrev is forthcoming. Thanks, iris PS: I believe that we are both out the week of 21 December, so I don't expect to hear back from you until the New Year. From forax at univ-mlv.fr Tue Jan 12 12:15:30 2016 From: forax at univ-mlv.fr (Remi Forax) Date: Tue, 12 Jan 2016 13:15:30 +0100 (CET) Subject: Version and Security In-Reply-To: References: Message-ID: <2145153885.683558.1452600930518.JavaMail.zimbra@u-pem.fr> Hi Paul, while using dates to indicate the last security patch is interesting, you want the version of the produced artifact to reflect the security patch level to ease the work of the ops. R?mi ----- Mail original ----- > De: "Paul Benedict" > ?: verona-dev at openjdk.java.net > Envoy?: Lundi 11 Janvier 2016 21:47:55 > Objet: Version and Security > > I'd like to offer a suggestion. I am late to the game with this idea, but I > think it's worth mentioning. Right now I think the proposed encoding is too > complex and would like an alternative. > > I don't think the JDK version string should include any special encoding > for security. I believe product versioning and security patch versioning > should be made clear by 2 different system properties. There should be an > additional "security patch level" property that corresponds to the version > (or date) of either OpenJDK and/or Oracle for whatever their statuses are. > > Example strings: > java.version=9.0.1 > openjdk.java.security.level=2016-01-02 > oracle.java.security.level=2016-01-11 > > How to interpret this example: > Java 9.0.1 has all security patches from OpenJDK since 2016-01-02 and, > because my example is using an Oracle JDK, it includes their own > proprietary security patches up to 2016-01-11. > > Cheers, > Paul > From pbenedict at apache.org Tue Jan 12 13:12:10 2016 From: pbenedict at apache.org (Paul Benedict) Date: Tue, 12 Jan 2016 07:12:10 -0600 Subject: Version and Security In-Reply-To: <2145153885.683558.1452600930518.JavaMail.zimbra@u-pem.fr> References: <2145153885.683558.1452600930518.JavaMail.zimbra@u-pem.fr> Message-ID: Remi, thanks for the reply. I am not sure what you said is very important for ops. You can call the filename installer anything you want and document the patches however. That's what ops are looking for in deciding when/how to upgrade. So that doesn't mean the official versioning of the product has to encode security iterations. I refer back to Martin's email regarding how confusing the last digit is. I don't believe this is the way to go. On Jan 12, 2016 6:16 AM, "Remi Forax" wrote: > Hi Paul, > while using dates to indicate the last security patch is interesting, > you want the version of the produced artifact to reflect the security > patch level to ease the work of the ops. > > R?mi > > ----- Mail original ----- > > De: "Paul Benedict" > > ?: verona-dev at openjdk.java.net > > Envoy?: Lundi 11 Janvier 2016 21:47:55 > > Objet: Version and Security > > > > I'd like to offer a suggestion. I am late to the game with this idea, > but I > > think it's worth mentioning. Right now I think the proposed encoding is > too > > complex and would like an alternative. > > > > I don't think the JDK version string should include any special encoding > > for security. I believe product versioning and security patch versioning > > should be made clear by 2 different system properties. There should be an > > additional "security patch level" property that corresponds to the > version > > (or date) of either OpenJDK and/or Oracle for whatever their statuses > are. > > > > Example strings: > > java.version=9.0.1 > > openjdk.java.security.level=2016-01-02 > > oracle.java.security.level=2016-01-11 > > > > How to interpret this example: > > Java 9.0.1 has all security patches from OpenJDK since 2016-01-02 and, > > because my example is using an Oracle JDK, it includes their own > > proprietary security patches up to 2016-01-11. > > > > Cheers, > > Paul > > > From Alan.Bateman at oracle.com Tue Jan 12 15:41:17 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 12 Jan 2016 15:41:17 +0000 Subject: RFR: 8072379: Implement jdk.Version and jdk.OracleVersion In-Reply-To: <7ca276d8-5e4f-4da2-a1a9-999a0cac9f57@default> References: <50765a19-34e4-4115-a32d-cea84c25394e@default> <38DD183B-1D89-4C6F-B759-3F4512656F77@oracle.com> <565628C5.1040905@oracle.com> <92b9301d-2418-4618-b877-b13c88216520@default> <7ca276d8-5e4f-4da2-a1a9-999a0cac9f57@default> Message-ID: <56951E9D.2040509@oracle.com> On 11/01/2016 21:44, Iris Clark wrote: > Hi, Joe, Roger, Alan, Magnus, and Mandy. > > At the end of December (shortly before the Christmas/Winter > break and my vacation), I provided responses to your messages > and an updated webrev: > > http://cr.openjdk.java.net/~iris/verona/8072379/webrev.2/ > > I didn't hear from anybody, so I'd like to optimistically assume > that you were satisfied. Is that correct? > > For you convenience, here's a reference to the December and November > threads: > > http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-December/037062.html > http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-November/036904.html > > I'd like to wrap up this work for the initial implementation of > jdk.Version soon. > I think this looks good but we'll to decide which module to put this in. It can't be java.base (see design principles in JEP 200). If it's going into java.base temporarily then the top-level modules.xml will need to be updated to export the "jdk" package. -Alan From pbenedict at apache.org Tue Jan 12 16:52:45 2016 From: pbenedict at apache.org (Paul Benedict) Date: Tue, 12 Jan 2016 10:52:45 -0600 Subject: Version and Security In-Reply-To: References: <2145153885.683558.1452600930518.JavaMail.zimbra@u-pem.fr> Message-ID: Remi, one more addition from me. If the intent is really to flag which version has security fixes, you can use a qualifier for that. For example, Spring releases with the .SEC qualifier. The numbering is just an iteration; but no need to specify how many security iterations there has been in the version. Cheers, Paul On Tue, Jan 12, 2016 at 7:12 AM, Paul Benedict wrote: > Remi, thanks for the reply. I am not sure what you said is very important > for ops. You can call the filename installer anything you want and document > the patches however. That's what ops are looking for in deciding when/how > to upgrade. So that doesn't mean the official versioning of the product has > to encode security iterations. I refer back to Martin's email regarding how > confusing the last digit is. I don't believe this is the way to go. > On Jan 12, 2016 6:16 AM, "Remi Forax" wrote: > >> Hi Paul, >> while using dates to indicate the last security patch is interesting, >> you want the version of the produced artifact to reflect the security >> patch level to ease the work of the ops. >> >> R?mi >> >> ----- Mail original ----- >> > De: "Paul Benedict" >> > ?: verona-dev at openjdk.java.net >> > Envoy?: Lundi 11 Janvier 2016 21:47:55 >> > Objet: Version and Security >> > >> > I'd like to offer a suggestion. I am late to the game with this idea, >> but I >> > think it's worth mentioning. Right now I think the proposed encoding is >> too >> > complex and would like an alternative. >> > >> > I don't think the JDK version string should include any special encoding >> > for security. I believe product versioning and security patch versioning >> > should be made clear by 2 different system properties. There should be >> an >> > additional "security patch level" property that corresponds to the >> version >> > (or date) of either OpenJDK and/or Oracle for whatever their statuses >> are. >> > >> > Example strings: >> > java.version=9.0.1 >> > openjdk.java.security.level=2016-01-02 >> > oracle.java.security.level=2016-01-11 >> > >> > How to interpret this example: >> > Java 9.0.1 has all security patches from OpenJDK since 2016-01-02 and, >> > because my example is using an Oracle JDK, it includes their own >> > proprietary security patches up to 2016-01-11. >> > >> > Cheers, >> > Paul >> > >> > From mandy.chung at oracle.com Tue Jan 12 22:25:53 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 12 Jan 2016 14:25:53 -0800 Subject: RFR: 8072379: Implement jdk.Version and jdk.OracleVersion In-Reply-To: <7ca276d8-5e4f-4da2-a1a9-999a0cac9f57@default> References: <50765a19-34e4-4115-a32d-cea84c25394e@default> <38DD183B-1D89-4C6F-B759-3F4512656F77@oracle.com> <565628C5.1040905@oracle.com> <92b9301d-2418-4618-b877-b13c88216520@default> <7ca276d8-5e4f-4da2-a1a9-999a0cac9f57@default> Message-ID: > On Jan 11, 2016, at 1:44 PM, Iris Clark wrote: > > Hi, Joe, Roger, Alan, Magnus, and Mandy. > > At the end of December (shortly before the Christmas/Winter > break and my vacation), I provided responses to your messages > and an updated webrev: > > http://cr.openjdk.java.net/~iris/verona/8072379/webrev.2/ It?s good to see that jdk.OracleVersion has been removed and use jdk.Version to obtain the fourth element of the version number. This patch looks good in general. Minor comment: 273 current = parse(System.getProperty("java.version")); System.getProperty will do a permission check and it needs to be called within a doPrivileged block. 154 * @see JEP 223: New Version-String Scheme Does the javadoc have the essential information from this JEP? Wonder if this @see is necessary. Alan already comment on the ?jdk? package that needs to find the proper module to export it (that?s a future RFE) and modules.xml should be updated. Mandy From joe.darcy at oracle.com Wed Jan 13 01:06:37 2016 From: joe.darcy at oracle.com (Joseph D. Darcy) Date: Tue, 12 Jan 2016 17:06:37 -0800 Subject: RFR: 8072379: Implement jdk.Version and jdk.OracleVersion In-Reply-To: <7ca276d8-5e4f-4da2-a1a9-999a0cac9f57@default> References: <50765a19-34e4-4115-a32d-cea84c25394e@default> <38DD183B-1D89-4C6F-B759-3F4512656F77@oracle.com> <565628C5.1040905@oracle.com> <92b9301d-2418-4618-b877-b13c88216520@default> <7ca276d8-5e4f-4da2-a1a9-999a0cac9f57@default> Message-ID: <5695A31D.1050405@oracle.com> Hi Iris, Catching up on old reviews, the regular expression for versions is given as ^[1-9][0-9]*(((\.0)*\.[1-9][0-9]*)*)*$ Is this equivalent to ^[1-9][0-9]*(\.[0-9])* Trying to put this in words, "The version number starts with a sequence of digits where the leading digit is not "0". Afterward, there are zero or more period separated groups of digits with no restrictions on the digits. Note that this implies The version number ends with a digit group." I suggest changing the class-level javadoc discussing comparisons to defer to the various compare methods. It would be helpful to not which compare methods are consistent with equals and which are not. Thanks, -Joe On 1/11/2016 1:44 PM, Iris Clark wrote: > Hi, Joe, Roger, Alan, Magnus, and Mandy. > > At the end of December (shortly before the Christmas/Winter > break and my vacation), I provided responses to your messages > and an updated webrev: > > http://cr.openjdk.java.net/~iris/verona/8072379/webrev.2/ > > I didn't hear from anybody, so I'd like to optimistically assume > that you were satisfied. Is that correct? > > For you convenience, here's a reference to the December and November > threads: > > http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-December/037062.html > http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-November/036904.html > > I'd like to wrap up this work for the initial implementation of > jdk.Version soon. > > Regards, > iris > > -----Original Message----- > From: Iris Clark > Sent: Friday, December 18, 2015 1:55 PM > To: Joe Darcy; Mandy Chung > Cc: core-libs-dev at openjdk.java.net; verona-dev at openjdk.java.net > Subject: RE: RFR: 8072379: Implement jdk.Version and jdk.OracleVersion > > Hi, Joe. > > Thanks for the review comments. > >>>> http://cr.openjdk.java.net/~irisa/verona/8072379/webrev.1/ >> Is the intention that downstream JDK distributions, such as IcedTea, >> whether based on OpenJDK or otherwise, would provide their own >> specialization of the jdk.Version class? > No. Downstream users may provide their own specialization, but there is no requirement that they must do so. > > jdk.OracleVersion has been removed. The functionality it provided, access to the fourth element of the version number, is trivially accessed by existing methods in jdk.Version. > > I've filed the following bug to address the more general use case: > > 8145793: Provide vendor-specific interpretation of a JDK version string > https://bugs.openjdk.java.net/browse/JDK-8145793 > >> The equals / hashCode behavior of Version and OracleVersion is bit >> surprising and I think somewhat underspecified given the possibility >> of defining subclasses. > Given the above regarding downstream use, I've make jdk.Version final and the constructor is now private. Oracle or any other JDK distribution wishing to impose additional semantics to the version string interpretation will need to do so via encapsulation rather than inheritance. > >> How is this API supposed to behave if the component version strings >> have a numerical value greater than Integer.MAX_VALUE? > From the specification of the only instance method, Version.parse(): > > * @throws NumberFormatException > * If an element of the version number or the build number cannot > * be represented as an {@link Integer} > >> Was using Longs to record numerical versions rather than Integers >> considered? > Yes. In an informal poll conducted during implementation, it was thought that 2^32 bits would be more than sufficient to represent the components of typical version numbers. > > An updated webrev is forthcoming. > > Thanks, > iris > > PS: I believe that we are both out the week of 21 December, so I don't expect to hear back from you until the New Year. From daniel.fuchs at oracle.com Wed Jan 13 09:01:13 2016 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Wed, 13 Jan 2016 10:01:13 +0100 Subject: RFR: 8072379: Implement jdk.Version and jdk.OracleVersion In-Reply-To: <5695A31D.1050405@oracle.com> References: <50765a19-34e4-4115-a32d-cea84c25394e@default> <38DD183B-1D89-4C6F-B759-3F4512656F77@oracle.com> <565628C5.1040905@oracle.com> <92b9301d-2418-4618-b877-b13c88216520@default> <7ca276d8-5e4f-4da2-a1a9-999a0cac9f57@default> <5695A31D.1050405@oracle.com> Message-ID: <56961259.7000503@oracle.com> Hi Joe, On 1/13/16 2:06 AM, Joseph D. Darcy wrote: > Hi Iris, > > Catching up on old reviews, the regular expression for versions is given as > > ^[1-9][0-9]*(((\.0)*\.[1-9][0-9]*)*)*$ > > Is this equivalent to > > ^[1-9][0-9]*(\.[0-9])* Iris's regexp will disallow trailing .0 9.0.1 will match, but 9.0 and 9.0.0 will not - the version should be plain 9 in those latter cases as documented in the javadoc. I believe this is important because it ensures that the version string is always in canonical form, which makes it possible to simply compare the 'versions' list (List) within the various variations of equals... So the regexp matching will eliminate non canonical forms without having to perform further checks down the road. Took me a while to figure it, I had to look at the test to pinpoint it. Now that I understand, I find it quite elegant :-) best regards, -- daniel From forax at univ-mlv.fr Wed Jan 13 09:03:56 2016 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Wed, 13 Jan 2016 10:03:56 +0100 (CET) Subject: Version and Security In-Reply-To: References: <2145153885.683558.1452600930518.JavaMail.zimbra@u-pem.fr> Message-ID: <1103960401.1273224.1452675836370.JavaMail.zimbra@u-pem.fr> Paul, you suggest to have two properties one for the version and of for the security fixes, i just said that i think that it easier if the two information are consolidated into one that is used as artifact name and module version. R?mi ----- Mail original ----- > De: "Paul Benedict" > ?: "Remi Forax" > Cc: verona-dev at openjdk.java.net > Envoy?: Mardi 12 Janvier 2016 17:52:45 > Objet: Re: Version and Security > Remi, one more addition from me. If the intent is really to flag which > version has security fixes, you can use a qualifier for that. For example, > Spring releases with the .SEC qualifier. The numbering is just an iteration; > but no need to specify how many security iterations there has been in the > version. > Cheers, > Paul > On Tue, Jan 12, 2016 at 7:12 AM, Paul Benedict < pbenedict at apache.org > > wrote: > > Remi, thanks for the reply. I am not sure what you said is very important > > for > > ops. You can call the filename installer anything you want and document the > > patches however. That's what ops are looking for in deciding when/how to > > upgrade. So that doesn't mean the official versioning of the product has to > > encode security iterations. I refer back to Martin's email regarding how > > confusing the last digit is. I don't believe this is the way to go. > > > On Jan 12, 2016 6:16 AM, "Remi Forax" < forax at univ-mlv.fr > wrote: > > > > Hi Paul, > > > > > > while using dates to indicate the last security patch is interesting, > > > > > > you want the version of the produced artifact to reflect the security > > > patch > > > level to ease the work of the ops. > > > > > > R?mi > > > > > > ----- Mail original ----- > > > > > > > De: "Paul Benedict" < pbenedict at apache.org > > > > > > > > ?: verona-dev at openjdk.java.net > > > > > > > Envoy?: Lundi 11 Janvier 2016 21:47:55 > > > > > > > Objet: Version and Security > > > > > > > > > > > > > > I'd like to offer a suggestion. I am late to the game with this idea, > > > > but > > > > I > > > > > > > think it's worth mentioning. Right now I think the proposed encoding is > > > > too > > > > > > > complex and would like an alternative. > > > > > > > > > > > > > > I don't think the JDK version string should include any special > > > > encoding > > > > > > > for security. I believe product versioning and security patch > > > > versioning > > > > > > > should be made clear by 2 different system properties. There should be > > > > an > > > > > > > additional "security patch level" property that corresponds to the > > > > version > > > > > > > (or date) of either OpenJDK and/or Oracle for whatever their statuses > > > > are. > > > > > > > > > > > > > > Example strings: > > > > > > > java.version=9.0.1 > > > > > > > openjdk.java.security.level=2016-01-02 > > > > > > > oracle.java.security.level=2016-01-11 > > > > > > > > > > > > > > How to interpret this example: > > > > > > > Java 9.0.1 has all security patches from OpenJDK since 2016-01-02 and, > > > > > > > because my example is using an Oracle JDK, it includes their own > > > > > > > proprietary security patches up to 2016-01-11. > > > > > > > > > > > > > > Cheers, > > > > > > > Paul > > > > > > > > > > From iris.clark at oracle.com Wed Jan 13 21:54:44 2016 From: iris.clark at oracle.com (Iris Clark) Date: Wed, 13 Jan 2016 13:54:44 -0800 (PST) Subject: RFR: 8072379: Implement jdk.Version and jdk.OracleVersion In-Reply-To: <56951E9D.2040509@oracle.com> References: <50765a19-34e4-4115-a32d-cea84c25394e@default> <38DD183B-1D89-4C6F-B759-3F4512656F77@oracle.com> <565628C5.1040905@oracle.com> <92b9301d-2418-4618-b877-b13c88216520@default> <7ca276d8-5e4f-4da2-a1a9-999a0cac9f57@default> <56951E9D.2040509@oracle.com> Message-ID: Hi, Alan. Thanks for looking at this (hopefully) one last time. > It can't be java.base (see design principles in JEP 200). > If it's going into java.base temporarily then the top-level > modules.xml will need to be updated to export the "jdk" package. This diff has been applied to modules.xml: diff -r 6fefc5bce180 modules.xml --- a/modules.xml Wed Jan 13 13:56:19 2016 +0000 +++ b/modules.xml Wed Jan 13 13:46:56 2016 -0800 @@ -205,6 +205,9 @@ javax.security.cert + jdk + + jdk.net It essentially reverts your 8049422 change [0] to that file. I will not re-add jdk to the javadoc bundle for javac trees API since that is not an appropriate location. I filed the following bug to track publication of jdk.Version: 8144069: Determine correct publication for jdk.Version API https://bugs.openjdk.java.net/browse/JDK-8144069 When this came up earlier, I filed this bug to track finding a more appropriate module for jdk.Version: 8144062: Determine appropriate module for jdk.Version https://bugs.openjdk.java.net/browse/JDK-8144062 Thanks, iris [0] http://hg.openjdk.java.net/jdk9/dev/rev/1bee5efa73e3 -----Original Message----- From: Alan Bateman Sent: Tuesday, January 12, 2016 7:41 AM To: Iris Clark; core-libs-dev at openjdk.java.net; verona-dev at openjdk.java.net Subject: Re: RFR: 8072379: Implement jdk.Version and jdk.OracleVersion On 11/01/2016 21:44, Iris Clark wrote: > Hi, Joe, Roger, Alan, Magnus, and Mandy. > > At the end of December (shortly before the Christmas/Winter break and > my vacation), I provided responses to your messages and an updated > webrev: > > http://cr.openjdk.java.net/~iris/verona/8072379/webrev.2/ > > I didn't hear from anybody, so I'd like to optimistically assume that > you were satisfied. Is that correct? > > For you convenience, here's a reference to the December and November > threads: > > http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-December/037062.html > > http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-November/036 > 904.html > > I'd like to wrap up this work for the initial implementation of > jdk.Version soon. > I think this looks good but we'll to decide which module to put this in. It can't be java.base (see design principles in JEP 200). If it's going into java.base temporarily then the top-level modules.xml will need to be updated to export the "jdk" package. -Alan From iris.clark at oracle.com Thu Jan 14 05:27:04 2016 From: iris.clark at oracle.com (Iris Clark) Date: Wed, 13 Jan 2016 21:27:04 -0800 (PST) Subject: RFR: 8072379: Implement jdk.Version and jdk.OracleVersion In-Reply-To: References: <50765a19-34e4-4115-a32d-cea84c25394e@default> <38DD183B-1D89-4C6F-B759-3F4512656F77@oracle.com> <565628C5.1040905@oracle.com> <92b9301d-2418-4618-b877-b13c88216520@default> <7ca276d8-5e4f-4da2-a1a9-999a0cac9f57@default> Message-ID: Hi, Mandy. Thanks for looking at this webrev again. > 273 current = parse(System.getProperty("java.version")); > > System.getProperty will do a permission check and it needs to be called within a doPrivileged block. Nice catch! I've added the permission check and the associated @throws. > 154 * @see JEP 223: New Version-String Scheme > > Does the javadoc have the essential information from this JEP? Wonder if this @see is necessary. I thought it might be nice to include the JEP reference as it contains additional data about versioning beyond the JavaDoc for this method; however, it's not critical to the understanding or use of this class. For some reason I'd thought that there was precedence in including JEP numbers as @see references, but I find no evidence of that. I've removed the @see. These are the diffs to address both of your comments: $ diff Version.java_save Version.java 28a29,30 > import java.security.AccessController; > import java.security.PrivilegedAction; 154,155d155 < * @see JEP 223: New Version-String Scheme < * 268a269,274 > * @throws SecurityException > * If a security manager exists and its {@link > * SecurityManager#checkPropertyAccess(String) > * checkPropertyAccess} method does not allow access to the > * system property "java.version" > * 272,273c278,285 < if (current == null) < current = parse(System.getProperty("java.version")); --- > if (current == null) { > current = parse(AccessController.doPrivileged( > new PrivilegedAction<>() { > public String run() { > return System.getProperty("java.version"); > } > })); > } Regards, iris -----Original Message----- From: Mandy Chung Sent: Tuesday, January 12, 2016 2:26 PM To: Iris Clark Cc: Mandy Chung; Joe Darcy; Magnus Ihse Bursie; Roger Riggs; Alan Bateman; core-libs-dev; verona-dev at openjdk.java.net Subject: Re: RFR: 8072379: Implement jdk.Version and jdk.OracleVersion > On Jan 11, 2016, at 1:44 PM, Iris Clark wrote: > > Hi, Joe, Roger, Alan, Magnus, and Mandy. > > At the end of December (shortly before the Christmas/Winter break and > my vacation), I provided responses to your messages and an updated > webrev: > > http://cr.openjdk.java.net/~iris/verona/8072379/webrev.2/ It?s good to see that jdk.OracleVersion has been removed and use jdk.Version to obtain the fourth element of the version number. This patch looks good in general. Minor comment: 273 current = parse(System.getProperty("java.version")); System.getProperty will do a permission check and it needs to be called within a doPrivileged block. 154 * @see JEP 223: New Version-String Scheme Does the javadoc have the essential information from this JEP? Wonder if this @see is necessary. Alan already comment on the ?jdk? package that needs to find the proper module to export it (that?s a future RFE) and modules.xml should be updated. Mandy From joe.darcy at oracle.com Thu Jan 14 06:56:21 2016 From: joe.darcy at oracle.com (joe darcy) Date: Wed, 13 Jan 2016 22:56:21 -0800 Subject: RFR: 8072379: Implement jdk.Version and jdk.OracleVersion In-Reply-To: <56961259.7000503@oracle.com> References: <50765a19-34e4-4115-a32d-cea84c25394e@default> <38DD183B-1D89-4C6F-B759-3F4512656F77@oracle.com> <565628C5.1040905@oracle.com> <92b9301d-2418-4618-b877-b13c88216520@default> <7ca276d8-5e4f-4da2-a1a9-999a0cac9f57@default> <5695A31D.1050405@oracle.com> <56961259.7000503@oracle.com> Message-ID: <56974695.7020800@oracle.com> Hi Daniel, On 1/13/2016 1:01 AM, Daniel Fuchs wrote: > Hi Joe, > > On 1/13/16 2:06 AM, Joseph D. Darcy wrote: >> Hi Iris, >> >> Catching up on old reviews, the regular expression for versions is >> given as >> >> ^[1-9][0-9]*(((\.0)*\.[1-9][0-9]*)*)*$ >> >> Is this equivalent to >> >> ^[1-9][0-9]*(\.[0-9])* > > > Iris's regexp will disallow trailing .0 > > 9.0.1 will match, but 9.0 and 9.0.0 will not - the version should > be plain 9 in those latter cases as documented in the javadoc. > > I believe this is important because it ensures that the version string > is always in canonical form, which makes it possible to simply compare > the 'versions' list (List) within the various variations > of equals... > > So the regexp matching will eliminate non canonical forms without > having to perform further checks down the road. > Took me a while to figure it, I had to look at the test to > pinpoint it. Now that I understand, I find it quite elegant :-) Ah okay, I missed those points when reading over the regular expression. I suggest some discussion be added to explain and document that those aspects of the design are intentional. Thanks, -Joe From dmitry.samersoff at oracle.com Thu Jan 14 08:58:14 2016 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Thu, 14 Jan 2016 11:58:14 +0300 Subject: RFR: 8072379: Implement jdk.Version and jdk.OracleVersion In-Reply-To: <50765a19-34e4-4115-a32d-cea84c25394e@default> References: <50765a19-34e4-4115-a32d-cea84c25394e@default> Message-ID: <56976326.7040809@oracle.com> Iris, Did you consider to split version string into array of groups first (using String.split()), then validate each group separately? It may make the code better readable and more resilient to possible future changes. -Dmitry On 2015-11-25 04:54, Iris Clark wrote: > Hi. > > Please review the new classes jdk.Version and jdk.OracleVersion. These are > simple Java APIs to parse, validate, and compare version numbers. > > Bug > > 8072379: Implement jdk.Version and jdk.OracleVersion > https://bugs.openjdk.java.net/browse/JDK-8072379 > > Webrev > > http://cr.openjdk.java.net/~iris/verona/8072379/webrev.1/ > > JavaDoc > > http://cr.openjdk.java.net/~iris/verona/8072379/doc.1/jdk/Version.html > http://cr.openjdk.java.net/~iris/verona/8072379/doc.1/jdk/OracleVersion.html > > The .java files are predominantly javadoc. The code is relatively > straight-forward. > > jdk.Version is the representation of the JDK version string as described in > JEP 223 ([0], 8061493). The javadoc is largely taken from the description > section in the JEP. The API is described in the "API" section. > > jdk.OracleVersion extends jdk.Version and is the representation of the Oracle > JDK version string. Its only purpose is to interpret the fourth element of > the version number as a patch release. > > There are some minor discrepancies between the implementation and the JEP. > The JEP will need to be updated. The most notable is the name of the package > ("jdk" vs. the original "jdk.util"). The rename was recommended by Mark. > > Thanks, > iris > > [0] http://openjdk.java.net/jeps/223 > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From Alan.Bateman at oracle.com Thu Jan 14 09:54:40 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 14 Jan 2016 09:54:40 +0000 Subject: RFR: 8072379: Implement jdk.Version and jdk.OracleVersion In-Reply-To: References: <50765a19-34e4-4115-a32d-cea84c25394e@default> <38DD183B-1D89-4C6F-B759-3F4512656F77@oracle.com> <565628C5.1040905@oracle.com> <92b9301d-2418-4618-b877-b13c88216520@default> <7ca276d8-5e4f-4da2-a1a9-999a0cac9f57@default> <56951E9D.2040509@oracle.com> Message-ID: <56977060.1060001@oracle.com> On 13/01/2016 21:54, Iris Clark wrote: > : > This diff has been applied to modules.xml: This looks okay. > : > > When this came up earlier, I filed this bug to track finding > a more appropriate module for jdk.Version: > > 8144062: Determine appropriate module for jdk.Version > https://bugs.openjdk.java.net/browse/JDK-8144062 > Thanks, I've changed this to be a P2 as we will need to decide on this soon. -Alan. From magnus.ihse.bursie at oracle.com Thu Jan 14 10:38:00 2016 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 14 Jan 2016 11:38:00 +0100 Subject: Improve $OPT on current EA builds In-Reply-To: <567FBBC7.9060106@gmx.net> References: <567FBBC7.9060106@gmx.net> Message-ID: <56977A88.7000201@oracle.com> On 2015-12-27 11:21, Michael Osipov wrote: > Hi folks, > > just tried Java 9 build 99 and noticed that $OPT of JEP 223 is not > easily parseable/not a valid ISO date: > > java --version >> Java(TM) SE Runtime Environment (build >> 9-ea+99-2015-12-23-183325.javare.4146.nc) > > Can you kindly file an issue to make that a proper basic ISO datetime > string? Date format would be here yyyyMMdd'T'HHmmss'Z' with timezone > Etc/UTC as in DateTimeFormatter#basicDateTimeNoMillis. Michael, The OPT string is a free-form string, the contents of which are not specified in JEP 223. If a user-specified opt string is not specified, the build system makes up a default opt string. This uses some heuristics to form a more-or-less unique string, based on the current time, user name and base directory name. However, you should not rely on the opt string to really *mean* something. If you want to pass a date string with a specific format for use in your internal processes, please use the --with-version-opt argument to configure. /Magnus From magnus.ihse.bursie at oracle.com Thu Jan 14 11:38:17 2016 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 14 Jan 2016 12:38:17 +0100 Subject: RFR: 8072379: Implement jdk.Version and jdk.OracleVersion In-Reply-To: <7ca276d8-5e4f-4da2-a1a9-999a0cac9f57@default> References: <50765a19-34e4-4115-a32d-cea84c25394e@default> <38DD183B-1D89-4C6F-B759-3F4512656F77@oracle.com> <565628C5.1040905@oracle.com> <92b9301d-2418-4618-b877-b13c88216520@default> <7ca276d8-5e4f-4da2-a1a9-999a0cac9f57@default> Message-ID: <569788A9.3010509@oracle.com> On 2016-01-11 22:44, Iris Clark wrote: > Hi, Joe, Roger, Alan, Magnus, and Mandy. > > At the end of December (shortly before the Christmas/Winter > break and my vacation), I provided responses to your messages > and an updated webrev: > > http://cr.openjdk.java.net/~iris/verona/8072379/webrev.2/ > > I didn't hear from anybody, so I'd like to optimistically assume > that you were satisfied. Is that correct? I'm basically happy. As other reviewers, I think the regexes are a bit tough to parse (regexes always are), and some additional comments on the effect would be appreciated. Thanh Hong Dai had some good suggestions as well on how to improve readability. I noted that your java source file had a lot of initial tabs instead of spaces. I'm not sure if we have any code guidelines about this, but I have not encountered that in the JDK source base before, so I'd recommend you turn them into spaces. /Magnus > > For you convenience, here's a reference to the December and November > threads: > > http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-December/037062.html > http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-November/036904.html > > I'd like to wrap up this work for the initial implementation of > jdk.Version soon. > > Regards, > iris > > -----Original Message----- > From: Iris Clark > Sent: Friday, December 18, 2015 1:55 PM > To: Joe Darcy; Mandy Chung > Cc: core-libs-dev at openjdk.java.net; verona-dev at openjdk.java.net > Subject: RE: RFR: 8072379: Implement jdk.Version and jdk.OracleVersion > > Hi, Joe. > > Thanks for the review comments. > >>>> http://cr.openjdk.java.net/~irisa/verona/8072379/webrev.1/ >> Is the intention that downstream JDK distributions, such as IcedTea, >> whether based on OpenJDK or otherwise, would provide their own >> specialization of the jdk.Version class? > No. Downstream users may provide their own specialization, but there is no requirement that they must do so. > > jdk.OracleVersion has been removed. The functionality it provided, access to the fourth element of the version number, is trivially accessed by existing methods in jdk.Version. > > I've filed the following bug to address the more general use case: > > 8145793: Provide vendor-specific interpretation of a JDK version string > https://bugs.openjdk.java.net/browse/JDK-8145793 > >> The equals / hashCode behavior of Version and OracleVersion is bit >> surprising and I think somewhat underspecified given the possibility >> of defining subclasses. > Given the above regarding downstream use, I've make jdk.Version final and the constructor is now private. Oracle or any other JDK distribution wishing to impose additional semantics to the version string interpretation will need to do so via encapsulation rather than inheritance. > >> How is this API supposed to behave if the component version strings >> have a numerical value greater than Integer.MAX_VALUE? > From the specification of the only instance method, Version.parse(): > > * @throws NumberFormatException > * If an element of the version number or the build number cannot > * be represented as an {@link Integer} > >> Was using Longs to record numerical versions rather than Integers >> considered? > Yes. In an informal poll conducted during implementation, it was thought that 2^32 bits would be more than sufficient to represent the components of typical version numbers. > > An updated webrev is forthcoming. > > Thanks, > iris > > PS: I believe that we are both out the week of 21 December, so I don't expect to hear back from you until the New Year. From iris.clark at oracle.com Thu Jan 14 15:48:49 2016 From: iris.clark at oracle.com (Iris Clark) Date: Thu, 14 Jan 2016 07:48:49 -0800 (PST) Subject: RFR: 8072379: Implement jdk.Version and jdk.OracleVersion In-Reply-To: <569788A9.3010509@oracle.com> References: <50765a19-34e4-4115-a32d-cea84c25394e@default> <38DD183B-1D89-4C6F-B759-3F4512656F77@oracle.com> <565628C5.1040905@oracle.com> <92b9301d-2418-4618-b877-b13c88216520@default> <7ca276d8-5e4f-4da2-a1a9-999a0cac9f57@default> <569788A9.3010509@oracle.com> Message-ID: Hi, Magnus. Thanks for taking the time to look at this again. > I noted that your java source file had a lot of initial tabs instead of spaces. > I'm not sure if we have any code guidelines about this, jcheck prevents tabs in comments and source. I remove them, one of my editors adds them when I make changes. It's annoying. They won't be in the checked in source. Regards, iris -----Original Message----- From: Magnus Ihse Bursie Sent: Thursday, January 14, 2016 3:38 AM To: Iris Clark; Joe Darcy; Mandy Chung; Roger Riggs; Alan Bateman Cc: core-libs-dev at openjdk.java.net; verona-dev at openjdk.java.net Subject: Re: RFR: 8072379: Implement jdk.Version and jdk.OracleVersion On 2016-01-11 22:44, Iris Clark wrote: > Hi, Joe, Roger, Alan, Magnus, and Mandy. > > At the end of December (shortly before the Christmas/Winter break and > my vacation), I provided responses to your messages and an updated > webrev: > > http://cr.openjdk.java.net/~iris/verona/8072379/webrev.2/ > > I didn't hear from anybody, so I'd like to optimistically assume that > you were satisfied. Is that correct? I'm basically happy. As other reviewers, I think the regexes are a bit tough to parse (regexes always are), and some additional comments on the effect would be appreciated. Thanh Hong Dai had some good suggestions as well on how to improve readability. I noted that your java source file had a lot of initial tabs instead of spaces. I'm not sure if we have any code guidelines about this, but I have not encountered that in the JDK source base before, so I'd recommend you turn them into spaces. /Magnus > > For you convenience, here's a reference to the December and November > threads: > > http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-December/037062.html > > http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-November/036 > 904.html > > I'd like to wrap up this work for the initial implementation of > jdk.Version soon. > > Regards, > iris > > -----Original Message----- > From: Iris Clark > Sent: Friday, December 18, 2015 1:55 PM > To: Joe Darcy; Mandy Chung > Cc: core-libs-dev at openjdk.java.net; verona-dev at openjdk.java.net > Subject: RE: RFR: 8072379: Implement jdk.Version and jdk.OracleVersion > > Hi, Joe. > > Thanks for the review comments. > >>>> http://cr.openjdk.java.net/~irisa/verona/8072379/webrev.1/ >> Is the intention that downstream JDK distributions, such as IcedTea, >> whether based on OpenJDK or otherwise, would provide their own >> specialization of the jdk.Version class? > No. Downstream users may provide their own specialization, but there is no requirement that they must do so. > > jdk.OracleVersion has been removed. The functionality it provided, access to the fourth element of the version number, is trivially accessed by existing methods in jdk.Version. > > I've filed the following bug to address the more general use case: > > 8145793: Provide vendor-specific interpretation of a JDK version string > https://bugs.openjdk.java.net/browse/JDK-8145793 > >> The equals / hashCode behavior of Version and OracleVersion is bit >> surprising and I think somewhat underspecified given the possibility >> of defining subclasses. > Given the above regarding downstream use, I've make jdk.Version final and the constructor is now private. Oracle or any other JDK distribution wishing to impose additional semantics to the version string interpretation will need to do so via encapsulation rather than inheritance. > >> How is this API supposed to behave if the component version strings >> have a numerical value greater than Integer.MAX_VALUE? > From the specification of the only instance method, Version.parse(): > > * @throws NumberFormatException > * If an element of the version number or the build number cannot > * be represented as an {@link Integer} > >> Was using Longs to record numerical versions rather than Integers >> considered? > Yes. In an informal poll conducted during implementation, it was thought that 2^32 bits would be more than sufficient to represent the components of typical version numbers. > > An updated webrev is forthcoming. > > Thanks, > iris > > PS: I believe that we are both out the week of 21 December, so I don't expect to hear back from you until the New Year. From mandy.chung at oracle.com Thu Jan 14 15:59:07 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 14 Jan 2016 07:59:07 -0800 Subject: RFR: 8072379: Implement jdk.Version and jdk.OracleVersion In-Reply-To: References: <50765a19-34e4-4115-a32d-cea84c25394e@default> <38DD183B-1D89-4C6F-B759-3F4512656F77@oracle.com> <565628C5.1040905@oracle.com> <92b9301d-2418-4618-b877-b13c88216520@default> <7ca276d8-5e4f-4da2-a1a9-999a0cac9f57@default> Message-ID: <03FABAC5-9DF0-4A33-ADCA-C0F8EDFC3B85@oracle.com> > On Jan 13, 2016, at 9:27 PM, Iris Clark wrote: > > These are the diffs to address both of your comments: > > $ diff Version.java_save Version.java > 28a29,30 >> import java.security.AccessController; >> import java.security.PrivilegedAction; > 154,155d155 > < * @see JEP 223: New Version-String Scheme > < * > 268a269,274 >> * @throws SecurityException >> * If a security manager exists and its {@link >> * SecurityManager#checkPropertyAccess(String) >> * checkPropertyAccess} method does not allow access to the >> * system property "java.version" >> * > 272,273c278,285 > < if (current == null) > < current = parse(System.getProperty("java.version")); > --- >> if (current == null) { >> current = parse(AccessController.doPrivileged( >> new PrivilegedAction<>() { >> public String run() { >> return System.getProperty("java.version"); >> } >> })); >> } Looks fine. Thanks Mandy From hdthanh at tma.com.vn Thu Jan 14 03:53:22 2016 From: hdthanh at tma.com.vn (Thanh Hong Dai) Date: Thu, 14 Jan 2016 10:53:22 +0700 Subject: RFR: 8072379: Implement jdk.Version and jdk.OracleVersion In-Reply-To: References: <50765a19-34e4-4115-a32d-cea84c25394e@default> <38DD183B-1D89-4C6F-B759-3F4512656F77@oracle.com> <565628C5.1040905@oracle.com> <92b9301d-2418-4618-b877-b13c88216520@default> <7ca276d8-5e4f-4da2-a1a9-999a0cac9f57@default> <56951E9D.2040509@oracle.com> Message-ID: <04d501d14e7f$1ee19b50$5ca4d1f0$@tma.com.vn> Hi, Some comment on the regex (and also the JEP): ([1-9][0-9]*(((\.0)*\.[1-9][0-9]*)*)*)(\-([a-zA-Z0-9]+))?((\+)(0|[1-9][0-9]*)?)?(-([\-a-zA-Z0-9\.]+))? - The outer most quantifier in (((\.0)*\.[1-9][0-9]*)*)* is redundant and a source of catastrophic backtracking. You only need ((\.0)*\.[1-9][0-9]*)*. - The outside - in PRE part (\-([a-zA-Z0-9]+))? doesn't need escaping. Simplify it to (-([a-zA-Z0-9]+))? - Do you want to allow only a plus without the number in the BUILD part? Why do you capture the +? ((\+)(0|[1-9][0-9]*)?)? - Dot loses meaning in the character class, and hyphen loses meaning at the beginning or at the end of the character class. You can simplify the OPT part to (-([-a-zA-Z0-9.]+))? - You might want to consider using named-capturing groups instead of numbered capturing groups. Also, consider using non-capturing groups for groups you don't need to extract. Best regards, Hong Dai Thanh. -----Original Message----- From: core-libs-dev [mailto:core-libs-dev-bounces at openjdk.java.net] On Behalf Of Iris Clark Sent: Thursday, 14 January, 2016 4:55 AM To: Alan Bateman ; core-libs-dev at openjdk.java.net; verona-dev at openjdk.java.net Subject: RE: RFR: 8072379: Implement jdk.Version and jdk.OracleVersion Hi, Alan. Thanks for looking at this (hopefully) one last time. > It can't be java.base (see design principles in JEP 200). > If it's going into java.base temporarily then the top-level > modules.xml will need to be updated to export the "jdk" package. This diff has been applied to modules.xml: diff -r 6fefc5bce180 modules.xml --- a/modules.xml Wed Jan 13 13:56:19 2016 +0000 +++ b/modules.xml Wed Jan 13 13:46:56 2016 -0800 @@ -205,6 +205,9 @@ javax.security.cert + jdk + + jdk.net It essentially reverts your 8049422 change [0] to that file. I will not re-add jdk to the javadoc bundle for javac trees API since that is not an appropriate location. I filed the following bug to track publication of jdk.Version: 8144069: Determine correct publication for jdk.Version API https://bugs.openjdk.java.net/browse/JDK-8144069 When this came up earlier, I filed this bug to track finding a more appropriate module for jdk.Version: 8144062: Determine appropriate module for jdk.Version https://bugs.openjdk.java.net/browse/JDK-8144062 Thanks, iris [0] http://hg.openjdk.java.net/jdk9/dev/rev/1bee5efa73e3 -----Original Message----- From: Alan Bateman Sent: Tuesday, January 12, 2016 7:41 AM To: Iris Clark; core-libs-dev at openjdk.java.net; verona-dev at openjdk.java.net Subject: Re: RFR: 8072379: Implement jdk.Version and jdk.OracleVersion On 11/01/2016 21:44, Iris Clark wrote: > Hi, Joe, Roger, Alan, Magnus, and Mandy. > > At the end of December (shortly before the Christmas/Winter break and > my vacation), I provided responses to your messages and an updated > webrev: > > http://cr.openjdk.java.net/~iris/verona/8072379/webrev.2/ > > I didn't hear from anybody, so I'd like to optimistically assume that > you were satisfied. Is that correct? > > For you convenience, here's a reference to the December and November > threads: > > > http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-December/037 > 062.html > > http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-November/036 > 904.html > > I'd like to wrap up this work for the initial implementation of > jdk.Version soon. > I think this looks good but we'll to decide which module to put this in. It can't be java.base (see design principles in JEP 200). If it's going into java.base temporarily then the top-level modules.xml will need to be updated to export the "jdk" package. -Alan From victor2 at ukr.net Thu Jan 14 09:36:09 2016 From: victor2 at ukr.net (Victor Polischuk) Date: Thu, 14 Jan 2016 11:36:09 +0200 Subject: RFR: 8072379: Implement jdk.Version and jdk.OracleVersion In-Reply-To: <7ca276d8-5e4f-4da2-a1a9-999a0cac9f57@default> References: <50765a19-34e4-4115-a32d-cea84c25394e@default> <38DD183B-1D89-4C6F-B759-3F4512656F77@oracle.com> <565628C5.1040905@oracle.com> <92b9301d-2418-4618-b877-b13c88216520@default> <7ca276d8-5e4f-4da2-a1a9-999a0cac9f57@default> Message-ID: <1452763568.271873285.enbp1j4a@frv39.fwdcdn.com> Hi Iris, Do you consider an option to let community reuse JDK versioning style for their own purposes. Probably defining an interface with basic default methods which can be extended by various libraries to provide unified way to gather version information from MANIFEST.MF, ClassLoader's jars and simply to allow developers inventing one wheel lesser. ? /Victor --- Original message --- From: "Iris Clark" Date: 11 January 2016, 23:45:56 > Hi, Joe, Roger, Alan, Magnus, and Mandy. > > At the end of December (shortly before the Christmas/Winter > break and my vacation), I provided responses to your messages > and an updated webrev: > > http://cr.openjdk.java.net/~iris/verona/8072379/webrev.2/ > > I didn't hear from anybody, so I'd like to optimistically assume > that you were satisfied. Is that correct? > > For you convenience, here's a reference to the December and November > threads: > > http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-December/037062.html > http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-November/036904.html > > I'd like to wrap up this work for the initial implementation of > jdk.Version soon. > > Regards, > iris From alex.buckley at oracle.com Thu Jan 14 22:18:06 2016 From: alex.buckley at oracle.com (Alex Buckley) Date: Thu, 14 Jan 2016 14:18:06 -0800 Subject: JNI and JVM TI version numbers In-Reply-To: <568D69A2.5000705@oracle.com> References: <5681252E.70407@oracle.com> <73bd1e74-7db9-41d3-85f0-bb6e340a8fbd@default> <568D69A2.5000705@oracle.com> Message-ID: <56981E9E.9090005@oracle.com> On 1/6/2016 11:23 AM, Daniel D. Daugherty wrote: > I've heard rumblings about the need to make JVM/TI changes due to > JigSaw so it makes sense the change the JVM/TI version number at > the same time. As Alan mentioned, JVM/TI versions weren't tied > to JDK releases so changing the major version from '1' to '9' > could be done at this time if we feel that aligning the JVM/TI > version number with the new Verona scheme has some value. > > IMHO, I don't think we need to match the new Verona scheme for > JVM/TI since it has historically been independent of JDK release > numbers. > > As for JNI version numbers, I don't think we've been consistent > about setting the version number to match the current JDK release, > but when we do update it we try to match the current JDK release > that contains the motivating API change... The Java Language Spec and JVM Spec used to have versions independent of JDK release numbers. For example, the Third Edition of the JLS corresponded to JDK 5.0, and the Second Edition of the JVMS corresponded to JDK 1.3. Suffice to say that this led to a lack of rigor in producing updates, and maximized confusion for readers. Nowadays these specs are versioned by the Java SE Platform release that controls their content. Even if there were no language changes between Java SE n and Java SE n+1, there would still be a Java language in Java SE n+1, so I would produce a Java SE n+1 Edition of the JLS. As JCP-controlled technologies, JNI and JVM/TI are in the same boat as the Java language and JVM. The clearest thing you can do is adopt the Java SE Platform number and bump your version with every Platform release. Alex From iris.clark at oracle.com Tue Jan 19 23:00:17 2016 From: iris.clark at oracle.com (Iris Clark) Date: Tue, 19 Jan 2016 15:00:17 -0800 (PST) Subject: RFR: 8136494 Update "@since 1.9" to "@since 9" to match java.specification.version In-Reply-To: <80f56f2e-78b5-4b6e-a3ec-1f200ed2118b@default> References: <8bb087f1-2969-49f1-8de8-1069a61e6306@default> <5b78e36f-dc67-4bca-936f-f480f413bede@default> <80f56f2e-78b5-4b6e-a3ec-1f200ed2118b@default> Message-ID: <6e54fd25-d58d-41ad-978c-9f844dc405c9@default> Hi, Lance. Just getting back to this bug. Here's the updated webrev: http://cr.openjdk.java.net/~iris/verona/8136494/webrev.1/ I've sync'd with jdk9/dev as of this morning and verified that only expected changes are in the new patch. Thanks, iris -----Original Message----- From: Iris Clark Sent: Thursday, January 07, 2016 9:06 AM To: Lance Andersen Cc: jdk9-dev at openjdk.java.net; verona-dev at openjdk.java.net Subject: RE: RFR: 8136494 Update "@since 1.9" to "@since 9" to match java.specification.version Hi, Lance. Thanks for the review. I was a bit puzzled by the code you quoted back since it relates to the recent move of VM class, which I didn't touch. It appears that my forest was not sufficiently up-to-date with respect to dev when I did the webrev. The build I launched after I sent out the RFR failed. I'll fix the forest/webrev later today. Regards, iris From: Lance Andersen Sent: Thursday, January 07, 2016 4:35 AM To: Iris Clark Cc: jdk9-dev at openjdk.java.net; verona-dev at openjdk.java.net Subject: Re: RFR: 8136494 Update "@since 1.9" to "@since 9" to match java.specification.version Hi Iris, I think the changes are OK. I would suggest making your description clear for your changes such as: ------ @@ -1019,7 +1019,7 @@ * may be controlled by the {@code -XX:AutoBoxCacheMax=} option. * During VM initialization, java.lang.Integer.IntegerCache.high property * may be set and saved in the private system properties in the - * jdk.internal.misc.VM class. + * sun.misc.VM class. */ ------- for your push. Best Lance From lance.andersen at oracle.com Tue Jan 19 23:07:49 2016 From: lance.andersen at oracle.com (Lance @ Oracle) Date: Tue, 19 Jan 2016 18:07:49 -0500 Subject: RFR: 8136494 Update "@since 1.9" to "@since 9" to match java.specification.version In-Reply-To: <6e54fd25-d58d-41ad-978c-9f844dc405c9@default> References: <8bb087f1-2969-49f1-8de8-1069a61e6306@default> <5b78e36f-dc67-4bca-936f-f480f413bede@default> <80f56f2e-78b5-4b6e-a3ec-1f200ed2118b@default> <6e54fd25-d58d-41ad-978c-9f844dc405c9@default> Message-ID: <13A5F009-9199-4DB5-89A9-1504D5D3A23B@oracle.com> Hi iris Looks fine Best Lance Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com Sent from my iPad > On Jan 19, 2016, at 6:00 PM, Iris Clark wrote: > > Hi, Lance. > > Just getting back to this bug. > > Here's the updated webrev: > > http://cr.openjdk.java.net/~iris/verona/8136494/webrev.1/ > > I've sync'd with jdk9/dev as of this morning and verified > that only expected changes are in the new patch. > > Thanks, > iris > > -----Original Message----- > From: Iris Clark > Sent: Thursday, January 07, 2016 9:06 AM > To: Lance Andersen > Cc: jdk9-dev at openjdk.java.net; verona-dev at openjdk.java.net > Subject: RE: RFR: 8136494 Update "@since 1.9" to "@since 9" to match java.specification.version > > Hi, Lance. > > Thanks for the review. > > I was a bit puzzled by the code you quoted back since it relates to the recent move of VM class, which I didn't touch. It appears that my forest was not sufficiently up-to-date with respect to dev when I did the webrev. The build I launched after I sent out the RFR failed. > > I'll fix the forest/webrev later today. > > Regards, > iris > > > From: Lance Andersen > Sent: Thursday, January 07, 2016 4:35 AM > To: Iris Clark > Cc: jdk9-dev at openjdk.java.net; verona-dev at openjdk.java.net > Subject: Re: RFR: 8136494 Update "@since 1.9" to "@since 9" to match java.specification.version > > Hi Iris, > > I think the changes are OK. I would suggest making your description clear for your changes such as: > > ------ > > @@ -1019,7 +1019,7 @@ > * may be controlled by the {@code -XX:AutoBoxCacheMax=} option. > * During VM initialization, java.lang.Integer.IntegerCache.high property > * may be set and saved in the private system properties in the > - * jdk.internal.misc.VM class. > + * sun.misc.VM class. > */ > > ------- > > for your push. > > Best > Lance From iris.clark at oracle.com Tue Jan 19 23:09:01 2016 From: iris.clark at oracle.com (Iris Clark) Date: Tue, 19 Jan 2016 15:09:01 -0800 (PST) Subject: RFR: 8136494 Update "@since 1.9" to "@since 9" to match java.specification.version In-Reply-To: <13A5F009-9199-4DB5-89A9-1504D5D3A23B@oracle.com> References: <8bb087f1-2969-49f1-8de8-1069a61e6306@default> <5b78e36f-dc67-4bca-936f-f480f413bede@default> <80f56f2e-78b5-4b6e-a3ec-1f200ed2118b@default> <6e54fd25-d58d-41ad-978c-9f844dc405c9@default> <13A5F009-9199-4DB5-89A9-1504D5D3A23B@oracle.com> Message-ID: <86d99f65-0266-4eb6-af5a-f34d98e481a3@default> Thanks! iris ? From: Lance @ Oracle Sent: Tuesday, January 19, 2016 3:08 PM To: Iris Clark Cc: jdk9-dev at openjdk.java.net; verona-dev at openjdk.java.net Subject: Re: RFR: 8136494 Update "@since 1.9" to "@since 9" to match java.specification.version ? Hi iris ? Looks fine ? Best Lance HYPERLINK "http://oracle.com/us/design/oracle-email-sig-198324.gif" Lance Andersen| Principal Member of Technical Staff |?HYPERLINK "tel:+1.781.442.2037"+1.781.442.2037 Oracle?Java Engineering? HYPERLINK "x-apple-data-detectors://34/0"1 Network Drive HYPERLINK "x-apple-data-detectors://34/0"Burlington, MA 01803 HYPERLINK "mailto:Lance.Andersen at oracle.com"Lance.Andersen at oracle.com Sent from my iPad On Jan 19, 2016, at 6:00 PM, Iris Clark wrote: Hi, Lance. Just getting back to this bug. Here's the updated webrev: ?http://cr.openjdk.java.net/~iris/verona/8136494/webrev.1/ I've sync'd with jdk9/dev as of this morning and verified that only expected changes are in the new patch. Thanks, iris -----Original Message----- From: Iris Clark Sent: Thursday, January 07, 2016 9:06 AM To: Lance Andersen Cc: HYPERLINK "mailto:jdk9-dev at openjdk.java.net"jdk9-dev at openjdk.java.net; HYPERLINK "mailto:verona-dev at openjdk.java.net"verona-dev at openjdk.java.net Subject: RE: RFR: 8136494 Update "@since 1.9" to "@since 9" to match java.specification.version Hi, Lance. Thanks for the review. I was a bit puzzled by the code you quoted back since it relates to the recent move of VM class, which I didn't touch. ??It appears that my forest was not sufficiently up-to-date with respect to dev when I did the webrev. ?The build I launched after I sent out the RFR failed. I'll fix the forest/webrev later today. Regards, iris From: Lance Andersen Sent: Thursday, January 07, 2016 4:35 AM To: Iris Clark Cc: HYPERLINK "mailto:jdk9-dev at openjdk.java.net"jdk9-dev at openjdk.java.net; HYPERLINK "mailto:verona-dev at openjdk.java.net"verona-dev at openjdk.java.net Subject: Re: RFR: 8136494 Update "@since 1.9" to "@since 9" to match java.specification.version Hi Iris, I think the changes are OK. ?I would suggest ?making your description clear for your changes such as: ------ @@ -1019,7 +1019,7 @@ ?????* may be controlled by the {@code -XX:AutoBoxCacheMax=} option. ?????* During VM initialization, java.lang.Integer.IntegerCache.high property ?????* may be set and saved in the private system properties in the - ????* jdk.internal.misc.VM class. + ????* sun.misc.VM class. ?????*/ ------- for your push. Best Lance From iris.clark at oracle.com Wed Jan 20 19:43:46 2016 From: iris.clark at oracle.com (Iris Clark) Date: Wed, 20 Jan 2016 11:43:46 -0800 (PST) Subject: RFR: 8136494 Update "@since 1.9" to "@since 9" to match java.specification.version In-Reply-To: <6e54fd25-d58d-41ad-978c-9f844dc405c9@default> References: <8bb087f1-2969-49f1-8de8-1069a61e6306@default> <5b78e36f-dc67-4bca-936f-f480f413bede@default> <80f56f2e-78b5-4b6e-a3ec-1f200ed2118b@default> <6e54fd25-d58d-41ad-978c-9f844dc405c9@default> Message-ID: Hi, Jon. Thanks so much for pushing the changesets for this bug. Regards, iris -----Original Message----- From: Iris Clark Sent: Tuesday, January 19, 2016 3:00 PM To: Iris Clark; Lance Andersen Cc: jdk9-dev at openjdk.java.net; verona-dev at openjdk.java.net Subject: RE: RFR: 8136494 Update "@since 1.9" to "@since 9" to match java.specification.version Hi, Lance. Just getting back to this bug. Here's the updated webrev: http://cr.openjdk.java.net/~iris/verona/8136494/webrev.1/ I've sync'd with jdk9/dev as of this morning and verified that only expected changes are in the new patch. Thanks, iris From goetz.lindenmaier at sap.com Tue Jan 26 16:13:23 2016 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 26 Jan 2016 16:13:23 +0000 Subject: Version special case '9' Message-ID: <4295855A5C1DE049A61835A1887419CC41F20DD2@DEWDFEMB12A.global.corp.sap> Hi, We appreciate the new version scheme introduced with JEP 223. It simplifies the versioning and we agree that it is to it's best downward compatible. Unfortunately there is one exception to this. The initial version of a new major release skips the minor and security digits. This makes parsing the string unnecessarily complicated, because the format is not predictable. In this, the JEP also is inconsistent. In chapter "Dropping the initial 1 element from version numbers" it is argued that comparing "9.0.0" to "1.8.0" by digit will show that 9 is newer than 8. But there is no such version as 9.0.0. This is stated in chapter "Version numbers": "The version number does not include trailing zero elements; i.e., $SECURITY is omitted if it has the value zero, and $MINOR is omitted if both $MINOR and $SECURITY have the value zero." Our BussinessObjects applications parse the option string by Float.parseFloat(System.getProperty("java.version").substring(0,3)) This delivers 1.7 for Java 7, but currently crashes for jdk9, as it tries to parse "9-i" from 9-internal. With trailing .0.0, this would see 9.0 and could parse the Java version until Java 99. As a workaround for this, we are now configuring with --with-version-patch=1 which results in version string 9.0.0.1-internal. At another place, we use split() to analyse the version. if (Integer.parseInt(System.getProperty("java.version").split("\\.")[1]) > 7)) { ... If there are always 3 numbers, this could be fixed to: if (Integer.parseInt(System.getProperty("java.version").split("\\.")[0]) > 7) || Integer.parseInt(System.getProperty("java.version").split("\\.")[1]) > 7)) { ... which was probably in mind when the But with omitting the .0.0, we must also split at '-' and '+': String[] version_elements = System.getProperty("java.version").split("\\.|-|+"); if (Integer.parseInt(version_elements[0]) > 7) || Integer.parseInt(version_elements[1]) > 7)) { ... If you want to check for a version > 9.*.22 it's even more complicated: String[] version_elements = System.getProperty("java.version").split("+|-")[0].split("\\."); if (Integer.parseInt(version_elements[0]) > 9 || (Integer.parseInt(version_elements[0]) == 9 && version_elements.length >= 3 && Integer.parseInt(version_elements[2]) > 22)) { ... So we would appreciate if the JEP was enhanced to always guarantee three version numbers 'x.y.z'. Further, version number 9.0.0.1 breaks the jck test api/java_lang/System/index.html#GetProperty. It fails with: "getJavaSpecVersion0001: Failed. System property 'java.specification.version' does not corresponds to the format 'major.minor.micro'". Maybe a fix of this test is already worked on, we are using jck suite from 9.9.15. Best regards, Goetz. From anthony.vanelverdinghe at gmail.com Wed Jan 27 18:17:05 2016 From: anthony.vanelverdinghe at gmail.com (Anthony Vanelverdinghe) Date: Wed, 27 Jan 2016 19:17:05 +0100 Subject: RFR: 8072379: Implement jdk.Version and jdk.OracleVersion In-Reply-To: <7ca276d8-5e4f-4da2-a1a9-999a0cac9f57@default> References: <50765a19-34e4-4115-a32d-cea84c25394e@default> <38DD183B-1D89-4C6F-B759-3F4512656F77@oracle.com> <565628C5.1040905@oracle.com> <92b9301d-2418-4618-b877-b13c88216520@default> <7ca276d8-5e4f-4da2-a1a9-999a0cac9f57@default> Message-ID: <56A909A1.7080504@gmail.com> Hi Iris There are a few typos in the Version.java of the webrev: - "less than than" - "lexiographically" (2x) - "comparision" Kind regards, Anthony On 11/01/2016 22:44, iris.clark at oracle.com (Iris Clark) wrote: > Hi, Joe, Roger, Alan, Magnus, and Mandy. > > At the end of December (shortly before the Christmas/Winter > break and my vacation), I provided responses to your messages > and an updated webrev: > > http://cr.openjdk.java.net/~iris/verona/8072379/webrev.2/ > > I didn't hear from anybody, so I'd like to optimistically assume > that you were satisfied. Is that correct? > > For you convenience, here's a reference to the December and November > threads: > > http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-December/037062.html > http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-November/036904.html > > I'd like to wrap up this work for the initial implementation of > jdk.Version soon. > > Regards, > iris > > -----Original Message----- > From: Iris Clark > Sent: Friday, December 18, 2015 1:55 PM > To: Joe Darcy; Mandy Chung > Cc: core-libs-dev at openjdk.java.net; verona-dev at openjdk.java.net > Subject: RE: RFR: 8072379: Implement jdk.Version and jdk.OracleVersion > > Hi, Joe. > > Thanks for the review comments. > >>>> http://cr.openjdk.java.net/~irisa/verona/8072379/webrev.1/ >> Is the intention that downstream JDK distributions, such as IcedTea, >> whether based on OpenJDK or otherwise, would provide their own >> specialization of the jdk.Version class? > No. Downstream users may provide their own specialization, but there is no requirement that they must do so. > > jdk.OracleVersion has been removed. The functionality it provided, access to the fourth element of the version number, is trivially accessed by existing methods in jdk.Version. > > I've filed the following bug to address the more general use case: > > 8145793: Provide vendor-specific interpretation of a JDK version string > https://bugs.openjdk.java.net/browse/JDK-8145793 > >> The equals / hashCode behavior of Version and OracleVersion is bit >> surprising and I think somewhat underspecified given the possibility >> of defining subclasses. > Given the above regarding downstream use, I've make jdk.Version final and the constructor is now private. Oracle or any other JDK distribution wishing to impose additional semantics to the version string interpretation will need to do so via encapsulation rather than inheritance. > >> How is this API supposed to behave if the component version strings >> have a numerical value greater than Integer.MAX_VALUE? > >From the specification of the only instance method, Version.parse(): > > * @throws NumberFormatException > * If an element of the version number or the build number cannot > * be represented as an {@link Integer} > >> Was using Longs to record numerical versions rather than Integers >> considered? > Yes. In an informal poll conducted during implementation, it was thought that 2^32 bits would be more than sufficient to represent the components of typical version numbers. > > An updated webrev is forthcoming. > > Thanks, > iris > > PS: I believe that we are both out the week of 21 December, so I don't expect to hear back from you until the New Year. > From iris.clark at oracle.com Wed Jan 27 19:27:40 2016 From: iris.clark at oracle.com (Iris Clark) Date: Wed, 27 Jan 2016 11:27:40 -0800 (PST) Subject: RFR: 8072379: Implement jdk.Version and jdk.OracleVersion In-Reply-To: <56A909A1.7080504@gmail.com> References: <50765a19-34e4-4115-a32d-cea84c25394e@default> <38DD183B-1D89-4C6F-B759-3F4512656F77@oracle.com> <565628C5.1040905@oracle.com> <92b9301d-2418-4618-b877-b13c88216520@default> <7ca276d8-5e4f-4da2-a1a9-999a0cac9f57@default> <56A909A1.7080504@gmail.com> Message-ID: Hi, Anthony. Great timing! I just finished on addressing some of Joe Darcy's concerns regarding the spec for the comparison methods and was going to generate a new webrev and JavaDoc later today or tomorrow. Your typos should be addressed in the updated webrev. Regards, iris -----Original Message----- From: Anthony Vanelverdinghe [mailto:anthony.vanelverdinghe at gmail.com] Sent: Wednesday, January 27, 2016 10:17 AM To: Iris Clark; verona-dev at openjdk.java.net Subject: Re: RFR: 8072379: Implement jdk.Version and jdk.OracleVersion Hi Iris There are a few typos in the Version.java of the webrev: - "less than than" - "lexiographically" (2x) - "comparision" Kind regards, Anthony On 11/01/2016 22:44, iris.clark at oracle.com (Iris Clark) wrote: > Hi, Joe, Roger, Alan, Magnus, and Mandy. > > At the end of December (shortly before the Christmas/Winter break and > my vacation), I provided responses to your messages and an updated > webrev: > > http://cr.openjdk.java.net/~iris/verona/8072379/webrev.2/ > > I didn't hear from anybody, so I'd like to optimistically assume that > you were satisfied. Is that correct? > > For you convenience, here's a reference to the December and November > threads: > > http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-December/037062.html > > http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-November/036 > 904.html > > I'd like to wrap up this work for the initial implementation of > jdk.Version soon. > > Regards, > iris > > -----Original Message----- > From: Iris Clark > Sent: Friday, December 18, 2015 1:55 PM > To: Joe Darcy; Mandy Chung > Cc: core-libs-dev at openjdk.java.net; verona-dev at openjdk.java.net > Subject: RE: RFR: 8072379: Implement jdk.Version and jdk.OracleVersion > > Hi, Joe. > > Thanks for the review comments. > >>>> http://cr.openjdk.java.net/~irisa/verona/8072379/webrev.1/ >> Is the intention that downstream JDK distributions, such as IcedTea, >> whether based on OpenJDK or otherwise, would provide their own >> specialization of the jdk.Version class? > No. Downstream users may provide their own specialization, but there is no requirement that they must do so. > > jdk.OracleVersion has been removed. The functionality it provided, access to the fourth element of the version number, is trivially accessed by existing methods in jdk.Version. > > I've filed the following bug to address the more general use case: > > 8145793: Provide vendor-specific interpretation of a JDK version string > https://bugs.openjdk.java.net/browse/JDK-8145793 > >> The equals / hashCode behavior of Version and OracleVersion is bit >> surprising and I think somewhat underspecified given the possibility >> of defining subclasses. > Given the above regarding downstream use, I've make jdk.Version final and the constructor is now private. Oracle or any other JDK distribution wishing to impose additional semantics to the version string interpretation will need to do so via encapsulation rather than inheritance. > >> How is this API supposed to behave if the component version strings >> have a numerical value greater than Integer.MAX_VALUE? > >From the specification of the only instance method, Version.parse(): > > * @throws NumberFormatException > * If an element of the version number or the build number cannot > * be represented as an {@link Integer} > >> Was using Longs to record numerical versions rather than Integers >> considered? > Yes. In an informal poll conducted during implementation, it was thought that 2^32 bits would be more than sufficient to represent the components of typical version numbers. > > An updated webrev is forthcoming. > > Thanks, > iris > > PS: I believe that we are both out the week of 21 December, so I don't expect to hear back from you until the New Year. > From Alan.Bateman at oracle.com Thu Jan 28 09:05:22 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 28 Jan 2016 09:05:22 +0000 Subject: JNI VERSION CHANGE: RFR: 8145098: JNI GetVersion should return JNI_VERSION_9 In-Reply-To: <56A94C8C.9050306@oracle.com> References: <56A94C8C.9050306@oracle.com> Message-ID: <56A9D9D2.2030208@oracle.com> On 27/01/2016 23:02, Rachel Protacio wrote: > Hello! > > Small but important change for review: updating the JNI_VERSION and in > so doing, changing the format from JNI_VERSION_1_x to JNI_VERSION_x_y > (see code/bug for details). > > Bug: https://bugs.openjdk.java.net/browse/JDK-8145098 > > hotspot repo webrev: http://cr.openjdk.java.net/~rprotacio/JNI_hotspot/ > jdk repo webrev: http://cr.openjdk.java.net/~rprotacio/JNI_jdk/ It would be good if Iris or someone on JEP 223 would comment on this. In JEP 223 then the version number doesn't have trailing zeros and I'm wondering if this should be JNI_VERSION_9 rather than JNI_VERSION_9_0. I brought up the issue of the native interfaces on verona-dev recently [1] and I think Iris was open to having the JEP document this so that there is one document of truth on the version changes. Also just to mention that we have draft updates to the JVM TI spec in the jake forest. As part of that work then we've optimistically rev'ed the JVM TI version so that jvmti.h defines JVMTI_VERSION_9. We should at least be consistent so that both native interfaces are _9 or _9_0. -Alan. [1] http://mail.openjdk.java.net/pipermail/verona-dev/2015-December/000324.html From iris.clark at oracle.com Thu Jan 28 19:16:52 2016 From: iris.clark at oracle.com (Iris Clark) Date: Thu, 28 Jan 2016 11:16:52 -0800 (PST) Subject: RFR: 8072379: Implement jdk.Version and jdk.OracleVersion In-Reply-To: <5695A31D.1050405@oracle.com> References: <50765a19-34e4-4115-a32d-cea84c25394e@default> <38DD183B-1D89-4C6F-B759-3F4512656F77@oracle.com> <565628C5.1040905@oracle.com> <92b9301d-2418-4618-b877-b13c88216520@default> <7ca276d8-5e4f-4da2-a1a9-999a0cac9f57@default> <5695A31D.1050405@oracle.com> Message-ID: Hi, Joe. > I suggest changing the class-level javadoc discussing comparisons > to defer to the various compare methods. It would be helpful to > not which compare methods are consistent with equals and which > are not. I've reworked the class and method javadoc for the comparison methods so that comparison details exist in only one place. I believe that this resolves the remaining spec issue to get an initial implementation of jdk.Version into jdk9/dev. After I've enhanced the regular expression as suggested elsewhere in this thread I'll post the updated webrev. Thanks, iris