From joe.darcy at oracle.com Tue Dec 1 01:32:52 2015 From: joe.darcy at oracle.com (joe darcy) Date: Mon, 30 Nov 2015 17:32:52 -0800 Subject: RFR: 8072379: Implement jdk.Version and jdk.OracleVersion In-Reply-To: <56586A7A.2040007@oracle.com> References: <50765a19-34e4-4115-a32d-cea84c25394e@default> <56586A7A.2040007@oracle.com> Message-ID: <565CF8C4.1020208@oracle.com> Another comment below... On 11/27/2015 6:36 AM, Magnus Ihse Bursie wrote: > On 2015-11-25 02: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/ > > Hi Iris, > > I thought the end agreement was that the + should always be present > even if build was empty, if opt was present but not pre. That is, > "9-foo" should unambigiously parse as vnum=9 and pre="foo", while > "9-+foo" should umambigously parse as vnum=9 and opt="foo". The > javadoc does not seem to reflect this. > > I've also had to read and re-read the regexp and parsing logic in the > constructor to convince myself that this (most likely) will be > correctly handled. Perhaps a few comments around this would be helpful? > > The comparison of two version strings which differs only in "pre" does > not adhere to the principle of astonishment. > > The documentation states: "Pre-release identifiers are compared > numerically when they consist only of digits, and lexiographically > otherwise. Numeric identifiers are considered to be less than > non-numeric identifiers." But consider the following version strings: > > 9-01 > 9-01a > 9-02 > 9-003b > > That sequence would be ordered like this, which I find highly surprising. > 9-01 > 9-02 > 9-003b > 9-01a > > I'm also surprised that equals() does not produce the same result as > compareTo(). If opt is to be ignored, surely it should be so in > equals() as well? > I'm one of the maintainers of BigDecimal, one of the few Comparable classes in the JDK where compareTo is "inconsistent with equals" (see "Effective Java, 2nd edition", Item 12 - Considering implementing Comparable). It is consistently surprising to users if compareTo is inconsistent with equals ;-) Therefore, if at all possible it is preferable to have compareTo be *consistent* rather than *inconsistent* with equals; although there are cases where the inconsistency is necessary or at least defensible. I suggest providing multiple compareFoo methods for version that did or did not include certain components, some of these could be consistent with equals and others not. HTH, -Joe From iris.clark at oracle.com Thu Dec 3 05:14:27 2015 From: iris.clark at oracle.com (Iris Clark) Date: Wed, 2 Dec 2015 21:14:27 -0800 (PST) Subject: Verona (JEP 223) Integration to JDK 9 In-Reply-To: <2c54fc7e-4550-411c-b8f1-603031a808d7@default> References: <2c54fc7e-4550-411c-b8f1-603031a808d7@default> Message-ID: <410a3f39-96ac-431c-9197-883d467d6777@default> Hi. I'm thrilled to report that the Verona integration to jdk9/jdk9 is complete. The changes have been sync'd down to jdk9/dev and jdk9/client. Sync to Other dependent forests is forthcoming. JDK 9 build 95 has been promoted and tagged using the new tag format, "jdk-9+95". Additional work still needs to be done before we can declare Verona complete, but the largest, highest impact changes are now in the JDK 9 release forest. Thanks, Iris P.S. If you have a local copy of jcheck.py [0], please update to the latest version which was modified to accept the new tag format. [0] http://hg.openjdk.java.net/code-tools/jcheck -----Original Message----- From: Iris Clark Sent: Tuesday, November 24, 2015 11:41 AM To: jdk9-dev at openjdk.java.net Cc: Iris Clark; verona-dev at openjdk.java.net Subject: Verona (JEP 223) Integration to JDK 9 Hi. Implementation of the new version-string scheme for OpenJDK (JEP 223 [0]) is nearly complete and we are almost ready to push verona/stage [1] into the JDK 9 release. The changes for Verona were primarily in the build system and the jdk and hotspot repositories to support the modified system properties. Most notably, "java.version" now returns "9" instead of "1.9.0". Additional changes were also needed in a small number of regression tests. The most common problem we've discovered is that applications that detect the version number may include code which assumes that the version string begins with "1." or that there is always a '.' in the version string. As you may recall, we've been using this forest to stage all Reviewed changesets. Now that we are ready to integrate we will use build 95 to integrate all the Project Verona changes as an isolated integration. Other jdk9/* development forests will continue to accumulate changesets for an additional week. Here's the anticipated time line: Thu 26 Nov [ US Thanksgiving ] - jdk9/jdk9 (MASTER) build 94 promotion On or before Mon 30 Nov - Sync verona/stage with jdk9/jdk9 MASTER (build 94) Tues 1 Dec - Integrate verona/stage to jdk9/jdk9 (MASTER) Wed 2 Dec - jdk9/jdk9 build 95 promotion (with Verona) - After promotion, sync down to jdk9/dev and other dependent forests All remaining Verona changes will be pushed to a standard JDK 9 development forest (e.g. jdk9/dev or jdk9/client). The regular integration and promotion schedule will resume with build 96 the week of 7 Dec. Thanks, iris [0] http://openjdk.java.net/jeps/223 [1] http://hg.openjdk.java.net/verona/stage From alejandro.murillo at oracle.com Fri Dec 4 09:37:38 2015 From: alejandro.murillo at oracle.com (Alejandro E Murillo) Date: Fri, 04 Dec 2015 02:37:38 -0700 Subject: Verona (JEP 223) Integration to JDK 9 In-Reply-To: <410a3f39-96ac-431c-9197-883d467d6777@default> References: <2c54fc7e-4550-411c-b8f1-603031a808d7@default> <410a3f39-96ac-431c-9197-883d467d6777@default> Message-ID: <56615EE2.4010300@oracle.com> The changes have also been synched down to jdk9/hs. will be in the hotspot group repos (hs-rt and hs-comp) soon. Thanks Alejandro On 12/2/2015 10:14 PM, Iris Clark wrote: > Hi. > > I'm thrilled to report that the Verona integration to jdk9/jdk9 is complete. > The changes have been sync'd down to jdk9/dev and jdk9/client. Sync to > Other dependent forests is forthcoming. JDK 9 build 95 has been promoted > and tagged using the new tag format, "jdk-9+95". > > Additional work still needs to be done before we can declare Verona > complete, but the largest, highest impact changes are now in the JDK 9 > release forest. > > Thanks, > Iris > > P.S. If you have a local copy of jcheck.py [0], please update to the > latest version which was modified to accept the new tag format. > > [0] http://hg.openjdk.java.net/code-tools/jcheck > > -----Original Message----- > From: Iris Clark > Sent: Tuesday, November 24, 2015 11:41 AM > To: jdk9-dev at openjdk.java.net > Cc: Iris Clark; verona-dev at openjdk.java.net > Subject: Verona (JEP 223) Integration to JDK 9 > > Hi. > > Implementation of the new version-string scheme for OpenJDK (JEP 223 [0]) is nearly complete and we are almost ready to push verona/stage [1] into the JDK 9 release. > > The changes for Verona were primarily in the build system and the jdk and hotspot repositories to support the modified system properties. Most notably, "java.version" now returns "9" instead of "1.9.0". Additional changes were also needed in a small number of regression tests. > > The most common problem we've discovered is that applications that detect the version number may include code which assumes that the version string begins with "1." or that there is always a '.' in the version string. > > As you may recall, we've been using this forest to stage all Reviewed changesets. Now that we are ready to integrate we will use build 95 to integrate all the Project Verona changes as an isolated integration. Other > jdk9/* development forests will continue to accumulate changesets for an additional week. > > Here's the anticipated time line: > > Thu 26 Nov [ US Thanksgiving ] > - jdk9/jdk9 (MASTER) build 94 promotion > > On or before Mon 30 Nov > - Sync verona/stage with jdk9/jdk9 MASTER (build 94) > > Tues 1 Dec > - Integrate verona/stage to jdk9/jdk9 (MASTER) > > Wed 2 Dec > - jdk9/jdk9 build 95 promotion (with Verona) > - After promotion, sync down to jdk9/dev and other dependent forests > > All remaining Verona changes will be pushed to a standard JDK 9 development forest (e.g. jdk9/dev or jdk9/client). The regular integration and promotion schedule will resume with build 96 the week of 7 Dec. > > Thanks, > iris > > [0] http://openjdk.java.net/jeps/223 > [1] http://hg.openjdk.java.net/verona/stage -- Alejandro From martinrb at google.com Tue Dec 8 23:30:12 2015 From: martinrb at google.com (Martin Buchholz) Date: Tue, 8 Dec 2015 15:30:12 -0800 Subject: Suggestions & Questions Message-ID: Hi, I'm one of the people updating all the regexes referring to jdk versions. Version numbers would be more machine parsable if they consistently used simply X.Y.Z as the Semantic Versioning folks suggest, but I can see it's desirable to mark early access versions clearly. Currently we use -ea. In the past -beta and -rc were used as well, and it would be nice if we could predict that. I don't think -beta and -rc proved very useful; I would stick with a single simple predictable -ea. I don't think it's useful to drop the Y and Z just because they're 0. The GA build has historically been special, but "9.0.0" is special enough and familiar and conveys the right expectations. In the real world, the GA build does not get used in production. JEP 223 says, """The sequence of numerals in a version number is compared to another such sequence in numerical, pointwise fashion; e.g., 9.9.1 is less than 9.10.0.""" That's unclear to me - in what way are the version numbers being compared? What does this sort order mean exactly? 9.9.1 is "less" than 9.10.0, but has more security patches applied and was released later in time? """$SECURITY is reset to zero only when $MAJOR is incremented. A higher value of $SECURITY for a given $MAJOR value, therefore, always indicates a more secure release, regardless of the value of $MINOR.""" This is surprising. Users of jdk9 will need to update to new MINOR releases anyways to get their security updates, because old MINOR releases don't get security updates (although icedtea sister project does do that). OTOH people often use multiple MAJOR versions for years, and there it would be more useful to be able to compare security patch levels, especially given that security patches are released simultaneously. But following that logic would require a global incrementing number whenever a security update happens; are we ready for jdk-13.1.43 coincident with jdk-12.4.43? I'd say either always reset $SECURITY to 0 or always increment it - the former is more consistent with Semantic Versioning. Maybe security information "October CPU" could be stuffed into the optional part of the version string? (Google's internal version scheme has also built up serious cruft) From sanne at redhat.com Thu Dec 10 15:48:59 2015 From: sanne at redhat.com (Sanne Grinovero) Date: Thu, 10 Dec 2015 10:48:59 -0500 (EST) Subject: Trouble with commonly used Maven plugins In-Reply-To: <511718707.26689653.1449761292853.JavaMail.zimbra@redhat.com> Message-ID: <622904821.26709662.1449762539292.JavaMail.zimbra@redhat.com> Hello all, Tomaz and myself work respectively on the WildFly and Hibernate teams; Rory O'Donnell kindly sends us reminders about each new JDK preview build so that we use these popular OSS projects and their extensive testsuites to verify early changes to the JDK, and possibly also to get a sense of the impact of changes on larger communities. It turns out that the "plexus-archiver" [1] library fails because of the Verona change; the fix is trivial of course as they just need to adjust the couple of lines which implement a version check, and Tomaz will send it to the Plexus team soon. Still, please consider that this library is very commonly used by build tools. In particular Maven uses it to implement the maven-jar-plugin, maven-source-plugin, and others. But while several of these are optional, the maven-jar-plugin is an essential component for most builds. It's a common pattern among Maven users to run the compilation and packaging with the same JVM as the one running the testsuite, so the unfortunate news here is that it seems a large population will have difficulties in testing JDK9 until this trivial patch to plexus-archiver will make its way in a Plexus release, and then gets picked up by a Maven release. I won't ask you to change or revert things as I agree this is a nice improvement, and thank you all for it! Just bear in mind that migrations and more feedback will be a bit slower than usual. Thanks, Sanne 1 - https://github.com/codehaus-plexus/plexus-archiver From iris.clark at oracle.com Fri Dec 18 21:55:16 2015 From: iris.clark at oracle.com (Iris Clark) Date: Fri, 18 Dec 2015 13:55:16 -0800 (PST) Subject: RFR: 8072379: Implement jdk.Version and jdk.OracleVersion In-Reply-To: <565628C5.1040905@oracle.com> References: <50765a19-34e4-4115-a32d-cea84c25394e@default> <38DD183B-1D89-4C6F-B759-3F4512656F77@oracle.com> <565628C5.1040905@oracle.com> Message-ID: <92b9301d-2418-4618-b877-b13c88216520@default> 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 Fri Dec 18 21:55:42 2015 From: iris.clark at oracle.com (Iris Clark) Date: Fri, 18 Dec 2015 13:55:42 -0800 (PST) Subject: RFR: 8072379: Implement jdk.Version and jdk.OracleVersion In-Reply-To: <565CF8C4.1020208@oracle.com> References: <50765a19-34e4-4115-a32d-cea84c25394e@default> <56586A7A.2040007@oracle.com> <565CF8C4.1020208@oracle.com> Message-ID: <6a1cda33-4134-4529-a97f-5e02c4158e03@default> Hi, Joe. You make a good point regarding the inconsistency between compareTo (which ignores $OPT) and equals (which includes $OPT). To resolve this difference, I will introduce two new methods so that users may choose to uniformly consider $OPT in comparisons. We now have the following: public int compareTo(Version ob); public int compareToIgnoreOpt(Version ob); public boolean equals(Version ob); public boolean equalsIgnoreOpt(Version ob); The names parallel String.{compareTo|equals}{IgnoreCase}*. I've re-arranged the code a bit around the implementation and tests for equals*() and compareTo*() to take advantage of code re-use. Thanks, iris -----Original Message----- From: joe darcy Sent: Monday, November 30, 2015 5:33 PM To: Magnus Ihse Bursie; Iris Clark; core-libs-dev at openjdk.java.net Cc: verona-dev at openjdk.java.net Subject: Re: RFR: 8072379: Implement jdk.Version and jdk.OracleVersion Another comment below... On 11/27/2015 6:36 AM, Magnus Ihse Bursie wrote: > On 2015-11-25 02: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/ > > Hi Iris, > > I thought the end agreement was that the + should always be present > even if build was empty, if opt was present but not pre. That is, > "9-foo" should unambigiously parse as vnum=9 and pre="foo", while > "9-+foo" should umambigously parse as vnum=9 and opt="foo". The > javadoc does not seem to reflect this. > > I've also had to read and re-read the regexp and parsing logic in the > constructor to convince myself that this (most likely) will be > correctly handled. Perhaps a few comments around this would be helpful? > > The comparison of two version strings which differs only in "pre" does > not adhere to the principle of astonishment. > > The documentation states: "Pre-release identifiers are compared > numerically when they consist only of digits, and lexiographically > otherwise. Numeric identifiers are considered to be less than > non-numeric identifiers." But consider the following version strings: > > 9-01 > 9-01a > 9-02 > 9-003b > > That sequence would be ordered like this, which I find highly surprising. > 9-01 > 9-02 > 9-003b > 9-01a > > I'm also surprised that equals() does not produce the same result as > compareTo(). If opt is to be ignored, surely it should be so in > equals() as well? > I'm one of the maintainers of BigDecimal, one of the few Comparable classes in the JDK where compareTo is "inconsistent with equals" (see "Effective Java, 2nd edition", Item 12 - Considering implementing Comparable). It is consistently surprising to users if compareTo is inconsistent with equals ;-) Therefore, if at all possible it is preferable to have compareTo be *consistent* rather than *inconsistent* with equals; although there are cases where the inconsistency is necessary or at least defensible. I suggest providing multiple compareFoo methods for version that did or did not include certain components, some of these could be consistent with equals and others not. HTH, -Joe From iris.clark at oracle.com Fri Dec 18 21:55:55 2015 From: iris.clark at oracle.com (Iris Clark) Date: Fri, 18 Dec 2015 13:55:55 -0800 (PST) Subject: RFR: 8072379: Implement jdk.Version and jdk.OracleVersion In-Reply-To: <56564B07.8000601@oracle.com> References: <50765a19-34e4-4115-a32d-cea84c25394e@default> <38DD183B-1D89-4C6F-B759-3F4512656F77@oracle.com> <565628C5.1040905@oracle.com> <56564B07.8000601@oracle.com> Message-ID: Hi, Joe. It is not the intention that all JDK distributions must provide their own specializations of jdk.Version. However, downstream users may wish to provide additional semantics to the version string via encapsulation rather than inheritance. In order to facilitate this, the following bug has been filed to consider that case: 8145793: Provide vendor-specific interpretation of a JDK version string https://bugs.openjdk.java.net/browse/JDK-8145793 Thanks, iris -----Original Message----- From: joe darcy Sent: Wednesday, November 25, 2015 3:58 PM To: Mandy Chung; Iris Clark Cc: core-libs-dev at openjdk.java.net; verona-dev at openjdk.java.net Subject: Re: RFR: 8072379: Implement jdk.Version and jdk.OracleVersion PS If the concepts the two classes Version and OracleVersion are trying to capture is a "Vendor-Version" then perhaps that can be surfaced more directly in the API. That is, if the basic notion is to interpret a version string in a way appropriate to and specialized for a given vendor of the JDK (a la the java.vendor system property), then perhaps a type like // API sketch public final class VendorVersion { public VendorVersion(String vendor, Version version, Comparator versionComp>) { ...} @Override public boolean equals(VendorVersion vv) { // Usual instance of checks return Objects.equals(vendor, vv.vendor()) && versionComp.version(), vv.version()); } int compareVersion(VendorVersion vv) { if (!vendor.equals(vv.vendor())) // throw an exception return versionComp(version, vv.version); } // ... } might serve the purposes at hand. HTH, -Joe From iris.clark at oracle.com Fri Dec 18 21:55:58 2015 From: iris.clark at oracle.com (Iris Clark) Date: Fri, 18 Dec 2015 13:55:58 -0800 (PST) Subject: RFR: 8072379: Implement jdk.Version and jdk.OracleVersion In-Reply-To: <565B95AE.3030505@oracle.com> References: <50765a19-34e4-4115-a32d-cea84c25394e@default> <38DD183B-1D89-4C6F-B759-3F4512656F77@oracle.com> <565628C5.1040905@oracle.com> <56564B07.8000601@oracle.com> <565B95AE.3030505@oracle.com> Message-ID: Hi, Joe. I've filed the following JDK 9 RFE to provide this functionality: 8145794: Provide Verona interpretation of historical JDK version strings https://bugs.openjdk.java.net/browse/JDK-8145794 Thanks, iris -----Original Message----- From: joe darcy Sent: Sunday, November 29, 2015 4:18 PM To: Mandy Chung; Iris Clark Cc: verona-dev at openjdk.java.net; core-libs-dev at openjdk.java.net Subject: Re: RFR: 8072379: Implement jdk.Version and jdk.OracleVersion PPS Perhaps this is already planned as future work, but it might be a kindness to those analyzing JDK version strings if there was a class that did a "best effort" at understanding Sun and Oracle JDK version strings pre-Verona to those post-Verona. In other words, a version class where new JdkVersion("1.8.0_25") would have major() == 8 and minor() == 25, but have the specified meaning for strings for Verona strings where the first group was numerically 9 or larger. Cheers, -Joe From iris.clark at oracle.com Fri Dec 18 21:56:36 2015 From: iris.clark at oracle.com (Iris Clark) Date: Fri, 18 Dec 2015 13:56:36 -0800 (PST) Subject: RFR: 8072379: Implement jdk.Version and jdk.OracleVersion In-Reply-To: <56586A7A.2040007@oracle.com> References: <50765a19-34e4-4115-a32d-cea84c25394e@default> <56586A7A.2040007@oracle.com> Message-ID: <9758b221-b38c-4028-9153-c6dd6b9977ce@default> Hi, Magnus. Thanks for the review comments. >> http://cr.openjdk.java.net/~iris/verona/8072379/webrev.1/ > I thought the end agreement was that the + should always be present even if build was empty, if opt was present but not pre. That is, "9-foo" > should unambigiously parse as vnum=9 and pre="foo", while "9-+foo" > should umambigously parse as vnum=9 and opt="foo". The javadoc does not seem to reflect this. You have correctly summarized the expectation and the implementation. I've made the following update the class javadoc: From: * 
   *     $VNUM(-$PRE)?(\+$BUILD)?(-$OPT)?
   *
To: * 
   *     $VNUM(-$PRE)?(\+($BUILD)?(-$OPT)?)?
   *
> The comparison of two version strings which differs only in "pre" does not adhere to the principle of astonishment. > > The documentation states: "Pre-release identifiers are compared numerically when they consist only of digits, and lexiographically otherwise. Numeric identifiers are considered to be less than non-numeric identifiers." But consider the following version strings: > > 9-01 > 9-01a > 9-02 > 9-003b > > That sequence would be ordered like this, which I find highly surprising. > 9-01 > 9-02 > 9-003b > 9-01a The current choice of comparison is motivated by Semantic Versioning. A goal of jdk.Version is to subset this scheme. The sorting may be counter-intuitive and it is possible that in the future we may decide that perfect alignment with semver.org is not critical. For now, we're settling with documenting the behavior. > I'm also surprised that equals() does not produce the same result as compareTo(). If opt is to be ignored, surely it should be so in equals() as well? Based on your comment and Joe's, I've added comparison methods compareTo()/equals() and compareToIgnoreOpt()/equalsIngnoreOpt() for consistency. I'll be sending an updated webrev shortly. Thanks, iris From iris.clark at oracle.com Fri Dec 18 21:56:53 2015 From: iris.clark at oracle.com (Iris Clark) Date: Fri, 18 Dec 2015 13:56:53 -0800 (PST) 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: <1b214934-562a-414d-aa23-cd775a1edff1@default> Hi. Updated webrev and JavaDoc: Webrev http://cr.openjdk.java.net/~iris/verona/8072379/webrev.2/ JavaDoc http://cr.openjdk.java.net/~iris/verona/8072379/doc.2/jdk/Version.html Thanks, iris PS: Please note that I'll be out the week of 21 December, back on 4 January. Access to e-mail will be intermittent at best. From 1983-01-06 at gmx.net Sun Dec 27 10:21:59 2015 From: 1983-01-06 at gmx.net (Michael Osipov) Date: Sun, 27 Dec 2015 11:21:59 +0100 Subject: Improve $OPT on current EA builds Message-ID: <567FBBC7.9060106@gmx.net> 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 Alan.Bateman at oracle.com Mon Dec 28 12:03:58 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 28 Dec 2015 12:03:58 +0000 Subject: JNI and JVM TI version numbers Message-ID: <5681252E.70407@oracle.com> 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