From doko at ubuntu.com Wed Nov 1 06:37:21 2017 From: doko at ubuntu.com (Matthias Klose) Date: Wed, 1 Nov 2017 07:37:21 +0100 Subject: version numbers for distribution builds? In-Reply-To: <1e1cb94c-f9c3-e655-6beb-159b8b315b1a@oracle.com> References: <85a1bac3-a933-c48b-080a-0525657cf080@ubuntu.com> <544dc6f7-d9fa-6a50-258a-d596b4aa11c7@ubuntu.com> <1e1cb94c-f9c3-e655-6beb-159b8b315b1a@oracle.com> Message-ID: <960adab7-9579-1fa5-40fd-50b6fe30642a@ubuntu.com> On 27.10.2017 12:46, Magnus Ihse Bursie wrote: > > On 2017-10-27 12:21, David Holmes wrote: >> Adding build-dev. >> >> David >> >> On 27/10/2017 9:13 AM, Matthias Klose wrote: >>> On 27.10.2017 00:56, Matthias Klose wrote: >>>> Hi, >>>> >>>> I recently learned that I should configure an openjdk build with an empty >>>> -with-version-pre string, and with any package information stuffed into the >>>> --with-version-opt argument. >>>> >>>> ?? --with-version-pre='' --with-version-opt='Debian-9.0.1+11-1' >>>> >>>> 9.0.1+11 is what I call the upstream version, directly derived from the tag in >>>> the mercurial repository.? The part after the dash is the packaging release and >>>> gets incremented when more than upload to the distribution is based on the same >>>> upstream version. >>>> >>>> However using that I get >>>> >>>> configure: WARNING: --with-version-opt value has been sanitized from >>>> 'Debian-9.0.1+11-1' to 'Debian-9.0.111-1' >>>> >>>> which makes the version string somehow cryptic.? Why is there a reason that the >>>> version string is mangled?? Is there a recommendation how to form the version >>>> for a source release? >>> >>> $ java -version >>> openjdk version "9.0.1" >>> OpenJDK Runtime Environment (build 9.0.1+0-Debian-9.0.111-1) >>> OpenJDK 64-Bit Server VM (build 9.0.1+0-Debian-9.0.111-1, mixed mode) >>> >>> Omar suggested on irc to use >>> >>> ?? --with-version-pre='' --with-version-build=11 --with-version-opt='Debian.1 >>> >>> however that will lead to 9.0.1+11-Debian.1, which doesn't match the package >>> version either.? It looks like this whole versioning schema is only fit for >>> upstream builds, and doesn't address any versioning in the downstream builds. >>> >>> Maybe I'm missing something, but how can I include the string Debian-9.0.1+11-1 >>> into that build information? > Unfortunately, you can't. JEP 223 specifices what a valid Java version string > looks like: http://openjdk.java.net/jeps/223 > > I believe your intention is correct to add the distribution versioning to the > "opt" part, but that is limited to containing ([-a-zA-Z0-9\.]+) according to JEP > 223, so it cannot contain a "+". (This is due to the fact that "+" has a special > meaning as the build prefix, and without this restriction, version strings could > become ambigious to parse. > > If you want the full version number repeated in the opt string, I recommend > replacing the "+" with a "-". This is error prone on the Debian side, because the additional "-" is getting interpreted as the Debian release number, if you don't include it explicitly, so something like 9.0.1-11 is interpreted as upstream 9.0.1. > Otherwise I'd recommend Omar's suggestion. I believe that was the intention of > the JEP 223 design. It will contain the version number of the JDK, the build > number, and the additional (opt) part saying that this is a Debian build, with a > Debian-specific version numbering of 1. so while discussing the new date based versioning schema, can we amend that with a downstream versioning schema? Note that other projects provide the ability to include downstream versioning without any mangling: $ gcc --version gcc (Debian 7.2.0-12) 7.2.1 20171025 configured with --with-pkgversion='Debian 7.2.0-12' Matthias From mark.reinhold at oracle.com Wed Nov 1 15:21:16 2017 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Wed, 1 Nov 2017 08:21:16 -0700 (PDT) Subject: New JDK development repositories Message-ID: <20171101152116.9B6BCEBE13@eggemoggin.niobe.net> Thus far we've continued main-line development in the existing JDK 10 repositories. This weekend, early on Sunday, 5 November UTC, we'll cut over to the new JDK Project repositories, which will be here: http://hg.openjdk.java.net/jdk/jdk -- Main line http://hg.openjdk.java.net/jdk/client -- Client development http://hg.openjdk.java.net/jdk/hs -- HotSpot development These repositories will be initialized from the JDK 10 master, client, and hs repositories, respectively. (We're moving back to "jdk" as the name of the main-line repository; "master" was a temporary name, needed to establish the consolidated JDK 10 repository as distinct from the previous main-line forest.) The old repositories under http://hg.openjdk.java.net/jdk10 will be made read-only at 02:30 UTC on Sunday [1]; the new repositories should be available a few hours later. After that, you can change the default pull and push paths of an existing clone of a JDK 10 repository via the Mercurial defpath extension [2], passing it one of the above URLs. If you subscribed to one or more of the jdk10-*-changes list(s) for Mercurial notifications then you'll automatically be subscribed to the corresponding jdk-*-changes list(s). The jdk10/client and jdk10/hs repositories will eventually be deleted; the jdk10/master repository will be retained, or else we'll set up an HTTP redirect, so that old URLs continue to work. - Mark [1] https://www.timeanddate.com/worldclock/fixedtime.html?msg=JDK+Repository+Cutover&iso=20171105T0230 [2] http://openjdk.java.net/projects/code-tools/defpath/ From mark.reinhold at oracle.com Thu Nov 2 15:10:48 2017 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Thu, 2 Nov 2017 08:10:48 -0700 (PDT) Subject: Version-string schemes for the Java SE Platform and the JDK In-Reply-To: <20171019150836.D4E1CEA77D@eggemoggin.niobe.net> Message-ID: <20171102151048.38D00EBFB4@eggemoggin.niobe.net> Thanks to those who read what I wrote [1] and took the time to reply. First, some general points: - Version numbers affect everyone. They're relevant not just to developers who work on the JDK, but to all who use it. The Java platform is not simply a library whose users can adjust to new releases by updating a few dependency constraints. It is, rather, the foundation of an enormous ecosystem of libraries, frameworks, and tools, some of which may require or benefit from upgrades when a JDK release ships. We all need sensible version numbers in order to plan ahead for upgrades and migrations. - Encoding the compatibility or significance of a JDK release in its version number is a recipe for confusion. The compatibility level of a release, or the significance of the changes within it, is not known until near the end of the release's six-month development cycle. Everyone who works on the JDK, or builds or uses components on top of it, would have to speak initially of the release date and then switch to speaking of the assigned version number. Those who maintain libraries, frameworks, and tools would have to be prepared to change code that inspects version numbers late in the JDK release cycle. - Encoding the support lifetime of a release in the release's version number is also a recipe for confusion. The version number of a release is meant to be the same across all implementations of that release. The support lifetime of a release can, however, vary from implementor to implementor, and the support lifetime of a release from a single implementor can change over time. (It could make sense to encode support lifetimes elsewhere in the overall version string, but not in the version number itself.) - I didn't suggest a time-based version scheme in order to work around some internal Oracle process problem. Oracle's management is fully committed to the six-month, time-based release model. Now, to summarize new information. Additional disadvantages of some of the alternatives that I listed: (-) A two-digit absolute time-based scheme would make it difficult to switch back to a more-traditional scheme, should we ever wish to do that [2]. (-) In the absolute time-based schemes, the gaps between successive version numbers make it awkward to specify versions to tools and APIs [2]. Additional alternatives to consider: (D) A dual scheme, in which there's both a "marketing" version and a "technical" version [3]. On this suggestion I agree with another respondent -- we've been here before, and it would add more confusion than it's worth [4]. (E) A sequence of incrementing numerals, much like JEP 223, plus the release date [5]. Encoding these two types of information in version strings seems like overkill, when one can be derived from the other. It may, however, be useful to convey the release date separately to indicate not just the age of the release but also as an indicator of its security level relative to some baseline. Up next: A specific proposal ... - Mark [1] http://mail.openjdk.java.net/pipermail/jdk-dev/2017-October/000007.html [2] http://mail.openjdk.java.net/pipermail/jdk-dev/2017-October/000030.html [3] http://mail.openjdk.java.net/pipermail/jdk-dev/2017-October/000031.html [4] http://mail.openjdk.java.net/pipermail/jdk-dev/2017-October/000033.html [5] http://mail.openjdk.java.net/pipermail/jdk-dev/2017-October/000028.html From mark.reinhold at oracle.com Thu Nov 2 15:11:48 2017 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Thu, 2 Nov 2017 08:11:48 -0700 (PDT) Subject: Proposal: Newer version-string scheme for the Java SE Platform and the JDK Message-ID: <20171102151148.49900EBFB8@eggemoggin.niobe.net> Here's a specific proposal, with commentary, and two questions. Summary: This is a time-based scheme, similar to alternative (C) in my earlier note [1][2] but even closer to the current scheme as defined in JEP 223 [3]. It's hence even less likely to surprise, and should be easier to adopt. * * * Version numbers --------------- A version number, $VNUM, is a sequence of numerals of arbitrary length, separated by period characters. The first four numerals are interpreted as follows: $FEATURE.$INTERIM.$UPDATE.$EMERG where: - $FEATURE -- The feature-release counter, incremented every six months regardless of release content. Thus the March 2018 release is 10, the September 2018 release is 11, and so forth. Features may be added in a feature release; they may also be removed, if advance notice was given at least one feature release ahead of time. Incompatible changes may be made when justified. (Formerly $MAJOR.) - $INTERIM -- The interim-release counter, incremented for non-feature releases that contain compatible bug fixes and enhancements but no incompatible changes, no feature removals, and no changes to standard APIs. This counter is always zero for the current six-month release model. We reserve it here to leave flexibility for the future, so that some future release model could say that JDK $N.1 and JDK $N.2 are compatible upgrades of JDK $N. Leaving this counter at zero for the current model has an additional benefit in that it increases the degree to which version numbers continue to reflect, roughly, both compatibility and significance. (Formerly $MINOR.) - $UPDATE -- The update-release counter, incremented every three months for compatible update releases that fix security issues, regressions, and bugs in newer features. Thus the April 2018 release is 10.0.1, the July release is 10.0.2, and so forth. (Formerly $SECURITY, but with a non-trivial incrementation rule.) - $EMERG -- The emergency-release counter, incremented only when it's necessary to produce an emergency release to fix an urgent security issue. Using an additional numeral for this purpose minimizes the disruption to both developers and users of in-flight update releases. The fifth and later elements of version numbers are reserved for use by downstream consumers of the JDK code base. The fifth element may be used to, e.g., identify implementor-specific patch releases. This is primarily a time-based scheme, since $FEATURE is incremented every six months regardless of release content and, for each feature release, $UPDATE is incremented every three months. We do expect most feature releases to contain at least one or two significant features, and never to ship interim releases under the new release model, so in practice this scheme will often be very similar to a compatibility- or significance-oriented scheme like that of JEP 223. JDK 10 is a feature release, JDK 10.0.1 and 10.0.2 are update releases with compatible bug fixes, and there is no interim JDK 10.1 release since in this model the next opportunity to add features is JDK 11. Version strings --------------- The overall format of version strings is unchanged. A version string is a version number, $VNUM, optionally followed by pre-release, build, and other optional information, one of: $VNUM(-$PRE)?\+$BUILD(-$OPT)? $VNUM-$PRE(-$OPT)? $VNUM(+-$OPT)? where $PRE is a pre-release identifier (e.g., `ea`), $BUILD is a build number, and $OPT is optional build information. Implementors who offer long-term support for a release should use an $OPT string that starts with "lts", e.g., 11.0.2+13-lts. System properties ----------------- To the system properties mentioned in JEP 223 we add one new property: java.version.date -- The GA date of this version, in ISO-8601 YYYY-MM-DD format. For EA releases this will be the intended GA date, i.e., some date in the future. This value is not part of the version string per se, but it will be displayed when useful and can be retrieved via a new method on the `Runtime.Version` API. This new property makes it easy to figure out how old a release is, so that as a user you can understand how far behind you are. It also reflects the security level of the release: A given GA release contains the latest security fixes if its version date is no earlier than that of any other GA release. Launcher -------- The `java` launcher will display version strings and system properties as follows, for a hypothetical build 13 of JDK 10.0.1: $ java --version openjdk 10.0.1 2018-04-19 OpenJDK Runtime Environment (build 10.0.1+13) OpenJDK 64-Bit Server VM (build 10.0.1+13, mixed mode) $ Similarly, for a hypothetical build 42 of JDK 11, an LTS release: $ java --version openjdk 11 2018-09-20 LTS OpenJDK Runtime Environment (build 11+42-lts) OpenJDK 64-Bit Server VM (build 11+42-lts, mixed mode) $ * * * If you've read this far, two questions: (1) Bearing in mind that no version-string scheme is ideal, is this scheme acceptable? (2) If this scheme is not acceptable then please explain why, and identify exactly what you would change. Ground rules, as before: I'll give much greater weight to your first reply to this message than to any other, I'll ignore replies-to-replies, and I'll heavily discount replies that quote more text than add new text of their own. I'll summarize relevant replies in about a week, and then draft a JEP. - Mark [1] http://mail.openjdk.java.net/pipermail/jdk-dev/2017-October/000007.html [2] http://mail.openjdk.java.net/pipermail/jdk-dev/2017-November/000088.html [3] http://openjdk.java.net/jeps/223 From aph at redhat.com Thu Nov 2 15:31:27 2017 From: aph at redhat.com (Andrew Haley) Date: Thu, 2 Nov 2017 15:31:27 +0000 Subject: Proposal: Newer version-string scheme for the Java SE Platform and the JDK In-Reply-To: <20171102151148.49900EBFB8@eggemoggin.niobe.net> References: <20171102151148.49900EBFB8@eggemoggin.niobe.net> Message-ID: <967a3551-8b2f-1853-dd6f-09cba8eacece@redhat.com> On 02/11/17 15:11, mark.reinhold at oracle.com wrote: > - $EMERG -- The emergency-release counter, incremented only when it's > necessary to produce an emergency release to fix an urgent security > issue. I'd like to modify this slightly because not every critical issue is an urgent security issue, and we must allow ourselves to fix bugs in a timely manner. An example of such a bug would be a crash in the GC caused by incorrect locking. Let's not paint ourselves into a corner. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From dwfranken at gmail.com Thu Nov 2 15:35:45 2017 From: dwfranken at gmail.com (Dave Franken) Date: Thu, 2 Nov 2017 16:35:45 +0100 Subject: Proposal: Newer version-string scheme for the Java SE Platform and the JDK In-Reply-To: <20171102151148.49900EBFB8@eggemoggin.niobe.net> References: <20171102151148.49900EBFB8@eggemoggin.niobe.net> Message-ID: <000201d353f0$401b6530$c0522f90$@gmail.com> > (1) Bearing in mind that no version-string scheme is ideal, > is this scheme acceptable? For me, this scheme is acceptable, it seems to be the least confusing one. I think we, developers and users alike, all have to accept that, in order to have nice things faster, we have to make sure we keep up with the latest version and have to do so at a faster pace than we've done in the past. Every released version is a stable version with added features, bug fixes, etc; no betas or milestones. Am I right in assuming that the main difference between LTS and non-LTS is that fixes that fall in the interim, update or emergency category are backported to LTS versions, but not to non-LTS versions? So currently, 11 will be a LTS version, so if there is going to be a update of non-LTS version 12.0 to 12.1, there will also be an 11.1, but not a 10.1? Kind regards, Dave Franken -----Original Message----- From: jdk-dev [mailto:jdk-dev-bounces at openjdk.java.net] On Behalf Of mark.reinhold at oracle.com Sent: donderdag 2 november 2017 16:12 To: jdk-dev at openjdk.java.net Subject: Proposal: Newer version-string scheme for the Java SE Platform and the JDK Here's a specific proposal, with commentary, and two questions. Summary: This is a time-based scheme, similar to alternative (C) in my earlier note [1][2] but even closer to the current scheme as defined in JEP 223 [3]. It's hence even less likely to surprise, and should be easier to adopt. * * * Version numbers --------------- A version number, $VNUM, is a sequence of numerals of arbitrary length, separated by period characters. The first four numerals are interpreted as follows: $FEATURE.$INTERIM.$UPDATE.$EMERG where: - $FEATURE -- The feature-release counter, incremented every six months regardless of release content. Thus the March 2018 release is 10, the September 2018 release is 11, and so forth. Features may be added in a feature release; they may also be removed, if advance notice was given at least one feature release ahead of time. Incompatible changes may be made when justified. (Formerly $MAJOR.) - $INTERIM -- The interim-release counter, incremented for non-feature releases that contain compatible bug fixes and enhancements but no incompatible changes, no feature removals, and no changes to standard APIs. This counter is always zero for the current six-month release model. We reserve it here to leave flexibility for the future, so that some future release model could say that JDK $N.1 and JDK $N.2 are compatible upgrades of JDK $N. Leaving this counter at zero for the current model has an additional benefit in that it increases the degree to which version numbers continue to reflect, roughly, both compatibility and significance. (Formerly $MINOR.) - $UPDATE -- The update-release counter, incremented every three months for compatible update releases that fix security issues, regressions, and bugs in newer features. Thus the April 2018 release is 10.0.1, the July release is 10.0.2, and so forth. (Formerly $SECURITY, but with a non-trivial incrementation rule.) - $EMERG -- The emergency-release counter, incremented only when it's necessary to produce an emergency release to fix an urgent security issue. Using an additional numeral for this purpose minimizes the disruption to both developers and users of in-flight update releases. The fifth and later elements of version numbers are reserved for use by downstream consumers of the JDK code base. The fifth element may be used to, e.g., identify implementor-specific patch releases. This is primarily a time-based scheme, since $FEATURE is incremented every six months regardless of release content and, for each feature release, $UPDATE is incremented every three months. We do expect most feature releases to contain at least one or two significant features, and never to ship interim releases under the new release model, so in practice this scheme will often be very similar to a compatibility- or significance-oriented scheme like that of JEP 223. JDK 10 is a feature release, JDK 10.0.1 and 10.0.2 are update releases with compatible bug fixes, and there is no interim JDK 10.1 release since in this model the next opportunity to add features is JDK 11. Version strings --------------- The overall format of version strings is unchanged. A version string is a version number, $VNUM, optionally followed by pre-release, build, and other optional information, one of: $VNUM(-$PRE)?\+$BUILD(-$OPT)? $VNUM-$PRE(-$OPT)? $VNUM(+-$OPT)? where $PRE is a pre-release identifier (e.g., `ea`), $BUILD is a build number, and $OPT is optional build information. Implementors who offer long-term support for a release should use an $OPT string that starts with "lts", e.g., 11.0.2+13-lts. System properties ----------------- To the system properties mentioned in JEP 223 we add one new property: java.version.date -- The GA date of this version, in ISO-8601 YYYY-MM-DD format. For EA releases this will be the intended GA date, i.e., some date in the future. This value is not part of the version string per se, but it will be displayed when useful and can be retrieved via a new method on the `Runtime.Version` API. This new property makes it easy to figure out how old a release is, so that as a user you can understand how far behind you are. It also reflects the security level of the release: A given GA release contains the latest security fixes if its version date is no earlier than that of any other GA release. Launcher -------- The `java` launcher will display version strings and system properties as follows, for a hypothetical build 13 of JDK 10.0.1: $ java --version openjdk 10.0.1 2018-04-19 OpenJDK Runtime Environment (build 10.0.1+13) OpenJDK 64-Bit Server VM (build 10.0.1+13, mixed mode) $ Similarly, for a hypothetical build 42 of JDK 11, an LTS release: $ java --version openjdk 11 2018-09-20 LTS OpenJDK Runtime Environment (build 11+42-lts) OpenJDK 64-Bit Server VM (build 11+42-lts, mixed mode) $ * * * If you've read this far, two questions: (1) Bearing in mind that no version-string scheme is ideal, is this scheme acceptable? (2) If this scheme is not acceptable then please explain why, and identify exactly what you would change. Ground rules, as before: I'll give much greater weight to your first reply to this message than to any other, I'll ignore replies-to-replies, and I'll heavily discount replies that quote more text than add new text of their own. I'll summarize relevant replies in about a week, and then draft a JEP. - Mark [1] http://mail.openjdk.java.net/pipermail/jdk-dev/2017-October/000007.html [2] http://mail.openjdk.java.net/pipermail/jdk-dev/2017-November/000088.html [3] http://openjdk.java.net/jeps/223 From mark.reinhold at oracle.com Thu Nov 2 15:42:06 2017 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Thu, 02 Nov 2017 08:42:06 -0700 Subject: Proposal: Newer version-string scheme for the Java SE Platform and the JDK In-Reply-To: <967a3551-8b2f-1853-dd6f-09cba8eacece@redhat.com> References: <20171102151148.49900EBFB8@eggemoggin.niobe.net> <967a3551-8b2f-1853-dd6f-09cba8eacece@redhat.com> Message-ID: <20171102084206.952282066@eggemoggin.niobe.net> 2017/11/2 8:31:27 -0700, Andrew Haley : > On 02/11/17 15:11, mark.reinhold at oracle.com wrote: >> - $EMERG -- The emergency-release counter, incremented only when it's >> necessary to produce an emergency release to fix an urgent security >> issue. > > I'd like to modify this slightly because not every critical issue is > an urgent security issue, and we must allow ourselves to fix bugs in a > timely manner. An example of such a bug would be a crash in the GC > caused by incorrect locking. Let's not paint ourselves into a corner. Agreed. Consider the proposal amended to read: - $EMERG -- The emergency-release counter, incremented only when it's necessary to produce an emergency release to fix a critical issue. Using an additional numeral for this purpose minimizes the disruption to both developers and users of in-flight update releases. - Mark From aph at redhat.com Thu Nov 2 15:42:36 2017 From: aph at redhat.com (Andrew Haley) Date: Thu, 2 Nov 2017 15:42:36 +0000 Subject: Proposal: Newer version-string scheme for the Java SE Platform and the JDK In-Reply-To: <000201d353f0$401b6530$c0522f90$@gmail.com> References: <20171102151148.49900EBFB8@eggemoggin.niobe.net> <000201d353f0$401b6530$c0522f90$@gmail.com> Message-ID: <9e4a14f8-03a5-075e-91f1-4a1096c8332d@redhat.com> On 02/11/17 15:35, Dave Franken wrote: > (1) Bearing in mind that no version-string scheme is ideal, > is this scheme acceptable? Yes. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From adinn at redhat.com Thu Nov 2 15:51:40 2017 From: adinn at redhat.com (Andrew Dinn) Date: Thu, 2 Nov 2017 15:51:40 +0000 Subject: Proposal: Newer version-string scheme for the Java SE Platform and the JDK In-Reply-To: <20171102151148.49900EBFB8@eggemoggin.niobe.net> References: <20171102151148.49900EBFB8@eggemoggin.niobe.net> Message-ID: <29fe4645-3fd6-f300-081c-7ba1ae1279ad@redhat.com> On 02/11/17 15:11, mark.reinhold at oracle.com wrote: > (1) Bearing in mind that no version-string scheme is ideal, > is this scheme acceptable? Yes (and bravo! ;-). regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From mark.reinhold at oracle.com Thu Nov 2 15:52:49 2017 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Thu, 02 Nov 2017 08:52:49 -0700 Subject: Proposal: Newer version-string scheme for the Java SE Platform and the JDK In-Reply-To: <000201d353f0$401b6530$c0522f90$@gmail.com> References: <20171102151148.49900EBFB8@eggemoggin.niobe.net> <000201d353f0$401b6530$c0522f90$@gmail.com> Message-ID: <20171102085249.472796151@eggemoggin.niobe.net> 2017/11/2 8:35:45 -0700, Dave Franken : > ... > > Am I right in assuming that the main difference between LTS and non-LTS is > that fixes that fall in the interim, update or emergency category are > backported to LTS versions, but not to non-LTS versions? Not all fixes will be backported. Whether a fix from a later release is backported to an LTS release will depend upon the importance and risk of the fix. > So currently, 11 will be a LTS version, so if there is going to be a update > of non-LTS version 12.0 to 12.1, there will also be an 11.1, but not a 10.1? No. JDK 11 will be an LTS release. Fixes from later releases, of any type, may be backported to JDK 11 update releases (11.0.1, 11.0.2, ...). If a fix in JDK 12.0.$N is backported to a JDK 11 update release then the version number of that update release need not be 11.0.$N. There will never be a JDK 10.1, 11.1, or 12.1 with the six-month release model, but there could be at some point in the future if we revise the model again. - Mark From forax at univ-mlv.fr Thu Nov 2 19:57:43 2017 From: forax at univ-mlv.fr (Remi Forax) Date: Thu, 2 Nov 2017 20:57:43 +0100 (CET) Subject: Proposal: Newer version-string scheme for the Java SE Platform and the JDK In-Reply-To: <20171102151148.49900EBFB8@eggemoggin.niobe.net> References: <20171102151148.49900EBFB8@eggemoggin.niobe.net> Message-ID: <557507391.1555418.1509652663920.JavaMail.zimbra@u-pem.fr> 'yes' inlined ----- Mail original ----- > De: "mark reinhold" > ?: "jdk-dev" > Envoy?: Jeudi 2 Novembre 2017 16:11:48 > Objet: Proposal: Newer version-string scheme for the Java SE Platform and the JDK > Here's a specific proposal, with commentary, and two questions. > > Summary: This is a time-based scheme, similar to alternative (C) in my > earlier note [1][2] but even closer to the current scheme as defined in > JEP 223 [3]. It's hence even less likely to surprise, and should be > easier to adopt. > ... > > If you've read this far, two questions: > > (1) Bearing in mind that no version-string scheme is ideal, > is this scheme acceptable? YES ! > > (2) If this scheme is not acceptable then please explain why, > and identify exactly what you would change. > > Ground rules, as before: I'll give much greater weight to your first > reply to this message than to any other, I'll ignore replies-to-replies, > and I'll heavily discount replies that quote more text than add new text > of their own. > > I'll summarize relevant replies in about a week, and then draft a JEP. > > - Mark R?mi > > > [1] http://mail.openjdk.java.net/pipermail/jdk-dev/2017-October/000007.html > [2] http://mail.openjdk.java.net/pipermail/jdk-dev/2017-November/000088.html > [3] http://openjdk.java.net/jeps/223 From cedric.champeau at gmail.com Thu Nov 2 20:08:04 2017 From: cedric.champeau at gmail.com (=?UTF-8?Q?C=C3=A9dric_Champeau?=) Date: Thu, 2 Nov 2017 21:08:04 +0100 Subject: Proposal: Newer version-string scheme for the Java SE Platform and the JDK In-Reply-To: <20171102151148.49900EBFB8@eggemoggin.niobe.net> References: <20171102151148.49900EBFB8@eggemoggin.niobe.net> Message-ID: > > >> >> >> If you've read this far, two questions: >> >> (1) Bearing in mind that no version-string scheme is ideal, >> is this scheme acceptable? >> >> Yes > >> >> >> One thing that I'd like to see explicit in the spec is whether this new > scheme implies that an upgrade of $FEATURE imply bumping the class format. > > Thanks Mark! > From jonathan.gibbons at oracle.com Thu Nov 2 20:14:02 2017 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 02 Nov 2017 13:14:02 -0700 Subject: Proposal: Newer version-string scheme for the Java SE Platform and the JDK In-Reply-To: <20171102151148.49900EBFB8@eggemoggin.niobe.net> References: <20171102151148.49900EBFB8@eggemoggin.niobe.net> Message-ID: <59FB7C8A.3060807@oracle.com> Mark, The proposed scheme fits well with related appearances of the feature/major version number, such as the argument for the -source/-target/--release options for javac and javadoc. I would also expect javac to follow the guidelines listed in the "Launcher" section. -- Jon From scolebourne at joda.org Thu Nov 2 21:08:20 2017 From: scolebourne at joda.org (Stephen Colebourne) Date: Thu, 2 Nov 2017 21:08:20 +0000 Subject: Proposal: Newer version-string scheme for the Java SE Platform and the JDK In-Reply-To: <20171102151148.49900EBFB8@eggemoggin.niobe.net> References: <20171102151148.49900EBFB8@eggemoggin.niobe.net> Message-ID: Overall, this is a pretty good scheme, thanks for listening. I'd argue however that the references to six months in $FEATURE and three months in $UPDATE are unhelpful. Those cadences may be the cadences around which the scheme is intended to work today, but this version scheme would also work with other cadences, such as alternating 5 month / 7 month for $FEATURE and 2 month for $UPDATE. As such, I'd suggest you don't conflate the two. Instead, separate the definitions of each numeral from the particular time-boxes you currently intend. For example: "The feature-release counter, incremented every six months regardless of release content" becomes "The feature-release counter, incremented for each time-boxed release, regardless of release content" "The update-release counter, incremented every three months for..." becomes "The update-release counter, incremented for each release of..." And then at the end noting that time-boxed $FEATURE releases are currently every six months and $UPDATE releases every 3 months. The proposal does not indicate what happens with the class file version, but replies on Twitter indicate an intention to update that number with each feature release. IMO this would be a mistake, as changing the class file number has a knock on effect on a lot of low-level downstream tools that often take months to update, with nasty impacts on the ability to adopt a feature release. As such, I *strongly* argue that the class file version should only change when it is required to do so. This will occur naturally when a change is merged into master that requires a new version, so there is no impact on process that I can see. I have separate concerns regarding LTS in general and feature removals in particular, but that deserves a separate thread. thanks Stephen On 2 November 2017 at 15:11, wrote: > Here's a specific proposal, with commentary, and two questions. > > Summary: This is a time-based scheme, similar to alternative (C) in my > earlier note [1][2] but even closer to the current scheme as defined in > JEP 223 [3]. It's hence even less likely to surprise, and should be > easier to adopt. > > * * * > > Version numbers > --------------- > > A version number, $VNUM, is a sequence of numerals of arbitrary length, > separated by period characters. The first four numerals are interpreted > as follows: > > $FEATURE.$INTERIM.$UPDATE.$EMERG > > where: > > - $FEATURE -- The feature-release counter, incremented every six months > regardless of release content. Thus the March 2018 release is 10, > the September 2018 release is 11, and so forth. Features may be > added in a feature release; they may also be removed, if advance > notice was given at least one feature release ahead of time. > Incompatible changes may be made when justified. (Formerly $MAJOR.) > > - $INTERIM -- The interim-release counter, incremented for non-feature > releases that contain compatible bug fixes and enhancements but no > incompatible changes, no feature removals, and no changes to standard > APIs. This counter is always zero for the current six-month release > model. We reserve it here to leave flexibility for the future, so > that some future release model could say that JDK $N.1 and JDK $N.2 > are compatible upgrades of JDK $N. Leaving this counter at zero for > the current model has an additional benefit in that it increases the > degree to which version numbers continue to reflect, roughly, both > compatibility and significance. (Formerly $MINOR.) > > - $UPDATE -- The update-release counter, incremented every three months > for compatible update releases that fix security issues, regressions, > and bugs in newer features. Thus the April 2018 release is 10.0.1, > the July release is 10.0.2, and so forth. (Formerly $SECURITY, but > with a non-trivial incrementation rule.) > > - $EMERG -- The emergency-release counter, incremented only when it's > necessary to produce an emergency release to fix an urgent security > issue. Using an additional numeral for this purpose minimizes the > disruption to both developers and users of in-flight update releases. > > The fifth and later elements of version numbers are reserved for use by > downstream consumers of the JDK code base. The fifth element may be used > to, e.g., identify implementor-specific patch releases. > > This is primarily a time-based scheme, since $FEATURE is incremented > every six months regardless of release content and, for each feature > release, $UPDATE is incremented every three months. We do expect most > feature releases to contain at least one or two significant features, > and never to ship interim releases under the new release model, so in > practice this scheme will often be very similar to a compatibility- or > significance-oriented scheme like that of JEP 223. JDK 10 is a feature > release, JDK 10.0.1 and 10.0.2 are update releases with compatible bug > fixes, and there is no interim JDK 10.1 release since in this model the > next opportunity to add features is JDK 11. > > Version strings > --------------- > > The overall format of version strings is unchanged. A version string is > a version number, $VNUM, optionally followed by pre-release, build, and > other optional information, one of: > > $VNUM(-$PRE)?\+$BUILD(-$OPT)? > $VNUM-$PRE(-$OPT)? > $VNUM(+-$OPT)? > > where $PRE is a pre-release identifier (e.g., `ea`), $BUILD is a build > number, and $OPT is optional build information. > > Implementors who offer long-term support for a release should use an $OPT > string that starts with "lts", e.g., 11.0.2+13-lts. > > System properties > ----------------- > > To the system properties mentioned in JEP 223 we add one new property: > > java.version.date -- The GA date of this version, in ISO-8601 > YYYY-MM-DD format. For EA releases this will be the intended GA > date, i.e., some date in the future. This value is not part of the > version string per se, but it will be displayed when useful and can > be retrieved via a new method on the `Runtime.Version` API. > > This new property makes it easy to figure out how old a release is, so > that as a user you can understand how far behind you are. It also > reflects the security level of the release: A given GA release contains > the latest security fixes if its version date is no earlier than that of > any other GA release. > > Launcher > -------- > > The `java` launcher will display version strings and system properties as > follows, for a hypothetical build 13 of JDK 10.0.1: > > $ java --version > openjdk 10.0.1 2018-04-19 > OpenJDK Runtime Environment (build 10.0.1+13) > OpenJDK 64-Bit Server VM (build 10.0.1+13, mixed mode) > $ > > Similarly, for a hypothetical build 42 of JDK 11, an LTS release: > > $ java --version > openjdk 11 2018-09-20 LTS > OpenJDK Runtime Environment (build 11+42-lts) > OpenJDK 64-Bit Server VM (build 11+42-lts, mixed mode) > $ > > * * * > > If you've read this far, two questions: > > (1) Bearing in mind that no version-string scheme is ideal, > is this scheme acceptable? > > (2) If this scheme is not acceptable then please explain why, > and identify exactly what you would change. > > Ground rules, as before: I'll give much greater weight to your first > reply to this message than to any other, I'll ignore replies-to-replies, > and I'll heavily discount replies that quote more text than add new text > of their own. > > I'll summarize relevant replies in about a week, and then draft a JEP. > > - Mark > > > [1] http://mail.openjdk.java.net/pipermail/jdk-dev/2017-October/000007.html > [2] http://mail.openjdk.java.net/pipermail/jdk-dev/2017-November/000088.html > [3] http://openjdk.java.net/jeps/223 From john.r.rose at oracle.com Thu Nov 2 21:21:18 2017 From: john.r.rose at oracle.com (John Rose) Date: Thu, 2 Nov 2017 14:21:18 -0700 Subject: Proposal: Newer version-string scheme for the Java SE Platform and the JDK In-Reply-To: References: <20171102151148.49900EBFB8@eggemoggin.niobe.net> Message-ID: On Nov 2, 2017, at 2:08 PM, Stephen Colebourne wrote: > > The proposal does not indicate what happens with the class file > version, but replies on Twitter indicate an intention to update that > number with each feature release. IMO this would be a mistake, as > changing the class file number has a knock on effect on a lot of > low-level downstream tools that often take months to update, with > nasty impacts on the ability to adopt a feature release. As such, I > *strongly* argue that the class file version should only change when > it is required to do so. This will occur naturally when a change is > merged into master that requires a new version, so there is no impact > on process that I can see. This argument works backwards if class file version changes are likely to occur in each feature release. In that case, we have the same knock-on effects as a deterministic lock-step rule, *plus* unpredictability. And we *are* likely to be introducing class file format changes frequently going forward. The tools will just need to keep up. In that environment, would you rather have a predictable lock-step rule for tool development, or would you still prefer your scheme, which optimizes for the infrequent "null" change, at the cost of guessing on a random variable? From my side of the fence, the process (given the assumption of frequent changes) is slightly simplified by a predictable class file version number to integrate against. Remember that features are only integrated when ready to release. For JVM work, this means changes to classfile format must keep the classfile version number late-bound, until the integration goes ahead. It's easier to late-bind against a predictable number. ? John From neugens.limasoftware at gmail.com Thu Nov 2 21:22:11 2017 From: neugens.limasoftware at gmail.com (Mario Torre) Date: Thu, 2 Nov 2017 22:22:11 +0100 Subject: Proposal: Newer version-string scheme for the Java SE Platform and the JDK In-Reply-To: <20171102151148.49900EBFB8@eggemoggin.niobe.net> References: <20171102151148.49900EBFB8@eggemoggin.niobe.net> Message-ID: 2017-11-02 16:11 GMT+01:00 : > (1) Bearing in mind that no version-string scheme is ideal, > is this scheme acceptable? Yes! Cheers, Mario -- pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens Proud GNU Classpath developer: http://www.classpath.org/ OpenJDK: http://openjdk.java.net/projects/caciocavallo/ Please, support open standards: http://endsoftpatents.org/ From joe.darcy at oracle.com Thu Nov 2 21:38:07 2017 From: joe.darcy at oracle.com (joe darcy) Date: Thu, 2 Nov 2017 14:38:07 -0700 Subject: Proposal: Newer version-string scheme for the Java SE Platform and the JDK In-Reply-To: References: <20171102151148.49900EBFB8@eggemoggin.niobe.net> Message-ID: On 11/2/2017 2:21 PM, John Rose wrote: > On Nov 2, 2017, at 2:08 PM, Stephen Colebourne wrote: >> The proposal does not indicate what happens with the class file >> version, but replies on Twitter indicate an intention to update that >> number with each feature release. IMO this would be a mistake, as >> changing the class file number has a knock on effect on a lot of >> low-level downstream tools that often take months to update, with >> nasty impacts on the ability to adopt a feature release. As such, I >> *strongly* argue that the class file version should only change when >> it is required to do so. This will occur naturally when a change is >> merged into master that requires a new version, so there is no impact >> on process that I can see. > This argument works backwards if class file version changes > are likely to occur in each feature release. In that case, we > have the same knock-on effects as a deterministic lock-step > rule, *plus* unpredictability. > > And we *are* likely to be introducing class file format changes > frequently going forward. The tools will just need to keep > up. In that environment, would you rather have a predictable > lock-step rule for tool development, or would you still prefer > your scheme, which optimizes for the infrequent "null" change, > at the cost of guessing on a random variable? > > The version of class file in jar provides an implicit mechanism to indicate the minimum JDK version needed to run the jar. -Joe From scolebourne at joda.org Thu Nov 2 22:10:56 2017 From: scolebourne at joda.org (Stephen Colebourne) Date: Thu, 2 Nov 2017 22:10:56 +0000 Subject: Proposal: Newer version-string scheme for the Java SE Platform and the JDK In-Reply-To: References: <20171102151148.49900EBFB8@eggemoggin.niobe.net> Message-ID: On 2 November 2017 at 21:21, John Rose wrote: > In that environment, would you rather have a predictable > lock-step rule for tool development, or would you still prefer > your scheme, which optimizes for the infrequent "null" change, > at the cost of guessing on a random variable? If the JVM/bytecode level has not changed, I can't see any advantages to anyone outside Oracle/OpenJDK of a version bump. Stephen From forax at univ-mlv.fr Thu Nov 2 22:22:16 2017 From: forax at univ-mlv.fr (Remi Forax) Date: Thu, 2 Nov 2017 23:22:16 +0100 (CET) Subject: Proposal: Newer version-string scheme for the Java SE Platform and the JDK In-Reply-To: References: <20171102151148.49900EBFB8@eggemoggin.niobe.net> Message-ID: <1610919770.1616945.1509661336888.JavaMail.zimbra@u-pem.fr> Hi Stephen, as John said, have a bijection between the JVM version and the Java version. and practically, given the backlog of VM spec changes we had actually, i will not be too worry of having a Java feature release without the JVM changes :) cheers, R?mi ----- Mail original ----- > De: "Stephen Colebourne" > ?: "jdk-dev" > Envoy?: Jeudi 2 Novembre 2017 23:10:56 > Objet: Re: Proposal: Newer version-string scheme for the Java SE Platform and the JDK > On 2 November 2017 at 21:21, John Rose wrote: >> In that environment, would you rather have a predictable >> lock-step rule for tool development, or would you still prefer >> your scheme, which optimizes for the infrequent "null" change, >> at the cost of guessing on a random variable? > > If the JVM/bytecode level has not changed, I can't see any advantages > to anyone outside Oracle/OpenJDK of a version bump. > > Stephen From mark.reinhold at oracle.com Thu Nov 2 22:37:59 2017 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Thu, 02 Nov 2017 15:37:59 -0700 Subject: JEPs proposed to target JDK 10 (2017/11/2) Message-ID: <20171102153759.744852081@eggemoggin.niobe.net> The following JEPs have been placed into the "Proposed to Target" state by their owners after discussion and review: 304: Garbage-Collector Interface http://openjdk.java.net/jeps/304 307: Parallel Full GC for G1 http://openjdk.java.net/jeps/307 312: Thread-Local Handshakes http://openjdk.java.net/jeps/312 Feedback on these proposals is more than welcome, as are reasoned objections. If no such objections are raised by 23:00 UTC on Thursday, 9 November, or if they're raised and then satisfactorily answered, then per the JEP 2.0 process proposal [1] I'll target these JEPs to JDK 10. - Mark [1] http://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html From scolebourne at joda.org Thu Nov 2 23:31:43 2017 From: scolebourne at joda.org (Stephen Colebourne) Date: Thu, 2 Nov 2017 23:31:43 +0000 Subject: Fwd: Impact of six month releases In-Reply-To: References: Message-ID: (originally sent to the wrong list) Like many others my first reaction on hearing of six monthly releases was very positive. Great to see things move forward faster. However, as time has progressed and more detail has come out I find myself struggling to see how it is actually useful in practice. This is the proposed timeline (as I understand it): - 10.0.0 - Feature release March 2018 - 10.0.1 - Update release April 2018 - 10.0.2 - Update release July 2018 - 11.0.0 - Feature release September 2018 - 11.0.1 - Update release October 2018 - 11.0.2 - Update release January 2019 - 12.0.0 - Feature release March 2019 Note that there is no overlap between the last v10 update (security) release 10.0.2 and the first v11 release. In order to be protected in security terms developers are required to upgrade to 11.0.0 immediately on release. I believe that this cannot work in practice. Every single major (feature) release of Java I can remember has caused a problem in at least one of the tools in the stack of the application I was working on. To upgrade to a new Java major/feature version I'd currently need all of these to be ready: - Eclipse - IntelliJ - Travis CI - Shippable - Amazon AWS - Maven - Maven plugins (compile, jar, source, javadoc, site, etc) - Checkstyle, & associated IDE plugins and maven plugin - JaCoCo, & associated IDE plugins and maven plugin - PMD, & associated maven plugin - SpotBugs, & associated maven plugin - OSGi bundle metadata tool - Bytecode tools (Byte buddy / ASM etc) - Over 100 jar file dependencies - Probably something else I've forgotten If just one of these isn't ready then I can't upgrade to the new version of Java. Now, historically, the solution to upgrading has been to wait. Over time, the open source community would - often in their unpaid spare time - bring the stack back to be working again. Traditionally, it has taken many months for the point where the whole stack is viable again. But to state the obvious - this simply does not work anymore. If it takes 3 months for the stack to be viable again (hugely optimistic) the version has just 3 months of life before the whole cycle has to start again. My experience would actually say that 6 months (and 2 updates) is generally the point at which the stack is fully stable and it would be OK to put a system into production. But, the six month point is where you get no more security updates. The logical conclusion is that this is a trap, and you should therefore not attempt to join the eternal upgrade train. As it stands, the only advice any consultant or experienced developer could give would be to stick with Java 8 or a future LTS (which is in theory v12, but with time-boxing it seems unwise to rely on that). The intermediate releases between LTS versions are fundamentally unsuited for use in production systems. In fact one might sensibly call them "milestones"... ---- Given the above, I find this proposal from Mark, deeply concerning: "Features may be added in a feature release; they may also be removed, if advance notice was given at least one feature release ahead of time." The statement above indicates that code can be deprecated and removed in just two releases. But there are 5 intermediate releases between LTS ones on the current schedule (from 12 to 18). This means that developers moving from LTS v12 to LTS v18 will probably see code fail to compile without ever seeing a deprecation. I think this is throwing the baby (Java's long standing backwards compatibility) out with the bathwater (frequent releases), but I'm happy to hear other opinions. Stephen From rschmitt at pobox.com Fri Nov 3 00:21:03 2017 From: rschmitt at pobox.com (Ryan Schmitt) Date: Thu, 2 Nov 2017 17:21:03 -0700 Subject: Impact of six month releases In-Reply-To: References: Message-ID: I have similar concerns along these lines. For example, JDK9 introduced the "one plus three back" policy for cross compilation, such that javac in JDK9 can now only target JDK6 and newer. Under the old release schedule, "one back plus three" could easily cover a decade's worth of JDKs, but now that window will shrink to approximately two years. There are similar questions around JDK deprecations: how long do my dependencies have to migrate to VarHandles and StackWalker? Three years or six months? Will we continue to have a new bytecode version with every release, or will the classfile format only be incremented as needed? From Alan.Bateman at oracle.com Fri Nov 3 09:42:12 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 3 Nov 2017 09:42:12 +0000 Subject: Impact of six month releases In-Reply-To: References: Message-ID: <0acf9176-938c-6ac3-9b36-18d8f57958a9@oracle.com> On 03/11/2017 00:21, Ryan Schmitt wrote: > I have similar concerns along these lines. For example, JDK9 > introduced the "one plus three back" policy for cross > compilation, such that javac in JDK9 can now only target JDK6 > and newer. Under the old release schedule, "one back plus > three" could easily cover a decade's worth of JDKs, but now > that window will shrink to approximately two years. There are > similar questions around JDK deprecations: how long do my > dependencies have to migrate to VarHandles and StackWalker? Moving to a feature release every 6 months will mean re-examining these policies, some will probably need to be changed to be based on time rather than "next release". The issue of APIs that are deprecated-for-removal is, at least in my view, the most important to decide on soon as it is impacts several areas with patches pending. Yes, policies for `javac --release N`, the version that jrtfs is compiled to is another, and there are several others.? Not clear if there is a "one-size-fits-all" policy, esp. when you get into the undocumented internal APIs and how aggressively we can remove/refactor internals when there are standard/supported APIs available. -Alan. From neugens.limasoftware at gmail.com Fri Nov 3 10:17:48 2017 From: neugens.limasoftware at gmail.com (Mario Torre) Date: Fri, 03 Nov 2017 10:17:48 +0000 Subject: Impact of six month releases In-Reply-To: <0acf9176-938c-6ac3-9b36-18d8f57958a9@oracle.com> References: <0acf9176-938c-6ac3-9b36-18d8f57958a9@oracle.com> Message-ID: We also need to consider that breakage is usually caused by the massive feature count introduced in each release, with a faster release cycle we have more chances to introduce features incrementally instead of the old patch bomb style approach, lowering the risk of substantial breakage. There will likely be a domino effect where all those projects will start moving at the same time aligning with the release pace of the jdk. That said, I think the quality outreach project and our downstream testing will have a larger role to play in this scenario. Cheers, Mario On Fri 3. Nov 2017 at 10:42, Alan Bateman wrote: > On 03/11/2017 00:21, Ryan Schmitt wrote: > > I have similar concerns along these lines. For example, JDK9 > > introduced the "one plus three back" policy for cross > > compilation, such that javac in JDK9 can now only target JDK6 > > and newer. Under the old release schedule, "one back plus > > three" could easily cover a decade's worth of JDKs, but now > > that window will shrink to approximately two years. There are > > similar questions around JDK deprecations: how long do my > > dependencies have to migrate to VarHandles and StackWalker? > Moving to a feature release every 6 months will mean re-examining these > policies, some will probably need to be changed to be based on time > rather than "next release". The issue of APIs that are > deprecated-for-removal is, at least in my view, the most important to > decide on soon as it is impacts several areas with patches pending. Yes, > policies for `javac --release N`, the version that jrtfs is compiled to > is another, and there are several others. Not clear if there is a > "one-size-fits-all" policy, esp. when you get into the undocumented > internal APIs and how aggressively we can remove/refactor internals when > there are standard/supported APIs available. > > -Alan. > From goetz.lindenmaier at sap.com Fri Nov 3 10:23:55 2017 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 3 Nov 2017 10:23:55 +0000 Subject: Impact of six month releases In-Reply-To: References: Message-ID: <9a50879008d14b0fbbcb110ae3ce7d00@sap.com> Hi, I share the concerns mentioned in this thread. I just picked up work on our internal "next Java release after 8" project, which now has been relabeled from '9' to '11', and has been delayed the third time now. The first change I looked at was " 8173421: Obsolete and expired flags for JDK 10 need to be removed and related tests updated". I think this change needs to be redone: First it needs to be reverted, then one needs to replace '9' by '11' and '10' by '17'. Thus, the flags can be removed in jdk17 only, which is in 2021. I appreciate that Java moves forward faster, as adding JEPs as "286: Local-Variable Type Inference" need not be delayed as long as it would have been in the old release rhythm. But deprecating stuff can only be done in the LTE releases, as most users will only see these. We are happy that one of our larger products will go to 8 next year, finally! For another product the installed base currently is 6: 5%, 7: 65%, 8: 30% ... Other teams that had planned to go to 9 now will wait until 11. We, the JVM team, would like to see faster adoption of new Java version, as we don't like to keep supporting the old releases. But now the next LTE will be delayed another year. And adoption of JDK11 by these products will be even harder if there are lots of sudden incompatible changes ... and here sudden means from one LTE to another, no matter how much time there is between LTEs. Best regards, Goetz. > -----Original Message----- > From: jdk-dev [mailto:jdk-dev-bounces at openjdk.java.net] On Behalf Of > Ryan Schmitt > Sent: Freitag, 3. November 2017 01:21 > To: Stephen Colebourne > Cc: jdk-dev at openjdk.java.net > Subject: Re: Impact of six month releases > > I have similar concerns along these lines. For example, JDK9 > introduced the "one plus three back" policy for cross > compilation, such that javac in JDK9 can now only target JDK6 > and newer. Under the old release schedule, "one back plus > three" could easily cover a decade's worth of JDKs, but now > that window will shrink to approximately two years. There are > similar questions around JDK deprecations: how long do my > dependencies have to migrate to VarHandles and StackWalker? > Three years or six months? Will we continue to have a new > bytecode version with every release, or will the classfile > format only be incremented as needed? From rfscholte at apache.org Fri Nov 3 13:02:34 2017 From: rfscholte at apache.org (Robert Scholte) Date: Fri, 03 Nov 2017 14:02:34 +0100 Subject: Proposal: Newer version-string scheme for the Java SE Platform and the JDK In-Reply-To: <20171102151148.49900EBFB8@eggemoggin.niobe.net> References: <20171102151148.49900EBFB8@eggemoggin.niobe.net> Message-ID: Thanks for accepting my additional disadvantages on the original proposal. This new proposal looks good to me. Robert On Thu, 02 Nov 2017 16:11:48 +0100, wrote: > Here's a specific proposal, with commentary, and two questions. > > Summary: This is a time-based scheme, similar to alternative (C) in my > earlier note [1][2] but even closer to the current scheme as defined in > JEP 223 [3]. It's hence even less likely to surprise, and should be > easier to adopt. > > * * * > > Version numbers > --------------- > > A version number, $VNUM, is a sequence of numerals of arbitrary length, > separated by period characters. The first four numerals are interpreted > as follows: > > $FEATURE.$INTERIM.$UPDATE.$EMERG > > where: > > - $FEATURE -- The feature-release counter, incremented every six months > regardless of release content. Thus the March 2018 release is 10, > the September 2018 release is 11, and so forth. Features may be > added in a feature release; they may also be removed, if advance > notice was given at least one feature release ahead of time. > Incompatible changes may be made when justified. (Formerly $MAJOR.) > > - $INTERIM -- The interim-release counter, incremented for non-feature > releases that contain compatible bug fixes and enhancements but no > incompatible changes, no feature removals, and no changes to standard > APIs. This counter is always zero for the current six-month release > model. We reserve it here to leave flexibility for the future, so > that some future release model could say that JDK $N.1 and JDK $N.2 > are compatible upgrades of JDK $N. Leaving this counter at zero for > the current model has an additional benefit in that it increases the > degree to which version numbers continue to reflect, roughly, both > compatibility and significance. (Formerly $MINOR.) > > - $UPDATE -- The update-release counter, incremented every three months > for compatible update releases that fix security issues, regressions, > and bugs in newer features. Thus the April 2018 release is 10.0.1, > the July release is 10.0.2, and so forth. (Formerly $SECURITY, but > with a non-trivial incrementation rule.) > > - $EMERG -- The emergency-release counter, incremented only when it's > necessary to produce an emergency release to fix an urgent security > issue. Using an additional numeral for this purpose minimizes the > disruption to both developers and users of in-flight update releases. > > The fifth and later elements of version numbers are reserved for use by > downstream consumers of the JDK code base. The fifth element may be used > to, e.g., identify implementor-specific patch releases. > > This is primarily a time-based scheme, since $FEATURE is incremented > every six months regardless of release content and, for each feature > release, $UPDATE is incremented every three months. We do expect most > feature releases to contain at least one or two significant features, > and never to ship interim releases under the new release model, so in > practice this scheme will often be very similar to a compatibility- or > significance-oriented scheme like that of JEP 223. JDK 10 is a feature > release, JDK 10.0.1 and 10.0.2 are update releases with compatible bug > fixes, and there is no interim JDK 10.1 release since in this model the > next opportunity to add features is JDK 11. > > Version strings > --------------- > > The overall format of version strings is unchanged. A version string is > a version number, $VNUM, optionally followed by pre-release, build, and > other optional information, one of: > > $VNUM(-$PRE)?\+$BUILD(-$OPT)? > $VNUM-$PRE(-$OPT)? > $VNUM(+-$OPT)? > > where $PRE is a pre-release identifier (e.g., `ea`), $BUILD is a build > number, and $OPT is optional build information. > > Implementors who offer long-term support for a release should use an $OPT > string that starts with "lts", e.g., 11.0.2+13-lts. > > System properties > ----------------- > > To the system properties mentioned in JEP 223 we add one new property: > > java.version.date -- The GA date of this version, in ISO-8601 > YYYY-MM-DD format. For EA releases this will be the intended GA > date, i.e., some date in the future. This value is not part of the > version string per se, but it will be displayed when useful and can > be retrieved via a new method on the `Runtime.Version` API. > > This new property makes it easy to figure out how old a release is, so > that as a user you can understand how far behind you are. It also > reflects the security level of the release: A given GA release contains > the latest security fixes if its version date is no earlier than that of > any other GA release. > > Launcher > -------- > > The `java` launcher will display version strings and system properties as > follows, for a hypothetical build 13 of JDK 10.0.1: > > $ java --version > openjdk 10.0.1 2018-04-19 > OpenJDK Runtime Environment (build 10.0.1+13) > OpenJDK 64-Bit Server VM (build 10.0.1+13, mixed mode) > $ > > Similarly, for a hypothetical build 42 of JDK 11, an LTS release: > > $ java --version > openjdk 11 2018-09-20 LTS > OpenJDK Runtime Environment (build 11+42-lts) > OpenJDK 64-Bit Server VM (build 11+42-lts, mixed mode) > $ > > * * * > > If you've read this far, two questions: > > (1) Bearing in mind that no version-string scheme is ideal, > is this scheme acceptable? > > (2) If this scheme is not acceptable then please explain why, > and identify exactly what you would change. > > Ground rules, as before: I'll give much greater weight to your first > reply to this message than to any other, I'll ignore replies-to-replies, > and I'll heavily discount replies that quote more text than add new text > of their own. > > I'll summarize relevant replies in about a week, and then draft a JEP. > > - Mark > > > [1] > http://mail.openjdk.java.net/pipermail/jdk-dev/2017-October/000007.html > [2] > http://mail.openjdk.java.net/pipermail/jdk-dev/2017-November/000088.html > [3] http://openjdk.java.net/jeps/223 From scolebourne at joda.org Fri Nov 3 14:41:00 2017 From: scolebourne at joda.org (Stephen Colebourne) Date: Fri, 3 Nov 2017 14:41:00 +0000 Subject: Impact of six month releases In-Reply-To: <52078f75-e29d-7ddf-934f-15fe1092c6aa@redhat.com> References: <52078f75-e29d-7ddf-934f-15fe1092c6aa@redhat.com> Message-ID: On 3 November 2017 at 09:14, Andrew Haley wrote: >> I think this is throwing the baby (Java's long standing backwards >> compatibility) out with the bathwater (frequent releases), but I'm >> happy to hear other opinions. > > I don't believe that such worries are necessarily justified. > > We need to be able to roll back mistakes. The Java tradition that > nothing ever gets removed, no matter how much mistaken, holds back > innovation. It does this because of a justified fear that if we make > a mistake, we're stuck with it, so we have to be ultra-cautious. I think its more than that. Java's success is built on the broader ecosystem. The JDK itself is an enabler for that. Open source projects have to be able to produce jar files that work on multiple releases of the JDK. Things that prevent that are a big issue. In practical terms I'd argue that: 1) LTS releases define the removal cycle. Code added in a non-LTS release (n) can be deprecated in the next non-LTS release (n+1) and removed in the release after that (n+2). This works because the code was never in an LTS release. However, code that *was* in the last LTS release cannot be removed until the release after the next LTS. eg. code present in 8 cannot be removed until 12 (as 11 is the first LTS where the deprecation is visible) eg. code added in 12 can be deprecated in 13 and removed in 14 as 12 and 13 are non-LTS 2) There should be more than 2 security updates for each release. Without an overlap period, developers are forced to upgrade to the next release immediately it is GA. This does not reflect real-world software development practice. If the non-LTS releases are to be used in production they will need a bare minimum of 4 security updates (one year) to create a time window overlap with the next release. 3) The javac --release flag should work for at least the last three LTS releases. A time-window of 10 years would also be about right. (Its a *really* convenient feature, and if possible I'd prefer it to never lose support for older versions). Stephen From mark.reinhold at oracle.com Fri Nov 3 15:06:53 2017 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Fri, 03 Nov 2017 08:06:53 -0700 Subject: JDK $NEXT Early-Access Builds Message-ID: <20171103080653.93570520@eggemoggin.niobe.net> FYI, EA builds from Oracle are now available here: http://jdk.java.net/10/ - Mark From aph at redhat.com Fri Nov 3 15:25:49 2017 From: aph at redhat.com (Andrew Haley) Date: Fri, 3 Nov 2017 15:25:49 +0000 Subject: Impact of six month releases In-Reply-To: References: <52078f75-e29d-7ddf-934f-15fe1092c6aa@redhat.com> Message-ID: <93626be0-968e-a1ec-0c9c-c07c4cc4ca59@redhat.com> On 03/11/17 14:41, Stephen Colebourne wrote: > On 3 November 2017 at 09:14, Andrew Haley wrote: >>> I think this is throwing the baby (Java's long standing backwards >>> compatibility) out with the bathwater (frequent releases), but I'm >>> happy to hear other opinions. >> >> I don't believe that such worries are necessarily justified. >> >> We need to be able to roll back mistakes. The Java tradition that >> nothing ever gets removed, no matter how much mistaken, holds back >> innovation. It does this because of a justified fear that if we make >> a mistake, we're stuck with it, so we have to be ultra-cautious. > > I think its more than that. Java's success is built on the broader > ecosystem. The JDK itself is an enabler for that. Open source projects > have to be able to produce jar files that work on multiple releases of > the JDK. Things that prevent that are a big issue. What would prevent that? A new feature that turns out to be a bad idea will only be a problem if someone actually uses it. Everybody else can build jarfiles that are backwards compatible, and probably will. > In practical terms I'd argue that: > > 1) LTS releases define the removal cycle. Code added in a non-LTS > release (n) can be deprecated in the next non-LTS release (n+1) and > removed in the release after that (n+2). This works because the code > was never in an LTS release. However, code that *was* in the last LTS > release cannot be removed until the release after the next LTS. That might happen, but we must not bake such a restriction into our processes. LTS releases are not anything special: they are a freeze of the state of OpenJDK at one time. > eg. code present in 8 cannot be removed until 12 (as 11 is the first > LTS where the deprecation is visible) > eg. code added in 12 can be deprecated in 13 and removed in 14 as 12 > and 13 are non-LTS > > 2) There should be more than 2 security updates for each release. > Without an overlap period, developers are forced to upgrade to the > next release immediately it is GA. This does not reflect real-world > software development practice. If the non-LTS releases are to be used > in production they will need a bare minimum of 4 security updates (one > year) to create a time window overlap with the next release. I don't think that should be baked in either. Security updates are a lot of work. It's by no means guaranteed that people will have sufficient engineering resources to do that. We have the largest team doing independent OpenJDK releases at Red Hat, and I don't think that we'd want to commit to doing it. > 3) The javac --release flag should work for at least the last three > LTS releases. A time-window of 10 years would also be about right. > (Its a *really* convenient feature, and if possible I'd prefer it to > never lose support for older versions). That seems reasonable, but again I don't want to see it baked in to the rules. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From mark.reinhold at oracle.com Fri Nov 3 15:45:18 2017 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Fri, 03 Nov 2017 08:45:18 -0700 Subject: Proposal: Newer version-string scheme for the Java SE Platform and the JDK In-Reply-To: <20171102151148.49900EBFB8@eggemoggin.niobe.net> References: <20171102151148.49900EBFB8@eggemoggin.niobe.net> Message-ID: <20171103084518.985342606@eggemoggin.niobe.net> 2017/11/2 8:11:48 -0700, mark.reinhold at oracle.com: > Here's a specific proposal, with commentary, and two questions. > > ... > > - $FEATURE -- The feature-release counter, incremented every six months > regardless of release content. Thus the March 2018 release is 10, > the September 2018 release is 11, and so forth. Features may be > added in a feature release; they may also be removed, if advance > notice was given at least one feature release ahead of time. Note the wording: "if advance notice was given *at least* one feature release ahead of time." That doesn't mean that any feature, regardless of scope, can be removed with just six months' notice. Judgement will be required, and we'll no doubt develop some guidelines around deprecation, removal, and related things such as how far back the `javac --release` option goes. - Mark From benjamin.john.evans at gmail.com Fri Nov 3 16:06:24 2017 From: benjamin.john.evans at gmail.com (Ben Evans) Date: Fri, 3 Nov 2017 09:06:24 -0700 Subject: Proposal: Newer version-string scheme for the Java SE Platform and the JDK In-Reply-To: <20171102151148.49900EBFB8@eggemoggin.niobe.net> References: <20171102151148.49900EBFB8@eggemoggin.niobe.net> Message-ID: Broadly, this scheme seems to be an acceptable compromise. Thank you for taking the time to discuss, and for listening to concerns. A special thank you for not dooming the community to years of trying to explain "which version of Java we're developing with" to baffled recruiters when hiring. Thanks, Ben On Thu, Nov 2, 2017 at 8:11 AM, wrote: > Here's a specific proposal, with commentary, and two questions. > > Summary: This is a time-based scheme, similar to alternative (C) in my > earlier note [1][2] but even closer to the current scheme as defined in > JEP 223 [3]. It's hence even less likely to surprise, and should be > easier to adopt. > > * * * > > Version numbers > --------------- > > A version number, $VNUM, is a sequence of numerals of arbitrary length, > separated by period characters. The first four numerals are interpreted > as follows: > > $FEATURE.$INTERIM.$UPDATE.$EMERG > > where: > > - $FEATURE -- The feature-release counter, incremented every six months > regardless of release content. Thus the March 2018 release is 10, > the September 2018 release is 11, and so forth. Features may be > added in a feature release; they may also be removed, if advance > notice was given at least one feature release ahead of time. > Incompatible changes may be made when justified. (Formerly $MAJOR.) > > - $INTERIM -- The interim-release counter, incremented for non-feature > releases that contain compatible bug fixes and enhancements but no > incompatible changes, no feature removals, and no changes to standard > APIs. This counter is always zero for the current six-month release > model. We reserve it here to leave flexibility for the future, so > that some future release model could say that JDK $N.1 and JDK $N.2 > are compatible upgrades of JDK $N. Leaving this counter at zero for > the current model has an additional benefit in that it increases the > degree to which version numbers continue to reflect, roughly, both > compatibility and significance. (Formerly $MINOR.) > > - $UPDATE -- The update-release counter, incremented every three months > for compatible update releases that fix security issues, regressions, > and bugs in newer features. Thus the April 2018 release is 10.0.1, > the July release is 10.0.2, and so forth. (Formerly $SECURITY, but > with a non-trivial incrementation rule.) > > - $EMERG -- The emergency-release counter, incremented only when it's > necessary to produce an emergency release to fix an urgent security > issue. Using an additional numeral for this purpose minimizes the > disruption to both developers and users of in-flight update releases. > > The fifth and later elements of version numbers are reserved for use by > downstream consumers of the JDK code base. The fifth element may be used > to, e.g., identify implementor-specific patch releases. > > This is primarily a time-based scheme, since $FEATURE is incremented > every six months regardless of release content and, for each feature > release, $UPDATE is incremented every three months. We do expect most > feature releases to contain at least one or two significant features, > and never to ship interim releases under the new release model, so in > practice this scheme will often be very similar to a compatibility- or > significance-oriented scheme like that of JEP 223. JDK 10 is a feature > release, JDK 10.0.1 and 10.0.2 are update releases with compatible bug > fixes, and there is no interim JDK 10.1 release since in this model the > next opportunity to add features is JDK 11. > > Version strings > --------------- > > The overall format of version strings is unchanged. A version string is > a version number, $VNUM, optionally followed by pre-release, build, and > other optional information, one of: > > $VNUM(-$PRE)?\+$BUILD(-$OPT)? > $VNUM-$PRE(-$OPT)? > $VNUM(+-$OPT)? > > where $PRE is a pre-release identifier (e.g., `ea`), $BUILD is a build > number, and $OPT is optional build information. > > Implementors who offer long-term support for a release should use an $OPT > string that starts with "lts", e.g., 11.0.2+13-lts. > > System properties > ----------------- > > To the system properties mentioned in JEP 223 we add one new property: > > java.version.date -- The GA date of this version, in ISO-8601 > YYYY-MM-DD format. For EA releases this will be the intended GA > date, i.e., some date in the future. This value is not part of the > version string per se, but it will be displayed when useful and can > be retrieved via a new method on the `Runtime.Version` API. > > This new property makes it easy to figure out how old a release is, so > that as a user you can understand how far behind you are. It also > reflects the security level of the release: A given GA release contains > the latest security fixes if its version date is no earlier than that of > any other GA release. > > Launcher > -------- > > The `java` launcher will display version strings and system properties as > follows, for a hypothetical build 13 of JDK 10.0.1: > > $ java --version > openjdk 10.0.1 2018-04-19 > OpenJDK Runtime Environment (build 10.0.1+13) > OpenJDK 64-Bit Server VM (build 10.0.1+13, mixed mode) > $ > > Similarly, for a hypothetical build 42 of JDK 11, an LTS release: > > $ java --version > openjdk 11 2018-09-20 LTS > OpenJDK Runtime Environment (build 11+42-lts) > OpenJDK 64-Bit Server VM (build 11+42-lts, mixed mode) > $ > > * * * > > If you've read this far, two questions: > > (1) Bearing in mind that no version-string scheme is ideal, > is this scheme acceptable? > > (2) If this scheme is not acceptable then please explain why, > and identify exactly what you would change. > > Ground rules, as before: I'll give much greater weight to your first > reply to this message than to any other, I'll ignore replies-to-replies, > and I'll heavily discount replies that quote more text than add new text > of their own. > > I'll summarize relevant replies in about a week, and then draft a JEP. > > - Mark > > > [1] http://mail.openjdk.java.net/pipermail/jdk-dev/2017-October/000007.html > [2] http://mail.openjdk.java.net/pipermail/jdk-dev/2017-November/000088.html > [3] http://openjdk.java.net/jeps/223 From neugens.limasoftware at gmail.com Fri Nov 3 16:19:05 2017 From: neugens.limasoftware at gmail.com (Mario Torre) Date: Fri, 03 Nov 2017 16:19:05 +0000 Subject: Proposal: Newer version-string scheme for the Java SE Platform and the JDK In-Reply-To: References: <20171102151148.49900EBFB8@eggemoggin.niobe.net> Message-ID: On Fri 3. Nov 2017 at 17:06, Ben Evans wrote: > Broadly, this scheme seems to be an acceptable compromise. > > Thank you for taking the time to discuss, and for listening to concerns. > > A special thank you for not dooming the community to years of trying > to explain "which version of Java we're developing with" to baffled > recruiters when hiring. They?ll still be baffled though! Cheers, Mario > Thanks, > > Ben > > On Thu, Nov 2, 2017 at 8:11 AM, wrote: > > Here's a specific proposal, with commentary, and two questions. > > > > Summary: This is a time-based scheme, similar to alternative (C) in my > > earlier note [1][2] but even closer to the current scheme as defined in > > JEP 223 [3]. It's hence even less likely to surprise, and should be > > easier to adopt. > > > > * * * > > > > Version numbers > > --------------- > > > > A version number, $VNUM, is a sequence of numerals of arbitrary length, > > separated by period characters. The first four numerals are interpreted > > as follows: > > > > $FEATURE.$INTERIM.$UPDATE.$EMERG > > > > where: > > > > - $FEATURE -- The feature-release counter, incremented every six months > > regardless of release content. Thus the March 2018 release is 10, > > the September 2018 release is 11, and so forth. Features may be > > added in a feature release; they may also be removed, if advance > > notice was given at least one feature release ahead of time. > > Incompatible changes may be made when justified. (Formerly $MAJOR.) > > > > - $INTERIM -- The interim-release counter, incremented for non-feature > > releases that contain compatible bug fixes and enhancements but no > > incompatible changes, no feature removals, and no changes to standard > > APIs. This counter is always zero for the current six-month release > > model. We reserve it here to leave flexibility for the future, so > > that some future release model could say that JDK $N.1 and JDK $N.2 > > are compatible upgrades of JDK $N. Leaving this counter at zero for > > the current model has an additional benefit in that it increases the > > degree to which version numbers continue to reflect, roughly, both > > compatibility and significance. (Formerly $MINOR.) > > > > - $UPDATE -- The update-release counter, incremented every three months > > for compatible update releases that fix security issues, regressions, > > and bugs in newer features. Thus the April 2018 release is 10.0.1, > > the July release is 10.0.2, and so forth. (Formerly $SECURITY, but > > with a non-trivial incrementation rule.) > > > > - $EMERG -- The emergency-release counter, incremented only when it's > > necessary to produce an emergency release to fix an urgent security > > issue. Using an additional numeral for this purpose minimizes the > > disruption to both developers and users of in-flight update releases. > > > > The fifth and later elements of version numbers are reserved for use by > > downstream consumers of the JDK code base. The fifth element may be used > > to, e.g., identify implementor-specific patch releases. > > > > This is primarily a time-based scheme, since $FEATURE is incremented > > every six months regardless of release content and, for each feature > > release, $UPDATE is incremented every three months. We do expect most > > feature releases to contain at least one or two significant features, > > and never to ship interim releases under the new release model, so in > > practice this scheme will often be very similar to a compatibility- or > > significance-oriented scheme like that of JEP 223. JDK 10 is a feature > > release, JDK 10.0.1 and 10.0.2 are update releases with compatible bug > > fixes, and there is no interim JDK 10.1 release since in this model the > > next opportunity to add features is JDK 11. > > > > Version strings > > --------------- > > > > The overall format of version strings is unchanged. A version string is > > a version number, $VNUM, optionally followed by pre-release, build, and > > other optional information, one of: > > > > $VNUM(-$PRE)?\+$BUILD(-$OPT)? > > $VNUM-$PRE(-$OPT)? > > $VNUM(+-$OPT)? > > > > where $PRE is a pre-release identifier (e.g., `ea`), $BUILD is a build > > number, and $OPT is optional build information. > > > > Implementors who offer long-term support for a release should use an $OPT > > string that starts with "lts", e.g., 11.0.2+13-lts. > > > > System properties > > ----------------- > > > > To the system properties mentioned in JEP 223 we add one new property: > > > > java.version.date -- The GA date of this version, in ISO-8601 > > YYYY-MM-DD format. For EA releases this will be the intended GA > > date, i.e., some date in the future. This value is not part of the > > version string per se, but it will be displayed when useful and can > > be retrieved via a new method on the `Runtime.Version` API. > > > > This new property makes it easy to figure out how old a release is, so > > that as a user you can understand how far behind you are. It also > > reflects the security level of the release: A given GA release contains > > the latest security fixes if its version date is no earlier than that of > > any other GA release. > > > > Launcher > > -------- > > > > The `java` launcher will display version strings and system properties as > > follows, for a hypothetical build 13 of JDK 10.0.1: > > > > $ java --version > > openjdk 10.0.1 2018-04-19 > > OpenJDK Runtime Environment (build 10.0.1+13) > > OpenJDK 64-Bit Server VM (build 10.0.1+13, mixed mode) > > $ > > > > Similarly, for a hypothetical build 42 of JDK 11, an LTS release: > > > > $ java --version > > openjdk 11 2018-09-20 LTS > > OpenJDK Runtime Environment (build 11+42-lts) > > OpenJDK 64-Bit Server VM (build 11+42-lts, mixed mode) > > $ > > > > * * * > > > > If you've read this far, two questions: > > > > (1) Bearing in mind that no version-string scheme is ideal, > > is this scheme acceptable? > > > > (2) If this scheme is not acceptable then please explain why, > > and identify exactly what you would change. > > > > Ground rules, as before: I'll give much greater weight to your first > > reply to this message than to any other, I'll ignore replies-to-replies, > > and I'll heavily discount replies that quote more text than add new text > > of their own. > > > > I'll summarize relevant replies in about a week, and then draft a JEP. > > > > - Mark > > > > > > [1] > http://mail.openjdk.java.net/pipermail/jdk-dev/2017-October/000007.html > > [2] > http://mail.openjdk.java.net/pipermail/jdk-dev/2017-November/000088.html > > [3] http://openjdk.java.net/jeps/223 > From mark at talios.com Sat Nov 4 04:03:23 2017 From: mark at talios.com (Mark Derricutt) Date: Sat, 4 Nov 2017 17:03:23 +1300 Subject: JDK $NEXT Early-Access Builds In-Reply-To: <20171103080653.93570520@eggemoggin.niobe.net> References: <20171103080653.93570520@eggemoggin.niobe.net> Message-ID: Is 'var' local interference merged into these builds at all? The changes list doesn't mention it, but only goes back to build 10 ( I guess I'll find out once I install tho ). Mark -- "Great artists are extremely selfish and arrogant things" ? Steven Wilson, Porcupine Tree On Sat, Nov 4, 2017 at 4:06 AM, wrote: > FYI, EA builds from Oracle are now available here: > > http://jdk.java.net/10/ > > - Mark > From Alan.Bateman at oracle.com Sat Nov 4 07:48:52 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 4 Nov 2017 07:48:52 +0000 Subject: JDK $NEXT Early-Access Builds In-Reply-To: References: <20171103080653.93570520@eggemoggin.niobe.net> Message-ID: On 04/11/2017 04:03, Mark Derricutt wrote: > Is 'var' local interference merged into these builds at all? The changes > list doesn't mention it, but only goes back to build 10 ( I guess I'll find > out once I install tho ). > Yes, try it.? The download page doesn't currently have the list of changes in the each build. I think the page you are looking at is the release notes that have accumulated so far. -Alan. From kim at javadog.io Sat Nov 4 08:33:45 2017 From: kim at javadog.io (Kim Jensen) Date: Sat, 04 Nov 2017 04:33:45 -0400 Subject: Version numbers & LTS Message-ID: Hi, I must admit, that I was horror struck, when I first heard of year.month proposal from Mark Reinhold, the new version number proposal is an improvement, but still one that I see many problems with, so it was a pleasure seeing that others like Stephen Colebourne shared my concerns. Many projects are months/years in the making and subsequent support, any updates will potentially have consequences - and upgrading to the next major Java version is thus not undertaken lightly. Having a new major release every few years is acceptable, but having a major release every few months (with or without LTS support), will be unacceptable to many customers as it may delay projects and increase prices. Resulting in customers either leaving the Java platform or simply insisting on using older, unsupported (insecure), versions of Java. As a developer, I fully support the wishes of the JDK developers, to have more frequent releases so they can quicker move forward. But, for a platform that is running on more than a billion devices, ranging from small apps to huge applications - there simply is a price. And part of Java's success was the stable backwards compatible releases. I see an improvement with the latest proposal - but as Stephen pointed out, it is still not good enough. And from looking at the latest proposal, it struck me that the interim/minor number is always suppose to be 0. Why not make the major number the LTS release, and the minor number the Feature or Mile Stone release ? This way, it will allow JDK developers to make more frequent releases, and give some more clarity for customers. My proposal, is to use a scheme similar to what SonarSource is using: - 10.0.0 - Initial 10 Development release - 10.0.1 - Update release - 10.0.2 - Update release - 10.1.0 - Feature or Mile Stone release - 10.1.1 - Update release - 10.1.2 - Update release - 10.2.0 - Feature or Milt Stone release - 10.2.1 - Update release - 10.2.2 - LTS Release - 11.0.0 - Initial 11 Development release - 10.2.3 - LTS Update release I respect that it would be good to reserve some information for future use, but now we have finally removed the leading 1 - please don't add more stale information to the version number. a static 0 as the minor number is simply redundant. Reserving it for future use, is silly as it can be put to good use now. /Kim Good judgment comes from experience; experience comes from bad judgment. From andy.herrick at oracle.com Sat Nov 4 13:27:11 2017 From: andy.herrick at oracle.com (Andy Herrick) Date: Sat, 4 Nov 2017 09:27:11 -0400 Subject: Proposal: Newer version-string scheme for the Java SE Platform and the JDK In-Reply-To: <20171102151148.49900EBFB8@eggemoggin.niobe.net> References: <20171102151148.49900EBFB8@eggemoggin.niobe.net> Message-ID: I would suggest to synchronize the $UPDATE number across $FEATURE releases so we would have: 10.0.0 : initial public release of JDK10 10.0.1: first update release of JDK10 10.0.2: second update release of JDK10 11.0.0 : initial public release of JDK10 (or 11.0.2, see below) 11.0.3 : first update release of JDK11 10.0.3 : third update release of JDK10 (if there is one with same set of security fixes as 11.0.3) 11.0.4 : second update of JDK11 10.0.4: fourth update of JDK10 (if released at same time as 11.0.4) We could even also use that for the first public release of JDK11, make it 11.0.2 (since it would have all the security fixes of 10.0.2) this way it would be programmatically easy to see which is more secure (10.0.4 or 11.0.3 for example) by looking at the $UPDATE.\, without resorting to looking at security basline info files.. /Andy On 11/2/2017 11:11 AM, mark.reinhold at oracle.com wrote: > Here's a specific proposal, with commentary, and two questions. > > Summary: This is a time-based scheme, similar to alternative (C) in my > earlier note [1][2] but even closer to the current scheme as defined in > JEP 223 [3]. It's hence even less likely to surprise, and should be > easier to adopt. > > * * * > > Version numbers > --------------- > > A version number, $VNUM, is a sequence of numerals of arbitrary length, > separated by period characters. The first four numerals are interpreted > as follows: > > $FEATURE.$INTERIM.$UPDATE.$EMERG > > where: > > - $FEATURE -- The feature-release counter, incremented every six months > regardless of release content. Thus the March 2018 release is 10, > the September 2018 release is 11, and so forth. Features may be > added in a feature release; they may also be removed, if advance > notice was given at least one feature release ahead of time. > Incompatible changes may be made when justified. (Formerly $MAJOR.) > > - $INTERIM -- The interim-release counter, incremented for non-feature > releases that contain compatible bug fixes and enhancements but no > incompatible changes, no feature removals, and no changes to standard > APIs. This counter is always zero for the current six-month release > model. We reserve it here to leave flexibility for the future, so > that some future release model could say that JDK $N.1 and JDK $N.2 > are compatible upgrades of JDK $N. Leaving this counter at zero for > the current model has an additional benefit in that it increases the > degree to which version numbers continue to reflect, roughly, both > compatibility and significance. (Formerly $MINOR.) > > - $UPDATE -- The update-release counter, incremented every three months > for compatible update releases that fix security issues, regressions, > and bugs in newer features. Thus the April 2018 release is 10.0.1, > the July release is 10.0.2, and so forth. (Formerly $SECURITY, but > with a non-trivial incrementation rule.) > > - $EMERG -- The emergency-release counter, incremented only when it's > necessary to produce an emergency release to fix an urgent security > issue. Using an additional numeral for this purpose minimizes the > disruption to both developers and users of in-flight update releases. > > The fifth and later elements of version numbers are reserved for use by > downstream consumers of the JDK code base. The fifth element may be used > to, e.g., identify implementor-specific patch releases. > > This is primarily a time-based scheme, since $FEATURE is incremented > every six months regardless of release content and, for each feature > release, $UPDATE is incremented every three months. We do expect most > feature releases to contain at least one or two significant features, > and never to ship interim releases under the new release model, so in > practice this scheme will often be very similar to a compatibility- or > significance-oriented scheme like that of JEP 223. JDK 10 is a feature > release, JDK 10.0.1 and 10.0.2 are update releases with compatible bug > fixes, and there is no interim JDK 10.1 release since in this model the > next opportunity to add features is JDK 11. > > Version strings > --------------- > > The overall format of version strings is unchanged. A version string is > a version number, $VNUM, optionally followed by pre-release, build, and > other optional information, one of: > > $VNUM(-$PRE)?\+$BUILD(-$OPT)? > $VNUM-$PRE(-$OPT)? > $VNUM(+-$OPT)? > > where $PRE is a pre-release identifier (e.g., `ea`), $BUILD is a build > number, and $OPT is optional build information. > > Implementors who offer long-term support for a release should use an $OPT > string that starts with "lts", e.g., 11.0.2+13-lts. > > System properties > ----------------- > > To the system properties mentioned in JEP 223 we add one new property: > > java.version.date -- The GA date of this version, in ISO-8601 > YYYY-MM-DD format. For EA releases this will be the intended GA > date, i.e., some date in the future. This value is not part of the > version string per se, but it will be displayed when useful and can > be retrieved via a new method on the `Runtime.Version` API. > > This new property makes it easy to figure out how old a release is, so > that as a user you can understand how far behind you are. It also > reflects the security level of the release: A given GA release contains > the latest security fixes if its version date is no earlier than that of > any other GA release. > > Launcher > -------- > > The `java` launcher will display version strings and system properties as > follows, for a hypothetical build 13 of JDK 10.0.1: > > $ java --version > openjdk 10.0.1 2018-04-19 > OpenJDK Runtime Environment (build 10.0.1+13) > OpenJDK 64-Bit Server VM (build 10.0.1+13, mixed mode) > $ > > Similarly, for a hypothetical build 42 of JDK 11, an LTS release: > > $ java --version > openjdk 11 2018-09-20 LTS > OpenJDK Runtime Environment (build 11+42-lts) > OpenJDK 64-Bit Server VM (build 11+42-lts, mixed mode) > $ > > * * * > > If you've read this far, two questions: > > (1) Bearing in mind that no version-string scheme is ideal, > is this scheme acceptable? > > (2) If this scheme is not acceptable then please explain why, > and identify exactly what you would change. > > Ground rules, as before: I'll give much greater weight to your first > reply to this message than to any other, I'll ignore replies-to-replies, > and I'll heavily discount replies that quote more text than add new text > of their own. > > I'll summarize relevant replies in about a week, and then draft a JEP. > > - Mark > > > [1] http://mail.openjdk.java.net/pipermail/jdk-dev/2017-October/000007.html > [2] http://mail.openjdk.java.net/pipermail/jdk-dev/2017-November/000088.html > [3] http://openjdk.java.net/jeps/223 From iris.clark at oracle.com Sun Nov 5 05:09:17 2017 From: iris.clark at oracle.com (Iris Clark) Date: Sat, 4 Nov 2017 22:09:17 -0700 (PDT) Subject: New JDK development repositories In-Reply-To: <<20171101152116.9B6BCEBE13@eggemoggin.niobe.net>> References: <<20171101152116.9B6BCEBE13@eggemoggin.niobe.net>> Message-ID: <3874bd33-bc7a-4ce1-be1c-813dac0e6b55@default> Hi. The new Project JDK forests and associated mailing lists have been created as described below. Enjoy, iris -----Original Message----- From: jdk-dev [mailto:jdk-dev-bounces at openjdk.java.net] On Behalf Of mark.reinhold at oracle.com Sent: Wednesday, November 1, 2017 8:21 AM To: jdk-dev at openjdk.java.net Subject: New JDK development repositories Thus far we've continued main-line development in the existing JDK 10 repositories. This weekend, early on Sunday, 5 November UTC, we'll cut over to the new JDK Project repositories, which will be here: http://hg.openjdk.java.net/jdk/jdk -- Main line http://hg.openjdk.java.net/jdk/client -- Client development http://hg.openjdk.java.net/jdk/hs -- HotSpot development These repositories will be initialized from the JDK 10 master, client, and hs repositories, respectively. (We're moving back to "jdk" as the name of the main-line repository; "master" was a temporary name, needed to establish the consolidated JDK 10 repository as distinct from the previous main-line forest.) The old repositories under http://hg.openjdk.java.net/jdk10 will be made read-only at 02:30 UTC on Sunday [1]; the new repositories should be available a few hours later. After that, you can change the default pull and push paths of an existing clone of a JDK 10 repository via the Mercurial defpath extension [2], passing it one of the above URLs. If you subscribed to one or more of the jdk10-*-changes list(s) for Mercurial notifications then you'll automatically be subscribed to the corresponding jdk-*-changes list(s). The jdk10/client and jdk10/hs repositories will eventually be deleted; the jdk10/master repository will be retained, or else we'll set up an HTTP redirect, so that old URLs continue to work. - Mark [1] https://www.timeanddate.com/worldclock/fixedtime.html?msg=JDK+Repository+Cutover&iso=20171105T0230 [2] http://openjdk.java.net/projects/code-tools/defpath/ From volker.simonis at gmail.com Sun Nov 5 23:49:22 2017 From: volker.simonis at gmail.com (Volker Simonis) Date: Sun, 05 Nov 2017 23:49:22 +0000 Subject: JEPs proposed to target JDK 10 (2017/11/2) In-Reply-To: <20171102153759.744852081@eggemoggin.niobe.net> References: <20171102153759.744852081@eggemoggin.niobe.net> Message-ID: Hi Mark, DISCLAIMER: my comments are purely process related! In a previous post you wrote that the mainline will always be feature complete [1]. Looking at these JEPs, I wonder how we can ensure that? I know that the proposed JEPs have been extensively discussed and (at least partially) reviewed on the corresponding mailing list. Still, from looking at JBS alone, it seems impossible to find out if one of the proposed JEPs is feature complete and thus ready to be targeted for JDK 10. For example the JBS entry forJEP 304 mentions 15 issues it relates to. Five of these issues have already been fixed and integrated (which seems strange if the overall JEP hasn't even been targeted). I think if we take you "increase the release cadence" proposal seriously, such new JEPs should actually really be implemented in their own repositories (or branches) with their own builds and tests. Only then we could say (and prove) that a JEP is really ready for integration into the main line. Of course such an approach is completely unrealistic with our current setup. Another problem I see is that scope of a JEP may vary from a single webrev up to a douzen and more different issues but we currently treat them all in the same way. If there's a vague feeling that a JEP is 'mostly' implemented, we target it. We really need something like lightweight branches with their own builds and tests to effectively work in the proposed way. Finall, I want to stress once again, that I don't want to criticize the three proposed JEPs in any way. I fully support all of them and I think it is good to have them in JDK 10. I just wonder if we can meet the high goals you set when proposing the new release cadence with our current tools and infrastructure. Comments welcome ... Regards, Volker [1] http://openjdk.java.net/projects/jdk8/milestones#Feature_Complete schrieb am Fr. 3. Nov. 2017 um 01:37: > The following JEPs have been placed into the "Proposed to Target" state > by their owners after discussion and review: > > 304: Garbage-Collector Interface > http://openjdk.java.net/jeps/304 > > 307: Parallel Full GC for G1 > http://openjdk.java.net/jeps/307 > > 312: Thread-Local Handshakes > http://openjdk.java.net/jeps/312 > > Feedback on these proposals is more than welcome, as are reasoned > objections. If no such objections are raised by 23:00 UTC on Thursday, > 9 November, or if they're raised and then satisfactorily answered, then > per the JEP 2.0 process proposal [1] I'll target these JEPs to JDK 10. > > - Mark > > > [1] http://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html > From david.holmes at oracle.com Mon Nov 6 01:05:50 2017 From: david.holmes at oracle.com (David Holmes) Date: Mon, 6 Nov 2017 11:05:50 +1000 Subject: Impact of six month releases In-Reply-To: <9a50879008d14b0fbbcb110ae3ce7d00@sap.com> References: <9a50879008d14b0fbbcb110ae3ce7d00@sap.com> Message-ID: <1625bb96-9398-08c3-f7e8-f0e0199b0ee5@oracle.com> Hi Goetz, On 3/11/2017 8:23 PM, Lindenmaier, Goetz wrote: > Hi, > > I share the concerns mentioned in this thread. > I just picked up work on our internal "next Java release after 8" > project, which now has been relabeled from '9' to '11', > and has been delayed the third time now. > > The first change I looked at was " 8173421: Obsolete and expired > flags for JDK 10 need to be removed and related tests updated". > > I think this change needs to be redone: First it needs to > be reverted, then one needs to replace '9' by '11' and '10' > by '17'. Thus, the flags can be removed in jdk17 only, > which is in 2021. > > I appreciate that Java moves forward faster, as adding > JEPs as "286: Local-Variable Type Inference" need not > be delayed as long as it would have been in the old > release rhythm. > But deprecating stuff can only be done in the LTE releases, > as most users will only see these. 8173421 is NOT deprecating stuff, it is removing flags that are as-of JDK 9 (if not earlier) completely unused - that is what "obsolete" means. David ----- > We are happy that one of our larger products will go to 8 > next year, finally! For another product the installed base currently > is 6: 5%, 7: 65%, 8: 30% ... Other teams that had planned to go to 9 > now will wait until 11. We, the JVM team, would like to see > faster adoption of new Java version, as we don't like to keep > supporting the old releases. But now the next LTE will be delayed > another year. And adoption of JDK11 by these products > will be even harder if there are lots of sudden incompatible > changes ... and here sudden means from one LTE to another, > no matter how much time there is between LTEs. > > Best regards, > Goetz. > > >> -----Original Message----- >> From: jdk-dev [mailto:jdk-dev-bounces at openjdk.java.net] On Behalf Of >> Ryan Schmitt >> Sent: Freitag, 3. November 2017 01:21 >> To: Stephen Colebourne >> Cc: jdk-dev at openjdk.java.net >> Subject: Re: Impact of six month releases >> >> I have similar concerns along these lines. For example, JDK9 >> introduced the "one plus three back" policy for cross >> compilation, such that javac in JDK9 can now only target JDK6 >> and newer. Under the old release schedule, "one back plus >> three" could easily cover a decade's worth of JDKs, but now >> that window will shrink to approximately two years. There are >> similar questions around JDK deprecations: how long do my >> dependencies have to migrate to VarHandles and StackWalker? >> Three years or six months? Will we continue to have a new >> bytecode version with every release, or will the classfile >> format only be incremented as needed? From david.holmes at oracle.com Mon Nov 6 01:33:50 2017 From: david.holmes at oracle.com (David Holmes) Date: Mon, 6 Nov 2017 11:33:50 +1000 Subject: Impact of six month releases In-Reply-To: <1625bb96-9398-08c3-f7e8-f0e0199b0ee5@oracle.com> References: <9a50879008d14b0fbbcb110ae3ce7d00@sap.com> <1625bb96-9398-08c3-f7e8-f0e0199b0ee5@oracle.com> Message-ID: My apologies Goetz, what I stated was incorrect for some of the flags ... On 6/11/2017 11:05 AM, David Holmes wrote: > Hi Goetz, > > On 3/11/2017 8:23 PM, Lindenmaier, Goetz wrote: >> Hi, >> >> I share the concerns mentioned in this thread. >> I just picked up work on our internal "next Java release after 8" >> project, which now has been relabeled from '9' to '11', >> and has been delayed the third time now. >> >> The first change I looked at was " 8173421: Obsolete and expired >> flags for JDK 10 need to be removed and related tests updated". >> >> I think this change needs to be redone:? First it needs to >> be reverted, then one needs to replace '9' by '11' and '10' >> by '17'.? Thus, the flags can be removed in jdk17 only, >> which is in 2021. >> >> I appreciate that Java moves forward faster, as adding >> JEPs as "286: Local-Variable Type Inference" need not >> be delayed as long as it would have been in the old >> release rhythm. >> But deprecating stuff can only be done in the LTE releases, >> as most users will only see these. > > 8173421 is NOT deprecating stuff, it is removing flags that are as-of > JDK 9 (if not earlier) completely unused - that is what "obsolete" means. Some of the GC flags were deprecated in 9 and expired in 10: AutoGCSelectPauseMillis UseAutoGCSelectPolicy UseParNewGC ExplicitGCInvokesConcurrentAndUnloadsClasses CMSMarkStackSizeMax CMSMarkStackSize G1MarkStackSize ParallelMarkingThreads ParallelCMSThreads Normally you would expect to step through deprecated -> obsolete -> expired in subsequent releases. However the GC team decided it was appropriate to remove them more aggressively (though the only difference between obsolete and expired is whether the flag can appear on the command-line without causing an error). Of course at the time this was pushed there was no knowledge that 10 would be anything other than the next major release. The argument being made now is that a product flag deprecated in one LTS release, should not be made obsolete until the next LTS release, and then expired in the following LTS release. Personally I feel that would be far too limiting and defeat the primary purpose of having six month releases as we would need to keep the code pertaining to those flags for many years. As a case in point it may be that the changes to GC that are already in JDK 10 would not allow for the restoration of the flags that have been removed. David ----- > David > ----- > >> We are happy that one of our larger products will go to 8 >> next year, finally!? For another product the installed base currently >> is 6: 5%, 7: 65%, 8: 30% ... Other teams that had planned to go to 9 >> now will wait until 11. We, the JVM team, would like to see >> faster adoption of new Java version, as we don't like to keep >> supporting the old releases. But now the next LTE will be delayed >> another year. And adoption of JDK11 by these products >> will be even harder if there are lots of sudden incompatible >> changes ... and here sudden means from one LTE to another, >> no matter how much time there is between LTEs. >> >> Best regards, >> ?? Goetz. >> >> >>> -----Original Message----- >>> From: jdk-dev [mailto:jdk-dev-bounces at openjdk.java.net] On Behalf Of >>> Ryan Schmitt >>> Sent: Freitag, 3. November 2017 01:21 >>> To: Stephen Colebourne >>> Cc: jdk-dev at openjdk.java.net >>> Subject: Re: Impact of six month releases >>> >>> I have similar concerns along these lines. For example, JDK9 >>> introduced the "one plus three back" policy for cross >>> compilation, such that javac in JDK9 can now only target JDK6 >>> and newer. Under the old release schedule, "one back plus >>> three" could easily cover a decade's worth of JDKs, but now >>> that window will shrink to approximately two years. There are >>> similar questions around JDK deprecations: how long do my >>> dependencies have to migrate to VarHandles and StackWalker? >>> Three years or six months? Will we continue to have a new >>> bytecode version with every release, or will the classfile >>> format only be incremented as needed? From volker.simonis at gmail.com Mon Nov 6 07:31:01 2017 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 06 Nov 2017 07:31:01 +0000 Subject: Impact of six month releases In-Reply-To: References: <52078f75-e29d-7ddf-934f-15fe1092c6aa@redhat.com> Message-ID: Hi Stephen, I fully agree with all the points you've raised. BUT the OpenJDK is not the binary Java distribution most people use (similar to that fact that few people use a vanilla Linux kernel). It wasn't even available until recently! The vast majority has always used the Oracle JDK or the JDK that comes with their Linux distribution (not to mention all the other commercial and free Java distributions which are available as well). All these binary distributions are downstream versions of the vanilla OpenJDK project and they can all freely choose their support time frame and downport policy. Again, as an analogy, just think about how Linux distros support old Linux kernels and enhance them with down ports from newer kernels independently of the main kernel development. My personal opinion is that we will eventually come to a similar model with Java. >From my understanding the "new release cadence" step has always been at least as much about reorganizing the Java support business as it was about innovation. And it seems that others are now slowly realizing this as well ;) Regards, Volker Stephen Colebourne schrieb am Fr. 3. Nov. 2017 um 17:41: > On 3 November 2017 at 09:14, Andrew Haley wrote: > >> I think this is throwing the baby (Java's long standing backwards > >> compatibility) out with the bathwater (frequent releases), but I'm > >> happy to hear other opinions. > > > > I don't believe that such worries are necessarily justified. > > > > We need to be able to roll back mistakes. The Java tradition that > > nothing ever gets removed, no matter how much mistaken, holds back > > innovation. It does this because of a justified fear that if we make > > a mistake, we're stuck with it, so we have to be ultra-cautious. > > I think its more than that. Java's success is built on the broader > ecosystem. The JDK itself is an enabler for that. Open source projects > have to be able to produce jar files that work on multiple releases of > the JDK. Things that prevent that are a big issue. > > In practical terms I'd argue that: > > 1) LTS releases define the removal cycle. Code added in a non-LTS > release (n) can be deprecated in the next non-LTS release (n+1) and > removed in the release after that (n+2). This works because the code > was never in an LTS release. However, code that *was* in the last LTS > release cannot be removed until the release after the next LTS. > > eg. code present in 8 cannot be removed until 12 (as 11 is the first > LTS where the deprecation is visible) > eg. code added in 12 can be deprecated in 13 and removed in 14 as 12 > and 13 are non-LTS > > 2) There should be more than 2 security updates for each release. > Without an overlap period, developers are forced to upgrade to the > next release immediately it is GA. This does not reflect real-world > software development practice. If the non-LTS releases are to be used > in production they will need a bare minimum of 4 security updates (one > year) to create a time window overlap with the next release. > > 3) The javac --release flag should work for at least the last three > LTS releases. A time-window of 10 years would also be about right. > (Its a *really* convenient feature, and if possible I'd prefer it to > never lose support for older versions). > > Stephen > From kim at javadog.io Mon Nov 6 08:32:43 2017 From: kim at javadog.io (Kim Jensen) Date: Mon, 06 Nov 2017 03:32:43 -0500 Subject: Impact of six month releases In-Reply-To: References: <52078f75-e29d-7ddf-934f-15fe1092c6aa@redhat.com> Message-ID: Hi Volker, Customers have so far been able to rely on Java, as a very innovative, stable, scalable and reliable platform - there is a reason why it is so widely adopted and used. However, with the release of Java 9 and the subsequent announcement of the new Release Cycles [1], many people were baffled. Earlier, we had at least a year to complete migration from one major version to the next. Sometimes the migration is not trivial, my best example is that JBoss only managed to ready for Java 8 one month before Java 7 the final Java 7 public update. Leaving us with very little time to test & push out the upgrades, as these all have to be coordinated with our customers internal patch & release cycles. Right now, we're in the situation that nobody knows how to deal with. Java 8 goes EOL in less than a year, Java 9 goes EOL in a few months. And the replacement has not even been released. Migrating to Java 9 is far from easy, we have so much code that doesn't work, and so many libraries which also fails. Right now, we cannot make any plans for the future - and the result will either be that the customers will run with outdated & insecure Java Versions or they'll go to different platform like .Net. It may be that in the future, the new LTS versions will work like a charm, but right now - with the new Release Cycle from Oracle - How can we upgrade ? Java 9 goes EOL in a few months and Java 8 in less than a year. It makes it impossible to plan, and this means that Java has moved from a rock solid foundation to a liability. /Kim [1] http://www.oracle.com/technetwork/java/eol-135779.html Good judgment comes from experience; experience comes from bad judgment. > -------- Original Message -------- > Subject: Re: Impact of six month releases > Local Time: November 6, 2017 8:31 AM > UTC Time: November 6, 2017 7:31 AM > From: volker.simonis at gmail.com > To: Stephen Colebourne > jdk-dev at openjdk.java.net > > Hi Stephen, > > I fully agree with all the points you've raised. BUT the OpenJDK is not the > binary Java distribution most people use (similar to that fact that few > people use a vanilla Linux kernel). It wasn't even available until recently! > > The vast majority has always used the Oracle JDK or the JDK that comes with > their Linux distribution (not to mention all the other commercial and free > Java distributions which are available as well). All these binary > distributions are downstream versions of the vanilla OpenJDK project and > they can all freely choose their support time frame and downport policy. > Again, as an analogy, just think about how Linux distros support old Linux > kernels and enhance them with down ports from newer kernels independently > of the main kernel development. My personal opinion is that we will > eventually come to a similar model with Java. > > From my understanding the "new release cadence" step has always been at > least as much about reorganizing the Java support business as it was about > innovation. And it seems that others are now slowly realizing this as well > ;) > > Regards, > Volker > > Stephen Colebourne scolebourne at joda.org schrieb am Fr. 3. Nov. 2017 um > 17:41: > >> On 3 November 2017 at 09:14, Andrew Haley aph at redhat.com wrote: >> >>>> I think this is throwing the baby (Java's long standing backwards >>>> compatibility) out with the bathwater (frequent releases), but I'm >>>> happy to hear other opinions. >>> >>> I don't believe that such worries are necessarily justified. >>> We need to be able to roll back mistakes. The Java tradition that >>> nothing ever gets removed, no matter how much mistaken, holds back >>> innovation. It does this because of a justified fear that if we make >>> a mistake, we're stuck with it, so we have to be ultra-cautious. >> >> I think its more than that. Java's success is built on the broader >> ecosystem. The JDK itself is an enabler for that. Open source projects >> have to be able to produce jar files that work on multiple releases of >> the JDK. Things that prevent that are a big issue. >> In practical terms I'd argue that: >> >> - LTS releases define the removal cycle. Code added in a non-LTS >> release (n) can be deprecated in the next non-LTS release (n+1) and >> removed in the release after that (n+2). This works because the code >> was never in an LTS release. However, code that was in the last LTS >> release cannot be removed until the release after the next LTS. >> >> eg. code present in 8 cannot be removed until 12 (as 11 is the first >> LTS where the deprecation is visible) >> eg. code added in 12 can be deprecated in 13 and removed in 14 as 12 >> and 13 are non-LTS >> >> - There should be more than 2 security updates for each release. >> Without an overlap period, developers are forced to upgrade to the >> next release immediately it is GA. This does not reflect real-world >> software development practice. If the non-LTS releases are to be used >> in production they will need a bare minimum of 4 security updates (one >> year) to create a time window overlap with the next release. >> - The javac --release flag should work for at least the last three >> LTS releases. A time-window of 10 years would also be about right. >> (Its a really convenient feature, and if possible I'd prefer it to >> never lose support for older versions). >> >> Stephen From mark.reinhold at oracle.com Mon Nov 6 09:14:41 2017 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Mon, 6 Nov 2017 10:14:41 +0100 (CET) Subject: What kinds of changes need a JEP? Message-ID: <20171106091441.3E141FD068@eggemoggin.niobe.net> I'm working on an overall update of the JEP process documents, which have been in a draft state for too long now. One issue we can discuss independently is that of the criteria for what kinds of changes need a JEP. The primary process document, JEP 1, currently states [1]: > An _enhancement_ is an effort to design and implement a nontrivial > change to the JDK code base or to do some other kind of work whose > goals, progress, and result are worth communicating broadly. A JDK > Enhancement Proposal (hereinafter "JEP") should be drafted for any > work that meets at least one of the following criteria: > > - It requires two or more weeks of engineering effort, > > - It makes a significant change to the JDK, or to the processes > and infrastructure by which it is developed, or > > - It is in high demand by developers or customers. Based on the experience of using the JEP process in one form or another for both JDK 8 and JDK 9, and looking ahead to the six-month release cadence, there are at least three ways in which these criteria could be improved. (1) Do not mandate a JEP for a change just because that change requires two or more weeks of engineering effort. Several committers and reviewers have observed that the first of the above criteria, "requires two or more weeks of engineering effort," is at odds with the preceding definition of "enhancement," namely a change that's "worth communicating broadly," especially when that means running it through the JEP process for candidate review, target proposal, and so forth. Some changes can take more than two weeks of effort but aren't worth the effort to communicate broadly via the JEP process, particularly if they mainly concern developers of the JDK itself and have minimal impact on those who use and deploy the JDK. Examples include, but are not limited to, straightforward performance enhancements, refactorings of internal implementation code, improvements to tests, and merges of upstream code that have little or no effect on exported APIs. Such changes can be communicated adequately via ordinary enhancement issues in JBS, in CSR issues when exported APIs or other public interfaces are affected, and in the public reviews of such changes that we already do. We could reduce the overhead of these sorts of changes by dropping the first criterion, so that we no longer mandate a JEP for a change that merely "requires two or more weeks of engineering effort," and adding a criterion to require a JEP for a change that can't be communicated adequately via normal JBS enhancement or CSR issues. (2) Do not use the JEP process to track changes in development processes or infrastructure. In practice we just haven't used the JEP process for these purposes. The processes by which we stabilized JDK 8 and JDK 9, e.g., were proposed and discussed on development mailing lists and documented on project-specific web pages. The same is true of the CSR process. We seem to have gotten along fine without using the JEP process as a meta-process for all other processes, so let's drop this part of the second criterion. Insofar as we've had "infrastructure" JEPs, they've been for enhancements to the infrastructure of the JDK's build system rather than to software or systems outside of the JDK, which was the original intent. Such JEPs could as easily be characterized as "feature" JEPs, so we can drop the "infrastructure" part of the second criterion also. (3) Do mandate JEPs for risky changes. A strict, six-month release cadence leaves few opportunities to repair or back out bad changes. A change that carries significant risk is worth communicating broadly, and can benefit from the additional scrutiny that it will receive when it's proposed to target a specific release. * * * Here's a proposed new list of criteria that incorporates these changes. A JEP should be drafted for a body of work when at least one of the following is true: - It makes a significant or risky change to the JDK, - It has a broader impact on developers and users than can reasonably be communicated in an ordinary enhancement or CSR issue, or - It is in high demand by developers or users. Comments? - Mark [1] http://openjdk.java.net/jeps/1#Overview From roman at kennke.org Mon Nov 6 10:35:12 2017 From: roman at kennke.org (Roman Kennke) Date: Mon, 6 Nov 2017 11:35:12 +0100 Subject: JEPs proposed to target JDK 10 (2017/11/2) In-Reply-To: References: <20171102153759.744852081@eggemoggin.niobe.net> Message-ID: Hi Volker, We started pushing JEP 304 related changes before the JEP has been targeted mostly because I did not know it. The JEP process is not clear about it. When we learned that having a JEP targeted is a pre-condition, we immediately moved it forward. Also, all GC interface related changes so far have been kind-of prepraratory and the really big and important one (the barrier refactoring) will come after the JEP has been targeted. The biggest issue is that the JEP is a sort of waterfall process, and it doesn't really align well with things like GC interface, which we are doing incrementally. In hindsight, it might have been more useful to not file a JEP to begin with. And I will certainly think twice before filing a JEP in the future. Roman > Hi Mark, > > DISCLAIMER: my comments are purely process related! > > In a previous post you wrote that the mainline will always be feature > complete [1]. > > Looking at these JEPs, I wonder how we can ensure that? I know that the > proposed JEPs have been extensively discussed and (at least partially) > reviewed on the corresponding mailing list. Still, from looking at JBS > alone, it seems impossible to find out if one of the proposed JEPs is > feature complete and thus ready to be targeted for JDK 10. > > For example the JBS entry forJEP 304 mentions 15 issues it relates to. Five > of these issues have already been fixed and integrated (which seems strange > if the overall JEP hasn't even been targeted). > > I think if we take you "increase the release cadence" proposal seriously, > such new JEPs should actually really be implemented in their own > repositories (or branches) with their own builds and tests. Only then we > could say (and prove) that a JEP is really ready for integration into the > main line. Of course such an approach is completely unrealistic with our > current setup. > > Another problem I see is that scope of a JEP may vary from a single webrev > up to a douzen and more different issues but we currently treat them all in > the same way. If there's a vague feeling that a JEP is 'mostly' > implemented, we target it. > > We really need something like lightweight branches with their own builds > and tests to effectively work in the proposed way. > > Finall, I want to stress once again, that I don't want to criticize the > three proposed JEPs in any way. I fully support all of them and I think it > is good to have them in JDK 10. I just wonder if we can meet the high goals > you set when proposing the new release cadence with our current tools and > infrastructure. > > Comments welcome ... > > Regards, > Volker > > [1] http://openjdk.java.net/projects/jdk8/milestones#Feature_Complete > > schrieb am Fr. 3. Nov. 2017 um 01:37: > >> The following JEPs have been placed into the "Proposed to Target" state >> by their owners after discussion and review: >> >> 304: Garbage-Collector Interface >> http://openjdk.java.net/jeps/304 >> >> 307: Parallel Full GC for G1 >> http://openjdk.java.net/jeps/307 >> >> 312: Thread-Local Handshakes >> http://openjdk.java.net/jeps/312 >> >> Feedback on these proposals is more than welcome, as are reasoned >> objections. If no such objections are raised by 23:00 UTC on Thursday, >> 9 November, or if they're raised and then satisfactorily answered, then >> per the JEP 2.0 process proposal [1] I'll target these JEPs to JDK 10. >> >> - Mark >> >> >> [1] http://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html >> From erik.helin at oracle.com Mon Nov 6 12:11:24 2017 From: erik.helin at oracle.com (Erik Helin) Date: Mon, 6 Nov 2017 13:11:24 +0100 Subject: What kinds of changes need a JEP? In-Reply-To: <20171106091441.3E141FD068@eggemoggin.niobe.net> References: <20171106091441.3E141FD068@eggemoggin.niobe.net> Message-ID: <14583a20-7565-445a-def7-016fc0b0aabb@oracle.com> On 11/06/2017 10:14 AM, mark.reinhold at oracle.com wrote: > * * * > > Here's a proposed new list of criteria that incorporates these changes. > > A JEP should be drafted for a body of work when at least one of the > following is true: > > - It makes a significant or risky change to the JDK, > > - It has a broader impact on developers and users than can reasonably > be communicated in an ordinary enhancement or CSR issue, or > > - It is in high demand by developers or users. > > Comments? For me, as primarily a HotSpot developer, this would be fantastic. There are a lot of work that takes longer than two weeks in HotSpot but doesn't really "fit" the JEP process today. This is particularly true for performance enhancements and internal refactorings (as you already have noticed). So two thumbs up from me, great update to the process! Erik > - Mark > > > [1] http://openjdk.java.net/jeps/1#Overview > From chris.hegarty at oracle.com Mon Nov 6 13:23:46 2017 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 6 Nov 2017 13:23:46 +0000 Subject: New JDK development repositories In-Reply-To: <3874bd33-bc7a-4ce1-be1c-813dac0e6b55@default> References: <20171101152116.9B6BCEBE13@eggemoggin.niobe.net> <3874bd33-bc7a-4ce1-be1c-813dac0e6b55@default> Message-ID: <448EDFD0-5EC8-41B4-AEA0-0217781CE550@oracle.com> Hi, The JDK Sandbox Development repository has also been created. As usual it?s default branch will be keep updated ( automatically ) with the changesets from the Main line. http://hg.openjdk.java.net/jdk/sandbox/ -- Sandbox development The JDK 10 Sandbox [1] has been made read-only. Branch owners should move their respective accumulated changes to the new sandbox. Depending on the scope and area of work, collapsing the changes into a single patch / webrev [2], and shuffling that patch [3], is one way to achieve this. This is what was done already for the http-client-branch. -Chris. [1] http://hg.openjdk.java.net/jdk10/sandbox [2] http://cr.openjdk.java.net/~chegar/docs/sandbox.html#webrev [3] http://hg.openjdk.java.net/jdk/jdk/file/tip/bin/unshuffle_patch.sh > On 5 Nov 2017, at 05:09, Iris Clark wrote: > > Hi. > > The new Project JDK forests and associated mailing lists have been created > as described below. > > Enjoy, > iris > > -----Original Message----- > From: jdk-dev [mailto:jdk-dev-bounces at openjdk.java.net] On Behalf Of mark.reinhold at oracle.com > Sent: Wednesday, November 1, 2017 8:21 AM > To: jdk-dev at openjdk.java.net > Subject: New JDK development repositories > > Thus far we've continued main-line development in the existing JDK 10 > repositories. This weekend, early on Sunday, 5 November UTC, we'll cut > over to the new JDK Project repositories, which will be here: > > http://hg.openjdk.java.net/jdk/jdk -- Main line > http://hg.openjdk.java.net/jdk/client -- Client development > http://hg.openjdk.java.net/jdk/hs -- HotSpot development > > These repositories will be initialized from the JDK 10 master, client, > and hs repositories, respectively. (We're moving back to "jdk" as the > name of the main-line repository; "master" was a temporary name, needed > to establish the consolidated JDK 10 repository as distinct from the > previous main-line forest.) > > The old repositories under http://hg.openjdk.java.net/jdk10 will be made > read-only at 02:30 UTC on Sunday [1]; the new repositories should be > available a few hours later. After that, you can change the default > pull and push paths of an existing clone of a JDK 10 repository via the > Mercurial defpath extension [2], passing it one of the above URLs. > > If you subscribed to one or more of the jdk10-*-changes list(s) for > Mercurial notifications then you'll automatically be subscribed to the > corresponding jdk-*-changes list(s). > > The jdk10/client and jdk10/hs repositories will eventually be deleted; > the jdk10/master repository will be retained, or else we'll set up an > HTTP redirect, so that old URLs continue to work. > > - Mark > > > [1] https://www.timeanddate.com/worldclock/fixedtime.html?msg=JDK+Repository+Cutover&iso=20171105T0230 > [2] http://openjdk.java.net/projects/code-tools/defpath/ From doko at ubuntu.com Mon Nov 6 13:34:31 2017 From: doko at ubuntu.com (Matthias Klose) Date: Mon, 6 Nov 2017 14:34:31 +0100 Subject: Proposal: Newer version-string scheme for the Java SE Platform and the JDK In-Reply-To: <20171102151148.49900EBFB8@eggemoggin.niobe.net> References: <20171102151148.49900EBFB8@eggemoggin.niobe.net> Message-ID: On 02.11.2017 16:11, mark.reinhold at oracle.com wrote: > Here's a specific proposal, with commentary, and two questions. > > Summary: This is a time-based scheme, similar to alternative (C) in my > earlier note [1][2] but even closer to the current scheme as defined in > JEP 223 [3]. It's hence even less likely to surprise, and should be > easier to adopt. As mentioned in a different thread, it is currently not possible to include the build id/number of a downstream build into the version information. I understand that it should be possible to parse the upstream version, however not having the possibility to include the downstream build version in some version information makes it difficult to identify specific downstream builds. Please could you add the ability to include a version comment which is *literally* included in or appended to the version information? E.g. configuring GCC with --with-pkgversion='Ubuntu 7.2.0-8ubuntu3' results in $ gcc --version gcc (Ubuntu 7.2.0-8ubuntu3) 7.2.0 So you have the upstream version, and the id/distro version in the version string. Thanks, Matthias From vladimir.kozlov at oracle.com Mon Nov 6 21:32:25 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 6 Nov 2017 13:32:25 -0800 Subject: Result: New JDK Reviewer: Dean Long Message-ID: <8846db54-9f67-17ac-6ad6-fb799b6c2f03@oracle.com> Voting for Dean Long [1] is now closed. Yes: 28 Veto: 0 Abstain: 0 According to the Bylaws definition of Three-Vote Consensus, this is sufficient to approve the nomination. Vladimir Kozlov [1] http://mail.openjdk.java.net/pipermail/jdk-dev/2017-October/000036.html From ropalka at redhat.com Tue Nov 7 10:32:20 2017 From: ropalka at redhat.com (Richard Opalka) Date: Tue, 7 Nov 2017 11:32:20 +0100 Subject: What kinds of changes need a JEP? In-Reply-To: <20171106091441.3E141FD068@eggemoggin.niobe.net> References: <20171106091441.3E141FD068@eggemoggin.niobe.net> Message-ID: Hi Mark, proposed criteria list is much more better, definitely. Assuming JEP and JSR processes will continue to go hand in hand, Java release cadence shrinks to 6 month plus JavaEE is in the process of moving to Eclipse foundation one would expect there will also be some changes or improvements to how JSR process will continue function? Richard On Mon, Nov 6, 2017 at 10:14 AM, wrote: > Here's a proposed new list of criteria that incorporates these changes. > > A JEP should be drafted for a body of work when at least one of the > following is true: > > - It makes a significant or risky change to the JDK, > > - It has a broader impact on developers and users than can reasonably > be communicated in an ordinary enhancement or CSR issue, or > > - It is in high demand by developers or users. > > Comments? > > - Mark > > > [1] http://openjdk.java.net/jeps/1#Overview > From dalibor.topic at oracle.com Tue Nov 7 10:49:16 2017 From: dalibor.topic at oracle.com (dalibor topic) Date: Tue, 7 Nov 2017 11:49:16 +0100 Subject: What kinds of changes need a JEP? In-Reply-To: References: <20171106091441.3E141FD068@eggemoggin.niobe.net> Message-ID: <9b569a41-c5a1-4a6d-72e3-847338c812ec@oracle.com> On 07.11.2017 11:32, Richard Opalka wrote: > one would expect there will also be some changes or > improvements to how JSR process will continue function? See https://jcp.org/aboutJava/communityprocess/maintenance/jsr364/index2.html cheers, dalibor topic -- Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile: +491737185961 ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher Oracle is committed to developing practices and products that help protect the environment From maurizio.cimadamore at oracle.com Tue Nov 7 12:38:02 2017 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Tue, 7 Nov 2017 12:38:02 +0000 Subject: What kinds of changes need a JEP? In-Reply-To: <20171106091441.3E141FD068@eggemoggin.niobe.net> References: <20171106091441.3E141FD068@eggemoggin.niobe.net> Message-ID: <699ce6e7-bc8f-de17-64ea-f708e2f2c054@oracle.com> Many thumbs up on this Mark! Thanks for taking the time to put together this revised proposal. As a langtools hacker, I've often felt the pain associated with JEP processes for what, in my mental model, was non-JEP work - an example of such non-JEPs I came across over the last few years in langtools-land are, IMHO: http://openjdk.java.net/jeps/215 http://openjdk.java.net/jeps/217 I believe this work would classify now as regular javac enhancements and would, therefore not be subject to the JEP process, which IMHO is good news (not because I hate the JEP process, but because I hate abusing it :-)). Maurizio On 06/11/17 09:14, mark.reinhold at oracle.com wrote: > I'm working on an overall update of the JEP process documents, which have > been in a draft state for too long now. > > One issue we can discuss independently is that of the criteria for what > kinds of changes need a JEP. The primary process document, JEP 1, > currently states [1]: > >> An _enhancement_ is an effort to design and implement a nontrivial >> change to the JDK code base or to do some other kind of work whose >> goals, progress, and result are worth communicating broadly. A JDK >> Enhancement Proposal (hereinafter "JEP") should be drafted for any >> work that meets at least one of the following criteria: >> >> - It requires two or more weeks of engineering effort, >> >> - It makes a significant change to the JDK, or to the processes >> and infrastructure by which it is developed, or >> >> - It is in high demand by developers or customers. > Based on the experience of using the JEP process in one form or another > for both JDK 8 and JDK 9, and looking ahead to the six-month release > cadence, there are at least three ways in which these criteria could be > improved. > > (1) Do not mandate a JEP for a change just because that change > requires two or more weeks of engineering effort. > > Several committers and reviewers have observed that the first of the > above criteria, "requires two or more weeks of engineering effort," is > at odds with the preceding definition of "enhancement," namely a change > that's "worth communicating broadly," especially when that means running > it through the JEP process for candidate review, target proposal, and so > forth. > > Some changes can take more than two weeks of effort but aren't worth the > effort to communicate broadly via the JEP process, particularly if they > mainly concern developers of the JDK itself and have minimal impact on > those who use and deploy the JDK. Examples include, but are not limited > to, straightforward performance enhancements, refactorings of internal > implementation code, improvements to tests, and merges of upstream code > that have little or no effect on exported APIs. Such changes can be > communicated adequately via ordinary enhancement issues in JBS, in CSR > issues when exported APIs or other public interfaces are affected, and > in the public reviews of such changes that we already do. > > We could reduce the overhead of these sorts of changes by dropping the > first criterion, so that we no longer mandate a JEP for a change that > merely "requires two or more weeks of engineering effort," and adding > a criterion to require a JEP for a change that can't be communicated > adequately via normal JBS enhancement or CSR issues. > > (2) Do not use the JEP process to track changes in development > processes or infrastructure. > > In practice we just haven't used the JEP process for these purposes. The > processes by which we stabilized JDK 8 and JDK 9, e.g., were proposed and > discussed on development mailing lists and documented on project-specific > web pages. The same is true of the CSR process. We seem to have gotten > along fine without using the JEP process as a meta-process for all other > processes, so let's drop this part of the second criterion. > > Insofar as we've had "infrastructure" JEPs, they've been for enhancements > to the infrastructure of the JDK's build system rather than to software > or systems outside of the JDK, which was the original intent. Such JEPs > could as easily be characterized as "feature" JEPs, so we can drop the > "infrastructure" part of the second criterion also. > > (3) Do mandate JEPs for risky changes. > > A strict, six-month release cadence leaves few opportunities to repair or > back out bad changes. A change that carries significant risk is worth > communicating broadly, and can benefit from the additional scrutiny that > it will receive when it's proposed to target a specific release. > > * * * > > Here's a proposed new list of criteria that incorporates these changes. > > A JEP should be drafted for a body of work when at least one of the > following is true: > > - It makes a significant or risky change to the JDK, > > - It has a broader impact on developers and users than can reasonably > be communicated in an ordinary enhancement or CSR issue, or > > - It is in high demand by developers or users. > > Comments? > > - Mark > > > [1] http://openjdk.java.net/jeps/1#Overview From brian.goetz at oracle.com Tue Nov 7 16:46:14 2017 From: brian.goetz at oracle.com (Brian Goetz) Date: Tue, 7 Nov 2017 17:46:14 +0100 Subject: What kinds of changes need a JEP? In-Reply-To: <20171106091441.3E141FD068@eggemoggin.niobe.net> References: <20171106091441.3E141FD068@eggemoggin.niobe.net> Message-ID: <3708CA1D-374F-477C-B6F5-99BE4B54A6CD@oracle.com> At the risk of being redundant, I?ll add that a JEP should be required for: - Any language feature; - Any change to the class file format. While one could argue that these are subsumed by the other criteria, it is best to be explicit. > On Nov 6, 2017, at 10:14 AM, mark.reinhold at oracle.com wrote: > > I'm working on an overall update of the JEP process documents, which have > been in a draft state for too long now. > > One issue we can discuss independently is that of the criteria for what > kinds of changes need a JEP. The primary process document, JEP 1, > currently states [1]: > >> An _enhancement_ is an effort to design and implement a nontrivial >> change to the JDK code base or to do some other kind of work whose >> goals, progress, and result are worth communicating broadly. A JDK >> Enhancement Proposal (hereinafter "JEP") should be drafted for any >> work that meets at least one of the following criteria: >> >> - It requires two or more weeks of engineering effort, >> >> - It makes a significant change to the JDK, or to the processes >> and infrastructure by which it is developed, or >> >> - It is in high demand by developers or customers. > > Based on the experience of using the JEP process in one form or another > for both JDK 8 and JDK 9, and looking ahead to the six-month release > cadence, there are at least three ways in which these criteria could be > improved. > > (1) Do not mandate a JEP for a change just because that change > requires two or more weeks of engineering effort. > > Several committers and reviewers have observed that the first of the > above criteria, "requires two or more weeks of engineering effort," is > at odds with the preceding definition of "enhancement," namely a change > that's "worth communicating broadly," especially when that means running > it through the JEP process for candidate review, target proposal, and so > forth. > > Some changes can take more than two weeks of effort but aren't worth the > effort to communicate broadly via the JEP process, particularly if they > mainly concern developers of the JDK itself and have minimal impact on > those who use and deploy the JDK. Examples include, but are not limited > to, straightforward performance enhancements, refactorings of internal > implementation code, improvements to tests, and merges of upstream code > that have little or no effect on exported APIs. Such changes can be > communicated adequately via ordinary enhancement issues in JBS, in CSR > issues when exported APIs or other public interfaces are affected, and > in the public reviews of such changes that we already do. > > We could reduce the overhead of these sorts of changes by dropping the > first criterion, so that we no longer mandate a JEP for a change that > merely "requires two or more weeks of engineering effort," and adding > a criterion to require a JEP for a change that can't be communicated > adequately via normal JBS enhancement or CSR issues. > > (2) Do not use the JEP process to track changes in development > processes or infrastructure. > > In practice we just haven't used the JEP process for these purposes. The > processes by which we stabilized JDK 8 and JDK 9, e.g., were proposed and > discussed on development mailing lists and documented on project-specific > web pages. The same is true of the CSR process. We seem to have gotten > along fine without using the JEP process as a meta-process for all other > processes, so let's drop this part of the second criterion. > > Insofar as we've had "infrastructure" JEPs, they've been for enhancements > to the infrastructure of the JDK's build system rather than to software > or systems outside of the JDK, which was the original intent. Such JEPs > could as easily be characterized as "feature" JEPs, so we can drop the > "infrastructure" part of the second criterion also. > > (3) Do mandate JEPs for risky changes. > > A strict, six-month release cadence leaves few opportunities to repair or > back out bad changes. A change that carries significant risk is worth > communicating broadly, and can benefit from the additional scrutiny that > it will receive when it's proposed to target a specific release. > > * * * > > Here's a proposed new list of criteria that incorporates these changes. > > A JEP should be drafted for a body of work when at least one of the > following is true: > > - It makes a significant or risky change to the JDK, > > - It has a broader impact on developers and users than can reasonably > be communicated in an ordinary enhancement or CSR issue, or > > - It is in high demand by developers or users. > > Comments? > > - Mark > > > [1] http://openjdk.java.net/jeps/1#Overview From brian.goetz at oracle.com Tue Nov 7 16:58:25 2017 From: brian.goetz at oracle.com (Brian Goetz) Date: Tue, 7 Nov 2017 17:58:25 +0100 Subject: JEPs proposed to target JDK 10 (2017/11/2) In-Reply-To: References: <20171102153759.744852081@eggemoggin.niobe.net> Message-ID: <1D08A688-BD7C-497A-A806-95B352AB6B4A@oracle.com> If that?s your conclusion, I think you have a serious misunderstanding of how the JEP process works. Yes ,there are a sequence of milestones, but you?ll notice none of them are ?design complete?, ?spec complete?, ?implementation complete?, ?testing complete? as a waterfall process would mandate. In fact, all of the JEP milestones are either related to inception as a project (is this something we want to consider having in the JDK), or tracking steps that all happen *after all the work is done*. For nontrivial projects, you are expected to work iteratively, progressively refining the design, interface, implementation, and test suite together, outside of the main code line, until it is ready, and then ? and only then ? do you start the process of proposing to target. That?s not waterfall; that?s ?get it right before you think about committing any of it.? While it would surely be possible to cheat and pretend that a project is merely N sub features each small enough to be called a bug/rfe, that would definitely be working outside the spirit of how we work. Surely that?s not what you were suggesting? > On Nov 6, 2017, at 11:35 AM, Roman Kennke wrote: > > The biggest issue is that the JEP is a sort of waterfall process From moorek at gmail.com Tue Nov 7 18:37:52 2017 From: moorek at gmail.com (Kyle Moore) Date: Tue, 7 Nov 2017 10:37:52 -0800 Subject: LTS for public releases Message-ID: Hi everyone. I was following the thread "Impact of six month releases" and was left scratching my head after something pointed out by Kim Jensen's post. Specifically, the Java SE Support Roadmap page: http://www.oracle.com/technetwork/java/eol-135779.html The releases under "Java SE Public Updates" don't explicitly mention any LTS releases, though these are clearly called out in the support roadmap on the second table. Call me crazy, but is the implication here that releases of Java SE will not be publicly supported longer than six months? In the open-source community, I struggle with the issues mentioned earlier about backwards compatibility. If I read and understood the roadmap correctly, the potential for churn and compatibility issues created by the lack of a public LTS release is deeply concerning. -- Kyle Moore http://gosu-lang.org/ http://manifold.systems/ From jiangli.zhou at Oracle.COM Tue Nov 7 20:41:45 2017 From: jiangli.zhou at Oracle.COM (Jiangli Zhou) Date: Tue, 7 Nov 2017 12:41:45 -0800 Subject: CFV: New JDK Reviewer: Calvin Cheung Message-ID: <39A85362-8842-4A45-B756-70934274F251@oracle.com> I hereby nominate Calvin Cheung (ccheung) to be a JDK Reviewer. Calvin Cheung is currently a member of Hotspot Runtime group. Before that he worked on java plugin and java webstart. As part of the Hotspot runtime team, Calvin has contributed total 57 changes in various runtime areas. In recent two years, he has primarily worked on hotspot CDS/AppCDS. His latest CDS/AppCDS contribution is changing the archive dumping process to use the Java builtin class loader instances (the system loader and the PlatformClassLoader) to load related classes. Votes are due by 21 November 2017, 1:00 pm PT. Only current JDK Reviewers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Three-Vote Consensus voting instructions, see [2]. Regards, Jiangli Zhou [1] http://openjdk.java.net/census [2] http://openjdk.java.net/projects/#reviewer-vote [3] http://hg.openjdk.java.net/jdk/hs/log?revcount=100&rev=%28keyword%28%22calvin.cheung%40oracle.com%22%29+or+author%28ccheung%29%29 From vladimir.x.ivanov at oracle.com Tue Nov 7 20:43:47 2017 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Tue, 7 Nov 2017 23:43:47 +0300 Subject: CFV: New JDK Reviewer: Calvin Cheung In-Reply-To: <39A85362-8842-4A45-B756-70934274F251@oracle.com> References: <39A85362-8842-4A45-B756-70934274F251@oracle.com> Message-ID: Vote: yes Best regards, Vladimir Ivanov On 11/7/17 11:41 PM, Jiangli Zhou wrote: > I hereby nominate Calvin Cheung (ccheung) to be a JDK Reviewer. From harold.seigel at oracle.com Tue Nov 7 20:43:47 2017 From: harold.seigel at oracle.com (harold seigel) Date: Tue, 7 Nov 2017 15:43:47 -0500 Subject: CFV: New JDK Reviewer: Calvin Cheung In-Reply-To: <39A85362-8842-4A45-B756-70934274F251@oracle.com> References: <39A85362-8842-4A45-B756-70934274F251@oracle.com> Message-ID: <38bc845a-7102-df76-9738-3f064eaca854@oracle.com> Vote: yes Harold On 11/7/2017 3:41 PM, Jiangli Zhou wrote: > I hereby nominate Calvin Cheung (ccheung) to be a JDK Reviewer. > > Calvin Cheung is currently a member of Hotspot Runtime group. Before that he worked on java plugin and java webstart. As part of the Hotspot runtime team, Calvin has contributed total 57 changes in various runtime areas. In recent two years, he has primarily worked on hotspot CDS/AppCDS. His latest CDS/AppCDS contribution is changing the archive dumping process to use the Java builtin class loader instances (the system loader and the PlatformClassLoader) to load related classes. > > Votes are due by 21 November 2017, 1:00 pm PT. > > Only current JDK Reviewers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Three-Vote Consensus voting instructions, see [2]. > > Regards, > Jiangli Zhou > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#reviewer-vote > [3] http://hg.openjdk.java.net/jdk/hs/log?revcount=100&rev=%28keyword%28%22calvin.cheung%40oracle.com%22%29+or+author%28ccheung%29%29 > > > > > > From jiangli.zhou at oracle.com Tue Nov 7 20:45:50 2017 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Tue, 7 Nov 2017 12:45:50 -0800 Subject: CFV: New JDK Reviewer: Calvin Cheung In-Reply-To: <39A85362-8842-4A45-B756-70934274F251@oracle.com> References: <39A85362-8842-4A45-B756-70934274F251@oracle.com> Message-ID: <4E7B1BB8-C1AF-4005-9A89-04A1B03B6940@oracle.com> Vote: yes Jiangli > On Nov 7, 2017, at 12:41 PM, Jiangli Zhou wrote: > > I hereby nominate Calvin Cheung (ccheung) to be a JDK Reviewer. > > Calvin Cheung is currently a member of Hotspot Runtime group. Before that he worked on java plugin and java webstart. As part of the Hotspot runtime team, Calvin has contributed total 57 changes in various runtime areas. In recent two years, he has primarily worked on hotspot CDS/AppCDS. His latest CDS/AppCDS contribution is changing the archive dumping process to use the Java builtin class loader instances (the system loader and the PlatformClassLoader) to load related classes. > > Votes are due by 21 November 2017, 1:00 pm PT. > > Only current JDK Reviewers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Three-Vote Consensus voting instructions, see [2]. > > Regards, > Jiangli Zhou > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#reviewer-vote > [3] http://hg.openjdk.java.net/jdk/hs/log?revcount=100&rev=%28keyword%28%22calvin.cheung%40oracle.com%22%29+or+author%28ccheung%29%29 > > > > > > From andy.herrick at oracle.com Tue Nov 7 20:45:44 2017 From: andy.herrick at oracle.com (Andy Herrick) Date: Tue, 7 Nov 2017 15:45:44 -0500 Subject: CFV: New JDK Reviewer: Calvin Cheung In-Reply-To: <39A85362-8842-4A45-B756-70934274F251@oracle.com> References: <39A85362-8842-4A45-B756-70934274F251@oracle.com> Message-ID: <9ca4a25b-3f07-af45-6e31-a0bf0740fabe@oracle.com> vote: yes Andy On 11/7/2017 3:41 PM, Jiangli Zhou wrote: > I hereby nominate Calvin Cheung (ccheung) to be a JDK Reviewer. > > Calvin Cheung is currently a member of Hotspot Runtime group. Before that he worked on java plugin and java webstart. As part of the Hotspot runtime team, Calvin has contributed total 57 changes in various runtime areas. In recent two years, he has primarily worked on hotspot CDS/AppCDS. His latest CDS/AppCDS contribution is changing the archive dumping process to use the Java builtin class loader instances (the system loader and the PlatformClassLoader) to load related classes. > > Votes are due by 21 November 2017, 1:00 pm PT. > > Only current JDK Reviewers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Three-Vote Consensus voting instructions, see [2]. > > Regards, > Jiangli Zhou > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#reviewer-vote > [3] http://hg.openjdk.java.net/jdk/hs/log?revcount=100&rev=%28keyword%28%22calvin.cheung%40oracle.com%22%29+or+author%28ccheung%29%29 > > > > > > From zgu at redhat.com Tue Nov 7 20:47:50 2017 From: zgu at redhat.com (Zhengyu Gu) Date: Tue, 7 Nov 2017 15:47:50 -0500 Subject: CFV: New JDK Reviewer: Calvin Cheung In-Reply-To: <39A85362-8842-4A45-B756-70934274F251@oracle.com> References: <39A85362-8842-4A45-B756-70934274F251@oracle.com> Message-ID: Vote: yes -Zhengyu On 11/07/2017 03:41 PM, Jiangli Zhou wrote: > I hereby nominate Calvin Cheung (ccheung) to be a JDK Reviewer. > > Calvin Cheung is currently a member of Hotspot Runtime group. Before that he worked on java plugin and java webstart. As part of the Hotspot runtime team, Calvin has contributed total 57 changes in various runtime areas. In recent two years, he has primarily worked on hotspot CDS/AppCDS. His latest CDS/AppCDS contribution is changing the archive dumping process to use the Java builtin class loader instances (the system loader and the PlatformClassLoader) to load related classes. > > Votes are due by 21 November 2017, 1:00 pm PT. > > Only current JDK Reviewers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Three-Vote Consensus voting instructions, see [2]. > > Regards, > Jiangli Zhou > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#reviewer-vote > [3] http://hg.openjdk.java.net/jdk/hs/log?revcount=100&rev=%28keyword%28%22calvin.cheung%40oracle.com%22%29+or+author%28ccheung%29%29 > > > > > > From kumar.x.srinivasan at oracle.com Tue Nov 7 20:54:35 2017 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Tue, 07 Nov 2017 12:54:35 -0800 Subject: CFV: New JDK Reviewer: Calvin Cheung In-Reply-To: <39A85362-8842-4A45-B756-70934274F251@oracle.com> References: <39A85362-8842-4A45-B756-70934274F251@oracle.com> Message-ID: <5A021D8B.8080208@oracle.com> Vote: yes On 11/7/2017 12:41 PM, Jiangli Zhou wrote: > I hereby nominate Calvin Cheung (ccheung) to be a JDK Reviewer. > > Calvin Cheung is currently a member of Hotspot Runtime group. Before that he worked on java plugin and java webstart. As part of the Hotspot runtime team, Calvin has contributed total 57 changes in various runtime areas. In recent two years, he has primarily worked on hotspot CDS/AppCDS. His latest CDS/AppCDS contribution is changing the archive dumping process to use the Java builtin class loader instances (the system loader and the PlatformClassLoader) to load related classes. > > Votes are due by 21 November 2017, 1:00 pm PT. > > Only current JDK Reviewers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Three-Vote Consensus voting instructions, see [2]. > > Regards, > Jiangli Zhou > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#reviewer-vote > [3] http://hg.openjdk.java.net/jdk/hs/log?revcount=100&rev=%28keyword%28%22calvin.cheung%40oracle.com%22%29+or+author%28ccheung%29%29 > > > > > > From jesper.wilhelmsson at oracle.com Tue Nov 7 21:00:00 2017 From: jesper.wilhelmsson at oracle.com (jesper.wilhelmsson at oracle.com) Date: Tue, 7 Nov 2017 22:00:00 +0100 Subject: CFV: New JDK Reviewer: Calvin Cheung In-Reply-To: <39A85362-8842-4A45-B756-70934274F251@oracle.com> References: <39A85362-8842-4A45-B756-70934274F251@oracle.com> Message-ID: <5CEBC7C8-B023-4347-8479-81C6AB419E5A@oracle.com> Vote: Yes /Jesper > On 7 Nov 2017, at 21:41, Jiangli Zhou wrote: > > I hereby nominate Calvin Cheung (ccheung) to be a JDK Reviewer. > > Calvin Cheung is currently a member of Hotspot Runtime group. Before that he worked on java plugin and java webstart. As part of the Hotspot runtime team, Calvin has contributed total 57 changes in various runtime areas. In recent two years, he has primarily worked on hotspot CDS/AppCDS. His latest CDS/AppCDS contribution is changing the archive dumping process to use the Java builtin class loader instances (the system loader and the PlatformClassLoader) to load related classes. > > Votes are due by 21 November 2017, 1:00 pm PT. > > Only current JDK Reviewers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Three-Vote Consensus voting instructions, see [2]. > > Regards, > Jiangli Zhou > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#reviewer-vote > [3] http://hg.openjdk.java.net/jdk/hs/log?revcount=100&rev=%28keyword%28%22calvin.cheung%40oracle.com%22%29+or+author%28ccheung%29%29 > > > > > > From vladimir.kozlov at oracle.com Tue Nov 7 21:04:08 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 7 Nov 2017 13:04:08 -0800 Subject: CFV: New JDK Reviewer: Calvin Cheung In-Reply-To: <39A85362-8842-4A45-B756-70934274F251@oracle.com> References: <39A85362-8842-4A45-B756-70934274F251@oracle.com> Message-ID: <1278183a-8a4c-a771-756b-e364609be96a@oracle.com> Vote: yes On 11/7/17 12:41 PM, Jiangli Zhou wrote: > I hereby nominate Calvin Cheung (ccheung) to be a JDK Reviewer. > > Calvin Cheung is currently a member of Hotspot Runtime group. Before that he worked on java plugin and java webstart. As part of the Hotspot runtime team, Calvin has contributed total 57 changes in various runtime areas. In recent two years, he has primarily worked on hotspot CDS/AppCDS. His latest CDS/AppCDS contribution is changing the archive dumping process to use the Java builtin class loader instances (the system loader and the PlatformClassLoader) to load related classes. > > Votes are due by 21 November 2017, 1:00 pm PT. > > Only current JDK Reviewers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Three-Vote Consensus voting instructions, see [2]. > > Regards, > Jiangli Zhou > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#reviewer-vote > [3] http://hg.openjdk.java.net/jdk/hs/log?revcount=100&rev=%28keyword%28%22calvin.cheung%40oracle.com%22%29+or+author%28ccheung%29%29 > > > > > > From daniel.daugherty at oracle.com Tue Nov 7 22:12:05 2017 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 7 Nov 2017 17:12:05 -0500 Subject: CFV: New JDK Reviewer: Calvin Cheung In-Reply-To: <39A85362-8842-4A45-B756-70934274F251@oracle.com> References: <39A85362-8842-4A45-B756-70934274F251@oracle.com> Message-ID: Vote: yes Dan On 11/7/17 3:41 PM, Jiangli Zhou wrote: > I hereby nominate Calvin Cheung (ccheung) to be a JDK Reviewer. > > Calvin Cheung is currently a member of Hotspot Runtime group. Before that he worked on java plugin and java webstart. As part of the Hotspot runtime team, Calvin has contributed total 57 changes in various runtime areas. In recent two years, he has primarily worked on hotspot CDS/AppCDS. His latest CDS/AppCDS contribution is changing the archive dumping process to use the Java builtin class loader instances (the system loader and the PlatformClassLoader) to load related classes. > > Votes are due by 21 November 2017, 1:00 pm PT. > > Only current JDK Reviewers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Three-Vote Consensus voting instructions, see [2]. > > Regards, > Jiangli Zhou > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#reviewer-vote > [3] http://hg.openjdk.java.net/jdk/hs/log?revcount=100&rev=%28keyword%28%22calvin.cheung%40oracle.com%22%29+or+author%28ccheung%29%29 > > > > > > > From serguei.spitsyn at oracle.com Tue Nov 7 23:23:37 2017 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 7 Nov 2017 15:23:37 -0800 Subject: CFV: New JDK Reviewer: Calvin Cheung In-Reply-To: <39A85362-8842-4A45-B756-70934274F251@oracle.com> References: <39A85362-8842-4A45-B756-70934274F251@oracle.com> Message-ID: <6b517f0e-d232-c404-f803-77a5b11770fc@oracle.com> Vote: yes From philip.race at oracle.com Tue Nov 7 23:32:19 2017 From: philip.race at oracle.com (Philip Race) Date: Tue, 07 Nov 2017 15:32:19 -0800 Subject: CFV: New JDK Reviewer: Calvin Cheung In-Reply-To: <39A85362-8842-4A45-B756-70934274F251@oracle.com> References: <39A85362-8842-4A45-B756-70934274F251@oracle.com> Message-ID: <5A024283.3000805@oracle.com> Vote: yes -phil. From coleen.phillimore at oracle.com Tue Nov 7 23:41:34 2017 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Tue, 7 Nov 2017 18:41:34 -0500 Subject: CFV: New JDK Reviewer: Calvin Cheung In-Reply-To: <39A85362-8842-4A45-B756-70934274F251@oracle.com> References: <39A85362-8842-4A45-B756-70934274F251@oracle.com> Message-ID: <40c0b45b-d794-c3fc-2c5a-b5bfd3e173cc@oracle.com> Vote: yes On 11/7/17 3:41 PM, Jiangli Zhou wrote: > I hereby nominate Calvin Cheung (ccheung) to be a JDK Reviewer. > > Calvin Cheung is currently a member of Hotspot Runtime group. Before that he worked on java plugin and java webstart. As part of the Hotspot runtime team, Calvin has contributed total 57 changes in various runtime areas. In recent two years, he has primarily worked on hotspot CDS/AppCDS. His latest CDS/AppCDS contribution is changing the archive dumping process to use the Java builtin class loader instances (the system loader and the PlatformClassLoader) to load related classes. > > Votes are due by 21 November 2017, 1:00 pm PT. > > Only current JDK Reviewers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Three-Vote Consensus voting instructions, see [2]. > > Regards, > Jiangli Zhou > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#reviewer-vote > [3] http://hg.openjdk.java.net/jdk/hs/log?revcount=100&rev=%28keyword%28%22calvin.cheung%40oracle.com%22%29+or+author%28ccheung%29%29 > > > > > > From gnu.andrew at redhat.com Wed Nov 8 16:31:00 2017 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 8 Nov 2017 16:31:00 +0000 Subject: LTS for public releases In-Reply-To: References: Message-ID: On 7 November 2017 at 18:37, Kyle Moore wrote: > Hi everyone. > > I was following the thread "Impact of six month releases" and was left > scratching my head after something pointed out by Kim Jensen's post. > Specifically, the Java SE Support Roadmap page: > http://www.oracle.com/technetwork/java/eol-135779.html > > The releases under "Java SE Public Updates" don't explicitly mention > any LTS releases, though these are clearly called out in the support > roadmap on the second table. > > Call me crazy, but is the implication here that releases of Java SE > will not be publicly supported longer than six months? In the > open-source community, I struggle with the issues mentioned earlier > about backwards compatibility. > > If I read and understood the roadmap correctly, the potential for > churn and compatibility issues created by the lack of a public LTS > release is deeply concerning. > > -- > Kyle Moore > http://gosu-lang.org/ > http://manifold.systems/ Well, that page is about Oracle's binaries, not OpenJDK in general. It's important not to confuse the two. It may well be that Oracle don't provide public binaries of LTS releases, but there's nothing stopping anyone else from doing so and I would expect that to continue as it does now in various distributions. The Oracle move seems to be explained by this comment: "instead of relying on a pre-installed standalone JRE, we will begin encouraging application developers to deliver JREs with their applications" As Oracle move from adding their own magic sauce to create their proprietary binaries to basically just building OpenJDK ("the ultimate goal is to make OpenJDK and Oracle JDK builds completely interchangeable" [0]), the need for them to do so at all diminishes as others can equally fulfil the role ("This will make it easier to publish early-access builds for features in development, and eventually make it possible for the OpenJDK Community itself to publish authoritative builds of the JDK") [0] http://mail.openjdk.java.net/pipermail/discuss/2017-September/004281.html -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Web Site: http://fuseyism.com Twitter: https://twitter.com/gnu_andrew_java PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From volker.simonis at gmail.com Wed Nov 8 17:07:18 2017 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 8 Nov 2017 18:07:18 +0100 Subject: JEPs proposed to target JDK 10 (2017/11/2) In-Reply-To: <1D08A688-BD7C-497A-A806-95B352AB6B4A@oracle.com> References: <20171102153759.744852081@eggemoggin.niobe.net> <1D08A688-BD7C-497A-A806-95B352AB6B4A@oracle.com> Message-ID: Hi Roman, Brian, @Roman: I just want to re-iterate that my post was in no way intended as a criticism of your work. I think you did everything right (at least as good as if can be done in the current project setup :) @Brian: You wrote: "For nontrivial projects, you are expected to work iteratively, progressively refining the design, interface, implementation, and test suite together, outside of the main code line, until it is ready, and then ? and only then ? do you start the process of proposing to target." That's actually exactly how I understand the process as well. However, looking at the reality, how many of the JEPs (except Jigsaw and some ports) have been developed in their own repositories before they have been integrated into the main line? We have a serious process/infrastructure problem because creating a new clone is a much to heavyweight operation and branches are not yet a generally accepted "working model" in the OpenJDK. Let alone the fact of testing such a clone/branch (i.e. JPRT/Mach5 for the insiders :) I'm also not sure if other tools like JBS work well with branches for example. Finally, it is currently much easier to attract the attention of a potential Oracle reviewer/sponsor when you subdivide your JEP into small sub features. I wouldn't call that cheating - it's just the only viable way to get your work done if you're an external contributor. So, to sum it up, I think we have a well defined and sound process but we really need the infrastructure and tools to execute it! Regards, Volker On Tue, Nov 7, 2017 at 5:58 PM, Brian Goetz wrote: > If that?s your conclusion, I think you have a serious misunderstanding of > how the JEP process works. Yes ,there are a sequence of milestones, but > you?ll notice none of them are ?design complete?, ?spec complete?, > ?implementation complete?, ?testing complete? as a waterfall process would > mandate. In fact, all of the JEP milestones are either related to inception > as a project (is this something we want to consider having in the JDK), or > tracking steps that all happen *after all the work is done*. For nontrivial > projects, you are expected to work iteratively, progressively refining the > design, interface, implementation, and test suite together, outside of the > main code line, until it is ready, and then ? and only then ? do you start > the process of proposing to target. That?s not waterfall; that?s ?get it > right before you think about committing any of it.? > > While it would surely be possible to cheat and pretend that a project is > merely N sub features each small enough to be called a bug/rfe, that would > definitely be working outside the spirit of how we work. Surely that?s not > what you were suggesting? > > > > On Nov 6, 2017, at 11:35 AM, Roman Kennke wrote: > > The biggest issue is that the JEP is a sort of waterfall process > > From scolebourne at joda.org Wed Nov 8 17:31:39 2017 From: scolebourne at joda.org (Stephen Colebourne) Date: Wed, 8 Nov 2017 17:31:39 +0000 Subject: LTS for public releases In-Reply-To: References: Message-ID: On 8 November 2017 at 16:31, Andrew Hughes wrote: > Well, that page is about Oracle's binaries, not OpenJDK in general. > It's important not to confuse the two. > > It may well be that Oracle don't provide public binaries of LTS releases, > but there's nothing stopping anyone else from doing so and I would > expect that to continue as it does now in various distributions. I don't think this game of "well someone else might support it" is at all helpful to the wider community. Architects/senior devs need to know that the code they are writing now can run on a supported platform for at least a few years after they finish coding it. This has been one of the critical factors in Java's success. What is actually being promised is ridiculously woolly by comparison. Oracle might provide 3 years of public updates on LTS for $free, or they might not. Red Hat might provide some LTS's or they might not. Red Hat LTS's might align with Oracle's LTS, or they might not. Some other random group of "OpenJDK community" might turn up and do something, or it might not. No certainty. No ability to plan. Its a mess. Stephen From volker.simonis at gmail.com Wed Nov 8 17:38:37 2017 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 8 Nov 2017 18:38:37 +0100 Subject: Impact of six month releases In-Reply-To: References: <52078f75-e29d-7ddf-934f-15fe1092c6aa@redhat.com> Message-ID: On Mon, Nov 6, 2017 at 9:32 AM, Kim Jensen wrote: > Hi Volker, > > Customers have so far been able to rely on Java, as a very innovative, > stable, scalable and reliable platform - there is a reason why it is so > widely adopted and used. > > However, with the release of Java 9 and the subsequent announcement of the > new Release Cycles [1], many people were baffled. Earlier, we had at least a > year to complete migration from one major version to the next. Sometimes the > migration is not trivial, my best example is that JBoss only managed to > ready for Java 8 one month before Java 7 the final Java 7 public update. > Leaving us with very little time to test & push out the upgrades, as these > all have to be coordinated with our customers internal patch & release > cycles. > > Right now, we're in the situation that nobody knows how to deal with. Java 8 > goes EOL in less than a year, Java 9 goes EOL in a few months. And the > replacement has not even been released. Migrating to Java 9 is far from > easy, we have so much code that doesn't work, and so many libraries which > also fails. Right now, we cannot make any plans for the future - and the > result will either be that the customers will run with outdated & insecure > Java Versions or they'll go to different platform like .Net. > > It may be that in the future, the new LTS versions will work like a charm, > but right now - with the new Release Cycle from Oracle - How can we upgrade > ? Java 9 goes EOL in a few months and Java 8 in less than a year. It makes > it impossible to plan, and this means that Java has moved from a rock solid > foundation to a liability. Well, that's not true. It is still rock solid. It just may be that for some use cases it moves from a free to a charged foundation :) > > /Kim > > [1] http://www.oracle.com/technetwork/java/eol-135779.html > Good judgment comes from experience; experience comes from bad judgment. > > > -------- Original Message -------- > Subject: Re: Impact of six month releases > Local Time: November 6, 2017 8:31 AM > UTC Time: November 6, 2017 7:31 AM > From: volker.simonis at gmail.com > To: Stephen Colebourne > jdk-dev at openjdk.java.net > > Hi Stephen, > > I fully agree with all the points you've raised. BUT the OpenJDK is not the > binary Java distribution most people use (similar to that fact that few > people use a vanilla Linux kernel). It wasn't even available until recently! > > The vast majority has always used the Oracle JDK or the JDK that comes with > their Linux distribution (not to mention all the other commercial and free > Java distributions which are available as well). All these binary > distributions are downstream versions of the vanilla OpenJDK project and > they can all freely choose their support time frame and downport policy. > Again, as an analogy, just think about how Linux distros support old Linux > kernels and enhance them with down ports from newer kernels independently > of the main kernel development. My personal opinion is that we will > eventually come to a similar model with Java. > > From my understanding the "new release cadence" step has always been at > least as much about reorganizing the Java support business as it was about > innovation. And it seems that others are now slowly realizing this as well > ;) > > Regards, > Volker > > > Stephen Colebourne scolebourne at joda.org schrieb am Fr. 3. Nov. 2017 um > 17:41: > > On 3 November 2017 at 09:14, Andrew Haley aph at redhat.com wrote: > > I think this is throwing the baby (Java's long standing backwards > compatibility) out with the bathwater (frequent releases), but I'm > happy to hear other opinions. > > I don't believe that such worries are necessarily justified. > We need to be able to roll back mistakes. The Java tradition that > nothing ever gets removed, no matter how much mistaken, holds back > innovation. It does this because of a justified fear that if we make > a mistake, we're stuck with it, so we have to be ultra-cautious. > > I think its more than that. Java's success is built on the broader > ecosystem. The JDK itself is an enabler for that. Open source projects > have to be able to produce jar files that work on multiple releases of > the JDK. Things that prevent that are a big issue. > In practical terms I'd argue that: > > LTS releases define the removal cycle. Code added in a non-LTS > release (n) can be deprecated in the next non-LTS release (n+1) and > removed in the release after that (n+2). This works because the code > was never in an LTS release. However, code that was in the last LTS > release cannot be removed until the release after the next LTS. > > eg. code present in 8 cannot be removed until 12 (as 11 is the first > LTS where the deprecation is visible) > eg. code added in 12 can be deprecated in 13 and removed in 14 as 12 > and 13 are non-LTS > > There should be more than 2 security updates for each release. > Without an overlap period, developers are forced to upgrade to the > next release immediately it is GA. This does not reflect real-world > software development practice. If the non-LTS releases are to be used > in production they will need a bare minimum of 4 security updates (one > year) to create a time window overlap with the next release. > The javac --release flag should work for at least the last three > LTS releases. A time-window of 10 years would also be about right. > (Its a really convenient feature, and if possible I'd prefer it to > never lose support for older versions). > > Stephen > > From adinn at redhat.com Wed Nov 8 17:44:03 2017 From: adinn at redhat.com (Andrew Dinn) Date: Wed, 8 Nov 2017 17:44:03 +0000 Subject: CFV: New JDK Reviewer: Calvin Cheung In-Reply-To: <39A85362-8842-4A45-B756-70934274F251@oracle.com> References: <39A85362-8842-4A45-B756-70934274F251@oracle.com> Message-ID: Vote: yes On 07/11/17 20:41, Jiangli Zhou wrote: > I hereby nominate Calvin Cheung (ccheung) to be a JDK Reviewer. > > Calvin Cheung is currently a member of Hotspot Runtime group. Before that he worked on java plugin and java webstart. As part of the Hotspot runtime team, Calvin has contributed total 57 changes in various runtime areas. In recent two years, he has primarily worked on hotspot CDS/AppCDS. His latest CDS/AppCDS contribution is changing the archive dumping process to use the Java builtin class loader instances (the system loader and the PlatformClassLoader) to load related classes. > > Votes are due by 21 November 2017, 1:00 pm PT. > > Only current JDK Reviewers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Three-Vote Consensus voting instructions, see [2]. > > Regards, > Jiangli Zhou > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#reviewer-vote > [3] http://hg.openjdk.java.net/jdk/hs/log?revcount=100&rev=%28keyword%28%22calvin.cheung%40oracle.com%22%29+or+author%28ccheung%29%29 > > > > > > > -- regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From sean.coffey at oracle.com Wed Nov 8 17:47:58 2017 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Wed, 8 Nov 2017 17:47:58 +0000 Subject: CFV: New JDK Reviewer: Calvin Cheung In-Reply-To: <39A85362-8842-4A45-B756-70934274F251@oracle.com> References: <39A85362-8842-4A45-B756-70934274F251@oracle.com> Message-ID: <38e29583-76ea-44a4-aa41-1c57ec2b770f@oracle.com> Vote: Yes Regards, Sean. On 07/11/17 20:41, Jiangli Zhou wrote: > I hereby nominate Calvin Cheung (ccheung) to be a JDK Reviewer. > > Calvin Cheung is currently a member of Hotspot Runtime group. Before that he worked on java plugin and java webstart. As part of the Hotspot runtime team, Calvin has contributed total 57 changes in various runtime areas. In recent two years, he has primarily worked on hotspot CDS/AppCDS. His latest CDS/AppCDS contribution is changing the archive dumping process to use the Java builtin class loader instances (the system loader and the PlatformClassLoader) to load related classes. > > Votes are due by 21 November 2017, 1:00 pm PT. > > Only current JDK Reviewers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Three-Vote Consensus voting instructions, see [2]. > > Regards, > Jiangli Zhou > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#reviewer-vote > [3] http://hg.openjdk.java.net/jdk/hs/log?revcount=100&rev=%28keyword%28%22calvin.cheung%40oracle.com%22%29+or+author%28ccheung%29%29 > > > > > > From volker.simonis at gmail.com Wed Nov 8 17:50:11 2017 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 8 Nov 2017 18:50:11 +0100 Subject: Impact of six month releases In-Reply-To: References: <52078f75-e29d-7ddf-934f-15fe1092c6aa@redhat.com> Message-ID: On Mon, Nov 6, 2017 at 8:31 AM, Volker Simonis wrote: > Hi Stephen, > > I fully agree with all the points you've raised. BUT the OpenJDK is not the > binary Java distribution most people use (similar to that fact that few > people use a vanilla Linux kernel). It wasn't even available until recently! > > The vast majority has always used the Oracle JDK or the JDK that comes with > their Linux distribution (not to mention all the other commercial and free > Java distributions which are available as well). All these binary > distributions are downstream versions of the vanilla OpenJDK project and > they can all freely choose their support time frame and downport policy. > Again, as an analogy, just think about how Linux distros support old Linux > kernels and enhance them with down ports from newer kernels independently of > the main kernel development. My personal opinion is that we will eventually > come to a similar model with Java. > Thinking more about the Linux kernel analogy, I still think it is mostly valid, however with one major exception. With the Linux kernel, a distributor can freely choose to down-port arbitrary features from newer to older kernels or support old kernel features in newer kernel versions which don't have these any more by default. With Java, this would only be possible with non-specification relevant features (e.g. GC, AOT, CDS, etc). For specification relevant features (i.e. new APIs, language fetures, etc) that would be not possible (at least not if you'd still like to call it Java compatible. So for example, you won't be able to downport "local variable type inference" from JDK 10 (assuming it will get into there) to 9 if you'd like to support JDK 9 for some long amount of time but don't want to support JDK 10. Also, you can't decide for your "JDK N" distribution to still support a standard API which was removed in "JDK N-1". That's of course a major drawback compared to the Linux kernel model. > From my understanding the "new release cadence" step has always been at > least as much about reorganizing the Java support business as it was about > innovation. And it seems that others are now slowly realizing this as well > ;) > > Regards, > Volker > > > Stephen Colebourne schrieb am Fr. 3. Nov. 2017 um > 17:41: >> >> On 3 November 2017 at 09:14, Andrew Haley wrote: >> >> I think this is throwing the baby (Java's long standing backwards >> >> compatibility) out with the bathwater (frequent releases), but I'm >> >> happy to hear other opinions. >> > >> > I don't believe that such worries are necessarily justified. >> > >> > We need to be able to roll back mistakes. The Java tradition that >> > nothing ever gets removed, no matter how much mistaken, holds back >> > innovation. It does this because of a justified fear that if we make >> > a mistake, we're stuck with it, so we have to be ultra-cautious. >> >> I think its more than that. Java's success is built on the broader >> ecosystem. The JDK itself is an enabler for that. Open source projects >> have to be able to produce jar files that work on multiple releases of >> the JDK. Things that prevent that are a big issue. >> >> In practical terms I'd argue that: >> >> 1) LTS releases define the removal cycle. Code added in a non-LTS >> release (n) can be deprecated in the next non-LTS release (n+1) and >> removed in the release after that (n+2). This works because the code >> was never in an LTS release. However, code that *was* in the last LTS >> release cannot be removed until the release after the next LTS. >> >> eg. code present in 8 cannot be removed until 12 (as 11 is the first >> LTS where the deprecation is visible) >> eg. code added in 12 can be deprecated in 13 and removed in 14 as 12 >> and 13 are non-LTS >> >> 2) There should be more than 2 security updates for each release. >> Without an overlap period, developers are forced to upgrade to the >> next release immediately it is GA. This does not reflect real-world >> software development practice. If the non-LTS releases are to be used >> in production they will need a bare minimum of 4 security updates (one >> year) to create a time window overlap with the next release. >> >> 3) The javac --release flag should work for at least the last three >> LTS releases. A time-window of 10 years would also be about right. >> (Its a *really* convenient feature, and if possible I'd prefer it to >> never lose support for older versions). >> >> Stephen From kim at javadog.io Wed Nov 8 18:44:21 2017 From: kim at javadog.io (Kim Jensen) Date: Wed, 08 Nov 2017 13:44:21 -0500 Subject: LTS for public releases In-Reply-To: References: Message-ID: <2tyMugCv1CbPEbrnQtcyPNZ-lAI7-lDulB8N-fZHqPqrVxAYuCF4ly13F8KGdud13lyl-zf0NWIG13qjnO9fc5JVI0paISahLWpI5MSyNQA=@javadog.io> >On 8 November 2017 at 16:31, Andrew Hughes gnu.andrew at redhat.com wrote: >> Well, that page is about Oracle's binaries, not OpenJDK in general. >> It's important not to confuse the two. >> >> It may well be that Oracle don't provide public binaries of LTS releases, >> but there's nothing stopping anyone else from doing so and I would >> expect that to continue as it does now in various distributions. > > I don't think this game of "well someone else might support it" is at > all helpful to the wider community. > > Architects/senior devs need to know that the code they are writing now > can run on a supported platform for at least a few years after they > finish coding it. This has been one of the critical factors in Java's > success. > > What is actually being promised is ridiculously woolly by comparison. > Oracle might provide 3 years of public updates on LTS for $free, or > they might not. Red Hat might provide some LTS's or they might not. > Red Hat LTS's might align with Oracle's LTS, or they might not. Some > other random group of "OpenJDK community" might turn up and do > something, or it might not. > > No certainty. No ability to plan. Its a mess. > > Stephen > Oracle's solution to the problem seems simple. Customers must pay! Only problem is, that Oracle's licensing and pricing policies is the most hated in the industry, because they lack transparency and is very pricy. Something, which larger companies may be able to afford, but many smaller ones can't. If you ask developers to embed the JRE, then it also implies that they have to support not only their own software - but the entire stack. Something which most Java developers either can't or won't do. Can't because it may require more knowledge than they have and won't as it will make their software very costly - especially if they have to support it for many years. If you keep writing a "thin" product, which relies on customers having a full stack available - then you suddenly need to know that the platform they have available is supporting Java. With the new policies, some platforms may simply decide to stop supporting Java, as it becomes too expensive. Many customers choose a platform, and stick to it. So, this means that if they no longer support Java, then it won't work. If it is left to Vendors to provide Java under their platforms, please explain why Microsoft should support Java ? After all, it is a direct competitor to .Net. Even if your IDE comes with a JRE, they still require a JDK, often many different JDK's for different projects - are the developers suppose to build it themselves ? I agree with Stephen, this is a mess. /Kim From volker.simonis at gmail.com Wed Nov 8 18:58:16 2017 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 8 Nov 2017 19:58:16 +0100 Subject: What kinds of changes need a JEP? In-Reply-To: <3708CA1D-374F-477C-B6F5-99BE4B54A6CD@oracle.com> References: <20171106091441.3E141FD068@eggemoggin.niobe.net> <3708CA1D-374F-477C-B6F5-99BE4B54A6CD@oracle.com> Message-ID: Hi Mark, thanks for finally addressing this long standing issue! I think your proposal is good. In a parallel thread [1] Brian has just describe the work on a JEP as follows: "For nontrivial projects, you are expected to work iteratively, progressively refining the design, interface, implementation, and test suite together, outside of the main code line, until it is ready, and then ? and only then ? do you start the process of proposing to target." I think that's a pretty accurate description of a JEP and I'm inclined to propose to add something like the following to the conditions for a JEP you've defined: A JEP should be drafted for a body of work when at least one of the following is true: - It makes a significant or risky change to the JDK, - It has a broader impact on developers and users than can reasonably be communicated in an ordinary enhancement or CSR issue, or - It is in high demand by developers or users. and it justifies an implementation and testing outside of the main code line. This would make it clear that a JEP is a more heavy-weight project than a simple enhancement and that we expect a fully working and tested implementation before we consider to integrate it into the "always feature complete" main line. It would also keep people from "cheating" by implementing parts of a JEP incrementally in the main line. Regards, Volker [1] http://mail.openjdk.java.net/pipermail/jdk-dev/2017-November/000138.html On Tue, Nov 7, 2017 at 5:46 PM, Brian Goetz wrote: > At the risk of being redundant, I?ll add that a JEP should be required for: > - Any language feature; > - Any change to the class file format. > > While one could argue that these are subsumed by the other criteria, it is best to be explicit. > >> On Nov 6, 2017, at 10:14 AM, mark.reinhold at oracle.com wrote: >> >> I'm working on an overall update of the JEP process documents, which have >> been in a draft state for too long now. >> >> One issue we can discuss independently is that of the criteria for what >> kinds of changes need a JEP. The primary process document, JEP 1, >> currently states [1]: >> >>> An _enhancement_ is an effort to design and implement a nontrivial >>> change to the JDK code base or to do some other kind of work whose >>> goals, progress, and result are worth communicating broadly. A JDK >>> Enhancement Proposal (hereinafter "JEP") should be drafted for any >>> work that meets at least one of the following criteria: >>> >>> - It requires two or more weeks of engineering effort, >>> >>> - It makes a significant change to the JDK, or to the processes >>> and infrastructure by which it is developed, or >>> >>> - It is in high demand by developers or customers. >> >> Based on the experience of using the JEP process in one form or another >> for both JDK 8 and JDK 9, and looking ahead to the six-month release >> cadence, there are at least three ways in which these criteria could be >> improved. >> >> (1) Do not mandate a JEP for a change just because that change >> requires two or more weeks of engineering effort. >> >> Several committers and reviewers have observed that the first of the >> above criteria, "requires two or more weeks of engineering effort," is >> at odds with the preceding definition of "enhancement," namely a change >> that's "worth communicating broadly," especially when that means running >> it through the JEP process for candidate review, target proposal, and so >> forth. >> >> Some changes can take more than two weeks of effort but aren't worth the >> effort to communicate broadly via the JEP process, particularly if they >> mainly concern developers of the JDK itself and have minimal impact on >> those who use and deploy the JDK. Examples include, but are not limited >> to, straightforward performance enhancements, refactorings of internal >> implementation code, improvements to tests, and merges of upstream code >> that have little or no effect on exported APIs. Such changes can be >> communicated adequately via ordinary enhancement issues in JBS, in CSR >> issues when exported APIs or other public interfaces are affected, and >> in the public reviews of such changes that we already do. >> >> We could reduce the overhead of these sorts of changes by dropping the >> first criterion, so that we no longer mandate a JEP for a change that >> merely "requires two or more weeks of engineering effort," and adding >> a criterion to require a JEP for a change that can't be communicated >> adequately via normal JBS enhancement or CSR issues. >> >> (2) Do not use the JEP process to track changes in development >> processes or infrastructure. >> >> In practice we just haven't used the JEP process for these purposes. The >> processes by which we stabilized JDK 8 and JDK 9, e.g., were proposed and >> discussed on development mailing lists and documented on project-specific >> web pages. The same is true of the CSR process. We seem to have gotten >> along fine without using the JEP process as a meta-process for all other >> processes, so let's drop this part of the second criterion. >> >> Insofar as we've had "infrastructure" JEPs, they've been for enhancements >> to the infrastructure of the JDK's build system rather than to software >> or systems outside of the JDK, which was the original intent. Such JEPs >> could as easily be characterized as "feature" JEPs, so we can drop the >> "infrastructure" part of the second criterion also. >> >> (3) Do mandate JEPs for risky changes. >> >> A strict, six-month release cadence leaves few opportunities to repair or >> back out bad changes. A change that carries significant risk is worth >> communicating broadly, and can benefit from the additional scrutiny that >> it will receive when it's proposed to target a specific release. >> >> * * * >> >> Here's a proposed new list of criteria that incorporates these changes. >> >> A JEP should be drafted for a body of work when at least one of the >> following is true: >> >> - It makes a significant or risky change to the JDK, >> >> - It has a broader impact on developers and users than can reasonably >> be communicated in an ordinary enhancement or CSR issue, or >> >> - It is in high demand by developers or users. >> >> Comments? >> >> - Mark >> >> >> [1] http://openjdk.java.net/jeps/1#Overview > From thomas.stuefe at gmail.com Wed Nov 8 19:11:29 2017 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Wed, 08 Nov 2017 19:11:29 +0000 Subject: CFV: New JDK Reviewer: Calvin Cheung In-Reply-To: <39A85362-8842-4A45-B756-70934274F251@oracle.com> References: <39A85362-8842-4A45-B756-70934274F251@oracle.com> Message-ID: On Tue 7. Nov 2017 at 21:42, Jiangli Zhou wrote: > I hereby nominate Calvin Cheung (ccheung) to be a JDK Reviewer. > > Calvin Cheung is currently a member of Hotspot Runtime group. Before that > he worked on java plugin and java webstart. As part of the Hotspot runtime > team, Calvin has contributed total 57 changes in various runtime areas. In > recent two years, he has primarily worked on hotspot CDS/AppCDS. His latest > CDS/AppCDS contribution is changing the archive dumping process to use the > Java builtin class loader instances (the system loader and the > PlatformClassLoader) to load related classes. > > Votes are due by 21 November 2017, 1:00 pm PT. > > Only current JDK Reviewers [1] are eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailing list. > > For Three-Vote Consensus voting instructions, see [2]. > > Regards, > Jiangli Zhou > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#reviewer-vote > [3] > http://hg.openjdk.java.net/jdk/hs/log?revcount=100&rev=%28keyword%28%22calvin.cheung%40oracle.com%22%29+or+author%28ccheung%29%29 > Vote: yes > > > > > > From martijnverburg at gmail.com Wed Nov 8 19:12:22 2017 From: martijnverburg at gmail.com (Martijn Verburg) Date: Wed, 8 Nov 2017 19:12:22 +0000 Subject: LTS for public releases In-Reply-To: <2tyMugCv1CbPEbrnQtcyPNZ-lAI7-lDulB8N-fZHqPqrVxAYuCF4ly13F8KGdud13lyl-zf0NWIG13qjnO9fc5JVI0paISahLWpI5MSyNQA=@javadog.io> References: <2tyMugCv1CbPEbrnQtcyPNZ-lAI7-lDulB8N-fZHqPqrVxAYuCF4ly13F8KGdud13lyl-zf0NWIG13qjnO9fc5JVI0paISahLWpI5MSyNQA=@javadog.io> Message-ID: Hi all, I'm going to disagree here. There are already a number of vendors that provide commercial supported OpenJDK derivatives including RedHat, Azul and of course Oracle. I suspect those support programmes will only be strengthened by the recent changes in release cycle and opening up of technology. I would not be surprised if other vendors also start offering support *because* things have been opened up even further! The Adopt OpenJDK community will also provide thoroughly tested (jtreg + donated tests + JCK) binaries (no $$ support though) for a wide array of platforms, with those platforms fully open and auditable (you know what it was built from as well as what was built). I personally don't see a major issue here (speaking as an end user and a vendor of sorts). Cheers, Martijn On 8 November 2017 at 18:44, Kim Jensen wrote: > >On 8 November 2017 at 16:31, Andrew Hughes gnu.andrew at redhat.com wrote: > >> Well, that page is about Oracle's binaries, not OpenJDK in general. > >> It's important not to confuse the two. > >> > >> It may well be that Oracle don't provide public binaries of LTS > releases, > >> but there's nothing stopping anyone else from doing so and I would > >> expect that to continue as it does now in various distributions. > > > > I don't think this game of "well someone else might support it" is at > > all helpful to the wider community. > > > > Architects/senior devs need to know that the code they are writing now > > can run on a supported platform for at least a few years after they > > finish coding it. This has been one of the critical factors in Java's > > success. > > > > What is actually being promised is ridiculously woolly by comparison. > > Oracle might provide 3 years of public updates on LTS for $free, or > > they might not. Red Hat might provide some LTS's or they might not. > > Red Hat LTS's might align with Oracle's LTS, or they might not. Some > > other random group of "OpenJDK community" might turn up and do > > something, or it might not. > > > > No certainty. No ability to plan. Its a mess. > > > > Stephen > > > > Oracle's solution to the problem seems simple. Customers must pay! Only > problem is, that Oracle's licensing and pricing policies is the most hated > in the industry, because they lack transparency and is very pricy. > Something, which larger companies may be able to afford, but many smaller > ones can't. > > If you ask developers to embed the JRE, then it also implies that they > have to support not only their own software - but the entire stack. > Something which most Java developers either can't or won't do. Can't > because it may require more knowledge than they have and won't as it will > make their software very costly - especially if they have to support it for > many years. > > If you keep writing a "thin" product, which relies on customers having a > full stack available - then you suddenly need to know that the platform > they have available is supporting Java. With the new policies, some > platforms may simply decide to stop supporting Java, as it becomes too > expensive. Many customers choose a platform, and stick to it. So, this > means that if they no longer support Java, then it won't work. > > If it is left to Vendors to provide Java under their platforms, please > explain why Microsoft should support Java ? After all, it is a direct > competitor to .Net. Even if your IDE comes with a JRE, they still require a > JDK, often many different JDK's for different projects - are the developers > suppose to build it themselves ? > > I agree with Stephen, this is a mess. > > /Kim > From kim at javadog.io Wed Nov 8 19:53:51 2017 From: kim at javadog.io (Kim Jensen) Date: Wed, 08 Nov 2017 14:53:51 -0500 Subject: Impact of six month releases In-Reply-To: References: <52078f75-e29d-7ddf-934f-15fe1092c6aa@redhat.com> Message-ID: <9Pw_Xwhan-GWCC51na1X7X_BLNdtBc2DQ9Wi1N-D-Qw3XKCOy6fdUJadmpPYQhkSFpCfgeJmWOxkFlXpk928IR1Y94XQwFSZQxBNOB0P5-Y=@javadog.io> Hi Volker, > Thinking more about the Linux kernel analogy, I still think it is > mostly valid, however with one major exception. With the Linux kernel, > a distributor can freely choose to down-port arbitrary features from > newer to older kernels or support old kernel features in newer kernel > versions which don't have these any more by default. > > With Java, this would only be possible with non-specification relevant > features (e.g. GC, AOT, CDS, etc). For specification relevant features > (i.e. new APIs, language fetures, etc) that would be not possible (at > least not if you'd still like to call it Java compatible. So for > example, you won't be able to downport "local variable type inference" > from JDK 10 (assuming it will get into there) to 9 if you'd like to > support JDK 9 for some long amount of time but don't want to support > JDK 10. Also, you can't decide for your "JDK N" distribution to still > support a standard API which was removed in "JDK N-1". That's of > course a major drawback compared to the Linux kernel model. Java is a platform, not an operating system. And for a platform, you don't wish to backport features, only move forward. As a Java Developer, I don't have a problem moving forward, in fact I find it fantastic to keep taking advantage of the work of better developers than me. However, my argument is not for the developers, but for the customers who purchase my products. Prior to Java 9, most applications were running quite well with newer Java versions, thanks to the fantastic work of the JDK team with keeping the JRE backward compatible. Combine that with a relatively long inexpensive support, stability & security - it makes Java a really good platform for most customers to rely on. However, post-Java 9 - with the new plans from Oracle... it is a different ballgame. Despite my many wishes that Java will be just as important a platform in 20 years, as it has been the last 20 years. The Customers are the ones making the choices. And for them, Java is moving in a direction that will make it an administrative security nightmare and thus a liability. /Kim Good judgment comes from experience; experience comes from bad judgment. From kim at javadog.io Wed Nov 8 20:34:42 2017 From: kim at javadog.io (Kim Jensen) Date: Wed, 08 Nov 2017 15:34:42 -0500 Subject: LTS for public releases In-Reply-To: References: <2tyMugCv1CbPEbrnQtcyPNZ-lAI7-lDulB8N-fZHqPqrVxAYuCF4ly13F8KGdud13lyl-zf0NWIG13qjnO9fc5JVI0paISahLWpI5MSyNQA=@javadog.io> Message-ID: Hi Martijn, >I'm going to disagree here.? There are already a number of vendors that provide commercial supported OpenJDK derivatives including RedHat, Azul and of course Oracle. I suspect those support programmes will only be strengthened by the recent changes in release cycle and opening up of technology.? I would not be surprised if other vendors also start offering support *because* things have been opened up even further! > The question is not about the commercially supported JDK's. Customers who can afford to pay will always be able to get that. But, not all customers can afford it - and although the argument can be made that there is no such thing as a free lunch, it is equally important to remember that the freely available and supported version is important for the widespread adoption of the platform. >The Adopt OpenJDK community will also provide thoroughly tested (jtreg + donated tests + JCK) binaries (no $$ support though) for a wide array of platforms, with those platforms fully open and auditable (you know what it was built from as well as what was built). > Now, this is the interesting question. How long will these be supported ? Will there be an overlap allowing customers & developers to catch up on the next version without the risk of running on an insecure platform ? Customers are very happy with the way things are, pre-Java9. But, the drastic changes may have some very damning consequences. /Kim Good judgment comes from experience; experience comes from bad judgment. From karen.kinnear at oracle.com Wed Nov 8 21:56:58 2017 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Wed, 8 Nov 2017 16:56:58 -0500 Subject: CFV: New JDK Reviewer: Calvin Cheung In-Reply-To: <39A85362-8842-4A45-B756-70934274F251@oracle.com> References: <39A85362-8842-4A45-B756-70934274F251@oracle.com> Message-ID: Vote: yes thanks, Karen > On Nov 7, 2017, at 3:41 PM, Jiangli Zhou wrote: > > I hereby nominate Calvin Cheung (ccheung) to be a JDK Reviewer. > > Calvin Cheung is currently a member of Hotspot Runtime group. Before that he worked on java plugin and java webstart. As part of the Hotspot runtime team, Calvin has contributed total 57 changes in various runtime areas. In recent two years, he has primarily worked on hotspot CDS/AppCDS. His latest CDS/AppCDS contribution is changing the archive dumping process to use the Java builtin class loader instances (the system loader and the PlatformClassLoader) to load related classes. > > Votes are due by 21 November 2017, 1:00 pm PT. > > Only current JDK Reviewers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Three-Vote Consensus voting instructions, see [2]. > > Regards, > Jiangli Zhou > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#reviewer-vote > [3] http://hg.openjdk.java.net/jdk/hs/log?revcount=100&rev=%28keyword%28%22calvin.cheung%40oracle.com%22%29+or+author%28ccheung%29%29 > > > > > > From brian.goetz at oracle.com Wed Nov 8 22:40:28 2017 From: brian.goetz at oracle.com (Brian Goetz) Date: Wed, 8 Nov 2017 23:40:28 +0100 Subject: What kinds of changes need a JEP? In-Reply-To: References: <20171106091441.3E141FD068@eggemoggin.niobe.net> <3708CA1D-374F-477C-B6F5-99BE4B54A6CD@oracle.com> Message-ID: I think this additional constraint is putting the dependency in the wrong direction. JEP is for something that is big enough, risky enough, or visible enough. Many things that are big enough or risky enough ALSO merit work outside of the mainline, but that?s not what makes them JEP-worthy; it?s the size / risk / visibility. The relationship is correlative, not causative. > On Nov 8, 2017, at 7:58 PM, Volker Simonis wrote: > > Hi Mark, > > thanks for finally addressing this long standing issue! I think your > proposal is good. > > In a parallel thread [1] Brian has just describe the work on a JEP as > follows: "For nontrivial projects, you are expected to work > iteratively, progressively refining the design, interface, > implementation, and test suite together, outside of the main code > line, until it is ready, and then ? and only then ? do you start the > process of proposing to target." > > I think that's a pretty accurate description of a JEP and I'm inclined > to propose to add something like the following to the conditions for a > JEP you've defined: > > A JEP should be drafted for a body of work when at least one of the > following is true: > > - It makes a significant or risky change to the JDK, > > - It has a broader impact on developers and users than can reasonably > be communicated in an ordinary enhancement or CSR issue, or > > - It is in high demand by developers or users. > > and it justifies an implementation and testing outside of the main code line. > > This would make it clear that a JEP is a more heavy-weight project > than a simple enhancement and that we expect a fully working and > tested implementation before we consider to integrate it into the > "always feature complete" main line. It would also keep people from > "cheating" by implementing parts of a JEP incrementally in the main > line. > > Regards, > Volker > > [1] http://mail.openjdk.java.net/pipermail/jdk-dev/2017-November/000138.html > > > On Tue, Nov 7, 2017 at 5:46 PM, Brian Goetz wrote: >> At the risk of being redundant, I?ll add that a JEP should be required for: >> - Any language feature; >> - Any change to the class file format. >> >> While one could argue that these are subsumed by the other criteria, it is best to be explicit. >> >>> On Nov 6, 2017, at 10:14 AM, mark.reinhold at oracle.com wrote: >>> >>> I'm working on an overall update of the JEP process documents, which have >>> been in a draft state for too long now. >>> >>> One issue we can discuss independently is that of the criteria for what >>> kinds of changes need a JEP. The primary process document, JEP 1, >>> currently states [1]: >>> >>>> An _enhancement_ is an effort to design and implement a nontrivial >>>> change to the JDK code base or to do some other kind of work whose >>>> goals, progress, and result are worth communicating broadly. A JDK >>>> Enhancement Proposal (hereinafter "JEP") should be drafted for any >>>> work that meets at least one of the following criteria: >>>> >>>> - It requires two or more weeks of engineering effort, >>>> >>>> - It makes a significant change to the JDK, or to the processes >>>> and infrastructure by which it is developed, or >>>> >>>> - It is in high demand by developers or customers. >>> >>> Based on the experience of using the JEP process in one form or another >>> for both JDK 8 and JDK 9, and looking ahead to the six-month release >>> cadence, there are at least three ways in which these criteria could be >>> improved. >>> >>> (1) Do not mandate a JEP for a change just because that change >>> requires two or more weeks of engineering effort. >>> >>> Several committers and reviewers have observed that the first of the >>> above criteria, "requires two or more weeks of engineering effort," is >>> at odds with the preceding definition of "enhancement," namely a change >>> that's "worth communicating broadly," especially when that means running >>> it through the JEP process for candidate review, target proposal, and so >>> forth. >>> >>> Some changes can take more than two weeks of effort but aren't worth the >>> effort to communicate broadly via the JEP process, particularly if they >>> mainly concern developers of the JDK itself and have minimal impact on >>> those who use and deploy the JDK. Examples include, but are not limited >>> to, straightforward performance enhancements, refactorings of internal >>> implementation code, improvements to tests, and merges of upstream code >>> that have little or no effect on exported APIs. Such changes can be >>> communicated adequately via ordinary enhancement issues in JBS, in CSR >>> issues when exported APIs or other public interfaces are affected, and >>> in the public reviews of such changes that we already do. >>> >>> We could reduce the overhead of these sorts of changes by dropping the >>> first criterion, so that we no longer mandate a JEP for a change that >>> merely "requires two or more weeks of engineering effort," and adding >>> a criterion to require a JEP for a change that can't be communicated >>> adequately via normal JBS enhancement or CSR issues. >>> >>> (2) Do not use the JEP process to track changes in development >>> processes or infrastructure. >>> >>> In practice we just haven't used the JEP process for these purposes. The >>> processes by which we stabilized JDK 8 and JDK 9, e.g., were proposed and >>> discussed on development mailing lists and documented on project-specific >>> web pages. The same is true of the CSR process. We seem to have gotten >>> along fine without using the JEP process as a meta-process for all other >>> processes, so let's drop this part of the second criterion. >>> >>> Insofar as we've had "infrastructure" JEPs, they've been for enhancements >>> to the infrastructure of the JDK's build system rather than to software >>> or systems outside of the JDK, which was the original intent. Such JEPs >>> could as easily be characterized as "feature" JEPs, so we can drop the >>> "infrastructure" part of the second criterion also. >>> >>> (3) Do mandate JEPs for risky changes. >>> >>> A strict, six-month release cadence leaves few opportunities to repair or >>> back out bad changes. A change that carries significant risk is worth >>> communicating broadly, and can benefit from the additional scrutiny that >>> it will receive when it's proposed to target a specific release. >>> >>> * * * >>> >>> Here's a proposed new list of criteria that incorporates these changes. >>> >>> A JEP should be drafted for a body of work when at least one of the >>> following is true: >>> >>> - It makes a significant or risky change to the JDK, >>> >>> - It has a broader impact on developers and users than can reasonably >>> be communicated in an ordinary enhancement or CSR issue, or >>> >>> - It is in high demand by developers or users. >>> >>> Comments? >>> >>> - Mark >>> >>> >>> [1] http://openjdk.java.net/jeps/1#Overview >> From david.holmes at oracle.com Thu Nov 9 00:46:45 2017 From: david.holmes at oracle.com (David Holmes) Date: Thu, 9 Nov 2017 10:46:45 +1000 Subject: CFV: New JDK Reviewer: Calvin Cheung In-Reply-To: <39A85362-8842-4A45-B756-70934274F251@oracle.com> References: <39A85362-8842-4A45-B756-70934274F251@oracle.com> Message-ID: <7d57b93d-13d5-2b56-402c-1da1db47d53c@oracle.com> Vote: yes David On 8/11/2017 6:41 AM, Jiangli Zhou wrote: > I hereby nominate Calvin Cheung (ccheung) to be a JDK Reviewer. From david.holmes at oracle.com Thu Nov 9 01:58:57 2017 From: david.holmes at oracle.com (David Holmes) Date: Thu, 9 Nov 2017 11:58:57 +1000 Subject: What kinds of changes need a JEP? In-Reply-To: References: <20171106091441.3E141FD068@eggemoggin.niobe.net> <3708CA1D-374F-477C-B6F5-99BE4B54A6CD@oracle.com> Message-ID: On 9/11/2017 4:58 AM, Volker Simonis wrote: > Hi Mark, > > thanks for finally addressing this long standing issue! I think your > proposal is good. > > In a parallel thread [1] Brian has just describe the work on a JEP as > follows: "For nontrivial projects, you are expected to work > iteratively, progressively refining the design, interface, > implementation, and test suite together, outside of the main code > line, until it is ready, and then ? and only then ? do you start the > process of proposing to target." > > I think that's a pretty accurate description of a JEP and I'm inclined > to propose to add something like the following to the conditions for a > JEP you've defined: > > A JEP should be drafted for a body of work when at least one of the > following is true: > > - It makes a significant or risky change to the JDK, > > - It has a broader impact on developers and users than can reasonably > be communicated in an ordinary enhancement or CSR issue, or > > - It is in high demand by developers or users. > > and it justifies an implementation and testing outside of the main code line. > > This would make it clear that a JEP is a more heavy-weight project > than a simple enhancement and that we expect a fully working and > tested implementation before we consider to integrate it into the > "always feature complete" main line. It would also keep people from > "cheating" by implementing parts of a JEP incrementally in the main > line. It is perfectly reasonable for JEP work to identify cleanups and refactorings that aid the JEP work, but which can be putback to the mainline as a standalone change. Without such enabling changes we would greatly increase the difficulty of integrating the JEP work when it is ready. I don't consider this "cheating". Cheers, David > Regards, > Volker > > [1] http://mail.openjdk.java.net/pipermail/jdk-dev/2017-November/000138.html > > > On Tue, Nov 7, 2017 at 5:46 PM, Brian Goetz wrote: >> At the risk of being redundant, I?ll add that a JEP should be required for: >> - Any language feature; >> - Any change to the class file format. >> >> While one could argue that these are subsumed by the other criteria, it is best to be explicit. >> >>> On Nov 6, 2017, at 10:14 AM, mark.reinhold at oracle.com wrote: >>> >>> I'm working on an overall update of the JEP process documents, which have >>> been in a draft state for too long now. >>> >>> One issue we can discuss independently is that of the criteria for what >>> kinds of changes need a JEP. The primary process document, JEP 1, >>> currently states [1]: >>> >>>> An _enhancement_ is an effort to design and implement a nontrivial >>>> change to the JDK code base or to do some other kind of work whose >>>> goals, progress, and result are worth communicating broadly. A JDK >>>> Enhancement Proposal (hereinafter "JEP") should be drafted for any >>>> work that meets at least one of the following criteria: >>>> >>>> - It requires two or more weeks of engineering effort, >>>> >>>> - It makes a significant change to the JDK, or to the processes >>>> and infrastructure by which it is developed, or >>>> >>>> - It is in high demand by developers or customers. >>> >>> Based on the experience of using the JEP process in one form or another >>> for both JDK 8 and JDK 9, and looking ahead to the six-month release >>> cadence, there are at least three ways in which these criteria could be >>> improved. >>> >>> (1) Do not mandate a JEP for a change just because that change >>> requires two or more weeks of engineering effort. >>> >>> Several committers and reviewers have observed that the first of the >>> above criteria, "requires two or more weeks of engineering effort," is >>> at odds with the preceding definition of "enhancement," namely a change >>> that's "worth communicating broadly," especially when that means running >>> it through the JEP process for candidate review, target proposal, and so >>> forth. >>> >>> Some changes can take more than two weeks of effort but aren't worth the >>> effort to communicate broadly via the JEP process, particularly if they >>> mainly concern developers of the JDK itself and have minimal impact on >>> those who use and deploy the JDK. Examples include, but are not limited >>> to, straightforward performance enhancements, refactorings of internal >>> implementation code, improvements to tests, and merges of upstream code >>> that have little or no effect on exported APIs. Such changes can be >>> communicated adequately via ordinary enhancement issues in JBS, in CSR >>> issues when exported APIs or other public interfaces are affected, and >>> in the public reviews of such changes that we already do. >>> >>> We could reduce the overhead of these sorts of changes by dropping the >>> first criterion, so that we no longer mandate a JEP for a change that >>> merely "requires two or more weeks of engineering effort," and adding >>> a criterion to require a JEP for a change that can't be communicated >>> adequately via normal JBS enhancement or CSR issues. >>> >>> (2) Do not use the JEP process to track changes in development >>> processes or infrastructure. >>> >>> In practice we just haven't used the JEP process for these purposes. The >>> processes by which we stabilized JDK 8 and JDK 9, e.g., were proposed and >>> discussed on development mailing lists and documented on project-specific >>> web pages. The same is true of the CSR process. We seem to have gotten >>> along fine without using the JEP process as a meta-process for all other >>> processes, so let's drop this part of the second criterion. >>> >>> Insofar as we've had "infrastructure" JEPs, they've been for enhancements >>> to the infrastructure of the JDK's build system rather than to software >>> or systems outside of the JDK, which was the original intent. Such JEPs >>> could as easily be characterized as "feature" JEPs, so we can drop the >>> "infrastructure" part of the second criterion also. >>> >>> (3) Do mandate JEPs for risky changes. >>> >>> A strict, six-month release cadence leaves few opportunities to repair or >>> back out bad changes. A change that carries significant risk is worth >>> communicating broadly, and can benefit from the additional scrutiny that >>> it will receive when it's proposed to target a specific release. >>> >>> * * * >>> >>> Here's a proposed new list of criteria that incorporates these changes. >>> >>> A JEP should be drafted for a body of work when at least one of the >>> following is true: >>> >>> - It makes a significant or risky change to the JDK, >>> >>> - It has a broader impact on developers and users than can reasonably >>> be communicated in an ordinary enhancement or CSR issue, or >>> >>> - It is in high demand by developers or users. >>> >>> Comments? >>> >>> - Mark >>> >>> >>> [1] http://openjdk.java.net/jeps/1#Overview >> From joe.darcy at oracle.com Thu Nov 9 10:09:47 2017 From: joe.darcy at oracle.com (joe darcy) Date: Thu, 9 Nov 2017 02:09:47 -0800 Subject: What kinds of changes need a JEP? In-Reply-To: <20171106091441.3E141FD068@eggemoggin.niobe.net> References: <20171106091441.3E141FD068@eggemoggin.niobe.net> Message-ID: <7f318d64-c177-5756-4ce5-f1b3890035ee@oracle.com> Hi Mark, On 11/6/2017 1:14 AM, mark.reinhold at oracle.com wrote: > I'm working on an overall update of the JEP process documents, which have > been in a draft state for too long now. > > One issue we can discuss independently is that of the criteria for what > kinds of changes need a JEP. The primary process document, JEP 1, > currently states [1]: > [...] I think the proposed changes are sensible improvements. Cheers, -Joe From neugens.limasoftware at gmail.com Thu Nov 9 13:46:13 2017 From: neugens.limasoftware at gmail.com (Mario Torre) Date: Thu, 9 Nov 2017 14:46:13 +0100 Subject: LTS for public releases In-Reply-To: References: Message-ID: 2017-11-08 18:31 GMT+01:00 Stephen Colebourne : > On 8 November 2017 at 16:31, Andrew Hughes wrote: >> Well, that page is about Oracle's binaries, not OpenJDK in general. >> It's important not to confuse the two. >> >> It may well be that Oracle don't provide public binaries of LTS releases, >> but there's nothing stopping anyone else from doing so and I would >> expect that to continue as it does now in various distributions. > > I don't think this game of "well someone else might support it" is at > all helpful to the wider community. > > Architects/senior devs need to know that the code they are writing now > can run on a supported platform for at least a few years after they > finish coding it. This has been one of the critical factors in Java's > success. > > What is actually being promised is ridiculously woolly by comparison. > Oracle might provide 3 years of public updates on LTS for $free, or > they might not. Red Hat might provide some LTS's or they might not. > Red Hat LTS's might align with Oracle's LTS, or they might not. Some > other random group of "OpenJDK community" might turn up and do > something, or it might not. > > No certainty. No ability to plan. Its a mess. Can't see why is that. No one of the involved party has any interest in devaluating the benefit of Java releases. LTS will behave as they do now, non LTS will be supported for as long as they are alive. Popular version may end up being supported for longer. This is already the case today, Java 6 has been around for far longer than anyone wanted, for example. Obviously, syncing up on LTS makes sense for all the vendors, since it provides a standard base for longer term standards, rather than each one doing their own thing. The goal of short term release is not to kill compatibility, if any, features will be introduced incrementally which will lower the risk of incompatible changes and offer a way of correcting them in no less that one short release cycle, I can see only benefit here. This is not not possible with the long term release scheme, where 10 or more new features end up being pushed in a monolithic upgrade every few years, without a real upgrade plan (which means we end up with older versions supported forever). The plan is simple, there one LTS (that meet the demand of customer that value stability) every fixed amount of time, and then there are short term releases every shorter amount of time, developers should use them to develop and test their software, while use the LTS in production systems that need long term support. It really can't get any easier and fits both worlds, no one is left behind. Cheers, Mario -- pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens Proud GNU Classpath developer: http://www.classpath.org/ OpenJDK: http://openjdk.java.net/projects/caciocavallo/ Please, support open standards: http://endsoftpatents.org/ From roger.riggs at oracle.com Thu Nov 9 14:54:48 2017 From: roger.riggs at oracle.com (Roger Riggs) Date: Thu, 9 Nov 2017 09:54:48 -0500 Subject: CFV: New JDK Reviewer: Calvin Cheung In-Reply-To: <39A85362-8842-4A45-B756-70934274F251@oracle.com> References: <39A85362-8842-4A45-B756-70934274F251@oracle.com> Message-ID: <0fdcb4e6-5910-a31d-0794-ce20c2e1fe05@oracle.com> Vote: Yes On 11/7/17 3:41 PM, Jiangli Zhou wrote: > I hereby nominate Calvin Cheung (ccheung) to be a JDK Reviewer. From aph at redhat.com Thu Nov 9 16:34:37 2017 From: aph at redhat.com (Andrew Haley) Date: Thu, 9 Nov 2017 16:34:37 +0000 Subject: LTS for public releases In-Reply-To: References: Message-ID: <59d4b980-ce59-3404-2cab-1a8890766663@redhat.com> On 08/11/17 17:31, Stephen Colebourne wrote: > On 8 November 2017 at 16:31, Andrew Hughes wrote: >> Well, that page is about Oracle's binaries, not OpenJDK in general. >> It's important not to confuse the two. >> >> It may well be that Oracle don't provide public binaries of LTS releases, >> but there's nothing stopping anyone else from doing so and I would >> expect that to continue as it does now in various distributions. > > I don't think this game of "well someone else might support it" is at > all helpful to the wider community. > > Architects/senior devs need to know that the code they are writing now > can run on a supported platform for at least a few years after they > finish coding it. This has been one of the critical factors in Java's > success. > > What is actually being promised is ridiculously woolly by comparison. > Oracle might provide 3 years of public updates on LTS for $free, or > they might not. Red Hat might provide some LTS's or they might not. > Red Hat LTS's might align with Oracle's LTS, or they might not. Some > other random group of "OpenJDK community" might turn up and do > something, or it might not. > > No certainty. No ability to plan. Its a mess. I'm finding it very hard to understand what you're complaining about. Look at the history: JDK 6 support has been extended by the community, led first by me and then by Andrew Byrgin at Azul. This was long beyond Oracle's EOL five years ago. This shows that the OpenJDK community has a solid track record of supporting old releases. Why would the LTS releases be any different? As long as people need the JDKs (and perhaps for longer!) they are available. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From kim at javadog.io Thu Nov 9 17:20:20 2017 From: kim at javadog.io (Kim Jensen) Date: Thu, 09 Nov 2017 12:20:20 -0500 Subject: LTS for public releases In-Reply-To: <59d4b980-ce59-3404-2cab-1a8890766663@redhat.com> References: <59d4b980-ce59-3404-2cab-1a8890766663@redhat.com> Message-ID: Hi Andrew, > I'm finding it very hard to understand what you're complaining about. > Look at the history: JDK 6 support has been extended by the community, > led first by me and then by Andrew Byrgin at Azul. This was long > beyond Oracle's EOL five years ago. This shows that the OpenJDK > community has a solid track record of supporting old releases. Why > would the LTS releases be any different? As long as people need the > JDKs (and perhaps for longer!) they are available. > First, allow me to apologize for spamming this list so much. I'm deeply in awe over the work that you and others have done, and you have my utmost respect for the fantastic work you have done over the years. Pre Java 9, things worked rather well with infrequent Java releases, and a transition period which was at least one year. Post Java 9, or more correctly with Java 18.9 LTS [2], we enter a new era - where there will be short term releases (6 month support) and LTS releases (5 year support). Plan is that every 3 years a new LTS release is made, giving customers 2 years to migrate. This is all good and well. Things can be planned and and customers & developers can continue to work. As an added benefit, developers such as myself can more frequently test our software with the short term releases and verify that things are working. This will also help with the migrations from one LTS to another. Again, wonderful. But, and here it comes... The announcement from Oracle stated that Java 8 is EOL in September 2018, Java 9 is EOL in March 2018. First LTS release is coming in September 2018, and as Short term releases only have support for 6 months, it means that there will be a period of 0 months to complete migrating from Java 8 to Java 18.9LTS. Migrating to Java 9 & Java 18.3 is not something our customers are willing to pay for, as it means 3 migrations rather than 1. And as we have seem, Java 8 to Java 9 is not a trivial upgrade. Loads of libraries are not working and I still have not seen what Java EE vendors will support or not. So, simply put. Is it possible to get a word, that there will be a transition period from Java 8 to Java 18.9LTS, so it is possible to migrate without our customers loosing support ? Thank you for listening to me. Unless asked, I will not comment again on this topic. Regards, Kim Jensen [1] http://www.oracle.com/technetwork/java/eol-135779.html Good judgment comes from experience; experience comes from bad judgment. From aph at redhat.com Thu Nov 9 19:10:03 2017 From: aph at redhat.com (Andrew Haley) Date: Thu, 9 Nov 2017 19:10:03 +0000 Subject: LTS for public releases In-Reply-To: References: <59d4b980-ce59-3404-2cab-1a8890766663@redhat.com> Message-ID: On 09/11/17 17:20, Kim Jensen wrote: > But, and here it comes... The announcement from Oracle stated that > Java 8 is EOL in September 2018, Java 9 is EOL in March 2018. That's Oracle's proprietary binary release of Java 8. OpenJDK 8 will go on after that. > First LTS release is coming in September 2018, and as Short term > releases only have support for 6 months, it means that there will be > a period of 0 months to complete migrating from Java 8 to Java > 18.9LTS. Migrating to Java 9 & Java 18.3 is not something our > customers are willing to pay for, as it means 3 migrations rather > than 1. And as we have seem, Java 8 to Java 9 is not a trivial > upgrade. Loads of libraries are not working and I still have not > seen what Java EE vendors will support or not. > > So, simply put. Is it possible to get a word, that there will be a > transition period from Java 8 to Java 18.9LTS, so it is possible to > migrate without our customers loosing support ? https://access.redhat.com/articles/1299013 We will support OpenJDK 8 until October 2020. We always make our updates publicly available in the appropriate OpenJDK projects. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From scolebourne at joda.org Fri Nov 10 20:16:52 2017 From: scolebourne at joda.org (Stephen Colebourne) Date: Fri, 10 Nov 2017 20:16:52 +0000 Subject: LTS for public releases In-Reply-To: <59d4b980-ce59-3404-2cab-1a8890766663@redhat.com> References: <59d4b980-ce59-3404-2cab-1a8890766663@redhat.com> Message-ID: On 9 November 2017 at 16:34, Andrew Haley wrote: > I'm finding it very hard to understand what you're complaining about. > Look at the history: JDK 6 support has been extended by the community, > led first by me and then by Andrew Byrgin at Azul. This was long > beyond Oracle's EOL five years ago. This shows that the OpenJDK > community has a solid track record of supporting old releases. Why > would the LTS releases be any different? As long as people need the > JDKs (and perhaps for longer!) they are available. As far as I can tell, I can't get a pre-built binary of JDK 6 or JDK 7 from Red Hat without paying. I imagine the same will apply for JDK 8 when that ends public updates. And OpenJDK hasn't been doing binaries until very recently so that isn't helpful for judging what will happen going forward. Up until today there have been 28 public update releases of Oracle JDK 8: http://www.oracle.com/technetwork/java/javase/8u-relnotes-2225394.html These are simple upgrades that generally require no developer work to upgrade to. Any serious company should use these to ensure they are security-patch safe. They have all been made available for $free. Looking to the future, and based on promises to date, the world looks very different. LTS from Oracle is almost certainly paid for. The equivalent from Red Hat or Azul is also likely to be paid for. Thus there appears to be no future official LTS release, with binaries, publicly available, for $free. The impact, based on current published dates, is that every security-conscious user of Java who does not pay, would have to join the ongoing train of releases. They would have to change feature version every 6 months, because those will be the only official security-safe binaries. For the less security-conscious, they'll just stick on 8 or 9 and get far fewer security updates than before - surely a step backward for Java as a platform. Ultimately, these are the criteria I believe are needed for a successful LTS: - a $free pre-built downloadable binary - pre-built for multi-platforms - from a single official location (eg. OpenJDK or Oracle) - $free security-patch updates every 3 months or so until at least one year after the GA of the next LTS I've yet to see Oracle or anyone else commit to these LTS criteria. But I'm happy to be proved wrong. Stephen From aph at redhat.com Fri Nov 10 21:35:08 2017 From: aph at redhat.com (Andrew Haley) Date: Fri, 10 Nov 2017 21:35:08 +0000 Subject: LTS for public releases In-Reply-To: References: <59d4b980-ce59-3404-2cab-1a8890766663@redhat.com> Message-ID: On 10/11/17 20:16, Stephen Colebourne wrote: > On 9 November 2017 at 16:34, Andrew Haley wrote: >> I'm finding it very hard to understand what you're complaining about. >> Look at the history: JDK 6 support has been extended by the community, >> led first by me and then by Andrew Byrgin at Azul. This was long >> beyond Oracle's EOL five years ago. This shows that the OpenJDK >> community has a solid track record of supporting old releases. Why >> would the LTS releases be any different? As long as people need the >> JDKs (and perhaps for longer!) they are available. > > As far as I can tell, I can't get a pre-built binary of JDK 6 or JDK 7 > from Red Hat without paying. You can get Linux binaries, kinda sorta, from fedoraproject.org and CentOS. Properly tested and TCK'd. We've been doing it a long while. I suppose you could complain that it's not "official" Red Hat, but that's more of a theoretical problem than a practical one. > I imagine the same will apply for JDK 8 when that ends public > updates. And OpenJDK hasn't been doing binaries until very recently > so that isn't helpful for judging what will happen going forward. > > Up until today there have been 28 public update releases of Oracle JDK 8: > http://www.oracle.com/technetwork/java/javase/8u-relnotes-2225394.html > These are simple upgrades that generally require no developer work to > upgrade to. Any serious company should use these to ensure they are > security-patch safe. They have all been made available for $free. > > Looking to the future, and based on promises to date, the world looks > very different. LTS from Oracle is almost certainly paid for. The > equivalent from Red Hat or Azul is also likely to be paid for. Thus > there appears to be no future official LTS release, with binaries, > publicly available, for $free. Sure, pre-built binaries need to be made available. We have been talking with all of the major players including Oracle and Adopt OpenJDK, to address this very issue. > The impact, based on current published dates, is that every > security-conscious user of Java who does not pay, would have to join > the ongoing train of releases. I hope not. I don't believe that would be practical. > Ultimately, these are the criteria I believe are needed for a successful LTS: > - a $free pre-built downloadable binary > - pre-built for multi-platforms > - from a single official location (eg. OpenJDK or Oracle) > - $free security-patch updates every 3 months or so until at least one > year after the GA of the next LTS > > I've yet to see Oracle or anyone else commit to these LTS criteria. > But I'm happy to be proved wrong. We're still talking about it. Of course, if you have no contract no-one is obliged to give you anything, but we don't want confidence in Java to falter. If you're going to insist that Oracle is the only One True Source of Java there's nothing I can do to help, but then you wouldn't be talking on this list, which is for OpenJDK. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From scolebourne at joda.org Fri Nov 10 22:02:40 2017 From: scolebourne at joda.org (Stephen Colebourne) Date: Fri, 10 Nov 2017 22:02:40 +0000 Subject: LTS for public releases In-Reply-To: References: <59d4b980-ce59-3404-2cab-1a8890766663@redhat.com> Message-ID: On 10 November 2017 at 21:35, Andrew Haley wrote: >> Ultimately, these are the criteria I believe are needed for a successful LTS: >> - a $free pre-built downloadable binary >> - pre-built for multi-platforms >> - from a single official location (eg. OpenJDK or Oracle) >> - $free security-patch updates every 3 months or so until at least one >> year after the GA of the next LTS >> >> I've yet to see Oracle or anyone else commit to these LTS criteria. >> But I'm happy to be proved wrong. > > We're still talking about it. Of course, if you have no contract > no-one is obliged to give you anything, but we don't want confidence > in Java to falter. If you're going to insist that Oracle is the only > One True Source of Java there's nothing I can do to help, but then > you wouldn't be talking on this list, which is for OpenJDK. If there is a plan behind the scenes, then good - right now I think there is a bit of a vacuum around future LTS releases which is the point I've been making. The criteria above is that the binaries need to be official. Being at OpenJDK rather than Oracle is just fine. Being at a location completely separate to OpenJDK is not fine. thanks Stephen From sritter at azul.com Sat Nov 11 14:55:41 2017 From: sritter at azul.com (Simon Ritter) Date: Sat, 11 Nov 2017 14:55:41 +0000 Subject: LTS for public releases Message-ID: I feel compelled to join this discussion... > Date: Fri, 10 Nov 2017 20:16:52 +0000 > From: Stephen Colebourne > To:jdk-dev at openjdk.java.net > Subject: Re: LTS for public releases > Message-ID: > > Content-Type: text/plain; charset="UTF-8" > > On 9 November 2017 at 16:34, Andrew Haley wrote: >> I'm finding it very hard to understand what you're complaining about. >> Look at the history: JDK 6 support has been extended by the community, >> led first by me and then by Andrew Byrgin at Azul. This was long >> beyond Oracle's EOL five years ago. This shows that the OpenJDK >> community has a solid track record of supporting old releases. Why >> would the LTS releases be any different? As long as people need the >> JDKs (and perhaps for longer!) they are available. > As far as I can tell, I can't get a pre-built binary of JDK 6 or JDK 7 > from Red Hat without paying. I imagine the same will apply for JDK 8 > when that ends public updates. And OpenJDK hasn't been doing binaries > until very recently so that isn't helpful for judging what will happen > going forward. Herein lies the crux of the problem.? Sun and subsequently Oracle have always provided the latest release of the JDK and JRE without charge for "general purpose computing" i.e., desktops and servers. Sun introduced the field-of-use restriction to protect the only area of Java that they ever made any money from: embedded and mobile. With the recent announcement of GPLv2 binaries, even that has, in effect, gone away. What I can't understand is why you would think that Oracle has a duty to provide free public updates for older versions of the platform indefinitely?? You can't get a pre-built binary of JDK 6 with the latest patches, sure.? However, JDK 6 is very nearly eleven years old and three full versions behind the current release.? It just doesn't make commercial sense to have engineers building binaries like this and doing it for free.? If you want support for an ancient version like this, I'm sorry, you have to pay for it. Otherwise, build the binary yourself (Azul backport the security fixes and upstream them to the OpenJDK6 project).? That way you only have to pay with your time. OpenJDK is free and open source, but that's free-as-in-speech, not free-as-in-beer. > > Up until today there have been 28 public update releases of Oracle JDK 8: > http://www.oracle.com/technetwork/java/javase/8u-relnotes-2225394.html > These are simple upgrades that generally require no developer work to > upgrade to. Any serious company should use these to ensure they are > security-patch safe. They have all been made available for $free. > > Looking to the future, and based on promises to date, the world looks > very different. LTS from Oracle is almost certainly paid for. The > equivalent from Red Hat or Azul is also likely to be paid for. Thus > there appears to be no future official LTS release, with binaries, > publicly available, for $free. > > The impact, based on current published dates, is that every > security-conscious user of Java who does not pay, would have to join > the ongoing train of releases. They would have to change feature > version every 6 months, because those will be the only official > security-safe binaries. For the less security-conscious, they'll just > stick on 8 or 9 and get far fewer security updates than before - > surely a step backward for Java as a platform. > > Ultimately, these are the criteria I believe are needed for a successful LTS: > - a $free pre-built downloadable binary > - pre-built for multi-platforms > - from a single official location (eg. OpenJDK or Oracle) > - $free security-patch updates every 3 months or so until at least one > year after the GA of the next LTS > > I've yet to see Oracle or anyone else commit to these LTS criteria. > But I'm happy to be proved wrong. > > Stephen From aph at redhat.com Sun Nov 12 07:51:36 2017 From: aph at redhat.com (Andrew Haley) Date: Sun, 12 Nov 2017 07:51:36 +0000 Subject: LTS for public releases In-Reply-To: References: <59d4b980-ce59-3404-2cab-1a8890766663@redhat.com> Message-ID: On 10/11/17 22:02, Stephen Colebourne wrote: > The criteria above is that the binaries need to be official. Being at > OpenJDK rather than Oracle is just fine. Being at a location > completely separate to OpenJDK is not fine. I suppose this applies to proprietary systems like Windows. If you have a GNU/Linux/etc. system you're not well advised to use a "portable" binary: you'll be using the appropriate package. (There are lots of good reasons for this; in particular, it'll have been TCKd in that environment.) So the issue of binaries boils down to Windows/Mac, I think. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From scolebourne at joda.org Sun Nov 12 10:45:30 2017 From: scolebourne at joda.org (Stephen Colebourne) Date: Sun, 12 Nov 2017 10:45:30 +0000 Subject: LTS for public releases In-Reply-To: References: Message-ID: On 11 November 2017 at 14:55, Simon Ritter wrote: > What I can't understand is why you would think that Oracle has a duty to > provide free public updates for older versions of the platform indefinitely? I haven't asked for that, nor would I. I have asked that there be $free public security updates with downloadable binaries of each LTS version until one year after the next LTS. ie. Java 8 supported until one year after Java 11. Java 11 supported until one year after Java 17 (on current LTS plans). This is pretty close to the model that Java has always had - a model that has been vital to its success. I don't think this is an unreasonable expectation of a platform used by 10+ million developers. I would also prefer that there were also 3 public updates of non-LTS releases like Java 9, 10 and 12, to allow a short migration period to the next feature release for those on the constant upgrade train, as I don't believe updating to the next version on the day of its release is viable. Stephen > You can't get a pre-built binary of JDK 6 with the latest patches, sure. > However, JDK 6 is very nearly eleven years old and three full versions > behind the current release. It just doesn't make commercial sense to have > engineers building binaries like this and doing it for free. If you want > support for an ancient version like this, I'm sorry, you have to pay for it. > Otherwise, build the binary yourself (Azul backport the security fixes and > upstream them to the OpenJDK6 project). That way you only have to pay with > your time. > > OpenJDK is free and open source, but that's free-as-in-speech, not > free-as-in-beer. >> >> >> Up until today there have been 28 public update releases of Oracle JDK 8: >> http://www.oracle.com/technetwork/java/javase/8u-relnotes-2225394.html >> These are simple upgrades that generally require no developer work to >> upgrade to. Any serious company should use these to ensure they are >> security-patch safe. They have all been made available for $free. >> >> Looking to the future, and based on promises to date, the world looks >> very different. LTS from Oracle is almost certainly paid for. The >> equivalent from Red Hat or Azul is also likely to be paid for. Thus >> there appears to be no future official LTS release, with binaries, >> publicly available, for $free. >> >> The impact, based on current published dates, is that every >> security-conscious user of Java who does not pay, would have to join >> the ongoing train of releases. They would have to change feature >> version every 6 months, because those will be the only official >> security-safe binaries. For the less security-conscious, they'll just >> stick on 8 or 9 and get far fewer security updates than before - >> surely a step backward for Java as a platform. >> >> Ultimately, these are the criteria I believe are needed for a successful >> LTS: >> - a $free pre-built downloadable binary >> - pre-built for multi-platforms >> - from a single official location (eg. OpenJDK or Oracle) >> - $free security-patch updates every 3 months or so until at least one >> year after the GA of the next LTS >> >> I've yet to see Oracle or anyone else commit to these LTS criteria. >> But I'm happy to be proved wrong. >> >> Stephen From martijnverburg at gmail.com Mon Nov 13 08:36:48 2017 From: martijnverburg at gmail.com (Martijn Verburg) Date: Mon, 13 Nov 2017 08:36:48 +0000 Subject: LTS for public releases In-Reply-To: References: Message-ID: Hi Stephen, It's our intention that the Adopt OpenJDK build farm will fill any gaps that occur here. Would be great if you and/or OpenGamma could help out with time and / or donated machines! Head on over to www.adoptopenjdk.net and you can join the mailing list and slack from there. Cheers, Martijn On 12 November 2017 at 10:45, Stephen Colebourne wrote: > On 11 November 2017 at 14:55, Simon Ritter wrote: > > What I can't understand is why you would think that Oracle has a duty to > > provide free public updates for older versions of the platform > indefinitely? > > I haven't asked for that, nor would I. > > I have asked that there be $free public security updates with > downloadable binaries of each LTS version until one year after the > next LTS. ie. Java 8 supported until one year after Java 11. Java 11 > supported until one year after Java 17 (on current LTS plans). This is > pretty close to the model that Java has always had - a model that has > been vital to its success. I don't think this is an unreasonable > expectation of a platform used by 10+ million developers. > > I would also prefer that there were also 3 public updates of non-LTS > releases like Java 9, 10 and 12, to allow a short migration period to > the next feature release for those on the constant upgrade train, as I > don't believe updating to the next version on the day of its release > is viable. > > Stephen > > > > You can't get a pre-built binary of JDK 6 with the latest patches, sure. > > However, JDK 6 is very nearly eleven years old and three full versions > > behind the current release. It just doesn't make commercial sense to > have > > engineers building binaries like this and doing it for free. If you want > > support for an ancient version like this, I'm sorry, you have to pay for > it. > > Otherwise, build the binary yourself (Azul backport the security fixes > and > > upstream them to the OpenJDK6 project). That way you only have to pay > with > > your time. > > > > OpenJDK is free and open source, but that's free-as-in-speech, not > > free-as-in-beer. > >> > >> > >> Up until today there have been 28 public update releases of Oracle JDK > 8: > >> http://www.oracle.com/technetwork/java/javase/8u- > relnotes-2225394.html > >> These are simple upgrades that generally require no developer work to > >> upgrade to. Any serious company should use these to ensure they are > >> security-patch safe. They have all been made available for $free. > >> > >> Looking to the future, and based on promises to date, the world looks > >> very different. LTS from Oracle is almost certainly paid for. The > >> equivalent from Red Hat or Azul is also likely to be paid for. Thus > >> there appears to be no future official LTS release, with binaries, > >> publicly available, for $free. > >> > >> The impact, based on current published dates, is that every > >> security-conscious user of Java who does not pay, would have to join > >> the ongoing train of releases. They would have to change feature > >> version every 6 months, because those will be the only official > >> security-safe binaries. For the less security-conscious, they'll just > >> stick on 8 or 9 and get far fewer security updates than before - > >> surely a step backward for Java as a platform. > >> > >> Ultimately, these are the criteria I believe are needed for a successful > >> LTS: > >> - a $free pre-built downloadable binary > >> - pre-built for multi-platforms > >> - from a single official location (eg. OpenJDK or Oracle) > >> - $free security-patch updates every 3 months or so until at least one > >> year after the GA of the next LTS > >> > >> I've yet to see Oracle or anyone else commit to these LTS criteria. > >> But I'm happy to be proved wrong. > >> > >> Stephen > From mark.reinhold at oracle.com Mon Nov 13 17:03:56 2017 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Mon, 13 Nov 2017 09:03:56 -0800 Subject: JEPs proposed to target JDK 10 (2017/11/2) In-Reply-To: <20171102153759.744852081@eggemoggin.niobe.net> References: <20171102153759.744852081@eggemoggin.niobe.net> Message-ID: <20171113090356.853655464@eggemoggin.niobe.net> 2017/11/2 15:37:59 -0700, mark.reinhold at oracle.com: > The following JEPs have been placed into the "Proposed to Target" state > by their owners after discussion and review: > > 304: Garbage-Collector Interface > http://openjdk.java.net/jeps/304 > > 307: Parallel Full GC for G1 > http://openjdk.java.net/jeps/307 > > 312: Thread-Local Handshakes > http://openjdk.java.net/jeps/312 > > Feedback on these proposals is more than welcome, as are reasoned > objections. If no such objections are raised by 23:00 UTC on Thursday, > 9 November, or if they're raised and then satisfactorily answered, then > per the JEP 2.0 process proposal [1] I'll target these JEPs to JDK 10. Hearing no objections to these specific JEPs, I've targeted them to JDK 10. - Mark From mark.reinhold at oracle.com Mon Nov 13 18:08:44 2017 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Mon, 13 Nov 2017 10:08:44 -0800 Subject: What kinds of changes need a JEP? In-Reply-To: <3708CA1D-374F-477C-B6F5-99BE4B54A6CD@oracle.com> References: <20171106091441.3E141FD068@eggemoggin.niobe.net> <3708CA1D-374F-477C-B6F5-99BE4B54A6CD@oracle.com> Message-ID: <20171113100844.555014842@eggemoggin.niobe.net> 2017/11/7 8:46:14 -0800, brian.goetz at oracle.com: > At the risk of being redundant, I?ll add that a JEP should be required for: > - Any language feature; > - Any change to the class file format. > > While one could argue that these are subsumed by the other criteria, > it is best to be explicit. Good point. Do you mean to allow changes to the language that are not "features" to be done without a JEP? In other words, why not say "any language change"? - Mark From mark.reinhold at oracle.com Mon Nov 13 18:11:15 2017 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Mon, 13 Nov 2017 10:11:15 -0800 Subject: What kinds of changes need a JEP? In-Reply-To: References: <20171106091441.3E141FD068@eggemoggin.niobe.net> <3708CA1D-374F-477C-B6F5-99BE4B54A6CD@oracle.com> Message-ID: <20171113101115.938921582@eggemoggin.niobe.net> 2017/11/8 14:40:28 -0800, brian.goetz at oracle.com: > I think this additional constraint is putting the dependency in the wrong > direction. > > JEP is for something that is big enough, risky enough, or visible enough. > > Many things that are big enough or risky enough ALSO merit work outside of > the mainline, but that?s not what makes them JEP-worthy; it?s the size / risk > / visibility. The relationship is correlative, not causative. Agreed. - Mark From mark.reinhold at oracle.com Mon Nov 13 18:18:09 2017 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Mon, 13 Nov 2017 10:18:09 -0800 Subject: What kinds of changes need a JEP? In-Reply-To: References: <20171106091441.3E141FD068@eggemoggin.niobe.net> <3708CA1D-374F-477C-B6F5-99BE4B54A6CD@oracle.com> Message-ID: <20171113101809.355469813@eggemoggin.niobe.net> 2017/11/8 17:58:57 -0800, david.holmes at oracle.com: > On 9/11/2017 4:58 AM, Volker Simonis wrote: >> ... >> >> This would make it clear that a JEP is a more heavy-weight project >> than a simple enhancement and that we expect a fully working and >> tested implementation before we consider to integrate it into the >> "always feature complete" main line. It would also keep people from >> "cheating" by implementing parts of a JEP incrementally in the main >> line. > > It is perfectly reasonable for JEP work to identify cleanups and > refactorings that aid the JEP work, but which can be putback to the > mainline as a standalone change. Without such enabling changes we would > greatly increase the difficulty of integrating the JEP work when it is > ready. I don't consider this "cheating". Agreed. If a preparatory change for a JEP can be justified on its own, without a separate JEP, then you can merge it before that JEP is targeted. - Mark From brian.goetz at oracle.com Mon Nov 13 18:41:36 2017 From: brian.goetz at oracle.com (Brian Goetz) Date: Mon, 13 Nov 2017 18:41:36 +0000 Subject: What kinds of changes need a JEP? In-Reply-To: <20171113100844.555014842@eggemoggin.niobe.net> References: <20171106091441.3E141FD068@eggemoggin.niobe.net> <3708CA1D-374F-477C-B6F5-99BE4B54A6CD@oracle.com> <20171113100844.555014842@eggemoggin.niobe.net> Message-ID: <8B195B10-B285-4507-95E9-F95FEEB625CC@oracle.com> I was thinking about drawing the distinction beteeen language spec changes that are purely spec bug fixes -- which are technically language changes. Sent from my MacBook Wheel > On Nov 13, 2017, at 6:08 PM, mark.reinhold at oracle.com wrote: > > 2017/11/7 8:46:14 -0800, brian.goetz at oracle.com: >> At the risk of being redundant, I?ll add that a JEP should be required for: >> - Any language feature; >> - Any change to the class file format. >> >> While one could argue that these are subsumed by the other criteria, >> it is best to be explicit. > > Good point. > > Do you mean to allow changes to the language that are not "features" > to be done without a JEP? In other words, why not say "any language > change"? > > - Mark From mark.reinhold at oracle.com Mon Nov 13 18:48:51 2017 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Mon, 13 Nov 2017 10:48:51 -0800 Subject: What kinds of changes need a JEP? In-Reply-To: <8B195B10-B285-4507-95E9-F95FEEB625CC@oracle.com> References: <20171106091441.3E141FD068@eggemoggin.niobe.net> <3708CA1D-374F-477C-B6F5-99BE4B54A6CD@oracle.com> <20171113100844.555014842@eggemoggin.niobe.net> <8B195B10-B285-4507-95E9-F95FEEB625CC@oracle.com> Message-ID: <20171113104851.141091447@eggemoggin.niobe.net> 2017/11/13 10:41:36 -0800, brian.goetz at oracle.com: > I was thinking about drawing the distinction beteeen language spec > changes that are purely spec bug fixes -- which are technically > language changes. Wouldn't the same be true of bug fixes to the class-file specification (i.e., the JVMS)? - Mark From mark.reinhold at oracle.com Mon Nov 13 21:05:50 2017 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Mon, 13 Nov 2017 13:05:50 -0800 Subject: JEPs proposed to target JDK 10 (2017/11/2) In-Reply-To: References: <20171102153759.744852081@eggemoggin.niobe.net> <1D08A688-BD7C-497A-A806-95B352AB6B4A@oracle.com> Message-ID: <20171113130550.848390010@eggemoggin.niobe.net> 2017/11/8 9:07:18 -0800, volker.simonis at gmail.com: > ... > > @Brian: You wrote: "For nontrivial projects, you are expected to work > iteratively, progressively refining the design, interface, > implementation, and test suite together, outside of the main code > line, until it is ready, and then ? and only then ? do you start the > process of proposing to target." That's actually exactly how I > understand the process as well. However, looking at the reality, how > many of the JEPs (except Jigsaw and some ports) have been developed in > their own repositories before they have been integrated into the main > line? Many other JEPs were, or are being, developed in their own forests or repositories. Off the top of my head: 104: Annotations on Java Types 109: Enhance Core Libraries with Lambda 126: Lambda Expressions & Virtual Extension Methods 127: Improve Locale Data Packaging and Adopt Unicode CLDR Data 128: Unicode BCP 47 Locale Matching 138: Autoconf-Based Build System 139: Enhance javac to Improve Build Speed 150: Date & Time API 169: Value Objects 174: Nashorn JavaScript Engine 189: Shenandoah: An Ultra-Low-Pause-Time Garbage Collector 191: Foreign Function Interface 199: Smart Java Compilation, Phase Two 217: Annotations Pipeline 2.0 218: Generics over Primitive Types 222: jshell: The Java Shell (Read-Eval-Print Loop) 223: New Version-String Scheme 258: HarfBuzz Font-Layout Engine 265: Marlin Graphics Renderer 286: Local-Variable Type Inference 300: Augment Use-Site Variance with Declaration-Site Defaults 301: Enhanced Enums 302: Lambda Leftovers 303: Intrinsics for the LDC and INVOKEDYNAMIC Instructions 305: Pattern Matching 309: Dynamic Class-File Constants Quite a few other, typically smaller, JEPs were, or are being, developed in their own branches in a sandbox forest/repository [1]. > We have a serious process/infrastructure problem because creating a > new clone is a much to heavyweight operation What do you mean by "heavyweight"? Sure, it takes more disk space than we'd like, but even most laptops these days are big enough to hold a handful of forests/repositories (if not dozens), and fast enough that cloning another one is no big deal. > and branches are not yet > a generally accepted "working model" in the OpenJDK. We can almost certainly make more and better use of branches, or perhaps bookmarks, going forward, and now that we have a consolidated repository I suspect that various interested contributors will look more closely at that. > Let alone the > fact of testing such a clone/branch (i.e. JPRT/Mach5 for the insiders > :) I'm also not sure if other tools like JBS work well with branches > for example. Finally, it is currently much easier to attract the > attention of a potential Oracle reviewer/sponsor when you subdivide > your JEP into small sub features. I wouldn't call that cheating - it's > just the only viable way to get your work done if you're an external > contributor. > > So, to sum it up, I think we have a well defined and sound process but > we really need the infrastructure and tools to execute it! I agree that it'd be nice to have better infrastructure and tools, and as you know a number of efforts are under way on that front. In the meantime, however, if you have a question about a Proposed-to-Target JEP, and the answer to that question would be obvious if we had better infrastructure and tools, then please just ask the question of the JEP's owner. Even perfect infrastructure and tools would be no substitute for conversation and collaboration, nor for the resulting trust that builds up over time. - Mark [1] http://cr.openjdk.java.net/~chegar/docs/sandbox.html From mark.reinhold at oracle.com Mon Nov 13 21:45:24 2017 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Mon, 13 Nov 2017 13:45:24 -0800 Subject: What kinds of changes need a JEP? In-Reply-To: <699ce6e7-bc8f-de17-64ea-f708e2f2c054@oracle.com> References: <20171106091441.3E141FD068@eggemoggin.niobe.net> <699ce6e7-bc8f-de17-64ea-f708e2f2c054@oracle.com> Message-ID: <20171113134524.185408823@eggemoggin.niobe.net> 2017/11/7 4:38:02 -0800, maurizio.cimadamore at oracle.com: > Many thumbs up on this Mark! Thanks for taking the time to put together > this revised proposal. > > As a langtools hacker, I've often felt the pain associated with JEP > processes for what, in my mental model, was non-JEP work - an example of > such non-JEPs I came across over the last few years in langtools-land > are, IMHO: > > http://openjdk.java.net/jeps/215 > > http://openjdk.java.net/jeps/217 > > I believe this work would classify now as regular javac enhancements and > would, therefore not be subject to the JEP process, which IMHO is good > news (not because I hate the JEP process, but because I hate abusing it > :-)). These two JEPs, along with JEP 304 (GC Interface) which Roman mentions nearby, strike me as interesting edge cases. The text in each of these JEPs describes the motivation, background, and design of each change. Wouldn't that be useful to other developers who work on the code, both present and future, even though these changes are strictly internal? The other typical places for such information are wiki pages, long e-mail messages, and JBS issues. These are harder to find, and in some cases far less permanent, than JEPs. Perhaps another criterion should be: - It has a non-trivial design (although maybe that's just another sense of "significant"). What do you think? - Mark From michael.rasmussen at zeroturnaround.com Tue Nov 14 00:01:56 2017 From: michael.rasmussen at zeroturnaround.com (Michael Rasmussen) Date: Tue, 14 Nov 2017 02:01:56 +0200 Subject: java.bytecode (or similar) module? Message-ID: Hi, The new release cadence means a new class file version every 6 months [1]. This means framework parsing/generating bytecode (or relying on libraries like ASM), will always be playing catch-up, or waiting for ASM etc to be updated. Or alternatively, for frameworks slow to update, users of those frameworks will have to explicitly override the versions of its dependencies in their build scrips, hoping that ASM n+1 is binary compatible with ASM n. Previously, with the old release model, a new class file version every few years wasn't that big a hassle, but having to do this every 6 months, in order to ensure that your version of ASM doesn't throws exception because the class file version is now n+1, is going to be tedious. So have there been any talks about (or any concrete plans to) create a java.bytecode module, that is able to parse/generate bytecode for the release's class file version? Meaning a library/framework could simply depend on this module, and thus have an API available that was able to parse the bytecode, and would also work and be able to parse class files running on the next java release. Yes, I know usage of such an API would have to be written somewhat defensively, what should I do if I get the bytes for a value-type? Personally I would prefer that the developer can decide this; if I'm just scanning class files for annotations on methods, it doest't matter much to me if a method uses a feature introduced in Java 12 or only use Java 6 stuff. Of course, there would be a constant overhead of keeping it up-to-date for every single JDK release; but some of that cost is there already. There are currently multiple such private APIs in the JDK, ranging from a shaded ASM used in lambdas, to the API used in Proxy, reflection, javac, javap, etc. Adding a java.bytecode module (or package in java.base), the code could then be reused, and thus help clean up the existing private APIs. Kind regards Michael Rasmussen [1] https://twitter.com/mreinhold/status/926135074780692480 From fridrich.strba at suse.com Tue Nov 14 07:36:22 2017 From: fridrich.strba at suse.com (Fridrich Strba) Date: Tue, 14 Nov 2017 08:36:22 +0100 Subject: java.bytecode (or similar) module? In-Reply-To: References: Message-ID: <585426c2-7111-6ec0-9ce3-ac7e02f67477@suse.com> This was actually something puzzling me in the whole versioning discussion: why on the earth increasing every 6 months a language source and target levels unless some new features require it. Especially if the version has 4 digits and one could intelligently use them. But did not want to add my grain of salt into the cacophony. Cheers F. On 14/11/17 01:01, Michael Rasmussen wrote: > The new release cadence means a new class file version every 6 months > [1]. This means framework parsing/generating bytecode (or relying on > libraries like ASM), will always be playing catch-up, or waiting for > ASM etc to be updated. Or alternatively, for frameworks slow to > update, users of those frameworks will have to explicitly override the > versions of its dependencies in their build scrips, hoping that ASM > n+1 is binary compatible with ASM n. > > Previously, with the old release model, a new class file version every > few years wasn't that big a hassle, but having to do this every 6 > months, in order to ensure that your version of ASM doesn't throws > exception because the class file version is now n+1, is going to be > tedious. > > So have there been any talks about (or any concrete plans to) create a > java.bytecode module, that is able to parse/generate bytecode for the > release's class file version? Meaning a library/framework could simply > depend on this module, and thus have an API available that was able to > parse the bytecode, and would also work and be able to parse class > files running on the next java release. > > Yes, I know usage of such an API would have to be written somewhat > defensively, what should I do if I get the bytes for a value-type? > Personally I would prefer that the developer can decide this; if I'm > just scanning class files for annotations on methods, it doest't > matter much to me if a method uses a feature introduced in Java 12 or > only use Java 6 stuff. > > Of course, there would be a constant overhead of keeping it up-to-date > for every single JDK release; but some of that cost is there already. > There are currently multiple such private APIs in the JDK, ranging > from a shaded ASM used in lambdas, to the API used in Proxy, > reflection, javac, javap, etc. Adding a java.bytecode module (or > package in java.base), the code could then be reused, and thus help > clean up the existing private APIs. > > Kind regards > Michael Rasmussen > > [1] https://twitter.com/mreinhold/status/926135074780692480 > From dalibor.topic at oracle.com Tue Nov 14 08:39:51 2017 From: dalibor.topic at oracle.com (dalibor topic) Date: Tue, 14 Nov 2017 09:39:51 +0100 Subject: java.bytecode (or similar) module? In-Reply-To: <585426c2-7111-6ec0-9ce3-ac7e02f67477@suse.com> References: <585426c2-7111-6ec0-9ce3-ac7e02f67477@suse.com> Message-ID: On 14.11.2017 08:36, Fridrich Strba wrote: > This was actually something puzzling me in the whole versioning > discussion: why on the earth increasing every 6 months a language source > and target levels unless some new features require it. Especially if the > version has 4 digits and one could intelligently use them. But did not > want to add my grain of salt into the cacophony. It should be simpler to increase them on a regular cadence. That way, everyone can plan for it, and have about 6 months to adjust. In the opportunistic case, it could be a much shorter runway if a language or VM change requiring class file format changes and consecutively a bump in the language/class file versions comes in late during the development of a new release. cheers, dalibor topic -- Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile: +491737185961 ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher Oracle is committed to developing practices and products that help protect the environment From volker.simonis at gmail.com Tue Nov 14 08:43:56 2017 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 14 Nov 2017 09:43:56 +0100 Subject: java.bytecode (or similar) module? In-Reply-To: References: Message-ID: Hi Michael, I think what you propose is a good idea. I actually already thought about proposing something similar :) Providing a java.bytecode module (i.e. in the "java" package/namespace) is probably not that easy because it would require specification through the JCP. So it may even require its own JSR? I think as an interim solution it could already help if the version of ASM, which as you correctly noticed, is already included in the JDK anyway, would be publicly exported. In the medium term it could be made an incubator module and then finally standardized. Let's see what other (Alan, Remi ?) think about this. Regards, Volker On Tue, Nov 14, 2017 at 1:01 AM, Michael Rasmussen wrote: > Hi, > > The new release cadence means a new class file version every 6 months > [1]. This means framework parsing/generating bytecode (or relying on > libraries like ASM), will always be playing catch-up, or waiting for > ASM etc to be updated. Or alternatively, for frameworks slow to > update, users of those frameworks will have to explicitly override the > versions of its dependencies in their build scrips, hoping that ASM > n+1 is binary compatible with ASM n. > > Previously, with the old release model, a new class file version every > few years wasn't that big a hassle, but having to do this every 6 > months, in order to ensure that your version of ASM doesn't throws > exception because the class file version is now n+1, is going to be > tedious. > > So have there been any talks about (or any concrete plans to) create a > java.bytecode module, that is able to parse/generate bytecode for the > release's class file version? Meaning a library/framework could simply > depend on this module, and thus have an API available that was able to > parse the bytecode, and would also work and be able to parse class > files running on the next java release. > > Yes, I know usage of such an API would have to be written somewhat > defensively, what should I do if I get the bytes for a value-type? > Personally I would prefer that the developer can decide this; if I'm > just scanning class files for annotations on methods, it doest't > matter much to me if a method uses a feature introduced in Java 12 or > only use Java 6 stuff. > > Of course, there would be a constant overhead of keeping it up-to-date > for every single JDK release; but some of that cost is there already. > There are currently multiple such private APIs in the JDK, ranging > from a shaded ASM used in lambdas, to the API used in Proxy, > reflection, javac, javap, etc. Adding a java.bytecode module (or > package in java.base), the code could then be reused, and thus help > clean up the existing private APIs. > > Kind regards > Michael Rasmussen > > [1] https://twitter.com/mreinhold/status/926135074780692480 From brian.goetz at oracle.com Tue Nov 14 08:55:52 2017 From: brian.goetz at oracle.com (Brian Goetz) Date: Tue, 14 Nov 2017 08:55:52 +0000 Subject: java.bytecode (or similar) module? In-Reply-To: References: Message-ID: <8230F6AE-6271-4E05-A21D-4789A7192622@oracle.com> The ASM folks are deeply involved in all projects that entail bytecode changes. Ensuring that ASM and other such tools are prepared for classfile changes with enough time to update is an important aspect of running such a project and determining if it is ready to propose to target. Sent from my MacBook Wheel > On Nov 14, 2017, at 8:43 AM, Volker Simonis wrote: > > Hi Michael, > > I think what you propose is a good idea. I actually already thought > about proposing something similar :) > > Providing a java.bytecode module (i.e. in the "java" > package/namespace) is probably not that easy because it would require > specification through the JCP. So it may even require its own JSR? > > I think as an interim solution it could already help if the version of > ASM, which as you correctly noticed, is already included in the JDK > anyway, would be publicly exported. In the medium term it could be > made an incubator module and then finally standardized. > > Let's see what other (Alan, Remi ?) think about this. > > Regards, > Volker > > > On Tue, Nov 14, 2017 at 1:01 AM, Michael Rasmussen > wrote: >> Hi, >> >> The new release cadence means a new class file version every 6 months >> [1]. This means framework parsing/generating bytecode (or relying on >> libraries like ASM), will always be playing catch-up, or waiting for >> ASM etc to be updated. Or alternatively, for frameworks slow to >> update, users of those frameworks will have to explicitly override the >> versions of its dependencies in their build scrips, hoping that ASM >> n+1 is binary compatible with ASM n. >> >> Previously, with the old release model, a new class file version every >> few years wasn't that big a hassle, but having to do this every 6 >> months, in order to ensure that your version of ASM doesn't throws >> exception because the class file version is now n+1, is going to be >> tedious. >> >> So have there been any talks about (or any concrete plans to) create a >> java.bytecode module, that is able to parse/generate bytecode for the >> release's class file version? Meaning a library/framework could simply >> depend on this module, and thus have an API available that was able to >> parse the bytecode, and would also work and be able to parse class >> files running on the next java release. >> >> Yes, I know usage of such an API would have to be written somewhat >> defensively, what should I do if I get the bytes for a value-type? >> Personally I would prefer that the developer can decide this; if I'm >> just scanning class files for annotations on methods, it doest't >> matter much to me if a method uses a feature introduced in Java 12 or >> only use Java 6 stuff. >> >> Of course, there would be a constant overhead of keeping it up-to-date >> for every single JDK release; but some of that cost is there already. >> There are currently multiple such private APIs in the JDK, ranging >> from a shaded ASM used in lambdas, to the API used in Proxy, >> reflection, javac, javap, etc. Adding a java.bytecode module (or >> package in java.base), the code could then be reused, and thus help >> clean up the existing private APIs. >> >> Kind regards >> Michael Rasmussen >> >> [1] https://twitter.com/mreinhold/status/926135074780692480 From forax at univ-mlv.fr Tue Nov 14 09:02:56 2017 From: forax at univ-mlv.fr (Remi Forax) Date: Tue, 14 Nov 2017 10:02:56 +0100 (CET) Subject: java.bytecode (or similar) module? In-Reply-To: References: <585426c2-7111-6ec0-9ce3-ac7e02f67477@suse.com> Message-ID: <1061110364.762532.1510650176996.JavaMail.zimbra@u-pem.fr> with my ASM hat, as dalibor said, we are changing the cadence. Specifically, - since ASM4, ASM is fully backward compatible, - we are also moving toward continuous deployment since September using more modern development tools, git, gradle, gitlab-ci and adding a bunch of new tests - upcoming VM spec changes are developed in different branches [1, 2, 3] and we try to follow all VM specs modification proposed by the different OpenJDK projects, i'm personally an expert for the project Amber and Valhalla. regards, R?mi [1] https://gitlab.ow2.org/asm/asm/tree/CONDY [2] https://gitlab.ow2.org/asm/asm/tree/NEST_MATES [3] https://gitlab.ow2.org/asm/asm/tree/MINIMAL_VALUE_TYPE ----- Mail original ----- > De: "dalibor topic" > ?: "jdk-dev" > Envoy?: Mardi 14 Novembre 2017 09:39:51 > Objet: Re: java.bytecode (or similar) module? > On 14.11.2017 08:36, Fridrich Strba wrote: >> This was actually something puzzling me in the whole versioning >> discussion: why on the earth increasing every 6 months a language source >> and target levels unless some new features require it. Especially if the >> version has 4 digits and one could intelligently use them. But did not >> want to add my grain of salt into the cacophony. > > It should be simpler to increase them on a regular cadence. > > That way, everyone can plan for it, and have about 6 months to adjust. > In the opportunistic case, it could be a much shorter runway if a > language or VM change requiring class file format changes and > consecutively a bump in the language/class file versions comes in late > during the development of a new release. > > cheers, > dalibor topic > -- > Dalibor Topic | Principal Product Manager > Phone: +494089091214 | Mobile: +491737185961 > > > ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg > > ORACLE Deutschland B.V. & Co. KG > Hauptverwaltung: Riesstr. 25, D-80992 M?nchen > Registergericht: Amtsgericht M?nchen, HRA 95603 > > Komplement?rin: ORACLE Deutschland Verwaltung B.V. > Hertogswetering 163/167, 3543 AS Utrecht, Niederlande > Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 > Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher > > Oracle is committed to developing > practices and products that help protect the environment From volker.simonis at gmail.com Tue Nov 14 09:11:44 2017 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 14 Nov 2017 09:11:44 +0000 Subject: java.bytecode (or similar) module? In-Reply-To: <8230F6AE-6271-4E05-A21D-4789A7192622@oracle.com> References: <8230F6AE-6271-4E05-A21D-4789A7192622@oracle.com> Message-ID: Brian Goetz schrieb am Di. 14. Nov. 2017 um 09:55: > The ASM folks are deeply involved in all projects that entail bytecode > changes. So then what's the rational to not export the ASM which is included in the JDK anyway? I mean exporting from a jdk.xxx module, not from a standard module. Wouldn't that be useful if it is there anyway? Ensuring that ASM and other such tools are prepared for classfile changes > with enough time to update is an Importanz aspect of running such a project > and determining if it is ready to propose to target. > > Sent from my MacBook Wheel > > > On Nov 14, 2017, at 8:43 AM, Volker Simonis > wrote: > > > > Hi Michael, > > > > I think what you propose is a good idea. I actually already thought > > about proposing something similar :) > > > > Providing a java.bytecode module (i.e. in the "java" > > package/namespace) is probably not that easy because it would require > > specification through the JCP. So it may even require its own JSR? > > > > I think as an interim solution it could already help if the version of > > ASM, which as you correctly noticed, is already included in the JDK > > anyway, would be publicly exported. In the medium term it could be > > made an incubator module and then finally standardized. > > > > Let's see what other (Alan, Remi ?) think about this. > > > > Regards, > > Volker > > > > > > On Tue, Nov 14, 2017 at 1:01 AM, Michael Rasmussen > > wrote: > >> Hi, > >> > >> The new release cadence means a new class file version every 6 months > >> [1]. This means framework parsing/generating bytecode (or relying on > >> libraries like ASM), will always be playing catch-up, or waiting for > >> ASM etc to be updated. Or alternatively, for frameworks slow to > >> update, users of those frameworks will have to explicitly override the > >> versions of its dependencies in their build scrips, hoping that ASM > >> n+1 is binary compatible with ASM n. > >> > >> Previously, with the old release model, a new class file version every > >> few years wasn't that big a hassle, but having to do this every 6 > >> months, in order to ensure that your version of ASM doesn't throws > >> exception because the class file version is now n+1, is going to be > >> tedious. > >> > >> So have there been any talks about (or any concrete plans to) create a > >> java.bytecode module, that is able to parse/generate bytecode for the > >> release's class file version? Meaning a library/framework could simply > >> depend on this module, and thus have an API available that was able to > >> parse the bytecode, and would also work and be able to parse class > >> files running on the next java release. > >> > >> Yes, I know usage of such an API would have to be written somewhat > >> defensively, what should I do if I get the bytes for a value-type? > >> Personally I would prefer that the developer can decide this; if I'm > >> just scanning class files for annotations on methods, it doest't > >> matter much to me if a method uses a feature introduced in Java 12 or > >> only use Java 6 stuff. > >> > >> Of course, there would be a constant overhead of keeping it up-to-date > >> for every single JDK release; but some of that cost is there already. > >> There are currently multiple such private APIs in the JDK, ranging > >> from a shaded ASM used in lambdas, to the API used in Proxy, > >> reflection, javac, javap, etc. Adding a java.bytecode module (or > >> package in java.base), the code could then be reused, and thus help > >> clean up the existing private APIs. > >> > >> Kind regards > >> Michael Rasmussen > >> > >> [1] https://twitter.com/mreinhold/status/926135074780692480 > > From forax at univ-mlv.fr Tue Nov 14 10:38:34 2017 From: forax at univ-mlv.fr (Remi Forax) Date: Tue, 14 Nov 2017 11:38:34 +0100 (CET) Subject: java.bytecode (or similar) module? In-Reply-To: References: <8230F6AE-6271-4E05-A21D-4789A7192622@oracle.com> Message-ID: <1010944624.833465.1510655914207.JavaMail.zimbra@u-pem.fr> Hi Volker, the easy anwser if the JDK do not include all packages of ASM and is patched version of ASM. In details, let me try to explain, how it works currently, the JDK version used internally: - is a parts of ASM, some packages are not present (asm.tree, asm.tree.analysis, asm.xml) because the JDK mostly uses ASM to read/write bytecodes, not to perform analysis on it. - is an older version than the current version of ASM, the process to include a version of the ASM in the JDK requires a released version of ASM and takes some times so an internal version do not contains all bug fixes already in the master of ASM. Bug fixes from ASM may not be needed because the JDK only uses some parts of ASM. We release a major version of ASM the weekend (all developers of ASM have a real job) just after the GA of the JDK. So a release of the JDK never contains a released version of ASM, usually it takes one or two updates. - a newer version compared to ASM, because the internal version is patched to introduce bytecode changes that will be speced in the future. Branch of ASM that contains upcoming changes are always based on drafts of the spec, so changes in branches appears later and are we hope cleaner because it's easier to implement a feature when you have a spec (even if it's a draft). regards, R?mi ----- Mail original ----- > De: "Volker Simonis" > ?: "Brian Goetz" > Cc: "jdk-dev" > Envoy?: Mardi 14 Novembre 2017 10:11:44 > Objet: Re: java.bytecode (or similar) module? > Brian Goetz schrieb am Di. 14. Nov. 2017 um 09:55: > >> The ASM folks are deeply involved in all projects that entail bytecode >> changes. > > > So then what's the rational to not export the ASM which is included in the > JDK anyway? I mean exporting from a jdk.xxx module, not from a standard > module. Wouldn't that be useful if it is there anyway? > > > Ensuring that ASM and other such tools are prepared for classfile changes >> with enough time to update is an Importanz aspect of running such a project >> and determining if it is ready to propose to target. >> >> Sent from my MacBook Wheel >> >> > On Nov 14, 2017, at 8:43 AM, Volker Simonis >> wrote: >> > >> > Hi Michael, >> > >> > I think what you propose is a good idea. I actually already thought >> > about proposing something similar :) >> > >> > Providing a java.bytecode module (i.e. in the "java" >> > package/namespace) is probably not that easy because it would require >> > specification through the JCP. So it may even require its own JSR? >> > >> > I think as an interim solution it could already help if the version of >> > ASM, which as you correctly noticed, is already included in the JDK >> > anyway, would be publicly exported. In the medium term it could be >> > made an incubator module and then finally standardized. >> > >> > Let's see what other (Alan, Remi ?) think about this. >> > >> > Regards, >> > Volker >> > >> > >> > On Tue, Nov 14, 2017 at 1:01 AM, Michael Rasmussen >> > wrote: >> >> Hi, >> >> >> >> The new release cadence means a new class file version every 6 months >> >> [1]. This means framework parsing/generating bytecode (or relying on >> >> libraries like ASM), will always be playing catch-up, or waiting for >> >> ASM etc to be updated. Or alternatively, for frameworks slow to >> >> update, users of those frameworks will have to explicitly override the >> >> versions of its dependencies in their build scrips, hoping that ASM >> >> n+1 is binary compatible with ASM n. >> >> >> >> Previously, with the old release model, a new class file version every >> >> few years wasn't that big a hassle, but having to do this every 6 >> >> months, in order to ensure that your version of ASM doesn't throws >> >> exception because the class file version is now n+1, is going to be >> >> tedious. >> >> >> >> So have there been any talks about (or any concrete plans to) create a >> >> java.bytecode module, that is able to parse/generate bytecode for the >> >> release's class file version? Meaning a library/framework could simply >> >> depend on this module, and thus have an API available that was able to >> >> parse the bytecode, and would also work and be able to parse class >> >> files running on the next java release. >> >> >> >> Yes, I know usage of such an API would have to be written somewhat >> >> defensively, what should I do if I get the bytes for a value-type? >> >> Personally I would prefer that the developer can decide this; if I'm >> >> just scanning class files for annotations on methods, it doest't >> >> matter much to me if a method uses a feature introduced in Java 12 or >> >> only use Java 6 stuff. >> >> >> >> Of course, there would be a constant overhead of keeping it up-to-date >> >> for every single JDK release; but some of that cost is there already. >> >> There are currently multiple such private APIs in the JDK, ranging >> >> from a shaded ASM used in lambdas, to the API used in Proxy, >> >> reflection, javac, javap, etc. Adding a java.bytecode module (or >> >> package in java.base), the code could then be reused, and thus help >> >> clean up the existing private APIs. >> >> >> >> Kind regards >> >> Michael Rasmussen >> >> >> >> [1] https://twitter.com/mreinhold/status/926135074780692480 >> From dalibor.topic at oracle.com Tue Nov 14 10:53:14 2017 From: dalibor.topic at oracle.com (dalibor topic) Date: Tue, 14 Nov 2017 11:53:14 +0100 Subject: java.bytecode (or similar) module? In-Reply-To: <1010944624.833465.1510655914207.JavaMail.zimbra@u-pem.fr> References: <8230F6AE-6271-4E05-A21D-4789A7192622@oracle.com> <1010944624.833465.1510655914207.JavaMail.zimbra@u-pem.fr> Message-ID: <0948a2f5-3e3b-5774-d0d2-7dc8461f0ed1@oracle.com> On 14.11.2017 11:38, Remi Forax wrote: > Hi Volker, > the easy anwser if the JDK do not include all packages of ASM Yeah - Generally speaking, this is a way to reduce the potential maintenance surface of baked in libraries, since they are baked in for a specific, internal reason, rather than to be exposed externally. In addition, as part of baking in a (part of a) third party library, you'd typically want to change the package names to eliminate the potential for conflicts on the classpath/modulepath, which makes it not very useful to expose as a public API (it was org.openjdk.org.objectweb.asm at one point in time for the internal ASM), as it requires users to adjust their code to work with the 'internal' version, rather than the actual one. cheers, dalibor topic -- Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile: +491737185961 ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher Oracle is committed to developing practices and products that help protect the environment From Alan.Bateman at oracle.com Tue Nov 14 11:22:55 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 14 Nov 2017 11:22:55 +0000 Subject: java.bytecode (or similar) module? In-Reply-To: References: <8230F6AE-6271-4E05-A21D-4789A7192622@oracle.com> Message-ID: <425e043f-a054-61dd-ba92-17b5841cb170@oracle.com> On 14/11/2017 09:11, Volker Simonis wrote: > : > So then what's the rational to not export the ASM which is included in the > JDK anyway? I mean exporting from a jdk.xxx module, not from a standard > module. Wouldn't that be useful if it is there anyway? > java.base exporting a non-standard API would be very problematic. It immediately falls foul of the design principles laid out in JEP 200. Moving it to another module isn't going to work either as java.base cannot depend on other modules. Doing so would introduce a circular dependency too. Additionally,? as R?mi notes, it's not the full API, it is instead a re-packaged and often modified version of ASM N-1. I don't think we want anything outside of the JDK modules depending on that. Going forward then maybe the JDK will move to using something else. -Alan From volker.simonis at gmail.com Tue Nov 14 13:55:57 2017 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 14 Nov 2017 14:55:57 +0100 Subject: java.bytecode (or similar) module? In-Reply-To: <425e043f-a054-61dd-ba92-17b5841cb170@oracle.com> References: <8230F6AE-6271-4E05-A21D-4789A7192622@oracle.com> <425e043f-a054-61dd-ba92-17b5841cb170@oracle.com> Message-ID: Remi, Dalibor, Alan, thanks a lot for the explanations. That all sounds reasonable. Regards, Volker On Tue, Nov 14, 2017 at 12:22 PM, Alan Bateman wrote: > On 14/11/2017 09:11, Volker Simonis wrote: >> >> : >> So then what's the rational to not export the ASM which is included in the >> JDK anyway? I mean exporting from a jdk.xxx module, not from a standard >> module. Wouldn't that be useful if it is there anyway? >> > java.base exporting a non-standard API would be very problematic. It > immediately falls foul of the design principles laid out in JEP 200. Moving > it to another module isn't going to work either as java.base cannot depend > on other modules. Doing so would introduce a circular dependency too. > > Additionally, as R?mi notes, it's not the full API, it is instead a > re-packaged and often modified version of ASM N-1. I don't think we want > anything outside of the JDK modules depending on that. Going forward then > maybe the JDK will move to using something else. > > -Alan From volker.simonis at gmail.com Tue Nov 14 17:55:38 2017 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 14 Nov 2017 18:55:38 +0100 Subject: Status of "Incubator Modules" (JEP 11) Message-ID: Hi, the Goals section of the "Incubator Modules" JEP [1,2] reads as follows: "The incubation lifetime of an API is limited: It is expected that the API will either be standardized or otherwise made final in the next release, or else removed." OpenJDK 9 was shipped with the httpclient incubator module and I havn't seen any effort to standardize this API in Java 10/18.3. Does this mean that the new httpclient library will be removed from OpenJDK 10/18.3? Or should we better revise JEP 11 and rephrase the Goals section to something like: "The incubation lifetime of an API is limited: It is expected that the API will either be standardized or otherwise made final in the next LTS release, or else removed." Regards, Volker [1] http://openjdk.java.net/jeps/11 [2] https://bugs.openjdk.java.net/browse/JDK-8169768 From chris.hegarty at oracle.com Tue Nov 14 18:33:05 2017 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 14 Nov 2017 18:33:05 +0000 Subject: Status of "Incubator Modules" (JEP 11) In-Reply-To: References: Message-ID: <7e26ae7b-7717-4254-871c-6a04b8edcc38@oracle.com> Volker, On 14/11/17 17:55, Volker Simonis wrote: > Hi, > > the Goals section of the "Incubator Modules" JEP [1,2] reads as follows: > > "The incubation lifetime of an API is limited: It is expected that the > API will either be standardized or otherwise made final in the next > release, or else removed." JEP 11 predates the shorter release cadence, hence the current wording. While not strictly incorrect, and in light of the shorter cadence, this wording could be better. > OpenJDK 9 was shipped with the httpclient incubator module and I > havn't seen any effort to standardize this API in Java 10/18.3. While there are no plans to standardize this particular API in Java 10, there is ongoing work to move it towards standardization. This work has been happening in the JDK 10 sandbox, and recently moved over to the new JDK sandbox ( on the http-client-branch [1] ). > Does this mean that the new httpclient library will be removed from > OpenJDK 10/18.3? It is my understanding that the folk working on this API are planning to "refresh" the current incubator code in 10, based on the work in the sandbox. Expect to see announcement to this effect on net-dev shortly. > Or should we better revise JEP 11 and rephrase the > Goals section to something like: > > "The incubation lifetime of an API is limited: It is expected that > the API will either be standardized or otherwise made final in the > next LTS release, or else removed." I don't think that it is appropriate, or even necessary, to tie incubating features to LTS releases. I will do a full review of JEP 11 and reply shortly. -Chris [1] http://hg.openjdk.java.net/jdk/sandbox/branches From aph at redhat.com Wed Nov 15 16:29:42 2017 From: aph at redhat.com (Andrew Haley) Date: Wed, 15 Nov 2017 16:29:42 +0000 Subject: Running and building with NetBeans: a plea for help Message-ID: <729a403d-c5c7-6140-ec1d-eb1c887a23ed@redhat.com> I've been trying to get the netbeans project at jdk/make/jdk/netbeans/jdk working. It all builds, but I can't get tests to run. Current output is: ant -f /scratch/jdk/make/jdk/netbeans/j2se jtreg /scratch/jdk/make/jdk/netbeans/common/shared.xml:266: No tests selected I don't know what to do, and I've been puzzling for days. If anyone here uses netbeans and jtreg, please send me your build.properties (or any other information) so I can try to figure out what I'm doing wrong. Thanks. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From Roger.Riggs at Oracle.com Wed Nov 15 20:13:58 2017 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Wed, 15 Nov 2017 15:13:58 -0500 Subject: Running and building with NetBeans: a plea for help In-Reply-To: <729a403d-c5c7-6140-ec1d-eb1c887a23ed@redhat.com> References: <729a403d-c5c7-6140-ec1d-eb1c887a23ed@redhat.com> Message-ID: Hi Andrew, It looks like you have found fortune on another path and that's good. The ant task in make/jdk/netbeans/common/shared.xml is passing the jtreg.tests incorrectly to jtreg. JTreg expects the tests to be command line arguments but is passed using an ant property. After the patch below, I had to define/override root, build.dir? to make it work; something like: ROOT=/scratch/open ant? -Djtreg.tests=$ROOT/test/jdk/java/time/ -Dbuild.dir=$ROOT/build/linux-x64/jdk/? \ -Droot=$ROOT -debug -verbose -f $ROOT/make/jdk/netbeans/j2se jtreg Alternatively you can supply the tests in the jtreg.options property that is passed as command line args. (There is lots of magic in the project files that I did not try to figure out; not being a Netbeans person) Good luck,? Roger diff --git a/make/jdk/netbeans/common/shared.xml b/make/jdk/netbeans/common/shared.xml --- a/make/jdk/netbeans/common/shared.xml +++ b/make/jdk/netbeans/common/shared.xml @@ -262,9 +262,8 @@ ??????????????? vmoptions="${jtreg.vm.options}" ??????????????? javacoptions="-g" ??????????????? reportDir="${jtreg.dir}/JTreport" -?????????????? workDir="${jtreg.dir}/JTwork" -?????????????? includes="${jtreg.tests}"> -??????????? +?????????????? workDir="${jtreg.dir}/JTwork"> +??????????? ???????? ???? ???? On 11/15/2017 11:29 AM, Andrew Haley wrote: > I've been trying to get the netbeans project at > jdk/make/jdk/netbeans/jdk working. It all builds, but I can't get > tests to run. > > Current output is: > > ant -f /scratch/jdk/make/jdk/netbeans/j2se jtreg > /scratch/jdk/make/jdk/netbeans/common/shared.xml:266: No tests selected > > I don't know what to do, and I've been puzzling for days. If anyone > here uses netbeans and jtreg, please send me your build.properties (or > any other information) so I can try to figure out what I'm doing > wrong. Thanks. > From jeffrey.wayne.evans at gmail.com Wed Nov 15 23:11:37 2017 From: jeffrey.wayne.evans at gmail.com (Jeff Evans) Date: Wed, 15 Nov 2017 17:11:37 -0600 Subject: Why does the inReady method of StreamDecoder swallow IOException? Message-ID: Hello, We are dealing with an issue where an underlying exception appears to be getting swallowed by the StreamDecoder class. In particular, the Jersey client library we are using (which happens to be version 2.25.1) is throwing an IOException out of its implementation of InputStream#available https://github.com/jersey/jersey/blob/master/core-common/src/main/java/org/glassfish/jersey/internal/util/collection/ByteBufferInputStream.java#L143 by way of calling checkThrowable https://github.com/jersey/jersey/blob/master/core-common/src/main/java/org/glassfish/jersey/internal/util/collection/ByteBufferInputStream.java#L127 The caller of that is ultimately StreamDecoder#inReady. We are seeing the problem under Oracle JDK 1.8.0_121, but it seems the StreamDecoder code hasn't changed in a while: http://hg.openjdk.java.net/jdk8/jdk8/jdk/file/687fd7c7986d/src/share/classes/sun/nio/cs/StreamDecoder.java#l366 Is there some issue with the way the Jersey library code implementation, or potentially some issue with our code that is resulting in this exception not being propagated out from StreamDecoder? Any insight is appreciated. Full stack trace image here: https://i.imgur.com/AuyYFAp.png From xueming.shen at oracle.com Thu Nov 16 00:00:52 2017 From: xueming.shen at oracle.com (Xueming Shen) Date: Wed, 15 Nov 2017 16:00:52 -0800 Subject: Why does the inReady method of StreamDecoder swallow IOException? In-Reply-To: References: Message-ID: <5A0CD534.2060407@oracle.com> Jeff, It appears StreamDecoder.inReady()/implReady() works this way, silently swallow the IOE, from the very beginning/jdk1.4.0. This design/implementation probably was based on the assumption that the InputStream.available() only throws the IOE when the input stream has been closed by calling its close() method, as the InputStream.available() spec suggests. Since the StreamDecoder.isReady()/implReady() is guaranteed to be invoked under synchronized/ensureOpen() protection, the IOE should never occur. But it appears this assumption might be incorrect as/if the underlying InputStream.available() might throw an IOE when the stream is still open/has not been closed via a reader's close() method, which does not appear to be against the spec. @exception IOException if an I/O error occurs. Is this issue only reproducible on the latest jdk1.8.x and works fine with previous version? If that is the case, it's possible that we might have a different "bug/issue" somewhere else that the input stream is getting closed without by its reader's close() method. regard, Sherman On 11/15/2017 03:11 PM, Jeff Evans wrote: > Hello, > > We are dealing with an issue where an underlying exception appears to > be getting swallowed by the StreamDecoder class. In particular, the > Jersey client library we are using (which happens to be version > 2.25.1) is throwing an IOException out of its implementation of > InputStream#available > > https://github.com/jersey/jersey/blob/master/core-common/src/main/java/org/glassfish/jersey/internal/util/collection/ByteBufferInputStream.java#L143 > > by way of calling checkThrowable > > https://github.com/jersey/jersey/blob/master/core-common/src/main/java/org/glassfish/jersey/internal/util/collection/ByteBufferInputStream.java#L127 > > The caller of that is ultimately StreamDecoder#inReady. We are seeing > the problem under Oracle JDK 1.8.0_121, but it seems the StreamDecoder > code hasn't changed in a while: > http://hg.openjdk.java.net/jdk8/jdk8/jdk/file/687fd7c7986d/src/share/classes/sun/nio/cs/StreamDecoder.java#l366 > > Is there some issue with the way the Jersey library code > implementation, or potentially some issue with our code that is > resulting in this exception not being propagated out from > StreamDecoder? Any insight is appreciated. > > Full stack trace image here: https://i.imgur.com/AuyYFAp.png From mark.reinhold at oracle.com Thu Nov 16 22:04:29 2017 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Thu, 16 Nov 2017 14:04:29 -0800 Subject: JEP proposed to target JDK 10 (2017/11/16) Message-ID: <20171116140429.837282412@eggemoggin.niobe.net> The following JEP has been placed into the "Proposed to Target" state by its owner after discussion and review: 310: Application Class-Data Sharing http://openjdk.java.net/jeps/310 Feedback on this proposal is more than welcome, as are reasoned objections. If no such objections are raised by 23:00 UTC on Thursday, 23 November, or if they're raised and then satisfactorily answered, then per the JEP 2.0 process proposal [1] I'll target this JEP to JDK 10. - Mark [1] http://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html From joe.darcy at oracle.com Thu Nov 16 22:49:55 2017 From: joe.darcy at oracle.com (joe darcy) Date: Thu, 16 Nov 2017 14:49:55 -0800 Subject: Reminder: submit CSRs for JDK 10 with sufficient time ahead of rampdown 1 milestone Message-ID: <1977a73f-ce74-27ce-3a1f-06302d906367@oracle.com> Hello, With the first rampdown phase of JDK 10 approaching in a few weeks [1], a reminder to factor in time for the CSR (compatibility and specification review) process [2] for any interface changes desired to made in JDK 10 ahead of the RDP1 milestone. A CSR needs to be in an approved state before the corresponding changeset is pushed to JDK 10 master or one of the other lines of development which integrate into master, namely client or hotspot. See plans for HotSpot integrations before RDP1: [3]. Cheers, -Joe [1] http://openjdk.java.net/projects/jdk/10/ [2] https://wiki.openjdk.java.net/display/csr/Main [3] http://mail.openjdk.java.net/pipermail/hotspot-dev/2017-November/029070.html From mark.reinhold at oracle.com Mon Nov 20 20:28:08 2017 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Mon, 20 Nov 2017 12:28:08 -0800 Subject: FYI: JEP 309 (Dynamic Class-File Constants) now proposed to target JDK 11 Message-ID: <20171120122808.861070392@eggemoggin.niobe.net> 2017/11/20 11:56:42 -0800, paul.sandoz at oracle.com: > The schedule of dynamic constants has been adjusted, the JEP is > currently proposed to target for 11. > > There is risk to integrating a change such as constant dynamic this > late in the 10 release schedule. Instead it's better, and more aligned > with the new release process, to integrate early on into the main > repository so it has time to bake. > > I don?t anticipate there will be significant changes to the existing > reviews in progress (code, CSRs, VM specification), so we can keep the > momentum, integrate, then iterate. More: http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-November/050077.html The next train is pulling into the station ... - Mark From mark.reinhold at oracle.com Mon Nov 20 22:02:30 2017 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Mon, 20 Nov 2017 14:02:30 -0800 Subject: JEP proposed to target JDK 10 (2017/11/20) Message-ID: <20171120140230.959870819@eggemoggin.niobe.net> The following JEP has been placed into the "Proposed to Target" state by its owner after discussion and review: 316: Heap Allocation on Alternative Memory Devices http://openjdk.java.net/jeps/316 Feedback on this proposal is more than welcome, as are reasoned objections. If no such objections are raised by 23:00 UTC on Monday, 27 November, or if they're raised and then satisfactorily answered, then per the JEP 2.0 process proposal [1] I'll target this JEP to JDK 10. - Mark [1] http://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html From jeffrey.wayne.evans at gmail.com Tue Nov 21 16:07:40 2017 From: jeffrey.wayne.evans at gmail.com (Jeff Evans) Date: Tue, 21 Nov 2017 10:07:40 -0600 Subject: Why does the inReady method of StreamDecoder swallow IOException? In-Reply-To: <5A0CD534.2060407@oracle.com> References: <5A0CD534.2060407@oracle.com> Message-ID: (replying again on-list) Hi Sherman, We actually only support JDK 1.8.x in our product, so I can't answer as to whether previous JDK versions exhibit the same behavior. Given the behavior of the library that ultimately throws this IOException (Jersey) - namely that it maintains an AtomicReference to the exception (presumably because it can actually be thrown by a different thread) - I'm inclined to think it would work the same. In this particular case, the IOException happens when the HTTP connection is terminated by the peer (RST packet), so the close does happen outside the control flow of StreamDecoder and its reference to the InputStream. Given that implRead is already declared to throw IOException, I don't see why it shouldn't simply allow one thrown from its inReady invocation to be thrown out from itself. But as you said, this code has been unchanged for a long time, and there could be other factors I'm not aware of. Perhaps I will reach out to the Jersey maintainers and ask if they have any suggestions. Thanks! On Wed, Nov 15, 2017 at 6:00 PM, Xueming Shen wrote: > Jeff, > > It appears StreamDecoder.inReady()/implReady() works this way, silently > swallow > the IOE, from the very beginning/jdk1.4.0. This design/implementation > probably was > based on the assumption that the InputStream.available() only throws the IOE > when > the input stream has been closed by calling its close() method, as the > InputStream.available() > spec suggests. Since the StreamDecoder.isReady()/implReady() is guaranteed > to be > invoked under synchronized/ensureOpen() protection, the IOE should never > occur. But > it appears this assumption might be incorrect as/if the underlying > InputStream.available() > might throw an IOE when the stream is still open/has not been closed via a > reader's > close() method, which does not appear to be against the spec. > > @exception IOException if an I/O error occurs. > > Is this issue only reproducible on the latest jdk1.8.x and works fine with > previous version? > If that is the case, it's possible that we might have a different > "bug/issue" somewhere > else that the input stream is getting closed without by its reader's close() > method. > > regard, > Sherman > > > On 11/15/2017 03:11 PM, Jeff Evans wrote: >> >> Hello, >> >> We are dealing with an issue where an underlying exception appears to >> be getting swallowed by the StreamDecoder class. In particular, the >> Jersey client library we are using (which happens to be version >> 2.25.1) is throwing an IOException out of its implementation of >> InputStream#available >> >> >> https://github.com/jersey/jersey/blob/master/core-common/src/main/java/org/glassfish/jersey/internal/util/collection/ByteBufferInputStream.java#L143 >> >> by way of calling checkThrowable >> >> >> https://github.com/jersey/jersey/blob/master/core-common/src/main/java/org/glassfish/jersey/internal/util/collection/ByteBufferInputStream.java#L127 >> >> The caller of that is ultimately StreamDecoder#inReady. We are seeing >> the problem under Oracle JDK 1.8.0_121, but it seems the StreamDecoder >> code hasn't changed in a while: >> >> http://hg.openjdk.java.net/jdk8/jdk8/jdk/file/687fd7c7986d/src/share/classes/sun/nio/cs/StreamDecoder.java#l366 >> >> Is there some issue with the way the Jersey library code >> implementation, or potentially some issue with our code that is >> resulting in this exception not being propagated out from >> StreamDecoder? Any insight is appreciated. >> >> Full stack trace image here: https://i.imgur.com/AuyYFAp.png > > From magnus.ihse.bursie at oracle.com Wed Nov 22 09:15:08 2017 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 22 Nov 2017 10:15:08 +0100 Subject: Tips: Saving local disk space when cloning Message-ID: I'd like to propagate a tips I got from Erik. If you have a recent enough mercurial, you can save some significant local disk space by applying Mercurials "aggressive merge" algorithm when cloning. This brings down the .hg directory from 1.6 GB to 1.1 GB. While disk is cheap these days, SSD:s on laptops are still quite limited (at least mine is!), and if you have multiple repos cloned, these gigabytes add up. The only downside is that the conversion takes quite some time (~1 hour). To achieve this, use the following command line when cloning: hg --config=format.generaldelta=1 --config=format.aggressivemergedeltas=1 clone --pull http://hg.openjdk.java.net/jdk/jdk jdk If you have already made a local clone and want to avoid re-downloading it, you can make a "lean" clone from your local "fat" clone, and then remove the fat clone: hg --config=format.generaldelta=1 --config=format.aggressivemergedeltas=1 clone --pull jdk-fat jdk-lean If you want a second lean clone, you can just clone that normally ("hg clone jdk-lean jdk-lean2") and benefit from mercurials hard linking facilities. Apparently there were some technical reasons why this could not been enabled by default on our hg.openjdk.java.net server. :-( But at least you can apply this for yourself, if disk space is a premium. /Magnus From coleen.phillimore at oracle.com Wed Nov 22 14:44:24 2017 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Wed, 22 Nov 2017 09:44:24 -0500 Subject: CFV: New JDK Committer: John Paul Adrian Glaubitz Message-ID: I hereby nominate John Paul Adrian Glaubitz (glaubitz) to JDK Committer. Adrian works for SUSE as a member of the Public Cloud Team but contributes patches to OpenJDK in his free time as an individual contributor. He enjoys working on various architectures that exist in Debian. He is working to reduce the necessary patches to get OpenJDK build on downstream distributions since this helps to relieve the maintenance burden of the OpenJDK maintainers in Debian and SUSE.? Adrian has contributed 16 changes [3] to OpenJDK, primarily timely and appreciated Hotspot patches to fix the Zero interpreter on multiple platforms. Votes are due by December 6, 2017. Only current JDK Committers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [2]. Thanks, Coleen [1] http://openjdk.java.net/census [2] http://openjdk.java.net/bylaws#lazy-consensus [3] List of changes: http://hg.openjdk.java.net/jdk/hs/rev/827e4ac05579 8191663: Zero variant broken after 8189170 and 8189871 http://hg.openjdk.java.net/jdk/hs/rev/0ad8a90268a7 8191333: Zero variant broken after 8189941 http://hg.openjdk.java.net/jdk/hs/rev/b140fe4ff916 8190570: Zero fails to build on linux-sparc due undefined reference http://hg.openjdk.java.net/jdk/hs/rev/0f7dce1e7690 8186578: Zero fails to build on linux-sparc due to sparc-specific code http://hg.openjdk.java.net/jdk/hs/rev/9c0137e5e37a 8187590: Zero runtime can lock-up on linux-alpha http://hg.openjdk.java.net/jdk/hs/rev/4cc46bb5057b 8186855: Multiple platforms broken after 8186476: Generalize Atomic::add with templates http://hg.openjdk.java.net/jdk/hs/rev/b7849991ae55 8186723: Add SuperH as new architecture for linux http://hg.openjdk.java.net/jdk/hs/rev/89fb7df32425 8186655: Identifier strings for PowerPC 64 LE and PowerPC 64 are swapped http://hg.openjdk.java.net/jdk/hs/rev/3cd94e2be178 8186443: Missing stdint.h for zero builds http://hg.openjdk.java.net/jdk/hs/rev/a8488a8b37fb 8186786: Name collisions with autoconf definitions on alpha and sh http://hg.openjdk.java.net/jdk/hs/rev/a4fa3280b8df 8186313: Additional platform definitions to support Zero builds http://hg.openjdk.java.net/jdk/hs/rev/6e1b59330482 8186433: Compiler flag -arch=sparc should not be passed on linux-sparc http://hg.openjdk.java.net/jdk/hs/rev/f4ded11e0f74 8186221: Define CPU search_string for M68K http://hg.openjdk.java.net/jdk/hs/rev/f5a564180f37 8182165: The header atomic_linux_sparc.inline.hpp should be named atomic_linux_sparc.hpp http://hg.openjdk.java.net/jdk/hs/rev/ff7b9f61209e 8182164: checkByteBuffer has the wrong signature http://hg.openjdk.java.net/jdk/hs/rev/32434b633549 8182163: Missing #include "logging/log.hpp" in vm_version_linux_sparc.cpp From coleen.phillimore at oracle.com Wed Nov 22 14:45:07 2017 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Wed, 22 Nov 2017 09:45:07 -0500 Subject: CFV: New JDK Committer: John Paul Adrian Glaubitz In-Reply-To: References: Message-ID: Vote: yes On 11/22/17 9:44 AM, coleen.phillimore at oracle.com wrote: > I hereby nominate John Paul Adrian Glaubitz (glaubitz) to JDK Committer. > > Adrian works for SUSE as a member of the Public Cloud Team but > contributes patches to OpenJDK in his free time as an individual > contributor. He enjoys working on various architectures that exist in > Debian. He is working to reduce the necessary patches to get OpenJDK > build on downstream distributions since this helps to relieve the > maintenance burden of the OpenJDK maintainers in Debian and SUSE.? > Adrian has contributed 16 changes [3] to OpenJDK, primarily timely and > appreciated Hotspot patches to fix the Zero interpreter on multiple > platforms. > > Votes are due by December 6, 2017. > > Only current JDK Committers [1] are eligible to vote on this nomination. > > Votes must be cast in the open by replying to this mailing list. For > Lazy Consensus voting instructions, see [2]. > > Thanks, > Coleen > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/bylaws#lazy-consensus > > [3] List of changes: > > http://hg.openjdk.java.net/jdk/hs/rev/827e4ac05579 > 8191663: Zero variant broken after 8189170 and 8189871 > > http://hg.openjdk.java.net/jdk/hs/rev/0ad8a90268a7 > 8191333: Zero variant broken after 8189941 > > http://hg.openjdk.java.net/jdk/hs/rev/b140fe4ff916 > 8190570: Zero fails to build on linux-sparc due undefined reference > > http://hg.openjdk.java.net/jdk/hs/rev/0f7dce1e7690 > 8186578: Zero fails to build on linux-sparc due to sparc-specific code > > http://hg.openjdk.java.net/jdk/hs/rev/9c0137e5e37a > 8187590: Zero runtime can lock-up on linux-alpha > > http://hg.openjdk.java.net/jdk/hs/rev/4cc46bb5057b > 8186855: Multiple platforms broken after 8186476: Generalize > Atomic::add with templates > > http://hg.openjdk.java.net/jdk/hs/rev/b7849991ae55 > 8186723: Add SuperH as new architecture for linux > > http://hg.openjdk.java.net/jdk/hs/rev/89fb7df32425 > 8186655: Identifier strings for PowerPC 64 LE and PowerPC 64 are swapped > > http://hg.openjdk.java.net/jdk/hs/rev/3cd94e2be178 > 8186443: Missing stdint.h for zero builds > > http://hg.openjdk.java.net/jdk/hs/rev/a8488a8b37fb > 8186786: Name collisions with autoconf definitions on alpha and sh > > http://hg.openjdk.java.net/jdk/hs/rev/a4fa3280b8df > 8186313: Additional platform definitions to support Zero builds > > http://hg.openjdk.java.net/jdk/hs/rev/6e1b59330482 > 8186433: Compiler flag -arch=sparc should not be passed on linux-sparc > > http://hg.openjdk.java.net/jdk/hs/rev/f4ded11e0f74 > 8186221: Define CPU search_string for M68K > > http://hg.openjdk.java.net/jdk/hs/rev/f5a564180f37 > 8182165: The header atomic_linux_sparc.inline.hpp should be named > atomic_linux_sparc.hpp > > http://hg.openjdk.java.net/jdk/hs/rev/ff7b9f61209e > 8182164: checkByteBuffer has the wrong signature > > http://hg.openjdk.java.net/jdk/hs/rev/32434b633549 > 8182163: Missing #include "logging/log.hpp" in vm_version_linux_sparc.cpp > From shade at redhat.com Wed Nov 22 14:47:24 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 22 Nov 2017 15:47:24 +0100 Subject: CFV: New JDK Committer: John Paul Adrian Glaubitz In-Reply-To: References: Message-ID: <10f08570-a656-e9de-6e1d-b8cbaf9dc383@redhat.com> Vote: yes On 11/22/2017 03:44 PM, coleen.phillimore at oracle.com wrote: > I hereby nominate John Paul Adrian Glaubitz (glaubitz) to JDK Committer. -Aleksey From ashipile at redhat.com Wed Nov 22 14:48:04 2017 From: ashipile at redhat.com (Aleksey Shipilev) Date: Wed, 22 Nov 2017 15:48:04 +0100 Subject: Tips: Saving local disk space when cloning In-Reply-To: References: Message-ID: <6dc72f82-6581-09ef-4fca-8447cd486880@redhat.com> On 11/22/2017 10:15 AM, Magnus Ihse Bursie wrote: > I'd like to propagate a tips I got from Erik. If you have a recent enough mercurial, you can save > some significant local disk space by applying Mercurials "aggressive merge" algorithm when cloning. > This brings down the .hg directory from 1.6 GB to 1.1 GB. While disk is cheap these days, SSD:s on > laptops are still quite limited (at least mine is!), and if you have multiple repos cloned, these > gigabytes add up. The only downside is that the conversion takes quite some time (~1 hour). > > To achieve this, use the following command line when cloning: > > hg --config=format.generaldelta=1 --config=format.aggressivemergedeltas=1 clone --pull > http://hg.openjdk.java.net/jdk/jdk jdk > > Apparently there were some technical reasons why this could not been enabled by default on our > hg.openjdk.java.net server. :-( But at least you can apply this for yourself, if disk space is a > premium. Very nice trick, thanks! You can do the same with pre-jdk10 builds, with: $ HGFOREST_GLOBALOPTS=" --config=format.generaldelta=1 --config=format.aggressivemergedeltas=1" \ sh common/bin/hgforest.sh clone This cuts down both workspace and compressed tarball sizes quite significantly. E.g. workspace tarballs at https://builds.shipilev.net/workspaces/ are now 50-300 MB lighter. -Aleksey From eric.caspole at oracle.com Wed Nov 22 14:49:26 2017 From: eric.caspole at oracle.com (Eric Caspole) Date: Wed, 22 Nov 2017 09:49:26 -0500 Subject: CFV: New JDK Committer: John Paul Adrian Glaubitz In-Reply-To: References: Message-ID: <1d925819-71f0-4f69-0350-8325570c063f@oracle.com> Vote: yes On 11/22/2017 09:45 AM, coleen.phillimore at oracle.com wrote: > Vote: yes > > On 11/22/17 9:44 AM, coleen.phillimore at oracle.com wrote: >> I hereby nominate John Paul Adrian Glaubitz (glaubitz) to JDK Committer. >> From dalibor.topic at oracle.com Wed Nov 22 14:50:08 2017 From: dalibor.topic at oracle.com (dalibor topic) Date: Wed, 22 Nov 2017 15:50:08 +0100 Subject: CFV: New JDK Committer: John Paul Adrian Glaubitz In-Reply-To: References: Message-ID: Vote: Yes -- Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile: +491737185961 ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher Oracle is committed to developing practices and products that help protect the environment From thomas.schatzl at oracle.com Wed Nov 22 14:53:47 2017 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Wed, 22 Nov 2017 15:53:47 +0100 Subject: CFV: New JDK Committer: John Paul Adrian Glaubitz In-Reply-To: References: Message-ID: <1511362427.2374.0.camel@oracle.com> Vote: yes On Wed, 2017-11-22 at 09:44 -0500, coleen.phillimore at oracle.com wrote: > I hereby nominate John Paul Adrian Glaubitz (glaubitz) to JDK > Committer. > > Adrian works for SUSE as a member of the Public Cloud Team but > contributes patches to OpenJDK in his free time as an individual > contributor. He enjoys working on various architectures that exist > in > Debian. He is working to reduce the necessary patches to get OpenJDK > build on downstream distributions since this helps to relieve the > maintenance burden of the OpenJDK maintainers in Debian and SUSE. > Adrian has contributed 16 changes [3] to OpenJDK, primarily timely > and > appreciated Hotspot patches to fix the Zero interpreter on multiple > platforms. > > Votes are due by December 6, 2017. > > Only current JDK Committers [1] are eligible to vote on this > nomination. > > Votes must be cast in the open by replying to this mailing list. For > Lazy Consensus voting instructions, see [2]. > > Thanks, > Coleen > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/bylaws#lazy-consensus > > [3] List of changes: > > http://hg.openjdk.java.net/jdk/hs/rev/827e4ac05579 > 8191663: Zero variant broken after 8189170 and 8189871 > > http://hg.openjdk.java.net/jdk/hs/rev/0ad8a90268a7 > 8191333: Zero variant broken after 8189941 > > http://hg.openjdk.java.net/jdk/hs/rev/b140fe4ff916 > 8190570: Zero fails to build on linux-sparc due undefined reference > > http://hg.openjdk.java.net/jdk/hs/rev/0f7dce1e7690 > 8186578: Zero fails to build on linux-sparc due to sparc-specific > code > > http://hg.openjdk.java.net/jdk/hs/rev/9c0137e5e37a > 8187590: Zero runtime can lock-up on linux-alpha > > http://hg.openjdk.java.net/jdk/hs/rev/4cc46bb5057b > 8186855: Multiple platforms broken after 8186476: Generalize > Atomic::add > with templates > > http://hg.openjdk.java.net/jdk/hs/rev/b7849991ae55 > 8186723: Add SuperH as new architecture for linux > > http://hg.openjdk.java.net/jdk/hs/rev/89fb7df32425 > 8186655: Identifier strings for PowerPC 64 LE and PowerPC 64 are > swapped > > http://hg.openjdk.java.net/jdk/hs/rev/3cd94e2be178 > 8186443: Missing stdint.h for zero builds > > http://hg.openjdk.java.net/jdk/hs/rev/a8488a8b37fb > 8186786: Name collisions with autoconf definitions on alpha and sh > > http://hg.openjdk.java.net/jdk/hs/rev/a4fa3280b8df > 8186313: Additional platform definitions to support Zero builds > > http://hg.openjdk.java.net/jdk/hs/rev/6e1b59330482 > 8186433: Compiler flag -arch=sparc should not be passed on linux- > sparc > > http://hg.openjdk.java.net/jdk/hs/rev/f4ded11e0f74 > 8186221: Define CPU search_string for M68K > > http://hg.openjdk.java.net/jdk/hs/rev/f5a564180f37 > 8182165: The header atomic_linux_sparc.inline.hpp should be named > atomic_linux_sparc.hpp > > http://hg.openjdk.java.net/jdk/hs/rev/ff7b9f61209e > 8182164: checkByteBuffer has the wrong signature > > http://hg.openjdk.java.net/jdk/hs/rev/32434b633549 > 8182163: Missing #include "logging/log.hpp" in > vm_version_linux_sparc.cpp > From adinn at redhat.com Wed Nov 22 14:54:39 2017 From: adinn at redhat.com (Andrew Dinn) Date: Wed, 22 Nov 2017 14:54:39 +0000 Subject: CFV: New JDK Committer: John Paul Adrian Glaubitz In-Reply-To: References: Message-ID: Vote: yes On 22/11/17 14:44, coleen.phillimore at oracle.com wrote: > I hereby nominate John Paul Adrian Glaubitz (glaubitz) to JDK Committer. > > Adrian works for SUSE as a member of the Public Cloud Team but > contributes patches to OpenJDK in his free time as an individual > contributor. He enjoys working on various architectures that exist in > Debian. He is working to reduce the necessary patches to get OpenJDK > build on downstream distributions since this helps to relieve the > maintenance burden of the OpenJDK maintainers in Debian and SUSE.? > Adrian has contributed 16 changes [3] to OpenJDK, primarily timely and > appreciated Hotspot patches to fix the Zero interpreter on multiple > platforms. > > Votes are due by December 6, 2017. > > Only current JDK Committers [1] are eligible to vote on this nomination. > > Votes must be cast in the open by replying to this mailing list. For > Lazy Consensus voting instructions, see [2]. > > Thanks, > Coleen > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/bylaws#lazy-consensus > > [3] List of changes: > > http://hg.openjdk.java.net/jdk/hs/rev/827e4ac05579 > 8191663: Zero variant broken after 8189170 and 8189871 > > http://hg.openjdk.java.net/jdk/hs/rev/0ad8a90268a7 > 8191333: Zero variant broken after 8189941 > > http://hg.openjdk.java.net/jdk/hs/rev/b140fe4ff916 > 8190570: Zero fails to build on linux-sparc due undefined reference > > http://hg.openjdk.java.net/jdk/hs/rev/0f7dce1e7690 > 8186578: Zero fails to build on linux-sparc due to sparc-specific code > > http://hg.openjdk.java.net/jdk/hs/rev/9c0137e5e37a > 8187590: Zero runtime can lock-up on linux-alpha > > http://hg.openjdk.java.net/jdk/hs/rev/4cc46bb5057b > 8186855: Multiple platforms broken after 8186476: Generalize > Atomic::add with templates > > http://hg.openjdk.java.net/jdk/hs/rev/b7849991ae55 > 8186723: Add SuperH as new architecture for linux > > http://hg.openjdk.java.net/jdk/hs/rev/89fb7df32425 > 8186655: Identifier strings for PowerPC 64 LE and PowerPC 64 are swapped > > http://hg.openjdk.java.net/jdk/hs/rev/3cd94e2be178 > 8186443: Missing stdint.h for zero builds > > http://hg.openjdk.java.net/jdk/hs/rev/a8488a8b37fb > 8186786: Name collisions with autoconf definitions on alpha and sh > > http://hg.openjdk.java.net/jdk/hs/rev/a4fa3280b8df > 8186313: Additional platform definitions to support Zero builds > > http://hg.openjdk.java.net/jdk/hs/rev/6e1b59330482 > 8186433: Compiler flag -arch=sparc should not be passed on linux-sparc > > http://hg.openjdk.java.net/jdk/hs/rev/f4ded11e0f74 > 8186221: Define CPU search_string for M68K > > http://hg.openjdk.java.net/jdk/hs/rev/f5a564180f37 > 8182165: The header atomic_linux_sparc.inline.hpp should be named > atomic_linux_sparc.hpp > > http://hg.openjdk.java.net/jdk/hs/rev/ff7b9f61209e > 8182164: checkByteBuffer has the wrong signature > > http://hg.openjdk.java.net/jdk/hs/rev/32434b633549 > 8182163: Missing #include "logging/log.hpp" in vm_version_linux_sparc.cpp > > -- regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From aph at redhat.com Wed Nov 22 14:56:07 2017 From: aph at redhat.com (Andrew Haley) Date: Wed, 22 Nov 2017 14:56:07 +0000 Subject: CFV: New JDK Committer: John Paul Adrian Glaubitz In-Reply-To: References: Message-ID: <5d5d0505-5caa-c40a-02f3-766670eadc81@redhat.com> On 22/11/17 14:44, coleen.phillimore at oracle.com wrote: > I hereby nominate John Paul Adrian Glaubitz (glaubitz) to JDK Committer. Vote: yes. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From Sergey.Bylokhov at oracle.com Wed Nov 22 14:59:33 2017 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 22 Nov 2017 06:59:33 -0800 Subject: CFV: New JDK Committer: John Paul Adrian Glaubitz In-Reply-To: References: Message-ID: <732c4d3e-7fc4-318a-0b56-1dd2860c3760@oracle.com> Vote: yes On 22/11/2017 06:44, coleen.phillimore at oracle.com wrote: > I hereby nominate John Paul Adrian Glaubitz (glaubitz) to JDK Committer. -- Best regards, Sergey. From erik.helin at oracle.com Wed Nov 22 15:00:46 2017 From: erik.helin at oracle.com (Erik Helin) Date: Wed, 22 Nov 2017 16:00:46 +0100 Subject: CFV: New JDK Committer: John Paul Adrian Glaubitz In-Reply-To: References: Message-ID: <79b2df6a-b032-cff0-3cb2-8c0057787814@oracle.com> Vote: yes Thanks, Erik On 11/22/2017 03:44 PM, coleen.phillimore at oracle.com wrote: > I hereby nominate John Paul Adrian Glaubitz (glaubitz) to JDK Committer. > > Adrian works for SUSE as a member of the Public Cloud Team but > contributes patches to OpenJDK in his free time as an individual > contributor. He enjoys working on various architectures that exist in > Debian. He is working to reduce the necessary patches to get OpenJDK > build on downstream distributions since this helps to relieve the > maintenance burden of the OpenJDK maintainers in Debian and SUSE. Adrian > has contributed 16 changes [3] to OpenJDK, primarily timely and > appreciated Hotspot patches to fix the Zero interpreter on multiple > platforms. > > Votes are due by December 6, 2017. > > Only current JDK Committers [1] are eligible to vote on this nomination. > > Votes must be cast in the open by replying to this mailing list. For > Lazy Consensus voting instructions, see [2]. > > Thanks, > Coleen > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/bylaws#lazy-consensus > > [3] List of changes: > > http://hg.openjdk.java.net/jdk/hs/rev/827e4ac05579 > 8191663: Zero variant broken after 8189170 and 8189871 > > http://hg.openjdk.java.net/jdk/hs/rev/0ad8a90268a7 > 8191333: Zero variant broken after 8189941 > > http://hg.openjdk.java.net/jdk/hs/rev/b140fe4ff916 > 8190570: Zero fails to build on linux-sparc due undefined reference > > http://hg.openjdk.java.net/jdk/hs/rev/0f7dce1e7690 > 8186578: Zero fails to build on linux-sparc due to sparc-specific code > > http://hg.openjdk.java.net/jdk/hs/rev/9c0137e5e37a > 8187590: Zero runtime can lock-up on linux-alpha > > http://hg.openjdk.java.net/jdk/hs/rev/4cc46bb5057b > 8186855: Multiple platforms broken after 8186476: Generalize Atomic::add > with templates > > http://hg.openjdk.java.net/jdk/hs/rev/b7849991ae55 > 8186723: Add SuperH as new architecture for linux > > http://hg.openjdk.java.net/jdk/hs/rev/89fb7df32425 > 8186655: Identifier strings for PowerPC 64 LE and PowerPC 64 are swapped > > http://hg.openjdk.java.net/jdk/hs/rev/3cd94e2be178 > 8186443: Missing stdint.h for zero builds > > http://hg.openjdk.java.net/jdk/hs/rev/a8488a8b37fb > 8186786: Name collisions with autoconf definitions on alpha and sh > > http://hg.openjdk.java.net/jdk/hs/rev/a4fa3280b8df > 8186313: Additional platform definitions to support Zero builds > > http://hg.openjdk.java.net/jdk/hs/rev/6e1b59330482 > 8186433: Compiler flag -arch=sparc should not be passed on linux-sparc > > http://hg.openjdk.java.net/jdk/hs/rev/f4ded11e0f74 > 8186221: Define CPU search_string for M68K > > http://hg.openjdk.java.net/jdk/hs/rev/f5a564180f37 > 8182165: The header atomic_linux_sparc.inline.hpp should be named > atomic_linux_sparc.hpp > > http://hg.openjdk.java.net/jdk/hs/rev/ff7b9f61209e > 8182164: checkByteBuffer has the wrong signature > > http://hg.openjdk.java.net/jdk/hs/rev/32434b633549 > 8182163: Missing #include "logging/log.hpp" in vm_version_linux_sparc.cpp > From zgu at redhat.com Wed Nov 22 15:07:24 2017 From: zgu at redhat.com (Zhengyu Gu) Date: Wed, 22 Nov 2017 10:07:24 -0500 Subject: CFV: New JDK Committer: John Paul Adrian Glaubitz In-Reply-To: References: Message-ID: Vote: yes -Zhengyu On 11/22/2017 09:45 AM, coleen.phillimore at oracle.com wrote: > Vote: yes > > On 11/22/17 9:44 AM, coleen.phillimore at oracle.com wrote: >> I hereby nominate John Paul Adrian Glaubitz (glaubitz) to JDK Committer. >> >> Adrian works for SUSE as a member of the Public Cloud Team but >> contributes patches to OpenJDK in his free time as an individual >> contributor. He enjoys working on various architectures that exist in >> Debian. He is working to reduce the necessary patches to get OpenJDK >> build on downstream distributions since this helps to relieve the >> maintenance burden of the OpenJDK maintainers in Debian and SUSE. >> Adrian has contributed 16 changes [3] to OpenJDK, primarily timely and >> appreciated Hotspot patches to fix the Zero interpreter on multiple >> platforms. >> >> Votes are due by December 6, 2017. >> >> Only current JDK Committers [1] are eligible to vote on this nomination. >> >> Votes must be cast in the open by replying to this mailing list. For >> Lazy Consensus voting instructions, see [2]. >> >> Thanks, >> Coleen >> >> [1] http://openjdk.java.net/census >> [2] http://openjdk.java.net/bylaws#lazy-consensus >> >> [3] List of changes: >> >> http://hg.openjdk.java.net/jdk/hs/rev/827e4ac05579 >> 8191663: Zero variant broken after 8189170 and 8189871 >> >> http://hg.openjdk.java.net/jdk/hs/rev/0ad8a90268a7 >> 8191333: Zero variant broken after 8189941 >> >> http://hg.openjdk.java.net/jdk/hs/rev/b140fe4ff916 >> 8190570: Zero fails to build on linux-sparc due undefined reference >> >> http://hg.openjdk.java.net/jdk/hs/rev/0f7dce1e7690 >> 8186578: Zero fails to build on linux-sparc due to sparc-specific code >> >> http://hg.openjdk.java.net/jdk/hs/rev/9c0137e5e37a >> 8187590: Zero runtime can lock-up on linux-alpha >> >> http://hg.openjdk.java.net/jdk/hs/rev/4cc46bb5057b >> 8186855: Multiple platforms broken after 8186476: Generalize >> Atomic::add with templates >> >> http://hg.openjdk.java.net/jdk/hs/rev/b7849991ae55 >> 8186723: Add SuperH as new architecture for linux >> >> http://hg.openjdk.java.net/jdk/hs/rev/89fb7df32425 >> 8186655: Identifier strings for PowerPC 64 LE and PowerPC 64 are swapped >> >> http://hg.openjdk.java.net/jdk/hs/rev/3cd94e2be178 >> 8186443: Missing stdint.h for zero builds >> >> http://hg.openjdk.java.net/jdk/hs/rev/a8488a8b37fb >> 8186786: Name collisions with autoconf definitions on alpha and sh >> >> http://hg.openjdk.java.net/jdk/hs/rev/a4fa3280b8df >> 8186313: Additional platform definitions to support Zero builds >> >> http://hg.openjdk.java.net/jdk/hs/rev/6e1b59330482 >> 8186433: Compiler flag -arch=sparc should not be passed on linux-sparc >> >> http://hg.openjdk.java.net/jdk/hs/rev/f4ded11e0f74 >> 8186221: Define CPU search_string for M68K >> >> http://hg.openjdk.java.net/jdk/hs/rev/f5a564180f37 >> 8182165: The header atomic_linux_sparc.inline.hpp should be named >> atomic_linux_sparc.hpp >> >> http://hg.openjdk.java.net/jdk/hs/rev/ff7b9f61209e >> 8182164: checkByteBuffer has the wrong signature >> >> http://hg.openjdk.java.net/jdk/hs/rev/32434b633549 >> 8182163: Missing #include "logging/log.hpp" in vm_version_linux_sparc.cpp >> > From tobias.hartmann at oracle.com Wed Nov 22 15:17:04 2017 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Wed, 22 Nov 2017 16:17:04 +0100 Subject: CFV: New JDK Committer: John Paul Adrian Glaubitz In-Reply-To: References: Message-ID: Vote: yes On 22.11.2017 15:44, coleen.phillimore at oracle.com wrote: > I hereby nominate John Paul Adrian Glaubitz (glaubitz) to JDK Committer. > > Adrian works for SUSE as a member of the Public Cloud Team but contributes patches to OpenJDK in his free time as an > individual contributor. He enjoys working on various architectures that exist in Debian. He is working to reduce the > necessary patches to get OpenJDK build on downstream distributions since this helps to relieve the maintenance burden of > the OpenJDK maintainers in Debian and SUSE.? Adrian has contributed 16 changes [3] to OpenJDK, primarily timely and > appreciated Hotspot patches to fix the Zero interpreter on multiple platforms. > > Votes are due by December 6, 2017. > > Only current JDK Committers [1] are eligible to vote on this nomination. > > Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [2]. > > Thanks, > Coleen > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/bylaws#lazy-consensus > [3] List of changes: > > http://hg.openjdk.java.net/jdk/hs/rev/827e4ac05579 > 8191663: Zero variant broken after 8189170 and 8189871 > > http://hg.openjdk.java.net/jdk/hs/rev/0ad8a90268a7 > 8191333: Zero variant broken after 8189941 > > http://hg.openjdk.java.net/jdk/hs/rev/b140fe4ff916 > 8190570: Zero fails to build on linux-sparc due undefined reference > > http://hg.openjdk.java.net/jdk/hs/rev/0f7dce1e7690 > 8186578: Zero fails to build on linux-sparc due to sparc-specific code > > http://hg.openjdk.java.net/jdk/hs/rev/9c0137e5e37a > 8187590: Zero runtime can lock-up on linux-alpha > > http://hg.openjdk.java.net/jdk/hs/rev/4cc46bb5057b > 8186855: Multiple platforms broken after 8186476: Generalize Atomic::add with templates > > http://hg.openjdk.java.net/jdk/hs/rev/b7849991ae55 > 8186723: Add SuperH as new architecture for linux > > http://hg.openjdk.java.net/jdk/hs/rev/89fb7df32425 > 8186655: Identifier strings for PowerPC 64 LE and PowerPC 64 are swapped > > http://hg.openjdk.java.net/jdk/hs/rev/3cd94e2be178 > 8186443: Missing stdint.h for zero builds > > http://hg.openjdk.java.net/jdk/hs/rev/a8488a8b37fb > 8186786: Name collisions with autoconf definitions on alpha and sh > > http://hg.openjdk.java.net/jdk/hs/rev/a4fa3280b8df > 8186313: Additional platform definitions to support Zero builds > > http://hg.openjdk.java.net/jdk/hs/rev/6e1b59330482 > 8186433: Compiler flag -arch=sparc should not be passed on linux-sparc > > http://hg.openjdk.java.net/jdk/hs/rev/f4ded11e0f74 > 8186221: Define CPU search_string for M68K > > http://hg.openjdk.java.net/jdk/hs/rev/f5a564180f37 > 8182165: The header atomic_linux_sparc.inline.hpp should be named atomic_linux_sparc.hpp > > http://hg.openjdk.java.net/jdk/hs/rev/ff7b9f61209e > 8182164: checkByteBuffer has the wrong signature > > http://hg.openjdk.java.net/jdk/hs/rev/32434b633549 > 8182163: Missing #include "logging/log.hpp" in vm_version_linux_sparc.cpp > From roman at kennke.org Wed Nov 22 15:17:29 2017 From: roman at kennke.org (Roman Kennke) Date: Wed, 22 Nov 2017 16:17:29 +0100 Subject: CFV: New JDK Committer: John Paul Adrian Glaubitz In-Reply-To: References: Message-ID: Vote: yes Thanks, Roman > I hereby nominate John Paul Adrian Glaubitz (glaubitz) to JDK Committer. > > Adrian works for SUSE as a member of the Public Cloud Team but > contributes patches to OpenJDK in his free time as an individual > contributor. He enjoys working on various architectures that exist in > Debian. He is working to reduce the necessary patches to get OpenJDK > build on downstream distributions since this helps to relieve the > maintenance burden of the OpenJDK maintainers in Debian and SUSE.? > Adrian has contributed 16 changes [3] to OpenJDK, primarily timely and > appreciated Hotspot patches to fix the Zero interpreter on multiple > platforms. > > Votes are due by December 6, 2017. > > Only current JDK Committers [1] are eligible to vote on this nomination. > > Votes must be cast in the open by replying to this mailing list. For > Lazy Consensus voting instructions, see [2]. > > Thanks, > Coleen > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/bylaws#lazy-consensus > > [3] List of changes: > > http://hg.openjdk.java.net/jdk/hs/rev/827e4ac05579 > 8191663: Zero variant broken after 8189170 and 8189871 > > http://hg.openjdk.java.net/jdk/hs/rev/0ad8a90268a7 > 8191333: Zero variant broken after 8189941 > > http://hg.openjdk.java.net/jdk/hs/rev/b140fe4ff916 > 8190570: Zero fails to build on linux-sparc due undefined reference > > http://hg.openjdk.java.net/jdk/hs/rev/0f7dce1e7690 > 8186578: Zero fails to build on linux-sparc due to sparc-specific code > > http://hg.openjdk.java.net/jdk/hs/rev/9c0137e5e37a > 8187590: Zero runtime can lock-up on linux-alpha > > http://hg.openjdk.java.net/jdk/hs/rev/4cc46bb5057b > 8186855: Multiple platforms broken after 8186476: Generalize > Atomic::add with templates > > http://hg.openjdk.java.net/jdk/hs/rev/b7849991ae55 > 8186723: Add SuperH as new architecture for linux > > http://hg.openjdk.java.net/jdk/hs/rev/89fb7df32425 > 8186655: Identifier strings for PowerPC 64 LE and PowerPC 64 are swapped > > http://hg.openjdk.java.net/jdk/hs/rev/3cd94e2be178 > 8186443: Missing stdint.h for zero builds > > http://hg.openjdk.java.net/jdk/hs/rev/a8488a8b37fb > 8186786: Name collisions with autoconf definitions on alpha and sh > > http://hg.openjdk.java.net/jdk/hs/rev/a4fa3280b8df > 8186313: Additional platform definitions to support Zero builds > > http://hg.openjdk.java.net/jdk/hs/rev/6e1b59330482 > 8186433: Compiler flag -arch=sparc should not be passed on linux-sparc > > http://hg.openjdk.java.net/jdk/hs/rev/f4ded11e0f74 > 8186221: Define CPU search_string for M68K > > http://hg.openjdk.java.net/jdk/hs/rev/f5a564180f37 > 8182165: The header atomic_linux_sparc.inline.hpp should be named > atomic_linux_sparc.hpp > > http://hg.openjdk.java.net/jdk/hs/rev/ff7b9f61209e > 8182164: checkByteBuffer has the wrong signature > > http://hg.openjdk.java.net/jdk/hs/rev/32434b633549 > 8182163: Missing #include "logging/log.hpp" in vm_version_linux_sparc.cpp > > From daniel.daugherty at oracle.com Wed Nov 22 15:31:54 2017 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 22 Nov 2017 10:31:54 -0500 Subject: CFV: New JDK Committer: John Paul Adrian Glaubitz In-Reply-To: References: Message-ID: <6c8ad9fd-0e6b-01ee-e480-3b8f8fe60c2b@oracle.com> Vote: yes Dan On 11/22/17 9:44 AM, coleen.phillimore at oracle.com wrote: > I hereby nominate John Paul Adrian Glaubitz (glaubitz) to JDK Committer. > > Adrian works for SUSE as a member of the Public Cloud Team but > contributes patches to OpenJDK in his free time as an individual > contributor. He enjoys working on various architectures that exist in > Debian. He is working to reduce the necessary patches to get OpenJDK > build on downstream distributions since this helps to relieve the > maintenance burden of the OpenJDK maintainers in Debian and SUSE.? > Adrian has contributed 16 changes [3] to OpenJDK, primarily timely and > appreciated Hotspot patches to fix the Zero interpreter on multiple > platforms. > > Votes are due by December 6, 2017. > > Only current JDK Committers [1] are eligible to vote on this nomination. > > Votes must be cast in the open by replying to this mailing list. For > Lazy Consensus voting instructions, see [2]. > > Thanks, > Coleen > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/bylaws#lazy-consensus > > [3] List of changes: > > http://hg.openjdk.java.net/jdk/hs/rev/827e4ac05579 > 8191663: Zero variant broken after 8189170 and 8189871 > > http://hg.openjdk.java.net/jdk/hs/rev/0ad8a90268a7 > 8191333: Zero variant broken after 8189941 > > http://hg.openjdk.java.net/jdk/hs/rev/b140fe4ff916 > 8190570: Zero fails to build on linux-sparc due undefined reference > > http://hg.openjdk.java.net/jdk/hs/rev/0f7dce1e7690 > 8186578: Zero fails to build on linux-sparc due to sparc-specific code > > http://hg.openjdk.java.net/jdk/hs/rev/9c0137e5e37a > 8187590: Zero runtime can lock-up on linux-alpha > > http://hg.openjdk.java.net/jdk/hs/rev/4cc46bb5057b > 8186855: Multiple platforms broken after 8186476: Generalize > Atomic::add with templates > > http://hg.openjdk.java.net/jdk/hs/rev/b7849991ae55 > 8186723: Add SuperH as new architecture for linux > > http://hg.openjdk.java.net/jdk/hs/rev/89fb7df32425 > 8186655: Identifier strings for PowerPC 64 LE and PowerPC 64 are swapped > > http://hg.openjdk.java.net/jdk/hs/rev/3cd94e2be178 > 8186443: Missing stdint.h for zero builds > > http://hg.openjdk.java.net/jdk/hs/rev/a8488a8b37fb > 8186786: Name collisions with autoconf definitions on alpha and sh > > http://hg.openjdk.java.net/jdk/hs/rev/a4fa3280b8df > 8186313: Additional platform definitions to support Zero builds > > http://hg.openjdk.java.net/jdk/hs/rev/6e1b59330482 > 8186433: Compiler flag -arch=sparc should not be passed on linux-sparc > > http://hg.openjdk.java.net/jdk/hs/rev/f4ded11e0f74 > 8186221: Define CPU search_string for M68K > > http://hg.openjdk.java.net/jdk/hs/rev/f5a564180f37 > 8182165: The header atomic_linux_sparc.inline.hpp should be named > atomic_linux_sparc.hpp > > http://hg.openjdk.java.net/jdk/hs/rev/ff7b9f61209e > 8182164: checkByteBuffer has the wrong signature > > http://hg.openjdk.java.net/jdk/hs/rev/32434b633549 > 8182163: Missing #include "logging/log.hpp" in vm_version_linux_sparc.cpp > > From martin.doerr at sap.com Wed Nov 22 15:37:19 2017 From: martin.doerr at sap.com (Doerr, Martin) Date: Wed, 22 Nov 2017 15:37:19 +0000 Subject: New JDK Committer: John Paul Adrian Glaubitz In-Reply-To: References: Message-ID: <03bdca2f72e949f78661a8d11e86eb92@sap.com> Vote: yes Best regards, Martin From goetz.lindenmaier at sap.com Wed Nov 22 16:09:03 2017 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 22 Nov 2017 16:09:03 +0000 Subject: New JDK Committer: John Paul Adrian Glaubitz In-Reply-To: References: Message-ID: <9aebf424e20d4acd886cfc8120fa7b36@sap.com> vote: yes Best regards, Goetz. > -----Original Message----- > From: jdk-dev [mailto:jdk-dev-bounces at openjdk.java.net] On Behalf Of > coleen.phillimore at oracle.com > Sent: Wednesday, November 22, 2017 3:44 PM > To: jdk-dev at openjdk.java.net > Subject: CFV: New JDK Committer: John Paul Adrian Glaubitz > > I hereby nominate John Paul Adrian Glaubitz (glaubitz) to JDK Committer. > > Adrian works for SUSE as a member of the Public Cloud Team but > contributes patches to OpenJDK in his free time as an individual > contributor. He enjoys working on various architectures that exist in > Debian. He is working to reduce the necessary patches to get OpenJDK > build on downstream distributions since this helps to relieve the > maintenance burden of the OpenJDK maintainers in Debian and SUSE. > Adrian has contributed 16 changes [3] to OpenJDK, primarily timely and > appreciated Hotspot patches to fix the Zero interpreter on multiple > platforms. > > Votes are due by December 6, 2017. > > Only current JDK Committers [1] are eligible to vote on this nomination. > > Votes must be cast in the open by replying to this mailing list. For > Lazy Consensus voting instructions, see [2]. > > Thanks, > Coleen > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/bylaws#lazy-consensus > > [3] List of changes: > > http://hg.openjdk.java.net/jdk/hs/rev/827e4ac05579 > 8191663: Zero variant broken after 8189170 and 8189871 > > http://hg.openjdk.java.net/jdk/hs/rev/0ad8a90268a7 > 8191333: Zero variant broken after 8189941 > > http://hg.openjdk.java.net/jdk/hs/rev/b140fe4ff916 > 8190570: Zero fails to build on linux-sparc due undefined reference > > http://hg.openjdk.java.net/jdk/hs/rev/0f7dce1e7690 > 8186578: Zero fails to build on linux-sparc due to sparc-specific code > > http://hg.openjdk.java.net/jdk/hs/rev/9c0137e5e37a > 8187590: Zero runtime can lock-up on linux-alpha > > http://hg.openjdk.java.net/jdk/hs/rev/4cc46bb5057b > 8186855: Multiple platforms broken after 8186476: Generalize Atomic::add > with templates > > http://hg.openjdk.java.net/jdk/hs/rev/b7849991ae55 > 8186723: Add SuperH as new architecture for linux > > http://hg.openjdk.java.net/jdk/hs/rev/89fb7df32425 > 8186655: Identifier strings for PowerPC 64 LE and PowerPC 64 are swapped > > http://hg.openjdk.java.net/jdk/hs/rev/3cd94e2be178 > 8186443: Missing stdint.h for zero builds > > http://hg.openjdk.java.net/jdk/hs/rev/a8488a8b37fb > 8186786: Name collisions with autoconf definitions on alpha and sh > > http://hg.openjdk.java.net/jdk/hs/rev/a4fa3280b8df > 8186313: Additional platform definitions to support Zero builds > > http://hg.openjdk.java.net/jdk/hs/rev/6e1b59330482 > 8186433: Compiler flag -arch=sparc should not be passed on linux-sparc > > http://hg.openjdk.java.net/jdk/hs/rev/f4ded11e0f74 > 8186221: Define CPU search_string for M68K > > http://hg.openjdk.java.net/jdk/hs/rev/f5a564180f37 > 8182165: The header atomic_linux_sparc.inline.hpp should be named > atomic_linux_sparc.hpp > > http://hg.openjdk.java.net/jdk/hs/rev/ff7b9f61209e > 8182164: checkByteBuffer has the wrong signature > > http://hg.openjdk.java.net/jdk/hs/rev/32434b633549 > 8182163: Missing #include "logging/log.hpp" in vm_version_linux_sparc.cpp From daniel.fuchs at oracle.com Wed Nov 22 16:11:45 2017 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Wed, 22 Nov 2017 16:11:45 +0000 Subject: CFV: New JDK Committer: John Paul Adrian Glaubitz In-Reply-To: References: Message-ID: Vote: yes best regards, -- daniel On 22/11/2017 14:44, coleen.phillimore at oracle.com wrote: > I hereby nominate John Paul Adrian Glaubitz (glaubitz) to JDK Committer. From serguei.spitsyn at oracle.com Thu Nov 23 00:59:47 2017 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 22 Nov 2017 16:59:47 -0800 Subject: CFV: New JDK Committer: John Paul Adrian Glaubitz In-Reply-To: References: Message-ID: <4a858eb2-b87e-6a5c-53fb-15bb56ffd3b4@oracle.com> Vote: yes From jesper.wilhelmsson at oracle.com Thu Nov 23 02:24:19 2017 From: jesper.wilhelmsson at oracle.com (jesper.wilhelmsson at oracle.com) Date: Thu, 23 Nov 2017 03:24:19 +0100 Subject: CFV: New JDK Committer: Ujwal Vangapally Message-ID: Hi, I hereby nominate Ujwal Vangapally (uvangapally) to JDK Committer. Ujwal works in the Monitor and Management team at Oracle and has contributed 14 changes to the OpenJDK. Ujwal has picked up and solved critical issues in the JMX area and is currently also responsible for analysing the M&M part of the HotSpot integration test results which (if you ask me) is a contribution in itself. Votes are due by December 7, 2017. Only current JDK Committers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [2]. Thanks, /Jesper [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/bylaws#lazy-consensus > [3] List of changes: (1) 8191313: Deprecate RMIConnectorServer.CREDENTIAL_TYPES http://hg.openjdk.java.net/jdk/hs/rev/49e605998d2b (2) 8024352: MBeanOperationInfo accepts any int value as "impact" http://hg.openjdk.java.net/jdk/hs/rev/da4fb7d2f917 (3) 8044122: MBean access to the PID http://hg.openjdk.java.net/jdk/hs/rev/fa213afbaadb (4) 8185003: JMX: Add a version of ThreadMXBean.dumpAllThreads with a maxDepth argument http://hg.openjdk.java.net/jdk/hs/rev/68d46cb9be45 (5) 8186224: javax/management/remote/mandatory/subjectDelegation/* fail with java.security.AccessControlException http://hg.openjdk.java.net/jdk/hs/rev/7c8ff90abc22 (6) 8181895: javax management docs contain links to technotes http://hg.openjdk.java.net/jdk/hs/rev/f51c14dc540f (7) 8183899: JMXConnectorFactory link to ServiceLoader gives 404 http://hg.openjdk.java.net/jdk/hs/rev/880c6fdf23e7 (8) 8178508: Co-locate remaining MM tests http://hg.openjdk.java.net/jdk/hs/rev/e7cbd383f71b (9) 8175845: Provide javadoc descriptions for jdk.hotspot.agent module http://hg.openjdk.java.net/jdk/hs/rev/265e40f06a2d http://hg.openjdk.java.net/jdk/hs/rev/1e2ad0809162 (10) 6515161: If remote removeNotificationListener gets SecurityException, client no longer gets notifications http://hg.openjdk.java.net/jdk/hs/rev/adbeae0f677e (11) 8130084: javax/management/MBeanServer/NotifDeadlockTest.java timed out http://hg.openjdk.java.net/jdk/hs/rev/ff2246213f7b (12) 8170861: Remove DcmdMBeanPermissionsTest.java from ProblemList http://hg.openjdk.java.net/jdk/hs/rev/b2e2caf26552 (13) 8168141: javax/management/remote/mandatory/notif/EmptyDomainNotificationTest.java: No notif received! http://hg.openjdk.java.net/jdk/hs/rev/d2c15c981e72 (14) 8165765: Unexpected ID for RMI connection http://hg.openjdk.java.net/jdk/hs/rev/3729cdfc89f6 From rahul.v.raghavan at oracle.com Thu Nov 23 05:47:28 2017 From: rahul.v.raghavan at oracle.com (Rahul Raghavan) Date: Thu, 23 Nov 2017 11:17:28 +0530 Subject: CFV: New JDK Committer: Ujwal Vangapally In-Reply-To: References: Message-ID: Vote: yes Thanks, Rahul On Thursday 23 November 2017 07:54 AM, jesper.wilhelmsson at oracle.com wrote: > Hi, > > I hereby nominate Ujwal Vangapally (uvangapally) to JDK Committer. > > Ujwal works in the Monitor and Management team at Oracle and has contributed 14 changes to the OpenJDK. Ujwal has picked up and solved critical issues in the JMX area and is currently also responsible for analysing the M&M part of the HotSpot integration test results which (if you ask me) is a contribution in itself. > > Votes are due by December 7, 2017. > > Only current JDK Committers [1] are eligible to vote on this nomination. > > Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [2]. > > Thanks, > /Jesper > > [1] http://openjdk.java.net/census > > [2] http://openjdk.java.net/bylaws#lazy-consensus > > [3] List of changes: > > (1) 8191313: Deprecate RMIConnectorServer.CREDENTIAL_TYPES > http://hg.openjdk.java.net/jdk/hs/rev/49e605998d2b > > (2) 8024352: MBeanOperationInfo accepts any int value as "impact" > http://hg.openjdk.java.net/jdk/hs/rev/da4fb7d2f917 > > (3) 8044122: MBean access to the PID > http://hg.openjdk.java.net/jdk/hs/rev/fa213afbaadb > > (4) 8185003: JMX: Add a version of ThreadMXBean.dumpAllThreads with a maxDepth argument > http://hg.openjdk.java.net/jdk/hs/rev/68d46cb9be45 > > (5) 8186224: javax/management/remote/mandatory/subjectDelegation/* fail with java.security.AccessControlException > http://hg.openjdk.java.net/jdk/hs/rev/7c8ff90abc22 > > (6) 8181895: javax management docs contain links to technotes > http://hg.openjdk.java.net/jdk/hs/rev/f51c14dc540f > > (7) 8183899: JMXConnectorFactory link to ServiceLoader gives 404 > http://hg.openjdk.java.net/jdk/hs/rev/880c6fdf23e7 > > (8) 8178508: Co-locate remaining MM tests > http://hg.openjdk.java.net/jdk/hs/rev/e7cbd383f71b > > (9) 8175845: Provide javadoc descriptions for jdk.hotspot.agent module > http://hg.openjdk.java.net/jdk/hs/rev/265e40f06a2d > http://hg.openjdk.java.net/jdk/hs/rev/1e2ad0809162 > > (10) 6515161: If remote removeNotificationListener gets SecurityException, client no longer gets notifications > http://hg.openjdk.java.net/jdk/hs/rev/adbeae0f677e > > (11) 8130084: javax/management/MBeanServer/NotifDeadlockTest.java timed out > http://hg.openjdk.java.net/jdk/hs/rev/ff2246213f7b > > (12) 8170861: Remove DcmdMBeanPermissionsTest.java from ProblemList > http://hg.openjdk.java.net/jdk/hs/rev/b2e2caf26552 > > (13) 8168141: javax/management/remote/mandatory/notif/EmptyDomainNotificationTest.java: No notif received! > http://hg.openjdk.java.net/jdk/hs/rev/d2c15c981e72 > > (14) 8165765: Unexpected ID for RMI connection > http://hg.openjdk.java.net/jdk/hs/rev/3729cdfc89f6 > From jini.george at oracle.com Thu Nov 23 05:54:43 2017 From: jini.george at oracle.com (Jini George) Date: Thu, 23 Nov 2017 11:24:43 +0530 Subject: CFV: New JDK Committer: Ujwal Vangapally In-Reply-To: References: Message-ID: <34d4e6d1-dc81-5357-7594-05eadb1afe37@oracle.com> Vote: yes Thanks, Jini. On 11/23/2017 7:54 AM, jesper.wilhelmsson at oracle.com wrote: > Hi, > > I hereby nominate Ujwal Vangapally (uvangapally) to JDK Committer. > > Ujwal works in the Monitor and Management team at Oracle and has contributed 14 changes to the OpenJDK. Ujwal has picked up and solved critical issues in the JMX area and is currently also responsible for analysing the M&M part of the HotSpot integration test results which (if you ask me) is a contribution in itself. > > Votes are due by December 7, 2017. > > Only current JDK Committers [1] are eligible to vote on this nomination. > > Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [2]. > > Thanks, > /Jesper > > [1] http://openjdk.java.net/census > > [2] http://openjdk.java.net/bylaws#lazy-consensus > > [3] List of changes: > > (1) 8191313: Deprecate RMIConnectorServer.CREDENTIAL_TYPES > http://hg.openjdk.java.net/jdk/hs/rev/49e605998d2b > > (2) 8024352: MBeanOperationInfo accepts any int value as "impact" > http://hg.openjdk.java.net/jdk/hs/rev/da4fb7d2f917 > > (3) 8044122: MBean access to the PID > http://hg.openjdk.java.net/jdk/hs/rev/fa213afbaadb > > (4) 8185003: JMX: Add a version of ThreadMXBean.dumpAllThreads with a maxDepth argument > http://hg.openjdk.java.net/jdk/hs/rev/68d46cb9be45 > > (5) 8186224: javax/management/remote/mandatory/subjectDelegation/* fail with java.security.AccessControlException > http://hg.openjdk.java.net/jdk/hs/rev/7c8ff90abc22 > > (6) 8181895: javax management docs contain links to technotes > http://hg.openjdk.java.net/jdk/hs/rev/f51c14dc540f > > (7) 8183899: JMXConnectorFactory link to ServiceLoader gives 404 > http://hg.openjdk.java.net/jdk/hs/rev/880c6fdf23e7 > > (8) 8178508: Co-locate remaining MM tests > http://hg.openjdk.java.net/jdk/hs/rev/e7cbd383f71b > > (9) 8175845: Provide javadoc descriptions for jdk.hotspot.agent module > http://hg.openjdk.java.net/jdk/hs/rev/265e40f06a2d > http://hg.openjdk.java.net/jdk/hs/rev/1e2ad0809162 > > (10) 6515161: If remote removeNotificationListener gets SecurityException, client no longer gets notifications > http://hg.openjdk.java.net/jdk/hs/rev/adbeae0f677e > > (11) 8130084: javax/management/MBeanServer/NotifDeadlockTest.java timed out > http://hg.openjdk.java.net/jdk/hs/rev/ff2246213f7b > > (12) 8170861: Remove DcmdMBeanPermissionsTest.java from ProblemList > http://hg.openjdk.java.net/jdk/hs/rev/b2e2caf26552 > > (13) 8168141: javax/management/remote/mandatory/notif/EmptyDomainNotificationTest.java: No notif received! > http://hg.openjdk.java.net/jdk/hs/rev/d2c15c981e72 > > (14) 8165765: Unexpected ID for RMI connection > http://hg.openjdk.java.net/jdk/hs/rev/3729cdfc89f6 > From jamsheed.c.m at oracle.com Thu Nov 23 05:57:38 2017 From: jamsheed.c.m at oracle.com (jamsheed) Date: Thu, 23 Nov 2017 11:27:38 +0530 Subject: CFV: New JDK Committer: Ujwal Vangapally In-Reply-To: References: Message-ID: <92625e11-1cd2-c361-5df8-095d7f008172@oracle.com> vote: Yes Best regards, Jamsheed On Thursday 23 November 2017 07:54 AM, jesper.wilhelmsson at oracle.com wrote: > Hi, > > I hereby nominate Ujwal Vangapally (uvangapally) to JDK Committer. > > Ujwal works in the Monitor and Management team at Oracle and has contributed 14 changes to the OpenJDK. Ujwal has picked up and solved critical issues in the JMX area and is currently also responsible for analysing the M&M part of the HotSpot integration test results which (if you ask me) is a contribution in itself. > > Votes are due by December 7, 2017. > > Only current JDK Committers [1] are eligible to vote on this nomination. > > Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [2]. > > Thanks, > /Jesper > > [1] http://openjdk.java.net/census > > [2] http://openjdk.java.net/bylaws#lazy-consensus > > [3] List of changes: > > (1) 8191313: Deprecate RMIConnectorServer.CREDENTIAL_TYPES > http://hg.openjdk.java.net/jdk/hs/rev/49e605998d2b > > (2) 8024352: MBeanOperationInfo accepts any int value as "impact" > http://hg.openjdk.java.net/jdk/hs/rev/da4fb7d2f917 > > (3) 8044122: MBean access to the PID > http://hg.openjdk.java.net/jdk/hs/rev/fa213afbaadb > > (4) 8185003: JMX: Add a version of ThreadMXBean.dumpAllThreads with a maxDepth argument > http://hg.openjdk.java.net/jdk/hs/rev/68d46cb9be45 > > (5) 8186224: javax/management/remote/mandatory/subjectDelegation/* fail with java.security.AccessControlException > http://hg.openjdk.java.net/jdk/hs/rev/7c8ff90abc22 > > (6) 8181895: javax management docs contain links to technotes > http://hg.openjdk.java.net/jdk/hs/rev/f51c14dc540f > > (7) 8183899: JMXConnectorFactory link to ServiceLoader gives 404 > http://hg.openjdk.java.net/jdk/hs/rev/880c6fdf23e7 > > (8) 8178508: Co-locate remaining MM tests > http://hg.openjdk.java.net/jdk/hs/rev/e7cbd383f71b > > (9) 8175845: Provide javadoc descriptions for jdk.hotspot.agent module > http://hg.openjdk.java.net/jdk/hs/rev/265e40f06a2d > http://hg.openjdk.java.net/jdk/hs/rev/1e2ad0809162 > > (10) 6515161: If remote removeNotificationListener gets SecurityException, client no longer gets notifications > http://hg.openjdk.java.net/jdk/hs/rev/adbeae0f677e > > (11) 8130084: javax/management/MBeanServer/NotifDeadlockTest.java timed out > http://hg.openjdk.java.net/jdk/hs/rev/ff2246213f7b > > (12) 8170861: Remove DcmdMBeanPermissionsTest.java from ProblemList > http://hg.openjdk.java.net/jdk/hs/rev/b2e2caf26552 > > (13) 8168141: javax/management/remote/mandatory/notif/EmptyDomainNotificationTest.java: No notif received! > http://hg.openjdk.java.net/jdk/hs/rev/d2c15c981e72 > > (14) 8165765: Unexpected ID for RMI connection > http://hg.openjdk.java.net/jdk/hs/rev/3729cdfc89f6 > From nishit.jain at oracle.com Thu Nov 23 06:07:57 2017 From: nishit.jain at oracle.com (Nishit Jain) Date: Thu, 23 Nov 2017 11:37:57 +0530 Subject: CFV: New JDK Committer: Ujwal Vangapally In-Reply-To: References: Message-ID: <1720a0bd-bd84-7dd2-0afe-941d7d84afb4@oracle.com> Vote: Yes Regards, Nishit Jain On 23-11-2017 07:54, jesper.wilhelmsson at oracle.com wrote: > Hi, > > I hereby nominate Ujwal Vangapally (uvangapally) to JDK Committer. > > Ujwal works in the Monitor and Management team at Oracle and has contributed 14 changes to the OpenJDK. Ujwal has picked up and solved critical issues in the JMX area and is currently also responsible for analysing the M&M part of the HotSpot integration test results which (if you ask me) is a contribution in itself. > > Votes are due by December 7, 2017. > > Only current JDK Committers [1] are eligible to vote on this nomination. > > Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [2]. > > Thanks, > /Jesper > > [1] http://openjdk.java.net/census > > [2] http://openjdk.java.net/bylaws#lazy-consensus > > [3] List of changes: > > (1) 8191313: Deprecate RMIConnectorServer.CREDENTIAL_TYPES > http://hg.openjdk.java.net/jdk/hs/rev/49e605998d2b > > (2) 8024352: MBeanOperationInfo accepts any int value as "impact" > http://hg.openjdk.java.net/jdk/hs/rev/da4fb7d2f917 > > (3) 8044122: MBean access to the PID > http://hg.openjdk.java.net/jdk/hs/rev/fa213afbaadb > > (4) 8185003: JMX: Add a version of ThreadMXBean.dumpAllThreads with a maxDepth argument > http://hg.openjdk.java.net/jdk/hs/rev/68d46cb9be45 > > (5) 8186224: javax/management/remote/mandatory/subjectDelegation/* fail with java.security.AccessControlException > http://hg.openjdk.java.net/jdk/hs/rev/7c8ff90abc22 > > (6) 8181895: javax management docs contain links to technotes > http://hg.openjdk.java.net/jdk/hs/rev/f51c14dc540f > > (7) 8183899: JMXConnectorFactory link to ServiceLoader gives 404 > http://hg.openjdk.java.net/jdk/hs/rev/880c6fdf23e7 > > (8) 8178508: Co-locate remaining MM tests > http://hg.openjdk.java.net/jdk/hs/rev/e7cbd383f71b > > (9) 8175845: Provide javadoc descriptions for jdk.hotspot.agent module > http://hg.openjdk.java.net/jdk/hs/rev/265e40f06a2d > http://hg.openjdk.java.net/jdk/hs/rev/1e2ad0809162 > > (10) 6515161: If remote removeNotificationListener gets SecurityException, client no longer gets notifications > http://hg.openjdk.java.net/jdk/hs/rev/adbeae0f677e > > (11) 8130084: javax/management/MBeanServer/NotifDeadlockTest.java timed out > http://hg.openjdk.java.net/jdk/hs/rev/ff2246213f7b > > (12) 8170861: Remove DcmdMBeanPermissionsTest.java from ProblemList > http://hg.openjdk.java.net/jdk/hs/rev/b2e2caf26552 > > (13) 8168141: javax/management/remote/mandatory/notif/EmptyDomainNotificationTest.java: No notif received! > http://hg.openjdk.java.net/jdk/hs/rev/d2c15c981e72 > > (14) 8165765: Unexpected ID for RMI connection > http://hg.openjdk.java.net/jdk/hs/rev/3729cdfc89f6 > From jayathirth.d.v at oracle.com Thu Nov 23 06:22:42 2017 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Wed, 22 Nov 2017 22:22:42 -0800 (PST) Subject: CFV: New JDK Committer: Ujwal Vangapally In-Reply-To: References: Message-ID: <0335d77c-c443-42b3-bb6f-715ec5b5817a@default> Vote : Yes. Thanks, Jay -----Original Message----- From: Jesper Wilhelmsson Sent: Thursday, November 23, 2017 7:54 AM To: jdk-dev at openjdk.java.net Subject: CFV: New JDK Committer: Ujwal Vangapally Hi, I hereby nominate Ujwal Vangapally (uvangapally) to JDK Committer. Ujwal works in the Monitor and Management team at Oracle and has contributed 14 changes to the OpenJDK. Ujwal has picked up and solved critical issues in the JMX area and is currently also responsible for analysing the M&M part of the HotSpot integration test results which (if you ask me) is a contribution in itself. Votes are due by December 7, 2017. Only current JDK Committers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [2]. Thanks, /Jesper [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/bylaws#lazy-consensus > [3] List of changes: (1) 8191313: Deprecate RMIConnectorServer.CREDENTIAL_TYPES http://hg.openjdk.java.net/jdk/hs/rev/49e605998d2b (2) 8024352: MBeanOperationInfo accepts any int value as "impact" http://hg.openjdk.java.net/jdk/hs/rev/da4fb7d2f917 (3) 8044122: MBean access to the PID http://hg.openjdk.java.net/jdk/hs/rev/fa213afbaadb (4) 8185003: JMX: Add a version of ThreadMXBean.dumpAllThreads with a maxDepth argument http://hg.openjdk.java.net/jdk/hs/rev/68d46cb9be45 (5) 8186224: javax/management/remote/mandatory/subjectDelegation/* fail with java.security.AccessControlException http://hg.openjdk.java.net/jdk/hs/rev/7c8ff90abc22 (6) 8181895: javax management docs contain links to technotes http://hg.openjdk.java.net/jdk/hs/rev/f51c14dc540f (7) 8183899: JMXConnectorFactory link to ServiceLoader gives 404 http://hg.openjdk.java.net/jdk/hs/rev/880c6fdf23e7 (8) 8178508: Co-locate remaining MM tests http://hg.openjdk.java.net/jdk/hs/rev/e7cbd383f71b (9) 8175845: Provide javadoc descriptions for jdk.hotspot.agent module http://hg.openjdk.java.net/jdk/hs/rev/265e40f06a2d http://hg.openjdk.java.net/jdk/hs/rev/1e2ad0809162 (10) 6515161: If remote removeNotificationListener gets SecurityException, client no longer gets notifications http://hg.openjdk.java.net/jdk/hs/rev/adbeae0f677e (11) 8130084: javax/management/MBeanServer/NotifDeadlockTest.java timed out http://hg.openjdk.java.net/jdk/hs/rev/ff2246213f7b (12) 8170861: Remove DcmdMBeanPermissionsTest.java from ProblemList http://hg.openjdk.java.net/jdk/hs/rev/b2e2caf26552 (13) 8168141: javax/management/remote/mandatory/notif/EmptyDomainNotificationTest.java: No notif received! http://hg.openjdk.java.net/jdk/hs/rev/d2c15c981e72 (14) 8165765: Unexpected ID for RMI connection http://hg.openjdk.java.net/jdk/hs/rev/3729cdfc89f6 From ramanand.patil at oracle.com Thu Nov 23 06:31:46 2017 From: ramanand.patil at oracle.com (Ramanand Patil) Date: Wed, 22 Nov 2017 22:31:46 -0800 (PST) Subject: CFV: New JDK Committer: Ujwal Vangapally In-Reply-To: References: Message-ID: <2111a65f-1aab-458a-a308-dfd57ca918fb@default> Vote: yes Regards, Ramanand. > -----Original Message----- > From: Jesper Wilhelmsson > Sent: Thursday, November 23, 2017 7:54 AM > To: jdk-dev at openjdk.java.net > Subject: CFV: New JDK Committer: Ujwal Vangapally > > Hi, > > I hereby nominate Ujwal Vangapally (uvangapally) to JDK Committer. > > Ujwal works in the Monitor and Management team at Oracle and has > contributed 14 changes to the OpenJDK. Ujwal has picked up and solved > critical issues in the JMX area and is currently also responsible for analysing > the M&M part of the HotSpot integration test results which (if you ask me) is > a contribution in itself. > > Votes are due by December 7, 2017. > > Only current JDK Committers [1] are eligible to vote on this nomination. > > Votes must be cast in the open by replying to this mailing list. For Lazy > Consensus voting instructions, see [2]. > > Thanks, > /Jesper > > [1] http://openjdk.java.net/census > > [2] > http://openjdk.java.net/bylaws#lazy-consensus > > > > [3] List of changes: > > (1) 8191313: Deprecate RMIConnectorServer.CREDENTIAL_TYPES > http://hg.openjdk.java.net/jdk/hs/rev/49e605998d2b > > (2) 8024352: MBeanOperationInfo accepts any int value as "impact" > http://hg.openjdk.java.net/jdk/hs/rev/da4fb7d2f917 > > (3) 8044122: MBean access to the PID > http://hg.openjdk.java.net/jdk/hs/rev/fa213afbaadb > > (4) 8185003: JMX: Add a version of ThreadMXBean.dumpAllThreads with a > maxDepth argument > http://hg.openjdk.java.net/jdk/hs/rev/68d46cb9be45 > > (5) 8186224: javax/management/remote/mandatory/subjectDelegation/* > fail with java.security.AccessControlException > http://hg.openjdk.java.net/jdk/hs/rev/7c8ff90abc22 > > (6) 8181895: javax management docs contain links to technotes > http://hg.openjdk.java.net/jdk/hs/rev/f51c14dc540f > > (7) 8183899: JMXConnectorFactory link to ServiceLoader gives 404 > http://hg.openjdk.java.net/jdk/hs/rev/880c6fdf23e7 > > (8) 8178508: Co-locate remaining MM tests > http://hg.openjdk.java.net/jdk/hs/rev/e7cbd383f71b > > (9) 8175845: Provide javadoc descriptions for jdk.hotspot.agent module > http://hg.openjdk.java.net/jdk/hs/rev/265e40f06a2d > http://hg.openjdk.java.net/jdk/hs/rev/1e2ad0809162 > > (10) 6515161: If remote removeNotificationListener gets SecurityException, > client no longer gets notifications > http://hg.openjdk.java.net/jdk/hs/rev/adbeae0f677e > > (11) 8130084: javax/management/MBeanServer/NotifDeadlockTest.java > timed out http://hg.openjdk.java.net/jdk/hs/rev/ff2246213f7b > > (12) 8170861: Remove DcmdMBeanPermissionsTest.java from ProblemList > http://hg.openjdk.java.net/jdk/hs/rev/b2e2caf26552 > > (13) 8168141: > javax/management/remote/mandatory/notif/EmptyDomainNotificationTest > .java: No notif received! > http://hg.openjdk.java.net/jdk/hs/rev/d2c15c981e72 > > (14) 8165765: Unexpected ID for RMI connection > http://hg.openjdk.java.net/jdk/hs/rev/3729cdfc89f6 > > From rachna.goel at oracle.com Thu Nov 23 06:38:56 2017 From: rachna.goel at oracle.com (Rachna Goel) Date: Thu, 23 Nov 2017 12:08:56 +0530 Subject: CFV: New JDK Committer: Ujwal Vangapally In-Reply-To: References: Message-ID: <38e790a4-4205-7dcb-6d63-27f97e88ba56@oracle.com> Vote: Yes Thanks, Rachna On 23/11/17 7:54 AM, jesper.wilhelmsson at oracle.com wrote: > Hi, > > I hereby nominate Ujwal Vangapally (uvangapally) to JDK Committer. > > Ujwal works in the Monitor and Management team at Oracle and has contributed 14 changes to the OpenJDK. Ujwal has picked up and solved critical issues in the JMX area and is currently also responsible for analysing the M&M part of the HotSpot integration test results which (if you ask me) is a contribution in itself. > > Votes are due by December 7, 2017. > > Only current JDK Committers [1] are eligible to vote on this nomination. > > Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [2]. > > Thanks, > /Jesper > > [1] http://openjdk.java.net/census > > [2] http://openjdk.java.net/bylaws#lazy-consensus > > [3] List of changes: > > (1) 8191313: Deprecate RMIConnectorServer.CREDENTIAL_TYPES > http://hg.openjdk.java.net/jdk/hs/rev/49e605998d2b > > (2) 8024352: MBeanOperationInfo accepts any int value as "impact" > http://hg.openjdk.java.net/jdk/hs/rev/da4fb7d2f917 > > (3) 8044122: MBean access to the PID > http://hg.openjdk.java.net/jdk/hs/rev/fa213afbaadb > > (4) 8185003: JMX: Add a version of ThreadMXBean.dumpAllThreads with a maxDepth argument > http://hg.openjdk.java.net/jdk/hs/rev/68d46cb9be45 > > (5) 8186224: javax/management/remote/mandatory/subjectDelegation/* fail with java.security.AccessControlException > http://hg.openjdk.java.net/jdk/hs/rev/7c8ff90abc22 > > (6) 8181895: javax management docs contain links to technotes > http://hg.openjdk.java.net/jdk/hs/rev/f51c14dc540f > > (7) 8183899: JMXConnectorFactory link to ServiceLoader gives 404 > http://hg.openjdk.java.net/jdk/hs/rev/880c6fdf23e7 > > (8) 8178508: Co-locate remaining MM tests > http://hg.openjdk.java.net/jdk/hs/rev/e7cbd383f71b > > (9) 8175845: Provide javadoc descriptions for jdk.hotspot.agent module > http://hg.openjdk.java.net/jdk/hs/rev/265e40f06a2d > http://hg.openjdk.java.net/jdk/hs/rev/1e2ad0809162 > > (10) 6515161: If remote removeNotificationListener gets SecurityException, client no longer gets notifications > http://hg.openjdk.java.net/jdk/hs/rev/adbeae0f677e > > (11) 8130084: javax/management/MBeanServer/NotifDeadlockTest.java timed out > http://hg.openjdk.java.net/jdk/hs/rev/ff2246213f7b > > (12) 8170861: Remove DcmdMBeanPermissionsTest.java from ProblemList > http://hg.openjdk.java.net/jdk/hs/rev/b2e2caf26552 > > (13) 8168141: javax/management/remote/mandatory/notif/EmptyDomainNotificationTest.java: No notif received! > http://hg.openjdk.java.net/jdk/hs/rev/d2c15c981e72 > > (14) 8165765: Unexpected ID for RMI connection > http://hg.openjdk.java.net/jdk/hs/rev/3729cdfc89f6 > -- Thanks, Rachna From manajit.halder at oracle.com Thu Nov 23 06:50:34 2017 From: manajit.halder at oracle.com (Manajit Halder) Date: Thu, 23 Nov 2017 12:20:34 +0530 Subject: CFV: New JDK Committer: Ujwal Vangapally In-Reply-To: References: Message-ID: Vote: yes Regards, Manajit > On 23-Nov-2017, at 7:54 AM, jesper.wilhelmsson at oracle.com wrote: > > Hi, > > I hereby nominate Ujwal Vangapally (uvangapally) to JDK Committer. > > Ujwal works in the Monitor and Management team at Oracle and has contributed 14 changes to the OpenJDK. Ujwal has picked up and solved critical issues in the JMX area and is currently also responsible for analysing the M&M part of the HotSpot integration test results which (if you ask me) is a contribution in itself. > > Votes are due by December 7, 2017. > > Only current JDK Committers [1] are eligible to vote on this nomination. > > Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [2]. > > Thanks, > /Jesper > > [1] http://openjdk.java.net/census > > [2] http://openjdk.java.net/bylaws#lazy-consensus > > [3] List of changes: > > (1) 8191313: Deprecate RMIConnectorServer.CREDENTIAL_TYPES > http://hg.openjdk.java.net/jdk/hs/rev/49e605998d2b > > (2) 8024352: MBeanOperationInfo accepts any int value as "impact" > http://hg.openjdk.java.net/jdk/hs/rev/da4fb7d2f917 > > (3) 8044122: MBean access to the PID > http://hg.openjdk.java.net/jdk/hs/rev/fa213afbaadb > > (4) 8185003: JMX: Add a version of ThreadMXBean.dumpAllThreads with a maxDepth argument > http://hg.openjdk.java.net/jdk/hs/rev/68d46cb9be45 > > (5) 8186224: javax/management/remote/mandatory/subjectDelegation/* fail with java.security.AccessControlException > http://hg.openjdk.java.net/jdk/hs/rev/7c8ff90abc22 > > (6) 8181895: javax management docs contain links to technotes > http://hg.openjdk.java.net/jdk/hs/rev/f51c14dc540f > > (7) 8183899: JMXConnectorFactory link to ServiceLoader gives 404 > http://hg.openjdk.java.net/jdk/hs/rev/880c6fdf23e7 > > (8) 8178508: Co-locate remaining MM tests > http://hg.openjdk.java.net/jdk/hs/rev/e7cbd383f71b > > (9) 8175845: Provide javadoc descriptions for jdk.hotspot.agent module > http://hg.openjdk.java.net/jdk/hs/rev/265e40f06a2d > http://hg.openjdk.java.net/jdk/hs/rev/1e2ad0809162 > > (10) 6515161: If remote removeNotificationListener gets SecurityException, client no longer gets notifications > http://hg.openjdk.java.net/jdk/hs/rev/adbeae0f677e > > (11) 8130084: javax/management/MBeanServer/NotifDeadlockTest.java timed out > http://hg.openjdk.java.net/jdk/hs/rev/ff2246213f7b > > (12) 8170861: Remove DcmdMBeanPermissionsTest.java from ProblemList > http://hg.openjdk.java.net/jdk/hs/rev/b2e2caf26552 > > (13) 8168141: javax/management/remote/mandatory/notif/EmptyDomainNotificationTest.java: No notif received! > http://hg.openjdk.java.net/jdk/hs/rev/d2c15c981e72 > > (14) 8165765: Unexpected ID for RMI connection > http://hg.openjdk.java.net/jdk/hs/rev/3729cdfc89f6 > From volker.simonis at gmail.com Thu Nov 23 08:00:54 2017 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 23 Nov 2017 09:00:54 +0100 Subject: CFV: New JDK Committer: John Paul Adrian Glaubitz In-Reply-To: References: Message-ID: Vote: yes On Wed, Nov 22, 2017 at 3:44 PM, wrote: > I hereby nominate John Paul Adrian Glaubitz (glaubitz) to JDK Committer. > > Adrian works for SUSE as a member of the Public Cloud Team but contributes > patches to OpenJDK in his free time as an individual contributor. He enjoys > working on various architectures that exist in Debian. He is working to > reduce the necessary patches to get OpenJDK build on downstream > distributions since this helps to relieve the maintenance burden of the > OpenJDK maintainers in Debian and SUSE. Adrian has contributed 16 changes > [3] to OpenJDK, primarily timely and appreciated Hotspot patches to fix the > Zero interpreter on multiple platforms. > > Votes are due by December 6, 2017. > > Only current JDK Committers [1] are eligible to vote on this nomination. > > Votes must be cast in the open by replying to this mailing list. For Lazy > Consensus voting instructions, see [2]. > > Thanks, > Coleen > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/bylaws#lazy-consensus > > [3] List of changes: > > http://hg.openjdk.java.net/jdk/hs/rev/827e4ac05579 > 8191663: Zero variant broken after 8189170 and 8189871 > > http://hg.openjdk.java.net/jdk/hs/rev/0ad8a90268a7 > 8191333: Zero variant broken after 8189941 > > http://hg.openjdk.java.net/jdk/hs/rev/b140fe4ff916 > 8190570: Zero fails to build on linux-sparc due undefined reference > > http://hg.openjdk.java.net/jdk/hs/rev/0f7dce1e7690 > 8186578: Zero fails to build on linux-sparc due to sparc-specific code > > http://hg.openjdk.java.net/jdk/hs/rev/9c0137e5e37a > 8187590: Zero runtime can lock-up on linux-alpha > > http://hg.openjdk.java.net/jdk/hs/rev/4cc46bb5057b > 8186855: Multiple platforms broken after 8186476: Generalize Atomic::add > with templates > > http://hg.openjdk.java.net/jdk/hs/rev/b7849991ae55 > 8186723: Add SuperH as new architecture for linux > > http://hg.openjdk.java.net/jdk/hs/rev/89fb7df32425 > 8186655: Identifier strings for PowerPC 64 LE and PowerPC 64 are swapped > > http://hg.openjdk.java.net/jdk/hs/rev/3cd94e2be178 > 8186443: Missing stdint.h for zero builds > > http://hg.openjdk.java.net/jdk/hs/rev/a8488a8b37fb > 8186786: Name collisions with autoconf definitions on alpha and sh > > http://hg.openjdk.java.net/jdk/hs/rev/a4fa3280b8df > 8186313: Additional platform definitions to support Zero builds > > http://hg.openjdk.java.net/jdk/hs/rev/6e1b59330482 > 8186433: Compiler flag -arch=sparc should not be passed on linux-sparc > > http://hg.openjdk.java.net/jdk/hs/rev/f4ded11e0f74 > 8186221: Define CPU search_string for M68K > > http://hg.openjdk.java.net/jdk/hs/rev/f5a564180f37 > 8182165: The header atomic_linux_sparc.inline.hpp should be named > atomic_linux_sparc.hpp > > http://hg.openjdk.java.net/jdk/hs/rev/ff7b9f61209e > 8182164: checkByteBuffer has the wrong signature > > http://hg.openjdk.java.net/jdk/hs/rev/32434b633549 > 8182163: Missing #include "logging/log.hpp" in vm_version_linux_sparc.cpp > From nadeesh.thatathil.valappu at mdcpartners.be Thu Nov 23 08:04:41 2017 From: nadeesh.thatathil.valappu at mdcpartners.be (Nadeesh TV) Date: Thu, 23 Nov 2017 09:04:41 +0100 Subject: CFV: New JDK Committer: Ujwal Vangapally In-Reply-To: References: Message-ID: <3542f1fa-e055-42d4-b87c-4ee233b37459@mdcpartners.be> Vote : Yes Regards, Nadeesh On 23/11/2017 03:24, jesper.wilhelmsson at oracle.com wrote: > Hi, > > I hereby nominate Ujwal Vangapally (uvangapally) to JDK Committer. > > Ujwal works in the Monitor and Management team at Oracle and has contributed 14 changes to the OpenJDK. Ujwal has picked up and solved critical issues in the JMX area and is currently also responsible for analysing the M&M part of the HotSpot integration test results which (if you ask me) is a contribution in itself. > > Votes are due by December 7, 2017. > > Only current JDK Committers [1] are eligible to vote on this nomination. > > Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [2]. > > Thanks, > /Jesper > > [1] http://openjdk.java.net/census > > [2] http://openjdk.java.net/bylaws#lazy-consensus > > [3] List of changes: > > (1) 8191313: Deprecate RMIConnectorServer.CREDENTIAL_TYPES > http://hg.openjdk.java.net/jdk/hs/rev/49e605998d2b > > (2) 8024352: MBeanOperationInfo accepts any int value as "impact" > http://hg.openjdk.java.net/jdk/hs/rev/da4fb7d2f917 > > (3) 8044122: MBean access to the PID > http://hg.openjdk.java.net/jdk/hs/rev/fa213afbaadb > > (4) 8185003: JMX: Add a version of ThreadMXBean.dumpAllThreads with a maxDepth argument > http://hg.openjdk.java.net/jdk/hs/rev/68d46cb9be45 > > (5) 8186224: javax/management/remote/mandatory/subjectDelegation/* fail with java.security.AccessControlException > http://hg.openjdk.java.net/jdk/hs/rev/7c8ff90abc22 > > (6) 8181895: javax management docs contain links to technotes > http://hg.openjdk.java.net/jdk/hs/rev/f51c14dc540f > > (7) 8183899: JMXConnectorFactory link to ServiceLoader gives 404 > http://hg.openjdk.java.net/jdk/hs/rev/880c6fdf23e7 > > (8) 8178508: Co-locate remaining MM tests > http://hg.openjdk.java.net/jdk/hs/rev/e7cbd383f71b > > (9) 8175845: Provide javadoc descriptions for jdk.hotspot.agent module > http://hg.openjdk.java.net/jdk/hs/rev/265e40f06a2d > http://hg.openjdk.java.net/jdk/hs/rev/1e2ad0809162 > > (10) 6515161: If remote removeNotificationListener gets SecurityException, client no longer gets notifications > http://hg.openjdk.java.net/jdk/hs/rev/adbeae0f677e > > (11) 8130084: javax/management/MBeanServer/NotifDeadlockTest.java timed out > http://hg.openjdk.java.net/jdk/hs/rev/ff2246213f7b > > (12) 8170861: Remove DcmdMBeanPermissionsTest.java from ProblemList > http://hg.openjdk.java.net/jdk/hs/rev/b2e2caf26552 > > (13) 8168141: javax/management/remote/mandatory/notif/EmptyDomainNotificationTest.java: No notif received! > http://hg.openjdk.java.net/jdk/hs/rev/d2c15c981e72 > > (14) 8165765: Unexpected ID for RMI connection > http://hg.openjdk.java.net/jdk/hs/rev/3729cdfc89f6 > From dalibor.topic at oracle.com Thu Nov 23 08:48:44 2017 From: dalibor.topic at oracle.com (dalibor topic) Date: Thu, 23 Nov 2017 09:48:44 +0100 Subject: CFV: New JDK Committer: Ujwal Vangapally In-Reply-To: References: Message-ID: <087bfc97-04e4-fa37-c441-ad5d4180dcad@oracle.com> Vote: Yes. -- Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile: +491737185961 ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher Oracle is committed to developing practices and products that help protect the environment From sgehwolf at redhat.com Thu Nov 23 08:56:51 2017 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Thu, 23 Nov 2017 09:56:51 +0100 Subject: CFV: New JDK Committer: John Paul Adrian Glaubitz In-Reply-To: References: Message-ID: <1511427411.4103.0.camel@redhat.com> On Wed, 2017-11-22 at 09:44 -0500, coleen.phillimore at oracle.com wrote: > I hereby nominate John Paul Adrian Glaubitz (glaubitz) to JDK > Committer. Vote: yes Thanks, Severin From patric.hedlin at oracle.com Thu Nov 23 11:50:27 2017 From: patric.hedlin at oracle.com (Patric Hedlin) Date: Thu, 23 Nov 2017 12:50:27 +0100 Subject: CFV: New JDK Committer: John Paul Adrian Glaubitz In-Reply-To: References: Message-ID: Vote: Yes On 11/22/2017 03:44 PM, coleen.phillimore at oracle.com wrote: > I hereby nominate John Paul Adrian Glaubitz (glaubitz) to JDK Committer. > > Adrian works for SUSE as a member of the Public Cloud Team but > contributes patches to OpenJDK in his free time as an individual > contributor. He enjoys working on various architectures that exist in > Debian. He is working to reduce the necessary patches to get OpenJDK > build on downstream distributions since this helps to relieve the > maintenance burden of the OpenJDK maintainers in Debian and SUSE. > Adrian has contributed 16 changes [3] to OpenJDK, primarily timely and > appreciated Hotspot patches to fix the Zero interpreter on multiple > platforms. > > Votes are due by December 6, 2017. > > Only current JDK Committers [1] are eligible to vote on this nomination. > > Votes must be cast in the open by replying to this mailing list. For > Lazy Consensus voting instructions, see [2]. > > Thanks, > Coleen > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/bylaws#lazy-consensus > > [3] List of changes: > > http://hg.openjdk.java.net/jdk/hs/rev/827e4ac05579 > 8191663: Zero variant broken after 8189170 and 8189871 > > http://hg.openjdk.java.net/jdk/hs/rev/0ad8a90268a7 > 8191333: Zero variant broken after 8189941 > > http://hg.openjdk.java.net/jdk/hs/rev/b140fe4ff916 > 8190570: Zero fails to build on linux-sparc due undefined reference > > http://hg.openjdk.java.net/jdk/hs/rev/0f7dce1e7690 > 8186578: Zero fails to build on linux-sparc due to sparc-specific code > > http://hg.openjdk.java.net/jdk/hs/rev/9c0137e5e37a > 8187590: Zero runtime can lock-up on linux-alpha > > http://hg.openjdk.java.net/jdk/hs/rev/4cc46bb5057b > 8186855: Multiple platforms broken after 8186476: Generalize > Atomic::add with templates > > http://hg.openjdk.java.net/jdk/hs/rev/b7849991ae55 > 8186723: Add SuperH as new architecture for linux > > http://hg.openjdk.java.net/jdk/hs/rev/89fb7df32425 > 8186655: Identifier strings for PowerPC 64 LE and PowerPC 64 are swapped > > http://hg.openjdk.java.net/jdk/hs/rev/3cd94e2be178 > 8186443: Missing stdint.h for zero builds > > http://hg.openjdk.java.net/jdk/hs/rev/a8488a8b37fb > 8186786: Name collisions with autoconf definitions on alpha and sh > > http://hg.openjdk.java.net/jdk/hs/rev/a4fa3280b8df > 8186313: Additional platform definitions to support Zero builds > > http://hg.openjdk.java.net/jdk/hs/rev/6e1b59330482 > 8186433: Compiler flag -arch=sparc should not be passed on linux-sparc > > http://hg.openjdk.java.net/jdk/hs/rev/f4ded11e0f74 > 8186221: Define CPU search_string for M68K > > http://hg.openjdk.java.net/jdk/hs/rev/f5a564180f37 > 8182165: The header atomic_linux_sparc.inline.hpp should be named > atomic_linux_sparc.hpp > > http://hg.openjdk.java.net/jdk/hs/rev/ff7b9f61209e > 8182164: checkByteBuffer has the wrong signature > > http://hg.openjdk.java.net/jdk/hs/rev/32434b633549 > 8182163: Missing #include "logging/log.hpp" in vm_version_linux_sparc.cpp > From vladimir.x.ivanov at oracle.com Thu Nov 23 12:01:54 2017 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Thu, 23 Nov 2017 15:01:54 +0300 Subject: CFV: New JDK Committer: John Paul Adrian Glaubitz In-Reply-To: References: Message-ID: Vote: yes Best regards, Vladimir Ivanov On 11/22/17 5:44 PM, coleen.phillimore at oracle.com wrote: > I hereby nominate John Paul Adrian Glaubitz (glaubitz) to JDK Committer. From thomas.schatzl at oracle.com Thu Nov 23 15:12:05 2017 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Thu, 23 Nov 2017 16:12:05 +0100 Subject: CFV: New JDK Committer: Alexander Harlap Message-ID: <1511449925.2477.20.camel@oracle.com> I hereby nominate Alexander Harlap (aharlap) to JDK Committer. Alexander works for Oracle as a member of the Garbage Collection team, and has in total contributed 22 changesets in various areas of the Hotspot VM [3]. Votes are due by December 7, 2017. Only current JDK Committers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [2]. Thanks, Coleen [1] http://openjdk.java.net/census [2] http://openjdk.java.net/bylaws#lazy-consensus [3] List of changes: (1) 8005204: Code Cache Reduction: command line options implementation http://hg.openjdk.java.net/jdk/jdk/rev/f3d755b11424 (2) 8005639: Move InlineSynchronizedMethods flag from develop to product http://hg.openjdk.java.net/jdk/jdk/rev/73bac1831823 (3) 8185591: guarantee(_byte_map[_guard_index] == last_card) failed: card table guard has been modified http://hg.openjdk.java.net/jdk/hs/rev/62d5973082e3 (4) 8187819: gc/TestFullGCALot.java fails on jdk10 started with "-XX:- UseCompressedOops" option http://hg.openjdk.java.net/jdk/hs/rev/72855b7d10ac (5) 8183973: gc/TestFullGCALot.java fails in JDK10-hs nightly http://hg.openjdk.java.net/jdk/hs/rev/71f1b50a1c6c (6) 8184045: TestSystemGCWithG1.java times out on Solaris SPARC http://hg.openjdk.java.net/jdk/hs/rev/01dc8e9d2da3 (7) 8178507: co-locate nsk.regression.gc tests http://hg.openjdk.java.net/jdk/hs/rev/cbe334268a4c (8) 8065402: G1 does not expand marking stack when mark stack overflow happens during concurrent marking http://hg.openjdk.java.net/jdk/hs/rev/dbb55d89699c (9) 8178542: G1: VM hangs during shutdown due to mark stack overflow http://hg.openjdk.java.net/jdk/hs/rev/62fac1c2c841 (10) 8165674: G1CMMarkStack::out_of_memory possibly redundant http://hg.openjdk.java.net/jdk/hs/rev/a587da3329a5 (11) 8151045: Remove code duplication in PLABStats/G1EvacStats::adjust_desired_plab_sz http://hg.openjdk.java.net/jdk/hs/rev/3c4c1591507d (12) 8140588: Internal Error: gc/g1/ptrQueue.hpp:126 assert(_index == _sz) failed: invariant: queues are empty when activated http://hg.openjdk.java.net/jdk/hs/rev/21041ea7c0fe (13) 8147906: G1 use of os::processor_count() http://hg.openjdk.java.net/jdk/hs/rev/98c7219214df (14) 8145038: Simplify mut_process_buffer worker id management http://hg.openjdk.java.net/jdk/hs/rev/53825bdb41a0 (15) 8145037: Clean up FreeIdSet usage http://hg.openjdk.java.net/jdk/hs/rev/34ab60aee787 (16) 8141123: Cleanup in FreeIdSet http://hg.openjdk.java.net/jdk/hs/rev/d00805788fdd (17) 8141135: Remove G1RemSet::write_ref http://hg.openjdk.java.net/jdk/hs/rev/7c558c120803 (18) 8139664: Delete ConcurrentMarkSweepThread::is_ConcurrentGC_thread() http://hg.openjdk.java.net/jdk/hs/rev/69416bbe5e84 (19) 8130265: gctests/LargeObjects/large001 fails with OutOfMemoryError: Java heap space http://hg.openjdk.java.net/jdk/hs/rev/6714a3872d8f (20) 8067460: G1: TestResourceManagementFlagWithCommercialBuild.java failed on embedded platform http://hg.openjdk.java.net/jdk/hs/rev/da47c3cc5c98 (21) 8059492: Wrong spelling in assert: "Not initialied properly?" http://hg.openjdk.java.net/jdk/hs/rev/3eee985a97e7 (22) 8011152: Precision problems on sflt builds http://hg.openjdk.java.net/jdk/hs/rev/b2bf9afdd360 From thomas.schatzl at oracle.com Thu Nov 23 15:13:10 2017 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Thu, 23 Nov 2017 16:13:10 +0100 Subject: CFV: New JDK Committer: Alexander Harlap In-Reply-To: <1511449925.2477.20.camel@oracle.com> References: <1511449925.2477.20.camel@oracle.com> Message-ID: <1511449990.2477.21.camel@oracle.com> Vote: yes On Thu, 2017-11-23 at 16:12 +0100, Thomas Schatzl wrote: > I hereby nominate Alexander Harlap (aharlap) to JDK Committer. > > Alexander works for Oracle as a member of the Garbage Collection > team, > and has in total contributed 22 changesets in various areas of the > Hotspot VM [3]. > > Votes are due by December 7, 2017. > > Only current JDK Committers [1] are eligible to vote on this > nomination. > > Votes must be cast in the open by replying to this mailing list. For > Lazy Consensus voting instructions, see [2]. > > Thanks, > Coleen > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/bylaws#lazy-consensus > > [3] List of changes: > > (1) 8005204: Code Cache Reduction: command line options > implementation > http://hg.openjdk.java.net/jdk/jdk/rev/f3d755b11424 > > (2) 8005639: Move InlineSynchronizedMethods flag from develop to > product > http://hg.openjdk.java.net/jdk/jdk/rev/73bac1831823 > > (3) 8185591: guarantee(_byte_map[_guard_index] == last_card) failed: > card table guard has been modified > http://hg.openjdk.java.net/jdk/hs/rev/62d5973082e3 > > (4) 8187819: gc/TestFullGCALot.java fails on jdk10 started with "- > XX:- > UseCompressedOops" option > http://hg.openjdk.java.net/jdk/hs/rev/72855b7d10ac > > (5) 8183973: gc/TestFullGCALot.java fails in JDK10-hs nightly > http://hg.openjdk.java.net/jdk/hs/rev/71f1b50a1c6c > > (6) 8184045: TestSystemGCWithG1.java times out on Solaris SPARC > http://hg.openjdk.java.net/jdk/hs/rev/01dc8e9d2da3 > > (7) 8178507: co-locate nsk.regression.gc tests > http://hg.openjdk.java.net/jdk/hs/rev/cbe334268a4c > > (8) 8065402: G1 does not expand marking stack when mark stack > overflow > happens during concurrent marking > http://hg.openjdk.java.net/jdk/hs/rev/dbb55d89699c > > (9) 8178542: G1: VM hangs during shutdown due to mark stack overflow > http://hg.openjdk.java.net/jdk/hs/rev/62fac1c2c841 > > (10) 8165674: G1CMMarkStack::out_of_memory possibly redundant > http://hg.openjdk.java.net/jdk/hs/rev/a587da3329a5 > > (11) 8151045: Remove code duplication in > PLABStats/G1EvacStats::adjust_desired_plab_sz > http://hg.openjdk.java.net/jdk/hs/rev/3c4c1591507d > > (12) 8140588: Internal Error: gc/g1/ptrQueue.hpp:126 assert(_index == > _sz) failed: invariant: queues are empty when activated > http://hg.openjdk.java.net/jdk/hs/rev/21041ea7c0fe > > (13) 8147906: G1 use of os::processor_count() > http://hg.openjdk.java.net/jdk/hs/rev/98c7219214df > > (14) 8145038: Simplify mut_process_buffer worker id management > http://hg.openjdk.java.net/jdk/hs/rev/53825bdb41a0 > > (15) 8145037: Clean up FreeIdSet usage > http://hg.openjdk.java.net/jdk/hs/rev/34ab60aee787 > > (16) 8141123: Cleanup in FreeIdSet > http://hg.openjdk.java.net/jdk/hs/rev/d00805788fdd > > (17) 8141135: Remove G1RemSet::write_ref > http://hg.openjdk.java.net/jdk/hs/rev/7c558c120803 > > (18) 8139664: Delete > ConcurrentMarkSweepThread::is_ConcurrentGC_thread() > http://hg.openjdk.java.net/jdk/hs/rev/69416bbe5e84 > > (19) 8130265: gctests/LargeObjects/large001 fails with > OutOfMemoryError: Java heap space > http://hg.openjdk.java.net/jdk/hs/rev/6714a3872d8f > > (20) 8067460: G1: TestResourceManagementFlagWithCommercialBuild.java > failed on embedded platform > http://hg.openjdk.java.net/jdk/hs/rev/da47c3cc5c98 > > (21) 8059492: Wrong spelling in assert: "Not initialied properly?" > http://hg.openjdk.java.net/jdk/hs/rev/3eee985a97e7 > > (22) 8011152: Precision problems on sflt builds > http://hg.openjdk.java.net/jdk/hs/rev/b2bf9afdd360 > From dalibor.topic at oracle.com Thu Nov 23 15:13:21 2017 From: dalibor.topic at oracle.com (dalibor topic) Date: Thu, 23 Nov 2017 16:13:21 +0100 Subject: CFV: New JDK Committer: Alexander Harlap In-Reply-To: <1511449925.2477.20.camel@oracle.com> References: <1511449925.2477.20.camel@oracle.com> Message-ID: Vote: Yes. -- Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile: +491737185961 ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher Oracle is committed to developing practices and products that help protect the environment From thomas.schatzl at oracle.com Thu Nov 23 15:14:49 2017 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Thu, 23 Nov 2017 16:14:49 +0100 Subject: CFV: New JDK Committer: Alexander Harlap In-Reply-To: <1511449925.2477.20.camel@oracle.com> References: <1511449925.2477.20.camel@oracle.com> Message-ID: <1511450089.2477.22.camel@oracle.com> Hi, On Thu, 2017-11-23 at 16:12 +0100, Thomas Schatzl wrote: > I hereby nominate Alexander Harlap (aharlap) to JDK Committer. > > Alexander works for Oracle as a member of the Garbage Collection > team, > and has in total contributed 22 changesets in various areas of the > Hotspot VM [3]. > > Votes are due by December 7, 2017. > > Only current JDK Committers [1] are eligible to vote on this > nomination. > > Votes must be cast in the open by replying to this mailing list. For > Lazy Consensus voting instructions, see [2]. > > Thanks, > Coleen ^^^^ copy&paste error, sorry Coleen :) Thanks, Thomas > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/bylaws#lazy-consensus > > [3] List of changes: > > (1) 8005204: Code Cache Reduction: command line options > implementation > http://hg.openjdk.java.net/jdk/jdk/rev/f3d755b11424 > > (2) 8005639: Move InlineSynchronizedMethods flag from develop to > product > http://hg.openjdk.java.net/jdk/jdk/rev/73bac1831823 > > (3) 8185591: guarantee(_byte_map[_guard_index] == last_card) failed: > card table guard has been modified > http://hg.openjdk.java.net/jdk/hs/rev/62d5973082e3 > > (4) 8187819: gc/TestFullGCALot.java fails on jdk10 started with "- > XX:- > UseCompressedOops" option > http://hg.openjdk.java.net/jdk/hs/rev/72855b7d10ac > > (5) 8183973: gc/TestFullGCALot.java fails in JDK10-hs nightly > http://hg.openjdk.java.net/jdk/hs/rev/71f1b50a1c6c > > (6) 8184045: TestSystemGCWithG1.java times out on Solaris SPARC > http://hg.openjdk.java.net/jdk/hs/rev/01dc8e9d2da3 > > (7) 8178507: co-locate nsk.regression.gc tests > http://hg.openjdk.java.net/jdk/hs/rev/cbe334268a4c > > (8) 8065402: G1 does not expand marking stack when mark stack > overflow > happens during concurrent marking > http://hg.openjdk.java.net/jdk/hs/rev/dbb55d89699c > > (9) 8178542: G1: VM hangs during shutdown due to mark stack overflow > http://hg.openjdk.java.net/jdk/hs/rev/62fac1c2c841 > > (10) 8165674: G1CMMarkStack::out_of_memory possibly redundant > http://hg.openjdk.java.net/jdk/hs/rev/a587da3329a5 > > (11) 8151045: Remove code duplication in > PLABStats/G1EvacStats::adjust_desired_plab_sz > http://hg.openjdk.java.net/jdk/hs/rev/3c4c1591507d > > (12) 8140588: Internal Error: gc/g1/ptrQueue.hpp:126 assert(_index == > _sz) failed: invariant: queues are empty when activated > http://hg.openjdk.java.net/jdk/hs/rev/21041ea7c0fe > > (13) 8147906: G1 use of os::processor_count() > http://hg.openjdk.java.net/jdk/hs/rev/98c7219214df > > (14) 8145038: Simplify mut_process_buffer worker id management > http://hg.openjdk.java.net/jdk/hs/rev/53825bdb41a0 > > (15) 8145037: Clean up FreeIdSet usage > http://hg.openjdk.java.net/jdk/hs/rev/34ab60aee787 > > (16) 8141123: Cleanup in FreeIdSet > http://hg.openjdk.java.net/jdk/hs/rev/d00805788fdd > > (17) 8141135: Remove G1RemSet::write_ref > http://hg.openjdk.java.net/jdk/hs/rev/7c558c120803 > > (18) 8139664: Delete > ConcurrentMarkSweepThread::is_ConcurrentGC_thread() > http://hg.openjdk.java.net/jdk/hs/rev/69416bbe5e84 > > (19) 8130265: gctests/LargeObjects/large001 fails with > OutOfMemoryError: Java heap space > http://hg.openjdk.java.net/jdk/hs/rev/6714a3872d8f > > (20) 8067460: G1: TestResourceManagementFlagWithCommercialBuild.java > failed on embedded platform > http://hg.openjdk.java.net/jdk/hs/rev/da47c3cc5c98 > > (21) 8059492: Wrong spelling in assert: "Not initialied properly?" > http://hg.openjdk.java.net/jdk/hs/rev/3eee985a97e7 > > (22) 8011152: Precision problems on sflt builds > http://hg.openjdk.java.net/jdk/hs/rev/b2bf9afdd360 > From vladimir.x.ivanov at oracle.com Thu Nov 23 15:28:18 2017 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Thu, 23 Nov 2017 18:28:18 +0300 Subject: CFV: New JDK Committer: Alexander Harlap In-Reply-To: <1511449925.2477.20.camel@oracle.com> References: <1511449925.2477.20.camel@oracle.com> Message-ID: <556d9428-2ac4-1640-e211-58d002953552@oracle.com> Vote: yes Best regards, Vladimir Ivanov On 11/23/17 6:12 PM, Thomas Schatzl wrote: > I hereby nominate Alexander Harlap (aharlap) to JDK Committer. From vladimir.kozlov at oracle.com Thu Nov 23 18:12:54 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 23 Nov 2017 10:12:54 -0800 Subject: CFV: New JDK Committer: Alexander Harlap In-Reply-To: <1511449925.2477.20.camel@oracle.com> References: <1511449925.2477.20.camel@oracle.com> Message-ID: <48088b8f-df46-bc6c-9fa9-dc4267108a99@oracle.com> Vote: yes On 11/23/17 7:12 AM, Thomas Schatzl wrote: > I hereby nominate Alexander Harlap (aharlap) to JDK Committer. > > Alexander works for Oracle as a member of the Garbage Collection team, > and has in total contributed 22 changesets in various areas of the > Hotspot VM [3]. > > Votes are due by December 7, 2017. > > Only current JDK Committers [1] are eligible to vote on this > nomination. > > Votes must be cast in the open by replying to this mailing list. For > Lazy Consensus voting instructions, see [2]. > > Thanks, > Coleen > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/bylaws#lazy-consensus > > [3] List of changes: > > (1) 8005204: Code Cache Reduction: command line options implementation > http://hg.openjdk.java.net/jdk/jdk/rev/f3d755b11424 > > (2) 8005639: Move InlineSynchronizedMethods flag from develop to > product > http://hg.openjdk.java.net/jdk/jdk/rev/73bac1831823 > > (3) 8185591: guarantee(_byte_map[_guard_index] == last_card) failed: > card table guard has been modified > http://hg.openjdk.java.net/jdk/hs/rev/62d5973082e3 > > (4) 8187819: gc/TestFullGCALot.java fails on jdk10 started with "-XX:- > UseCompressedOops" option > http://hg.openjdk.java.net/jdk/hs/rev/72855b7d10ac > > (5) 8183973: gc/TestFullGCALot.java fails in JDK10-hs nightly > http://hg.openjdk.java.net/jdk/hs/rev/71f1b50a1c6c > > (6) 8184045: TestSystemGCWithG1.java times out on Solaris SPARC > http://hg.openjdk.java.net/jdk/hs/rev/01dc8e9d2da3 > > (7) 8178507: co-locate nsk.regression.gc tests > http://hg.openjdk.java.net/jdk/hs/rev/cbe334268a4c > > (8) 8065402: G1 does not expand marking stack when mark stack overflow > happens during concurrent marking > http://hg.openjdk.java.net/jdk/hs/rev/dbb55d89699c > > (9) 8178542: G1: VM hangs during shutdown due to mark stack overflow > http://hg.openjdk.java.net/jdk/hs/rev/62fac1c2c841 > > (10) 8165674: G1CMMarkStack::out_of_memory possibly redundant > http://hg.openjdk.java.net/jdk/hs/rev/a587da3329a5 > > (11) 8151045: Remove code duplication in > PLABStats/G1EvacStats::adjust_desired_plab_sz > http://hg.openjdk.java.net/jdk/hs/rev/3c4c1591507d > > (12) 8140588: Internal Error: gc/g1/ptrQueue.hpp:126 assert(_index == > _sz) failed: invariant: queues are empty when activated > http://hg.openjdk.java.net/jdk/hs/rev/21041ea7c0fe > > (13) 8147906: G1 use of os::processor_count() > http://hg.openjdk.java.net/jdk/hs/rev/98c7219214df > > (14) 8145038: Simplify mut_process_buffer worker id management > http://hg.openjdk.java.net/jdk/hs/rev/53825bdb41a0 > > (15) 8145037: Clean up FreeIdSet usage > http://hg.openjdk.java.net/jdk/hs/rev/34ab60aee787 > > (16) 8141123: Cleanup in FreeIdSet > http://hg.openjdk.java.net/jdk/hs/rev/d00805788fdd > > (17) 8141135: Remove G1RemSet::write_ref > http://hg.openjdk.java.net/jdk/hs/rev/7c558c120803 > > (18) 8139664: Delete > ConcurrentMarkSweepThread::is_ConcurrentGC_thread() > http://hg.openjdk.java.net/jdk/hs/rev/69416bbe5e84 > > (19) 8130265: gctests/LargeObjects/large001 fails with > OutOfMemoryError: Java heap space > http://hg.openjdk.java.net/jdk/hs/rev/6714a3872d8f > > (20) 8067460: G1: TestResourceManagementFlagWithCommercialBuild.java > failed on embedded platform > http://hg.openjdk.java.net/jdk/hs/rev/da47c3cc5c98 > > (21) 8059492: Wrong spelling in assert: "Not initialied properly?" > http://hg.openjdk.java.net/jdk/hs/rev/3eee985a97e7 > > (22) 8011152: Precision problems on sflt builds > http://hg.openjdk.java.net/jdk/hs/rev/b2bf9afdd360 > From jesper.wilhelmsson at oracle.com Thu Nov 23 18:21:57 2017 From: jesper.wilhelmsson at oracle.com (jesper.wilhelmsson at oracle.com) Date: Thu, 23 Nov 2017 19:21:57 +0100 Subject: CFV: New JDK Committer: Alexander Harlap In-Reply-To: <1511449925.2477.20.camel@oracle.com> References: <1511449925.2477.20.camel@oracle.com> Message-ID: Vote: Yes /Jesper > On 23 Nov 2017, at 16:12, Thomas Schatzl wrote: > > I hereby nominate Alexander Harlap (aharlap) to JDK Committer. > > Alexander works for Oracle as a member of the Garbage Collection team, > and has in total contributed 22 changesets in various areas of the > Hotspot VM [3]. > > Votes are due by December 7, 2017. > > Only current JDK Committers [1] are eligible to vote on this > nomination. > > Votes must be cast in the open by replying to this mailing list. For > Lazy Consensus voting instructions, see [2]. > > Thanks, > Coleen > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/bylaws#lazy-consensus > > [3] List of changes: > > (1) 8005204: Code Cache Reduction: command line options implementation > http://hg.openjdk.java.net/jdk/jdk/rev/f3d755b11424 > > (2) 8005639: Move InlineSynchronizedMethods flag from develop to > product > http://hg.openjdk.java.net/jdk/jdk/rev/73bac1831823 > > (3) 8185591: guarantee(_byte_map[_guard_index] == last_card) failed: > card table guard has been modified > http://hg.openjdk.java.net/jdk/hs/rev/62d5973082e3 > > (4) 8187819: gc/TestFullGCALot.java fails on jdk10 started with "-XX:- > UseCompressedOops" option > http://hg.openjdk.java.net/jdk/hs/rev/72855b7d10ac > > (5) 8183973: gc/TestFullGCALot.java fails in JDK10-hs nightly > http://hg.openjdk.java.net/jdk/hs/rev/71f1b50a1c6c > > (6) 8184045: TestSystemGCWithG1.java times out on Solaris SPARC > http://hg.openjdk.java.net/jdk/hs/rev/01dc8e9d2da3 > > (7) 8178507: co-locate nsk.regression.gc tests > http://hg.openjdk.java.net/jdk/hs/rev/cbe334268a4c > > (8) 8065402: G1 does not expand marking stack when mark stack overflow > happens during concurrent marking > http://hg.openjdk.java.net/jdk/hs/rev/dbb55d89699c > > (9) 8178542: G1: VM hangs during shutdown due to mark stack overflow > http://hg.openjdk.java.net/jdk/hs/rev/62fac1c2c841 > > (10) 8165674: G1CMMarkStack::out_of_memory possibly redundant > http://hg.openjdk.java.net/jdk/hs/rev/a587da3329a5 > > (11) 8151045: Remove code duplication in > PLABStats/G1EvacStats::adjust_desired_plab_sz > http://hg.openjdk.java.net/jdk/hs/rev/3c4c1591507d > > (12) 8140588: Internal Error: gc/g1/ptrQueue.hpp:126 assert(_index == > _sz) failed: invariant: queues are empty when activated > http://hg.openjdk.java.net/jdk/hs/rev/21041ea7c0fe > > (13) 8147906: G1 use of os::processor_count() > http://hg.openjdk.java.net/jdk/hs/rev/98c7219214df > > (14) 8145038: Simplify mut_process_buffer worker id management > http://hg.openjdk.java.net/jdk/hs/rev/53825bdb41a0 > > (15) 8145037: Clean up FreeIdSet usage > http://hg.openjdk.java.net/jdk/hs/rev/34ab60aee787 > > (16) 8141123: Cleanup in FreeIdSet > http://hg.openjdk.java.net/jdk/hs/rev/d00805788fdd > > (17) 8141135: Remove G1RemSet::write_ref > http://hg.openjdk.java.net/jdk/hs/rev/7c558c120803 > > (18) 8139664: Delete > ConcurrentMarkSweepThread::is_ConcurrentGC_thread() > http://hg.openjdk.java.net/jdk/hs/rev/69416bbe5e84 > > (19) 8130265: gctests/LargeObjects/large001 fails with > OutOfMemoryError: Java heap space > http://hg.openjdk.java.net/jdk/hs/rev/6714a3872d8f > > (20) 8067460: G1: TestResourceManagementFlagWithCommercialBuild.java > failed on embedded platform > http://hg.openjdk.java.net/jdk/hs/rev/da47c3cc5c98 > > (21) 8059492: Wrong spelling in assert: "Not initialied properly?" > http://hg.openjdk.java.net/jdk/hs/rev/3eee985a97e7 > > (22) 8011152: Precision problems on sflt builds > http://hg.openjdk.java.net/jdk/hs/rev/b2bf9afdd360 > From jesper.wilhelmsson at oracle.com Thu Nov 23 18:23:26 2017 From: jesper.wilhelmsson at oracle.com (jesper.wilhelmsson at oracle.com) Date: Thu, 23 Nov 2017 19:23:26 +0100 Subject: CFV: New JDK Committer: Ujwal Vangapally In-Reply-To: References: Message-ID: <50313DD2-7CAE-4433-B3D3-F17237A437C2@oracle.com> vote: yes /Jesper > On 23 Nov 2017, at 03:24, jesper.wilhelmsson at oracle.com wrote: > > Hi, > > I hereby nominate Ujwal Vangapally (uvangapally) to JDK Committer. > > Ujwal works in the Monitor and Management team at Oracle and has contributed 14 changes to the OpenJDK. Ujwal has picked up and solved critical issues in the JMX area and is currently also responsible for analysing the M&M part of the HotSpot integration test results which (if you ask me) is a contribution in itself. > > Votes are due by December 7, 2017. > > Only current JDK Committers [1] are eligible to vote on this nomination. > > Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [2]. > > Thanks, > /Jesper > > [1] http://openjdk.java.net/census > > [2] http://openjdk.java.net/bylaws#lazy-consensus > > [3] List of changes: > > (1) 8191313: Deprecate RMIConnectorServer.CREDENTIAL_TYPES > http://hg.openjdk.java.net/jdk/hs/rev/49e605998d2b > > (2) 8024352: MBeanOperationInfo accepts any int value as "impact" > http://hg.openjdk.java.net/jdk/hs/rev/da4fb7d2f917 > > (3) 8044122: MBean access to the PID > http://hg.openjdk.java.net/jdk/hs/rev/fa213afbaadb > > (4) 8185003: JMX: Add a version of ThreadMXBean.dumpAllThreads with a maxDepth argument > http://hg.openjdk.java.net/jdk/hs/rev/68d46cb9be45 > > (5) 8186224: javax/management/remote/mandatory/subjectDelegation/* fail with java.security.AccessControlException > http://hg.openjdk.java.net/jdk/hs/rev/7c8ff90abc22 > > (6) 8181895: javax management docs contain links to technotes > http://hg.openjdk.java.net/jdk/hs/rev/f51c14dc540f > > (7) 8183899: JMXConnectorFactory link to ServiceLoader gives 404 > http://hg.openjdk.java.net/jdk/hs/rev/880c6fdf23e7 > > (8) 8178508: Co-locate remaining MM tests > http://hg.openjdk.java.net/jdk/hs/rev/e7cbd383f71b > > (9) 8175845: Provide javadoc descriptions for jdk.hotspot.agent module > http://hg.openjdk.java.net/jdk/hs/rev/265e40f06a2d > http://hg.openjdk.java.net/jdk/hs/rev/1e2ad0809162 > > (10) 6515161: If remote removeNotificationListener gets SecurityException, client no longer gets notifications > http://hg.openjdk.java.net/jdk/hs/rev/adbeae0f677e > > (11) 8130084: javax/management/MBeanServer/NotifDeadlockTest.java timed out > http://hg.openjdk.java.net/jdk/hs/rev/ff2246213f7b > > (12) 8170861: Remove DcmdMBeanPermissionsTest.java from ProblemList > http://hg.openjdk.java.net/jdk/hs/rev/b2e2caf26552 > > (13) 8168141: javax/management/remote/mandatory/notif/EmptyDomainNotificationTest.java: No notif received! > http://hg.openjdk.java.net/jdk/hs/rev/d2c15c981e72 > > (14) 8165765: Unexpected ID for RMI connection > http://hg.openjdk.java.net/jdk/hs/rev/3729cdfc89f6 > From mandy.chung at oracle.com Thu Nov 23 21:42:36 2017 From: mandy.chung at oracle.com (mandy chung) Date: Thu, 23 Nov 2017 13:42:36 -0800 Subject: CFV: New JDK Committer: Ujwal Vangapally In-Reply-To: References: Message-ID: Vote: yes Mandy From serguei.spitsyn at oracle.com Thu Nov 23 21:49:02 2017 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 23 Nov 2017 13:49:02 -0800 Subject: CFV: New JDK Committer: Ujwal Vangapally In-Reply-To: References: Message-ID: <639607e1-8dcd-5545-9d4c-d5ac40fb6551@oracle.com> Vote: yes From serguei.spitsyn at oracle.com Thu Nov 23 21:49:21 2017 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 23 Nov 2017 13:49:21 -0800 Subject: CFV: New JDK Committer: Alexander Harlap In-Reply-To: <1511449925.2477.20.camel@oracle.com> References: <1511449925.2477.20.camel@oracle.com> Message-ID: <4e83eaed-ef34-9d23-b87a-73e64a819955@oracle.com> Vote: yes From stefan.johansson at oracle.com Fri Nov 24 08:46:45 2017 From: stefan.johansson at oracle.com (Stefan Johansson) Date: Fri, 24 Nov 2017 09:46:45 +0100 Subject: CFV: New JDK Committer: Alexander Harlap In-Reply-To: <1511449925.2477.20.camel@oracle.com> References: <1511449925.2477.20.camel@oracle.com> Message-ID: <9ac0ed42-4bcb-9697-3b29-3f3810b64fd2@oracle.com> Vote: yes On 2017-11-23 16:12, Thomas Schatzl wrote: > I hereby nominate Alexander Harlap (aharlap) to JDK Committer. > > Alexander works for Oracle as a member of the Garbage Collection team, > and has in total contributed 22 changesets in various areas of the > Hotspot VM [3]. > > Votes are due by December 7, 2017. > > Only current JDK Committers [1] are eligible to vote on this > nomination. > > Votes must be cast in the open by replying to this mailing list. For > Lazy Consensus voting instructions, see [2]. > > Thanks, > Coleen > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/bylaws#lazy-consensus > > [3] List of changes: > > (1) 8005204: Code Cache Reduction: command line options implementation > http://hg.openjdk.java.net/jdk/jdk/rev/f3d755b11424 > > (2) 8005639: Move InlineSynchronizedMethods flag from develop to > product > http://hg.openjdk.java.net/jdk/jdk/rev/73bac1831823 > > (3) 8185591: guarantee(_byte_map[_guard_index] == last_card) failed: > card table guard has been modified > http://hg.openjdk.java.net/jdk/hs/rev/62d5973082e3 > > (4) 8187819: gc/TestFullGCALot.java fails on jdk10 started with "-XX:- > UseCompressedOops" option > http://hg.openjdk.java.net/jdk/hs/rev/72855b7d10ac > > (5) 8183973: gc/TestFullGCALot.java fails in JDK10-hs nightly > http://hg.openjdk.java.net/jdk/hs/rev/71f1b50a1c6c > > (6) 8184045: TestSystemGCWithG1.java times out on Solaris SPARC > http://hg.openjdk.java.net/jdk/hs/rev/01dc8e9d2da3 > > (7) 8178507: co-locate nsk.regression.gc tests > http://hg.openjdk.java.net/jdk/hs/rev/cbe334268a4c > > (8) 8065402: G1 does not expand marking stack when mark stack overflow > happens during concurrent marking > http://hg.openjdk.java.net/jdk/hs/rev/dbb55d89699c > > (9) 8178542: G1: VM hangs during shutdown due to mark stack overflow > http://hg.openjdk.java.net/jdk/hs/rev/62fac1c2c841 > > (10) 8165674: G1CMMarkStack::out_of_memory possibly redundant > http://hg.openjdk.java.net/jdk/hs/rev/a587da3329a5 > > (11) 8151045: Remove code duplication in > PLABStats/G1EvacStats::adjust_desired_plab_sz > http://hg.openjdk.java.net/jdk/hs/rev/3c4c1591507d > > (12) 8140588: Internal Error: gc/g1/ptrQueue.hpp:126 assert(_index == > _sz) failed: invariant: queues are empty when activated > http://hg.openjdk.java.net/jdk/hs/rev/21041ea7c0fe > > (13) 8147906: G1 use of os::processor_count() > http://hg.openjdk.java.net/jdk/hs/rev/98c7219214df > > (14) 8145038: Simplify mut_process_buffer worker id management > http://hg.openjdk.java.net/jdk/hs/rev/53825bdb41a0 > > (15) 8145037: Clean up FreeIdSet usage > http://hg.openjdk.java.net/jdk/hs/rev/34ab60aee787 > > (16) 8141123: Cleanup in FreeIdSet > http://hg.openjdk.java.net/jdk/hs/rev/d00805788fdd > > (17) 8141135: Remove G1RemSet::write_ref > http://hg.openjdk.java.net/jdk/hs/rev/7c558c120803 > > (18) 8139664: Delete > ConcurrentMarkSweepThread::is_ConcurrentGC_thread() > http://hg.openjdk.java.net/jdk/hs/rev/69416bbe5e84 > > (19) 8130265: gctests/LargeObjects/large001 fails with > OutOfMemoryError: Java heap space > http://hg.openjdk.java.net/jdk/hs/rev/6714a3872d8f > > (20) 8067460: G1: TestResourceManagementFlagWithCommercialBuild.java > failed on embedded platform > http://hg.openjdk.java.net/jdk/hs/rev/da47c3cc5c98 > > (21) 8059492: Wrong spelling in assert: "Not initialied properly?" > http://hg.openjdk.java.net/jdk/hs/rev/3eee985a97e7 > > (22) 8011152: Precision problems on sflt builds > http://hg.openjdk.java.net/jdk/hs/rev/b2bf9afdd360 > From daniel.fuchs at oracle.com Fri Nov 24 10:12:27 2017 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Fri, 24 Nov 2017 10:12:27 +0000 Subject: CFV: New JDK Committer: Ujwal Vangapally In-Reply-To: References: Message-ID: Vote: yes best regards, -- daniel On 23/11/2017 02:24, jesper.wilhelmsson at oracle.com wrote: > Hi, > > I hereby nominate Ujwal Vangapally (uvangapally) to JDK Committer. From erik.helin at oracle.com Fri Nov 24 12:32:51 2017 From: erik.helin at oracle.com (Erik Helin) Date: Fri, 24 Nov 2017 13:32:51 +0100 Subject: CFV: New JDK Committer: Alexander Harlap In-Reply-To: <1511449925.2477.20.camel@oracle.com> References: <1511449925.2477.20.camel@oracle.com> Message-ID: Vote: yes Thanks, Erik On 11/23/2017 04:12 PM, Thomas Schatzl wrote: > I hereby nominate Alexander Harlap (aharlap) to JDK Committer. > > Alexander works for Oracle as a member of the Garbage Collection team, > and has in total contributed 22 changesets in various areas of the > Hotspot VM [3]. > > Votes are due by December 7, 2017. > > Only current JDK Committers [1] are eligible to vote on this > nomination. > > Votes must be cast in the open by replying to this mailing list. For > Lazy Consensus voting instructions, see [2]. > > Thanks, > Coleen > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/bylaws#lazy-consensus > > [3] List of changes: > > (1) 8005204: Code Cache Reduction: command line options implementation > http://hg.openjdk.java.net/jdk/jdk/rev/f3d755b11424 > > (2) 8005639: Move InlineSynchronizedMethods flag from develop to > product > http://hg.openjdk.java.net/jdk/jdk/rev/73bac1831823 > > (3) 8185591: guarantee(_byte_map[_guard_index] == last_card) failed: > card table guard has been modified > http://hg.openjdk.java.net/jdk/hs/rev/62d5973082e3 > > (4) 8187819: gc/TestFullGCALot.java fails on jdk10 started with "-XX:- > UseCompressedOops" option > http://hg.openjdk.java.net/jdk/hs/rev/72855b7d10ac > > (5) 8183973: gc/TestFullGCALot.java fails in JDK10-hs nightly > http://hg.openjdk.java.net/jdk/hs/rev/71f1b50a1c6c > > (6) 8184045: TestSystemGCWithG1.java times out on Solaris SPARC > http://hg.openjdk.java.net/jdk/hs/rev/01dc8e9d2da3 > > (7) 8178507: co-locate nsk.regression.gc tests > http://hg.openjdk.java.net/jdk/hs/rev/cbe334268a4c > > (8) 8065402: G1 does not expand marking stack when mark stack overflow > happens during concurrent marking > http://hg.openjdk.java.net/jdk/hs/rev/dbb55d89699c > > (9) 8178542: G1: VM hangs during shutdown due to mark stack overflow > http://hg.openjdk.java.net/jdk/hs/rev/62fac1c2c841 > > (10) 8165674: G1CMMarkStack::out_of_memory possibly redundant > http://hg.openjdk.java.net/jdk/hs/rev/a587da3329a5 > > (11) 8151045: Remove code duplication in > PLABStats/G1EvacStats::adjust_desired_plab_sz > http://hg.openjdk.java.net/jdk/hs/rev/3c4c1591507d > > (12) 8140588: Internal Error: gc/g1/ptrQueue.hpp:126 assert(_index == > _sz) failed: invariant: queues are empty when activated > http://hg.openjdk.java.net/jdk/hs/rev/21041ea7c0fe > > (13) 8147906: G1 use of os::processor_count() > http://hg.openjdk.java.net/jdk/hs/rev/98c7219214df > > (14) 8145038: Simplify mut_process_buffer worker id management > http://hg.openjdk.java.net/jdk/hs/rev/53825bdb41a0 > > (15) 8145037: Clean up FreeIdSet usage > http://hg.openjdk.java.net/jdk/hs/rev/34ab60aee787 > > (16) 8141123: Cleanup in FreeIdSet > http://hg.openjdk.java.net/jdk/hs/rev/d00805788fdd > > (17) 8141135: Remove G1RemSet::write_ref > http://hg.openjdk.java.net/jdk/hs/rev/7c558c120803 > > (18) 8139664: Delete > ConcurrentMarkSweepThread::is_ConcurrentGC_thread() > http://hg.openjdk.java.net/jdk/hs/rev/69416bbe5e84 > > (19) 8130265: gctests/LargeObjects/large001 fails with > OutOfMemoryError: Java heap space > http://hg.openjdk.java.net/jdk/hs/rev/6714a3872d8f > > (20) 8067460: G1: TestResourceManagementFlagWithCommercialBuild.java > failed on embedded platform > http://hg.openjdk.java.net/jdk/hs/rev/da47c3cc5c98 > > (21) 8059492: Wrong spelling in assert: "Not initialied properly?" > http://hg.openjdk.java.net/jdk/hs/rev/3eee985a97e7 > > (22) 8011152: Precision problems on sflt builds > http://hg.openjdk.java.net/jdk/hs/rev/b2bf9afdd360 > From thomas.stuefe at gmail.com Fri Nov 24 16:58:39 2017 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Fri, 24 Nov 2017 17:58:39 +0100 Subject: CFV: New JDK Committer: John Paul Adrian Glaubitz In-Reply-To: References: Message-ID: Vote: yes! On Wed, Nov 22, 2017 at 3:44 PM, wrote: > I hereby nominate John Paul Adrian Glaubitz (glaubitz) to JDK Committer. > > Adrian works for SUSE as a member of the Public Cloud Team but contributes > patches to OpenJDK in his free time as an individual contributor. He enjoys > working on various architectures that exist in Debian. He is working to > reduce the necessary patches to get OpenJDK build on downstream > distributions since this helps to relieve the maintenance burden of the > OpenJDK maintainers in Debian and SUSE. Adrian has contributed 16 changes > [3] to OpenJDK, primarily timely and appreciated Hotspot patches to fix the > Zero interpreter on multiple platforms. > > Votes are due by December 6, 2017. > > Only current JDK Committers [1] are eligible to vote on this nomination. > > Votes must be cast in the open by replying to this mailing list. For Lazy > Consensus voting instructions, see [2]. > > Thanks, > Coleen > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/bylaws#lazy-consensus < > http://openjdk.java.net/bylaws#lazy-consensus> > [3] List of changes: > > http://hg.openjdk.java.net/jdk/hs/rev/827e4ac05579 > 8191663: Zero variant broken after 8189170 and 8189871 > > http://hg.openjdk.java.net/jdk/hs/rev/0ad8a90268a7 > 8191333: Zero variant broken after 8189941 > > http://hg.openjdk.java.net/jdk/hs/rev/b140fe4ff916 > 8190570: Zero fails to build on linux-sparc due undefined reference > > http://hg.openjdk.java.net/jdk/hs/rev/0f7dce1e7690 > 8186578: Zero fails to build on linux-sparc due to sparc-specific code > > http://hg.openjdk.java.net/jdk/hs/rev/9c0137e5e37a > 8187590: Zero runtime can lock-up on linux-alpha > > http://hg.openjdk.java.net/jdk/hs/rev/4cc46bb5057b > 8186855: Multiple platforms broken after 8186476: Generalize Atomic::add > with templates > > http://hg.openjdk.java.net/jdk/hs/rev/b7849991ae55 > 8186723: Add SuperH as new architecture for linux > > http://hg.openjdk.java.net/jdk/hs/rev/89fb7df32425 > 8186655: Identifier strings for PowerPC 64 LE and PowerPC 64 are swapped > > http://hg.openjdk.java.net/jdk/hs/rev/3cd94e2be178 > 8186443: Missing stdint.h for zero builds > > http://hg.openjdk.java.net/jdk/hs/rev/a8488a8b37fb > 8186786: Name collisions with autoconf definitions on alpha and sh > > http://hg.openjdk.java.net/jdk/hs/rev/a4fa3280b8df > 8186313: Additional platform definitions to support Zero builds > > http://hg.openjdk.java.net/jdk/hs/rev/6e1b59330482 > 8186433: Compiler flag -arch=sparc should not be passed on linux-sparc > > http://hg.openjdk.java.net/jdk/hs/rev/f4ded11e0f74 > 8186221: Define CPU search_string for M68K > > http://hg.openjdk.java.net/jdk/hs/rev/f5a564180f37 > 8182165: The header atomic_linux_sparc.inline.hpp should be named > atomic_linux_sparc.hpp > > http://hg.openjdk.java.net/jdk/hs/rev/ff7b9f61209e > 8182164: checkByteBuffer has the wrong signature > > http://hg.openjdk.java.net/jdk/hs/rev/32434b633549 > 8182163: Missing #include "logging/log.hpp" in vm_version_linux_sparc.cpp > > From aleksej.efimov at oracle.com Fri Nov 24 18:23:58 2017 From: aleksej.efimov at oracle.com (Aleks Efimov) Date: Fri, 24 Nov 2017 18:23:58 +0000 Subject: CFV: New JDK Committer: John Paul Adrian Glaubitz In-Reply-To: References: Message-ID: <85ed91dc-d7af-85f1-09f3-2493e08e7636@oracle.com> Vote: yes On 11/22/2017 02:44 PM, coleen.phillimore at oracle.com wrote: > I hereby nominate John Paul Adrian Glaubitz (glaubitz) to JDK Committer. > > Adrian works for SUSE as a member of the Public Cloud Team but > contributes patches to OpenJDK in his free time as an individual > contributor. He enjoys working on various architectures that exist in > Debian. He is working to reduce the necessary patches to get OpenJDK > build on downstream distributions since this helps to relieve the > maintenance burden of the OpenJDK maintainers in Debian and SUSE.? > Adrian has contributed 16 changes [3] to OpenJDK, primarily timely and > appreciated Hotspot patches to fix the Zero interpreter on multiple > platforms. > > Votes are due by December 6, 2017. > > Only current JDK Committers [1] are eligible to vote on this nomination. > > Votes must be cast in the open by replying to this mailing list. For > Lazy Consensus voting instructions, see [2]. > > Thanks, > Coleen > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/bylaws#lazy-consensus > > [3] List of changes: > > http://hg.openjdk.java.net/jdk/hs/rev/827e4ac05579 > 8191663: Zero variant broken after 8189170 and 8189871 > > http://hg.openjdk.java.net/jdk/hs/rev/0ad8a90268a7 > 8191333: Zero variant broken after 8189941 > > http://hg.openjdk.java.net/jdk/hs/rev/b140fe4ff916 > 8190570: Zero fails to build on linux-sparc due undefined reference > > http://hg.openjdk.java.net/jdk/hs/rev/0f7dce1e7690 > 8186578: Zero fails to build on linux-sparc due to sparc-specific code > > http://hg.openjdk.java.net/jdk/hs/rev/9c0137e5e37a > 8187590: Zero runtime can lock-up on linux-alpha > > http://hg.openjdk.java.net/jdk/hs/rev/4cc46bb5057b > 8186855: Multiple platforms broken after 8186476: Generalize > Atomic::add with templates > > http://hg.openjdk.java.net/jdk/hs/rev/b7849991ae55 > 8186723: Add SuperH as new architecture for linux > > http://hg.openjdk.java.net/jdk/hs/rev/89fb7df32425 > 8186655: Identifier strings for PowerPC 64 LE and PowerPC 64 are swapped > > http://hg.openjdk.java.net/jdk/hs/rev/3cd94e2be178 > 8186443: Missing stdint.h for zero builds > > http://hg.openjdk.java.net/jdk/hs/rev/a8488a8b37fb > 8186786: Name collisions with autoconf definitions on alpha and sh > > http://hg.openjdk.java.net/jdk/hs/rev/a4fa3280b8df > 8186313: Additional platform definitions to support Zero builds > > http://hg.openjdk.java.net/jdk/hs/rev/6e1b59330482 > 8186433: Compiler flag -arch=sparc should not be passed on linux-sparc > > http://hg.openjdk.java.net/jdk/hs/rev/f4ded11e0f74 > 8186221: Define CPU search_string for M68K > > http://hg.openjdk.java.net/jdk/hs/rev/f5a564180f37 > 8182165: The header atomic_linux_sparc.inline.hpp should be named > atomic_linux_sparc.hpp > > http://hg.openjdk.java.net/jdk/hs/rev/ff7b9f61209e > 8182164: checkByteBuffer has the wrong signature > > http://hg.openjdk.java.net/jdk/hs/rev/32434b633549 > 8182163: Missing #include "logging/log.hpp" in vm_version_linux_sparc.cpp > From Derek.White at cavium.com Fri Nov 24 18:36:59 2017 From: Derek.White at cavium.com (White, Derek) Date: Fri, 24 Nov 2017 18:36:59 +0000 Subject: CFV: New JDK Committer: Alexander Harlap In-Reply-To: References: <1511449925.2477.20.camel@oracle.com>, Message-ID: <64647822-5CD6-4E39-A333-94C24674833C@cavium.com> Vote: yes On Nov 24, 2017, at 7:34 AM, Erik Helin > wrote: Vote: yes Thanks, Erik On 11/23/2017 04:12 PM, Thomas Schatzl wrote: I hereby nominate Alexander Harlap (aharlap) to JDK Committer. Alexander works for Oracle as a member of the Garbage Collection team, and has in total contributed 22 changesets in various areas of the Hotspot VM [3]. Votes are due by December 7, 2017. Only current JDK Committers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [2]. Thanks, Coleen [1] http://openjdk.java.net/census [2] http://openjdk.java.net/bylaws#lazy-consensus [3] List of changes: (1) 8005204: Code Cache Reduction: command line options implementation http://hg.openjdk.java.net/jdk/jdk/rev/f3d755b11424 (2) 8005639: Move InlineSynchronizedMethods flag from develop to product http://hg.openjdk.java.net/jdk/jdk/rev/73bac1831823 (3) 8185591: guarantee(_byte_map[_guard_index] == last_card) failed: card table guard has been modified http://hg.openjdk.java.net/jdk/hs/rev/62d5973082e3 (4) 8187819: gc/TestFullGCALot.java fails on jdk10 started with "-XX:- UseCompressedOops" option http://hg.openjdk.java.net/jdk/hs/rev/72855b7d10ac (5) 8183973: gc/TestFullGCALot.java fails in JDK10-hs nightly http://hg.openjdk.java.net/jdk/hs/rev/71f1b50a1c6c (6) 8184045: TestSystemGCWithG1.java times out on Solaris SPARC http://hg.openjdk.java.net/jdk/hs/rev/01dc8e9d2da3 (7) 8178507: co-locate nsk.regression.gc tests http://hg.openjdk.java.net/jdk/hs/rev/cbe334268a4c (8) 8065402: G1 does not expand marking stack when mark stack overflow happens during concurrent marking http://hg.openjdk.java.net/jdk/hs/rev/dbb55d89699c (9) 8178542: G1: VM hangs during shutdown due to mark stack overflow http://hg.openjdk.java.net/jdk/hs/rev/62fac1c2c841 (10) 8165674: G1CMMarkStack::out_of_memory possibly redundant http://hg.openjdk.java.net/jdk/hs/rev/a587da3329a5 (11) 8151045: Remove code duplication in PLABStats/G1EvacStats::adjust_desired_plab_sz http://hg.openjdk.java.net/jdk/hs/rev/3c4c1591507d (12) 8140588: Internal Error: gc/g1/ptrQueue.hpp:126 assert(_index == _sz) failed: invariant: queues are empty when activated http://hg.openjdk.java.net/jdk/hs/rev/21041ea7c0fe (13) 8147906: G1 use of os::processor_count() http://hg.openjdk.java.net/jdk/hs/rev/98c7219214df (14) 8145038: Simplify mut_process_buffer worker id management http://hg.openjdk.java.net/jdk/hs/rev/53825bdb41a0 (15) 8145037: Clean up FreeIdSet usage http://hg.openjdk.java.net/jdk/hs/rev/34ab60aee787 (16) 8141123: Cleanup in FreeIdSet http://hg.openjdk.java.net/jdk/hs/rev/d00805788fdd (17) 8141135: Remove G1RemSet::write_ref http://hg.openjdk.java.net/jdk/hs/rev/7c558c120803 (18) 8139664: Delete ConcurrentMarkSweepThread::is_ConcurrentGC_thread() http://hg.openjdk.java.net/jdk/hs/rev/69416bbe5e84 (19) 8130265: gctests/LargeObjects/large001 fails with OutOfMemoryError: Java heap space http://hg.openjdk.java.net/jdk/hs/rev/6714a3872d8f (20) 8067460: G1: TestResourceManagementFlagWithCommercialBuild.java failed on embedded platform http://hg.openjdk.java.net/jdk/hs/rev/da47c3cc5c98 (21) 8059492: Wrong spelling in assert: "Not initialied properly?" http://hg.openjdk.java.net/jdk/hs/rev/3eee985a97e7 (22) 8011152: Precision problems on sflt builds http://hg.openjdk.java.net/jdk/hs/rev/b2bf9afdd360 From per.liden at oracle.com Fri Nov 24 21:54:03 2017 From: per.liden at oracle.com (Per Liden) Date: Fri, 24 Nov 2017 22:54:03 +0100 Subject: CFV: New JDK Committer: Alexander Harlap In-Reply-To: <1511449925.2477.20.camel@oracle.com> References: <1511449925.2477.20.camel@oracle.com> Message-ID: Vote: yes /Per On 2017-11-23 16:12, Thomas Schatzl wrote: > I hereby nominate Alexander Harlap (aharlap) to JDK Committer. > > Alexander works for Oracle as a member of the Garbage Collection team, > and has in total contributed 22 changesets in various areas of the > Hotspot VM [3]. > > Votes are due by December 7, 2017. > > Only current JDK Committers [1] are eligible to vote on this > nomination. > > Votes must be cast in the open by replying to this mailing list. For > Lazy Consensus voting instructions, see [2]. > > Thanks, > Coleen > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/bylaws#lazy-consensus > > [3] List of changes: > > (1) 8005204: Code Cache Reduction: command line options implementation > http://hg.openjdk.java.net/jdk/jdk/rev/f3d755b11424 > > (2) 8005639: Move InlineSynchronizedMethods flag from develop to > product > http://hg.openjdk.java.net/jdk/jdk/rev/73bac1831823 > > (3) 8185591: guarantee(_byte_map[_guard_index] == last_card) failed: > card table guard has been modified > http://hg.openjdk.java.net/jdk/hs/rev/62d5973082e3 > > (4) 8187819: gc/TestFullGCALot.java fails on jdk10 started with "-XX:- > UseCompressedOops" option > http://hg.openjdk.java.net/jdk/hs/rev/72855b7d10ac > > (5) 8183973: gc/TestFullGCALot.java fails in JDK10-hs nightly > http://hg.openjdk.java.net/jdk/hs/rev/71f1b50a1c6c > > (6) 8184045: TestSystemGCWithG1.java times out on Solaris SPARC > http://hg.openjdk.java.net/jdk/hs/rev/01dc8e9d2da3 > > (7) 8178507: co-locate nsk.regression.gc tests > http://hg.openjdk.java.net/jdk/hs/rev/cbe334268a4c > > (8) 8065402: G1 does not expand marking stack when mark stack overflow > happens during concurrent marking > http://hg.openjdk.java.net/jdk/hs/rev/dbb55d89699c > > (9) 8178542: G1: VM hangs during shutdown due to mark stack overflow > http://hg.openjdk.java.net/jdk/hs/rev/62fac1c2c841 > > (10) 8165674: G1CMMarkStack::out_of_memory possibly redundant > http://hg.openjdk.java.net/jdk/hs/rev/a587da3329a5 > > (11) 8151045: Remove code duplication in > PLABStats/G1EvacStats::adjust_desired_plab_sz > http://hg.openjdk.java.net/jdk/hs/rev/3c4c1591507d > > (12) 8140588: Internal Error: gc/g1/ptrQueue.hpp:126 assert(_index == > _sz) failed: invariant: queues are empty when activated > http://hg.openjdk.java.net/jdk/hs/rev/21041ea7c0fe > > (13) 8147906: G1 use of os::processor_count() > http://hg.openjdk.java.net/jdk/hs/rev/98c7219214df > > (14) 8145038: Simplify mut_process_buffer worker id management > http://hg.openjdk.java.net/jdk/hs/rev/53825bdb41a0 > > (15) 8145037: Clean up FreeIdSet usage > http://hg.openjdk.java.net/jdk/hs/rev/34ab60aee787 > > (16) 8141123: Cleanup in FreeIdSet > http://hg.openjdk.java.net/jdk/hs/rev/d00805788fdd > > (17) 8141135: Remove G1RemSet::write_ref > http://hg.openjdk.java.net/jdk/hs/rev/7c558c120803 > > (18) 8139664: Delete > ConcurrentMarkSweepThread::is_ConcurrentGC_thread() > http://hg.openjdk.java.net/jdk/hs/rev/69416bbe5e84 > > (19) 8130265: gctests/LargeObjects/large001 fails with > OutOfMemoryError: Java heap space > http://hg.openjdk.java.net/jdk/hs/rev/6714a3872d8f > > (20) 8067460: G1: TestResourceManagementFlagWithCommercialBuild.java > failed on embedded platform > http://hg.openjdk.java.net/jdk/hs/rev/da47c3cc5c98 > > (21) 8059492: Wrong spelling in assert: "Not initialied properly?" > http://hg.openjdk.java.net/jdk/hs/rev/3eee985a97e7 > > (22) 8011152: Precision problems on sflt builds > http://hg.openjdk.java.net/jdk/hs/rev/b2bf9afdd360 > From joe.darcy at oracle.com Mon Nov 27 01:55:17 2017 From: joe.darcy at oracle.com (joe darcy) Date: Sun, 26 Nov 2017 17:55:17 -0800 Subject: CFV: New JDK Committer: Ujwal Vangapally In-Reply-To: References: Message-ID: Vote: yes Cheers, -Joe On 11/22/2017 6:24 PM, jesper.wilhelmsson at oracle.com wrote: > Hi, > > I hereby nominate Ujwal Vangapally (uvangapally) to JDK Committer. > > Ujwal works in the Monitor and Management team at Oracle and has contributed 14 changes to the OpenJDK. Ujwal has picked up and solved critical issues in the JMX area and is currently also responsible for analysing the M&M part of the HotSpot integration test results which (if you ask me) is a contribution in itself. > > Votes are due by December 7, 2017. > > Only current JDK Committers [1] are eligible to vote on this nomination. > > Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [2]. > > Thanks, > /Jesper > > [1] http://openjdk.java.net/census > > [2] http://openjdk.java.net/bylaws#lazy-consensus > > [3] List of changes: > > (1) 8191313: Deprecate RMIConnectorServer.CREDENTIAL_TYPES > http://hg.openjdk.java.net/jdk/hs/rev/49e605998d2b > > (2) 8024352: MBeanOperationInfo accepts any int value as "impact" > http://hg.openjdk.java.net/jdk/hs/rev/da4fb7d2f917 > > (3) 8044122: MBean access to the PID > http://hg.openjdk.java.net/jdk/hs/rev/fa213afbaadb > > (4) 8185003: JMX: Add a version of ThreadMXBean.dumpAllThreads with a maxDepth argument > http://hg.openjdk.java.net/jdk/hs/rev/68d46cb9be45 > > (5) 8186224: javax/management/remote/mandatory/subjectDelegation/* fail with java.security.AccessControlException > http://hg.openjdk.java.net/jdk/hs/rev/7c8ff90abc22 > > (6) 8181895: javax management docs contain links to technotes > http://hg.openjdk.java.net/jdk/hs/rev/f51c14dc540f > > (7) 8183899: JMXConnectorFactory link to ServiceLoader gives 404 > http://hg.openjdk.java.net/jdk/hs/rev/880c6fdf23e7 > > (8) 8178508: Co-locate remaining MM tests > http://hg.openjdk.java.net/jdk/hs/rev/e7cbd383f71b > > (9) 8175845: Provide javadoc descriptions for jdk.hotspot.agent module > http://hg.openjdk.java.net/jdk/hs/rev/265e40f06a2d > http://hg.openjdk.java.net/jdk/hs/rev/1e2ad0809162 > > (10) 6515161: If remote removeNotificationListener gets SecurityException, client no longer gets notifications > http://hg.openjdk.java.net/jdk/hs/rev/adbeae0f677e > > (11) 8130084: javax/management/MBeanServer/NotifDeadlockTest.java timed out > http://hg.openjdk.java.net/jdk/hs/rev/ff2246213f7b > > (12) 8170861: Remove DcmdMBeanPermissionsTest.java from ProblemList > http://hg.openjdk.java.net/jdk/hs/rev/b2e2caf26552 > > (13) 8168141: javax/management/remote/mandatory/notif/EmptyDomainNotificationTest.java: No notif received! > http://hg.openjdk.java.net/jdk/hs/rev/d2c15c981e72 > > (14) 8165765: Unexpected ID for RMI connection > http://hg.openjdk.java.net/jdk/hs/rev/3729cdfc89f6 > From tobias.hartmann at oracle.com Mon Nov 27 08:43:01 2017 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Mon, 27 Nov 2017 09:43:01 +0100 Subject: CFV: New JDK Committer: Ujwal Vangapally In-Reply-To: References: Message-ID: <82a99549-a375-0075-fd85-89df466165b7@oracle.com> Vote: yes On 23.11.2017 03:24, jesper.wilhelmsson at oracle.com wrote: > Hi, > > I hereby nominate Ujwal Vangapally (uvangapally) to JDK Committer. > > Ujwal works in the Monitor and Management team at Oracle and has contributed 14 changes to the OpenJDK. Ujwal has picked up and solved critical issues in the JMX area and is currently also responsible for analysing the M&M part of the HotSpot integration test results which (if you ask me) is a contribution in itself. > > Votes are due by December 7, 2017. > > Only current JDK Committers [1] are eligible to vote on this nomination. > > Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [2]. > > Thanks, > /Jesper > > [1] http://openjdk.java.net/census > > [2] http://openjdk.java.net/bylaws#lazy-consensus > > [3] List of changes: > > (1) 8191313: Deprecate RMIConnectorServer.CREDENTIAL_TYPES > http://hg.openjdk.java.net/jdk/hs/rev/49e605998d2b > > (2) 8024352: MBeanOperationInfo accepts any int value as "impact" > http://hg.openjdk.java.net/jdk/hs/rev/da4fb7d2f917 > > (3) 8044122: MBean access to the PID > http://hg.openjdk.java.net/jdk/hs/rev/fa213afbaadb > > (4) 8185003: JMX: Add a version of ThreadMXBean.dumpAllThreads with a maxDepth argument > http://hg.openjdk.java.net/jdk/hs/rev/68d46cb9be45 > > (5) 8186224: javax/management/remote/mandatory/subjectDelegation/* fail with java.security.AccessControlException > http://hg.openjdk.java.net/jdk/hs/rev/7c8ff90abc22 > > (6) 8181895: javax management docs contain links to technotes > http://hg.openjdk.java.net/jdk/hs/rev/f51c14dc540f > > (7) 8183899: JMXConnectorFactory link to ServiceLoader gives 404 > http://hg.openjdk.java.net/jdk/hs/rev/880c6fdf23e7 > > (8) 8178508: Co-locate remaining MM tests > http://hg.openjdk.java.net/jdk/hs/rev/e7cbd383f71b > > (9) 8175845: Provide javadoc descriptions for jdk.hotspot.agent module > http://hg.openjdk.java.net/jdk/hs/rev/265e40f06a2d > http://hg.openjdk.java.net/jdk/hs/rev/1e2ad0809162 > > (10) 6515161: If remote removeNotificationListener gets SecurityException, client no longer gets notifications > http://hg.openjdk.java.net/jdk/hs/rev/adbeae0f677e > > (11) 8130084: javax/management/MBeanServer/NotifDeadlockTest.java timed out > http://hg.openjdk.java.net/jdk/hs/rev/ff2246213f7b > > (12) 8170861: Remove DcmdMBeanPermissionsTest.java from ProblemList > http://hg.openjdk.java.net/jdk/hs/rev/b2e2caf26552 > > (13) 8168141: javax/management/remote/mandatory/notif/EmptyDomainNotificationTest.java: No notif received! > http://hg.openjdk.java.net/jdk/hs/rev/d2c15c981e72 > > (14) 8165765: Unexpected ID for RMI connection > http://hg.openjdk.java.net/jdk/hs/rev/3729cdfc89f6 > From tobias.hartmann at oracle.com Mon Nov 27 08:43:28 2017 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Mon, 27 Nov 2017 09:43:28 +0100 Subject: CFV: New JDK Committer: Alexander Harlap In-Reply-To: <1511449925.2477.20.camel@oracle.com> References: <1511449925.2477.20.camel@oracle.com> Message-ID: <794a1ba9-5b28-9dde-1296-4b2860ba9542@oracle.com> Vote: yes On 23.11.2017 16:12, Thomas Schatzl wrote: > I hereby nominate Alexander Harlap (aharlap) to JDK Committer. > > Alexander works for Oracle as a member of the Garbage Collection team, > and has in total contributed 22 changesets in various areas of the > Hotspot VM [3]. > > Votes are due by December 7, 2017. > > Only current JDK Committers [1] are eligible to vote on this > nomination. > > Votes must be cast in the open by replying to this mailing list. For > Lazy Consensus voting instructions, see [2]. > > Thanks, > Coleen > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/bylaws#lazy-consensus > > [3] List of changes: > > (1) 8005204: Code Cache Reduction: command line options implementation > http://hg.openjdk.java.net/jdk/jdk/rev/f3d755b11424 > > (2) 8005639: Move InlineSynchronizedMethods flag from develop to > product > http://hg.openjdk.java.net/jdk/jdk/rev/73bac1831823 > > (3) 8185591: guarantee(_byte_map[_guard_index] == last_card) failed: > card table guard has been modified > http://hg.openjdk.java.net/jdk/hs/rev/62d5973082e3 > > (4) 8187819: gc/TestFullGCALot.java fails on jdk10 started with "-XX:- > UseCompressedOops" option > http://hg.openjdk.java.net/jdk/hs/rev/72855b7d10ac > > (5) 8183973: gc/TestFullGCALot.java fails in JDK10-hs nightly > http://hg.openjdk.java.net/jdk/hs/rev/71f1b50a1c6c > > (6) 8184045: TestSystemGCWithG1.java times out on Solaris SPARC > http://hg.openjdk.java.net/jdk/hs/rev/01dc8e9d2da3 > > (7) 8178507: co-locate nsk.regression.gc tests > http://hg.openjdk.java.net/jdk/hs/rev/cbe334268a4c > > (8) 8065402: G1 does not expand marking stack when mark stack overflow > happens during concurrent marking > http://hg.openjdk.java.net/jdk/hs/rev/dbb55d89699c > > (9) 8178542: G1: VM hangs during shutdown due to mark stack overflow > http://hg.openjdk.java.net/jdk/hs/rev/62fac1c2c841 > > (10) 8165674: G1CMMarkStack::out_of_memory possibly redundant > http://hg.openjdk.java.net/jdk/hs/rev/a587da3329a5 > > (11) 8151045: Remove code duplication in > PLABStats/G1EvacStats::adjust_desired_plab_sz > http://hg.openjdk.java.net/jdk/hs/rev/3c4c1591507d > > (12) 8140588: Internal Error: gc/g1/ptrQueue.hpp:126 assert(_index == > _sz) failed: invariant: queues are empty when activated > http://hg.openjdk.java.net/jdk/hs/rev/21041ea7c0fe > > (13) 8147906: G1 use of os::processor_count() > http://hg.openjdk.java.net/jdk/hs/rev/98c7219214df > > (14) 8145038: Simplify mut_process_buffer worker id management > http://hg.openjdk.java.net/jdk/hs/rev/53825bdb41a0 > > (15) 8145037: Clean up FreeIdSet usage > http://hg.openjdk.java.net/jdk/hs/rev/34ab60aee787 > > (16) 8141123: Cleanup in FreeIdSet > http://hg.openjdk.java.net/jdk/hs/rev/d00805788fdd > > (17) 8141135: Remove G1RemSet::write_ref > http://hg.openjdk.java.net/jdk/hs/rev/7c558c120803 > > (18) 8139664: Delete > ConcurrentMarkSweepThread::is_ConcurrentGC_thread() > http://hg.openjdk.java.net/jdk/hs/rev/69416bbe5e84 > > (19) 8130265: gctests/LargeObjects/large001 fails with > OutOfMemoryError: Java heap space > http://hg.openjdk.java.net/jdk/hs/rev/6714a3872d8f > > (20) 8067460: G1: TestResourceManagementFlagWithCommercialBuild.java > failed on embedded platform > http://hg.openjdk.java.net/jdk/hs/rev/da47c3cc5c98 > > (21) 8059492: Wrong spelling in assert: "Not initialied properly?" > http://hg.openjdk.java.net/jdk/hs/rev/3eee985a97e7 > > (22) 8011152: Precision problems on sflt builds > http://hg.openjdk.java.net/jdk/hs/rev/b2bf9afdd360 > From coleen.phillimore at oracle.com Mon Nov 27 13:16:36 2017 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Mon, 27 Nov 2017 08:16:36 -0500 Subject: CFV: New JDK Committer: Alexander Harlap In-Reply-To: <1511450089.2477.22.camel@oracle.com> References: <1511449925.2477.20.camel@oracle.com> <1511450089.2477.22.camel@oracle.com> Message-ID: <92b74cba-96a7-a60e-248f-c26df8c6e3ab@oracle.com> On 11/23/17 10:14 AM, Thomas Schatzl wrote: > Hi, > > On Thu, 2017-11-23 at 16:12 +0100, Thomas Schatzl wrote: >> I hereby nominate Alexander Harlap (aharlap) to JDK Committer. >> >> Alexander works for Oracle as a member of the Garbage Collection >> team, >> and has in total contributed 22 changesets in various areas of the >> Hotspot VM [3]. >> >> Votes are due by December 7, 2017. >> >> Only current JDK Committers [1] are eligible to vote on this >> nomination. >> >> Votes must be cast in the open by replying to this mailing list. For >> Lazy Consensus voting instructions, see [2]. >> >> Thanks, >> Coleen > ^^^^ copy&paste error, sorry Coleen :) ha ha. Coleen > > Thanks, > Thomas > >> [1] http://openjdk.java.net/census >> [2] http://openjdk.java.net/bylaws#lazy-consensus >> >> [3] List of changes: >> >> (1) 8005204: Code Cache Reduction: command line options >> implementation >> http://hg.openjdk.java.net/jdk/jdk/rev/f3d755b11424 >> >> (2) 8005639: Move InlineSynchronizedMethods flag from develop to >> product >> http://hg.openjdk.java.net/jdk/jdk/rev/73bac1831823 >> >> (3) 8185591: guarantee(_byte_map[_guard_index] == last_card) failed: >> card table guard has been modified >> http://hg.openjdk.java.net/jdk/hs/rev/62d5973082e3 >> >> (4) 8187819: gc/TestFullGCALot.java fails on jdk10 started with "- >> XX:- >> UseCompressedOops" option >> http://hg.openjdk.java.net/jdk/hs/rev/72855b7d10ac >> >> (5) 8183973: gc/TestFullGCALot.java fails in JDK10-hs nightly >> http://hg.openjdk.java.net/jdk/hs/rev/71f1b50a1c6c >> >> (6) 8184045: TestSystemGCWithG1.java times out on Solaris SPARC >> http://hg.openjdk.java.net/jdk/hs/rev/01dc8e9d2da3 >> >> (7) 8178507: co-locate nsk.regression.gc tests >> http://hg.openjdk.java.net/jdk/hs/rev/cbe334268a4c >> >> (8) 8065402: G1 does not expand marking stack when mark stack >> overflow >> happens during concurrent marking >> http://hg.openjdk.java.net/jdk/hs/rev/dbb55d89699c >> >> (9) 8178542: G1: VM hangs during shutdown due to mark stack overflow >> http://hg.openjdk.java.net/jdk/hs/rev/62fac1c2c841 >> >> (10) 8165674: G1CMMarkStack::out_of_memory possibly redundant >> http://hg.openjdk.java.net/jdk/hs/rev/a587da3329a5 >> >> (11) 8151045: Remove code duplication in >> PLABStats/G1EvacStats::adjust_desired_plab_sz >> http://hg.openjdk.java.net/jdk/hs/rev/3c4c1591507d >> >> (12) 8140588: Internal Error: gc/g1/ptrQueue.hpp:126 assert(_index == >> _sz) failed: invariant: queues are empty when activated >> http://hg.openjdk.java.net/jdk/hs/rev/21041ea7c0fe >> >> (13) 8147906: G1 use of os::processor_count() >> http://hg.openjdk.java.net/jdk/hs/rev/98c7219214df >> >> (14) 8145038: Simplify mut_process_buffer worker id management >> http://hg.openjdk.java.net/jdk/hs/rev/53825bdb41a0 >> >> (15) 8145037: Clean up FreeIdSet usage >> http://hg.openjdk.java.net/jdk/hs/rev/34ab60aee787 >> >> (16) 8141123: Cleanup in FreeIdSet >> http://hg.openjdk.java.net/jdk/hs/rev/d00805788fdd >> >> (17) 8141135: Remove G1RemSet::write_ref >> http://hg.openjdk.java.net/jdk/hs/rev/7c558c120803 >> >> (18) 8139664: Delete >> ConcurrentMarkSweepThread::is_ConcurrentGC_thread() >> http://hg.openjdk.java.net/jdk/hs/rev/69416bbe5e84 >> >> (19) 8130265: gctests/LargeObjects/large001 fails with >> OutOfMemoryError: Java heap space >> http://hg.openjdk.java.net/jdk/hs/rev/6714a3872d8f >> >> (20) 8067460: G1: TestResourceManagementFlagWithCommercialBuild.java >> failed on embedded platform >> http://hg.openjdk.java.net/jdk/hs/rev/da47c3cc5c98 >> >> (21) 8059492: Wrong spelling in assert: "Not initialied properly?" >> http://hg.openjdk.java.net/jdk/hs/rev/3eee985a97e7 >> >> (22) 8011152: Precision problems on sflt builds >> http://hg.openjdk.java.net/jdk/hs/rev/b2bf9afdd360 >> From coleen.phillimore at oracle.com Mon Nov 27 13:17:32 2017 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Mon, 27 Nov 2017 08:17:32 -0500 Subject: CFV: New JDK Committer: Alexander Harlap In-Reply-To: <1511449925.2477.20.camel@oracle.com> References: <1511449925.2477.20.camel@oracle.com> Message-ID: <5c292c9b-582a-6379-6ffc-a128851e67bb@oracle.com> Vote: yes On 11/23/17 10:12 AM, Thomas Schatzl wrote: > I hereby nominate Alexander Harlap (aharlap) to JDK Committer. > > Alexander works for Oracle as a member of the Garbage Collection team, > and has in total contributed 22 changesets in various areas of the > Hotspot VM [3]. > > Votes are due by December 7, 2017. > > Only current JDK Committers [1] are eligible to vote on this > nomination. > > Votes must be cast in the open by replying to this mailing list. For > Lazy Consensus voting instructions, see [2]. > > Thanks, > Coleen > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/bylaws#lazy-consensus > > [3] List of changes: > > (1) 8005204: Code Cache Reduction: command line options implementation > http://hg.openjdk.java.net/jdk/jdk/rev/f3d755b11424 > > (2) 8005639: Move InlineSynchronizedMethods flag from develop to > product > http://hg.openjdk.java.net/jdk/jdk/rev/73bac1831823 > > (3) 8185591: guarantee(_byte_map[_guard_index] == last_card) failed: > card table guard has been modified > http://hg.openjdk.java.net/jdk/hs/rev/62d5973082e3 > > (4) 8187819: gc/TestFullGCALot.java fails on jdk10 started with "-XX:- > UseCompressedOops" option > http://hg.openjdk.java.net/jdk/hs/rev/72855b7d10ac > > (5) 8183973: gc/TestFullGCALot.java fails in JDK10-hs nightly > http://hg.openjdk.java.net/jdk/hs/rev/71f1b50a1c6c > > (6) 8184045: TestSystemGCWithG1.java times out on Solaris SPARC > http://hg.openjdk.java.net/jdk/hs/rev/01dc8e9d2da3 > > (7) 8178507: co-locate nsk.regression.gc tests > http://hg.openjdk.java.net/jdk/hs/rev/cbe334268a4c > > (8) 8065402: G1 does not expand marking stack when mark stack overflow > happens during concurrent marking > http://hg.openjdk.java.net/jdk/hs/rev/dbb55d89699c > > (9) 8178542: G1: VM hangs during shutdown due to mark stack overflow > http://hg.openjdk.java.net/jdk/hs/rev/62fac1c2c841 > > (10) 8165674: G1CMMarkStack::out_of_memory possibly redundant > http://hg.openjdk.java.net/jdk/hs/rev/a587da3329a5 > > (11) 8151045: Remove code duplication in > PLABStats/G1EvacStats::adjust_desired_plab_sz > http://hg.openjdk.java.net/jdk/hs/rev/3c4c1591507d > > (12) 8140588: Internal Error: gc/g1/ptrQueue.hpp:126 assert(_index == > _sz) failed: invariant: queues are empty when activated > http://hg.openjdk.java.net/jdk/hs/rev/21041ea7c0fe > > (13) 8147906: G1 use of os::processor_count() > http://hg.openjdk.java.net/jdk/hs/rev/98c7219214df > > (14) 8145038: Simplify mut_process_buffer worker id management > http://hg.openjdk.java.net/jdk/hs/rev/53825bdb41a0 > > (15) 8145037: Clean up FreeIdSet usage > http://hg.openjdk.java.net/jdk/hs/rev/34ab60aee787 > > (16) 8141123: Cleanup in FreeIdSet > http://hg.openjdk.java.net/jdk/hs/rev/d00805788fdd > > (17) 8141135: Remove G1RemSet::write_ref > http://hg.openjdk.java.net/jdk/hs/rev/7c558c120803 > > (18) 8139664: Delete > ConcurrentMarkSweepThread::is_ConcurrentGC_thread() > http://hg.openjdk.java.net/jdk/hs/rev/69416bbe5e84 > > (19) 8130265: gctests/LargeObjects/large001 fails with > OutOfMemoryError: Java heap space > http://hg.openjdk.java.net/jdk/hs/rev/6714a3872d8f > > (20) 8067460: G1: TestResourceManagementFlagWithCommercialBuild.java > failed on embedded platform > http://hg.openjdk.java.net/jdk/hs/rev/da47c3cc5c98 > > (21) 8059492: Wrong spelling in assert: "Not initialied properly?" > http://hg.openjdk.java.net/jdk/hs/rev/3eee985a97e7 > > (22) 8011152: Precision problems on sflt builds > http://hg.openjdk.java.net/jdk/hs/rev/b2bf9afdd360 > From zgu at redhat.com Mon Nov 27 14:09:07 2017 From: zgu at redhat.com (Zhengyu Gu) Date: Mon, 27 Nov 2017 09:09:07 -0500 Subject: CFV: New JDK Committer: Alexander Harlap In-Reply-To: <1511449925.2477.20.camel@oracle.com> References: <1511449925.2477.20.camel@oracle.com> Message-ID: Vote: yes -Zhengyu On 11/23/2017 10:12 AM, Thomas Schatzl wrote: > I hereby nominate Alexander Harlap (aharlap) to JDK Committer. > > Alexander works for Oracle as a member of the Garbage Collection team, > and has in total contributed 22 changesets in various areas of the > Hotspot VM [3]. > > Votes are due by December 7, 2017. > > Only current JDK Committers [1] are eligible to vote on this > nomination. > > Votes must be cast in the open by replying to this mailing list. For > Lazy Consensus voting instructions, see [2]. > > Thanks, > Coleen > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/bylaws#lazy-consensus > > [3] List of changes: > > (1) 8005204: Code Cache Reduction: command line options implementation > http://hg.openjdk.java.net/jdk/jdk/rev/f3d755b11424 > > (2) 8005639: Move InlineSynchronizedMethods flag from develop to > product > http://hg.openjdk.java.net/jdk/jdk/rev/73bac1831823 > > (3) 8185591: guarantee(_byte_map[_guard_index] == last_card) failed: > card table guard has been modified > http://hg.openjdk.java.net/jdk/hs/rev/62d5973082e3 > > (4) 8187819: gc/TestFullGCALot.java fails on jdk10 started with "-XX:- > UseCompressedOops" option > http://hg.openjdk.java.net/jdk/hs/rev/72855b7d10ac > > (5) 8183973: gc/TestFullGCALot.java fails in JDK10-hs nightly > http://hg.openjdk.java.net/jdk/hs/rev/71f1b50a1c6c > > (6) 8184045: TestSystemGCWithG1.java times out on Solaris SPARC > http://hg.openjdk.java.net/jdk/hs/rev/01dc8e9d2da3 > > (7) 8178507: co-locate nsk.regression.gc tests > http://hg.openjdk.java.net/jdk/hs/rev/cbe334268a4c > > (8) 8065402: G1 does not expand marking stack when mark stack overflow > happens during concurrent marking > http://hg.openjdk.java.net/jdk/hs/rev/dbb55d89699c > > (9) 8178542: G1: VM hangs during shutdown due to mark stack overflow > http://hg.openjdk.java.net/jdk/hs/rev/62fac1c2c841 > > (10) 8165674: G1CMMarkStack::out_of_memory possibly redundant > http://hg.openjdk.java.net/jdk/hs/rev/a587da3329a5 > > (11) 8151045: Remove code duplication in > PLABStats/G1EvacStats::adjust_desired_plab_sz > http://hg.openjdk.java.net/jdk/hs/rev/3c4c1591507d > > (12) 8140588: Internal Error: gc/g1/ptrQueue.hpp:126 assert(_index == > _sz) failed: invariant: queues are empty when activated > http://hg.openjdk.java.net/jdk/hs/rev/21041ea7c0fe > > (13) 8147906: G1 use of os::processor_count() > http://hg.openjdk.java.net/jdk/hs/rev/98c7219214df > > (14) 8145038: Simplify mut_process_buffer worker id management > http://hg.openjdk.java.net/jdk/hs/rev/53825bdb41a0 > > (15) 8145037: Clean up FreeIdSet usage > http://hg.openjdk.java.net/jdk/hs/rev/34ab60aee787 > > (16) 8141123: Cleanup in FreeIdSet > http://hg.openjdk.java.net/jdk/hs/rev/d00805788fdd > > (17) 8141135: Remove G1RemSet::write_ref > http://hg.openjdk.java.net/jdk/hs/rev/7c558c120803 > > (18) 8139664: Delete > ConcurrentMarkSweepThread::is_ConcurrentGC_thread() > http://hg.openjdk.java.net/jdk/hs/rev/69416bbe5e84 > > (19) 8130265: gctests/LargeObjects/large001 fails with > OutOfMemoryError: Java heap space > http://hg.openjdk.java.net/jdk/hs/rev/6714a3872d8f > > (20) 8067460: G1: TestResourceManagementFlagWithCommercialBuild.java > failed on embedded platform > http://hg.openjdk.java.net/jdk/hs/rev/da47c3cc5c98 > > (21) 8059492: Wrong spelling in assert: "Not initialied properly?" > http://hg.openjdk.java.net/jdk/hs/rev/3eee985a97e7 > > (22) 8011152: Precision problems on sflt builds > http://hg.openjdk.java.net/jdk/hs/rev/b2bf9afdd360 > From eric.caspole at oracle.com Mon Nov 27 15:49:50 2017 From: eric.caspole at oracle.com (Eric Caspole) Date: Mon, 27 Nov 2017 10:49:50 -0500 Subject: CFV: New JDK Committer: Alexander Harlap In-Reply-To: <1511449925.2477.20.camel@oracle.com> References: <1511449925.2477.20.camel@oracle.com> Message-ID: <812c93cc-f3c9-ae46-f52d-abb2d2362f23@oracle.com> Vote: yes On 11/23/2017 10:12 AM, Thomas Schatzl wrote: > I hereby nominate Alexander Harlap (aharlap) to JDK Committer. > > Alexander works for Oracle as a member of the Garbage Collection team, > and has in total contributed 22 changesets in various areas of the > Hotspot VM [3]. > > Votes are due by December 7, 2017. > > Only current JDK Committers [1] are eligible to vote on this > nomination. > > Votes must be cast in the open by replying to this mailing list. For > Lazy Consensus voting instructions, see [2]. > > Thanks, > Coleen > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/bylaws#lazy-consensus > > [3] List of changes: > > (1) 8005204: Code Cache Reduction: command line options implementation > http://hg.openjdk.java.net/jdk/jdk/rev/f3d755b11424 > > (2) 8005639: Move InlineSynchronizedMethods flag from develop to > product > http://hg.openjdk.java.net/jdk/jdk/rev/73bac1831823 > > (3) 8185591: guarantee(_byte_map[_guard_index] == last_card) failed: > card table guard has been modified > http://hg.openjdk.java.net/jdk/hs/rev/62d5973082e3 > > (4) 8187819: gc/TestFullGCALot.java fails on jdk10 started with "-XX:- > UseCompressedOops" option > http://hg.openjdk.java.net/jdk/hs/rev/72855b7d10ac > > (5) 8183973: gc/TestFullGCALot.java fails in JDK10-hs nightly > http://hg.openjdk.java.net/jdk/hs/rev/71f1b50a1c6c > > (6) 8184045: TestSystemGCWithG1.java times out on Solaris SPARC > http://hg.openjdk.java.net/jdk/hs/rev/01dc8e9d2da3 > > (7) 8178507: co-locate nsk.regression.gc tests > http://hg.openjdk.java.net/jdk/hs/rev/cbe334268a4c > > (8) 8065402: G1 does not expand marking stack when mark stack overflow > happens during concurrent marking > http://hg.openjdk.java.net/jdk/hs/rev/dbb55d89699c > > (9) 8178542: G1: VM hangs during shutdown due to mark stack overflow > http://hg.openjdk.java.net/jdk/hs/rev/62fac1c2c841 > > (10) 8165674: G1CMMarkStack::out_of_memory possibly redundant > http://hg.openjdk.java.net/jdk/hs/rev/a587da3329a5 > > (11) 8151045: Remove code duplication in > PLABStats/G1EvacStats::adjust_desired_plab_sz > http://hg.openjdk.java.net/jdk/hs/rev/3c4c1591507d > > (12) 8140588: Internal Error: gc/g1/ptrQueue.hpp:126 assert(_index == > _sz) failed: invariant: queues are empty when activated > http://hg.openjdk.java.net/jdk/hs/rev/21041ea7c0fe > > (13) 8147906: G1 use of os::processor_count() > http://hg.openjdk.java.net/jdk/hs/rev/98c7219214df > > (14) 8145038: Simplify mut_process_buffer worker id management > http://hg.openjdk.java.net/jdk/hs/rev/53825bdb41a0 > > (15) 8145037: Clean up FreeIdSet usage > http://hg.openjdk.java.net/jdk/hs/rev/34ab60aee787 > > (16) 8141123: Cleanup in FreeIdSet > http://hg.openjdk.java.net/jdk/hs/rev/d00805788fdd > > (17) 8141135: Remove G1RemSet::write_ref > http://hg.openjdk.java.net/jdk/hs/rev/7c558c120803 > > (18) 8139664: Delete > ConcurrentMarkSweepThread::is_ConcurrentGC_thread() > http://hg.openjdk.java.net/jdk/hs/rev/69416bbe5e84 > > (19) 8130265: gctests/LargeObjects/large001 fails with > OutOfMemoryError: Java heap space > http://hg.openjdk.java.net/jdk/hs/rev/6714a3872d8f > > (20) 8067460: G1: TestResourceManagementFlagWithCommercialBuild.java > failed on embedded platform > http://hg.openjdk.java.net/jdk/hs/rev/da47c3cc5c98 > > (21) 8059492: Wrong spelling in assert: "Not initialied properly?" > http://hg.openjdk.java.net/jdk/hs/rev/3eee985a97e7 > > (22) 8011152: Precision problems on sflt builds > http://hg.openjdk.java.net/jdk/hs/rev/b2bf9afdd360 > From erik.osterlund at oracle.com Mon Nov 27 16:20:33 2017 From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=) Date: Mon, 27 Nov 2017 17:20:33 +0100 Subject: CFV: New JDK Committer: Alexander Harlap In-Reply-To: <1511449925.2477.20.camel@oracle.com> References: <1511449925.2477.20.camel@oracle.com> Message-ID: <5A1C3B51.1070207@oracle.com> Vote: yes /Erik On 2017-11-23 16:12, Thomas Schatzl wrote: > I hereby nominate Alexander Harlap (aharlap) to JDK Committer. > > Alexander works for Oracle as a member of the Garbage Collection team, > and has in total contributed 22 changesets in various areas of the > Hotspot VM [3]. > > Votes are due by December 7, 2017. > > Only current JDK Committers [1] are eligible to vote on this > nomination. > > Votes must be cast in the open by replying to this mailing list. For > Lazy Consensus voting instructions, see [2]. > > Thanks, > Coleen > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/bylaws#lazy-consensus > > [3] List of changes: > > (1) 8005204: Code Cache Reduction: command line options implementation > http://hg.openjdk.java.net/jdk/jdk/rev/f3d755b11424 > > (2) 8005639: Move InlineSynchronizedMethods flag from develop to > product > http://hg.openjdk.java.net/jdk/jdk/rev/73bac1831823 > > (3) 8185591: guarantee(_byte_map[_guard_index] == last_card) failed: > card table guard has been modified > http://hg.openjdk.java.net/jdk/hs/rev/62d5973082e3 > > (4) 8187819: gc/TestFullGCALot.java fails on jdk10 started with "-XX:- > UseCompressedOops" option > http://hg.openjdk.java.net/jdk/hs/rev/72855b7d10ac > > (5) 8183973: gc/TestFullGCALot.java fails in JDK10-hs nightly > http://hg.openjdk.java.net/jdk/hs/rev/71f1b50a1c6c > > (6) 8184045: TestSystemGCWithG1.java times out on Solaris SPARC > http://hg.openjdk.java.net/jdk/hs/rev/01dc8e9d2da3 > > (7) 8178507: co-locate nsk.regression.gc tests > http://hg.openjdk.java.net/jdk/hs/rev/cbe334268a4c > > (8) 8065402: G1 does not expand marking stack when mark stack overflow > happens during concurrent marking > http://hg.openjdk.java.net/jdk/hs/rev/dbb55d89699c > > (9) 8178542: G1: VM hangs during shutdown due to mark stack overflow > http://hg.openjdk.java.net/jdk/hs/rev/62fac1c2c841 > > (10) 8165674: G1CMMarkStack::out_of_memory possibly redundant > http://hg.openjdk.java.net/jdk/hs/rev/a587da3329a5 > > (11) 8151045: Remove code duplication in > PLABStats/G1EvacStats::adjust_desired_plab_sz > http://hg.openjdk.java.net/jdk/hs/rev/3c4c1591507d > > (12) 8140588: Internal Error: gc/g1/ptrQueue.hpp:126 assert(_index == > _sz) failed: invariant: queues are empty when activated > http://hg.openjdk.java.net/jdk/hs/rev/21041ea7c0fe > > (13) 8147906: G1 use of os::processor_count() > http://hg.openjdk.java.net/jdk/hs/rev/98c7219214df > > (14) 8145038: Simplify mut_process_buffer worker id management > http://hg.openjdk.java.net/jdk/hs/rev/53825bdb41a0 > > (15) 8145037: Clean up FreeIdSet usage > http://hg.openjdk.java.net/jdk/hs/rev/34ab60aee787 > > (16) 8141123: Cleanup in FreeIdSet > http://hg.openjdk.java.net/jdk/hs/rev/d00805788fdd > > (17) 8141135: Remove G1RemSet::write_ref > http://hg.openjdk.java.net/jdk/hs/rev/7c558c120803 > > (18) 8139664: Delete > ConcurrentMarkSweepThread::is_ConcurrentGC_thread() > http://hg.openjdk.java.net/jdk/hs/rev/69416bbe5e84 > > (19) 8130265: gctests/LargeObjects/large001 fails with > OutOfMemoryError: Java heap space > http://hg.openjdk.java.net/jdk/hs/rev/6714a3872d8f > > (20) 8067460: G1: TestResourceManagementFlagWithCommercialBuild.java > failed on embedded platform > http://hg.openjdk.java.net/jdk/hs/rev/da47c3cc5c98 > > (21) 8059492: Wrong spelling in assert: "Not initialied properly?" > http://hg.openjdk.java.net/jdk/hs/rev/3eee985a97e7 > > (22) 8011152: Precision problems on sflt builds > http://hg.openjdk.java.net/jdk/hs/rev/b2bf9afdd360 > From sangheon.kim at oracle.com Mon Nov 27 17:58:14 2017 From: sangheon.kim at oracle.com (sangheon.kim) Date: Mon, 27 Nov 2017 09:58:14 -0800 Subject: CFV: New JDK Committer: Alexander Harlap In-Reply-To: <1511449925.2477.20.camel@oracle.com> References: <1511449925.2477.20.camel@oracle.com> Message-ID: Vote: yes Thanks, Sangheon On 11/23/2017 07:12 AM, Thomas Schatzl wrote: > I hereby nominate Alexander Harlap (aharlap) to JDK Committer. > > Alexander works for Oracle as a member of the Garbage Collection team, > and has in total contributed 22 changesets in various areas of the > Hotspot VM [3]. > > Votes are due by December 7, 2017. > > Only current JDK Committers [1] are eligible to vote on this > nomination. > > Votes must be cast in the open by replying to this mailing list. For > Lazy Consensus voting instructions, see [2]. > > Thanks, > Coleen > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/bylaws#lazy-consensus > > [3] List of changes: > > (1) 8005204: Code Cache Reduction: command line options implementation > http://hg.openjdk.java.net/jdk/jdk/rev/f3d755b11424 > > (2) 8005639: Move InlineSynchronizedMethods flag from develop to > product > http://hg.openjdk.java.net/jdk/jdk/rev/73bac1831823 > > (3) 8185591: guarantee(_byte_map[_guard_index] == last_card) failed: > card table guard has been modified > http://hg.openjdk.java.net/jdk/hs/rev/62d5973082e3 > > (4) 8187819: gc/TestFullGCALot.java fails on jdk10 started with "-XX:- > UseCompressedOops" option > http://hg.openjdk.java.net/jdk/hs/rev/72855b7d10ac > > (5) 8183973: gc/TestFullGCALot.java fails in JDK10-hs nightly > http://hg.openjdk.java.net/jdk/hs/rev/71f1b50a1c6c > > (6) 8184045: TestSystemGCWithG1.java times out on Solaris SPARC > http://hg.openjdk.java.net/jdk/hs/rev/01dc8e9d2da3 > > (7) 8178507: co-locate nsk.regression.gc tests > http://hg.openjdk.java.net/jdk/hs/rev/cbe334268a4c > > (8) 8065402: G1 does not expand marking stack when mark stack overflow > happens during concurrent marking > http://hg.openjdk.java.net/jdk/hs/rev/dbb55d89699c > > (9) 8178542: G1: VM hangs during shutdown due to mark stack overflow > http://hg.openjdk.java.net/jdk/hs/rev/62fac1c2c841 > > (10) 8165674: G1CMMarkStack::out_of_memory possibly redundant > http://hg.openjdk.java.net/jdk/hs/rev/a587da3329a5 > > (11) 8151045: Remove code duplication in > PLABStats/G1EvacStats::adjust_desired_plab_sz > http://hg.openjdk.java.net/jdk/hs/rev/3c4c1591507d > > (12) 8140588: Internal Error: gc/g1/ptrQueue.hpp:126 assert(_index == > _sz) failed: invariant: queues are empty when activated > http://hg.openjdk.java.net/jdk/hs/rev/21041ea7c0fe > > (13) 8147906: G1 use of os::processor_count() > http://hg.openjdk.java.net/jdk/hs/rev/98c7219214df > > (14) 8145038: Simplify mut_process_buffer worker id management > http://hg.openjdk.java.net/jdk/hs/rev/53825bdb41a0 > > (15) 8145037: Clean up FreeIdSet usage > http://hg.openjdk.java.net/jdk/hs/rev/34ab60aee787 > > (16) 8141123: Cleanup in FreeIdSet > http://hg.openjdk.java.net/jdk/hs/rev/d00805788fdd > > (17) 8141135: Remove G1RemSet::write_ref > http://hg.openjdk.java.net/jdk/hs/rev/7c558c120803 > > (18) 8139664: Delete > ConcurrentMarkSweepThread::is_ConcurrentGC_thread() > http://hg.openjdk.java.net/jdk/hs/rev/69416bbe5e84 > > (19) 8130265: gctests/LargeObjects/large001 fails with > OutOfMemoryError: Java heap space > http://hg.openjdk.java.net/jdk/hs/rev/6714a3872d8f > > (20) 8067460: G1: TestResourceManagementFlagWithCommercialBuild.java > failed on embedded platform > http://hg.openjdk.java.net/jdk/hs/rev/da47c3cc5c98 > > (21) 8059492: Wrong spelling in assert: "Not initialied properly?" > http://hg.openjdk.java.net/jdk/hs/rev/3eee985a97e7 > > (22) 8011152: Precision problems on sflt builds > http://hg.openjdk.java.net/jdk/hs/rev/b2bf9afdd360 > From jiangli.zhou at Oracle.COM Mon Nov 27 18:39:11 2017 From: jiangli.zhou at Oracle.COM (Jiangli Zhou) Date: Mon, 27 Nov 2017 10:39:11 -0800 Subject: Result: New JDK Reviewer: Calvin Cheung Message-ID: <35902BF2-85D2-4AF8-82CD-5500D049BE6A@oracle.com> Voting for Calvin Cheung [1] now closed. Yes: 18 Veto: 0 Abstain: 0 According to the Bylaws definition of Three-Vote Consensus, this is sufficient to approve the nomination. Jiangli Zhou [1] http://mail.openjdk.java.net/pipermail/jdk-dev/2017-November/000140.html From jiangli.zhou at oracle.com Mon Nov 27 18:46:27 2017 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Mon, 27 Nov 2017 10:46:27 -0800 Subject: CFV: New JDK Committer: Alexander Harlap In-Reply-To: <1511449925.2477.20.camel@oracle.com> References: <1511449925.2477.20.camel@oracle.com> Message-ID: Vote: yes Thanks, Jiangli > On Nov 23, 2017, at 7:12 AM, Thomas Schatzl wrote: > > I hereby nominate Alexander Harlap (aharlap) to JDK Committer. > > Alexander works for Oracle as a member of the Garbage Collection team, > and has in total contributed 22 changesets in various areas of the > Hotspot VM [3]. > > Votes are due by December 7, 2017. > > Only current JDK Committers [1] are eligible to vote on this > nomination. > > Votes must be cast in the open by replying to this mailing list. For > Lazy Consensus voting instructions, see [2]. > > Thanks, > Coleen > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/bylaws#lazy-consensus > > [3] List of changes: > > (1) 8005204: Code Cache Reduction: command line options implementation > http://hg.openjdk.java.net/jdk/jdk/rev/f3d755b11424 > > (2) 8005639: Move InlineSynchronizedMethods flag from develop to > product > http://hg.openjdk.java.net/jdk/jdk/rev/73bac1831823 > > (3) 8185591: guarantee(_byte_map[_guard_index] == last_card) failed: > card table guard has been modified > http://hg.openjdk.java.net/jdk/hs/rev/62d5973082e3 > > (4) 8187819: gc/TestFullGCALot.java fails on jdk10 started with "-XX:- > UseCompressedOops" option > http://hg.openjdk.java.net/jdk/hs/rev/72855b7d10ac > > (5) 8183973: gc/TestFullGCALot.java fails in JDK10-hs nightly > http://hg.openjdk.java.net/jdk/hs/rev/71f1b50a1c6c > > (6) 8184045: TestSystemGCWithG1.java times out on Solaris SPARC > http://hg.openjdk.java.net/jdk/hs/rev/01dc8e9d2da3 > > (7) 8178507: co-locate nsk.regression.gc tests > http://hg.openjdk.java.net/jdk/hs/rev/cbe334268a4c > > (8) 8065402: G1 does not expand marking stack when mark stack overflow > happens during concurrent marking > http://hg.openjdk.java.net/jdk/hs/rev/dbb55d89699c > > (9) 8178542: G1: VM hangs during shutdown due to mark stack overflow > http://hg.openjdk.java.net/jdk/hs/rev/62fac1c2c841 > > (10) 8165674: G1CMMarkStack::out_of_memory possibly redundant > http://hg.openjdk.java.net/jdk/hs/rev/a587da3329a5 > > (11) 8151045: Remove code duplication in > PLABStats/G1EvacStats::adjust_desired_plab_sz > http://hg.openjdk.java.net/jdk/hs/rev/3c4c1591507d > > (12) 8140588: Internal Error: gc/g1/ptrQueue.hpp:126 assert(_index == > _sz) failed: invariant: queues are empty when activated > http://hg.openjdk.java.net/jdk/hs/rev/21041ea7c0fe > > (13) 8147906: G1 use of os::processor_count() > http://hg.openjdk.java.net/jdk/hs/rev/98c7219214df > > (14) 8145038: Simplify mut_process_buffer worker id management > http://hg.openjdk.java.net/jdk/hs/rev/53825bdb41a0 > > (15) 8145037: Clean up FreeIdSet usage > http://hg.openjdk.java.net/jdk/hs/rev/34ab60aee787 > > (16) 8141123: Cleanup in FreeIdSet > http://hg.openjdk.java.net/jdk/hs/rev/d00805788fdd > > (17) 8141135: Remove G1RemSet::write_ref > http://hg.openjdk.java.net/jdk/hs/rev/7c558c120803 > > (18) 8139664: Delete > ConcurrentMarkSweepThread::is_ConcurrentGC_thread() > http://hg.openjdk.java.net/jdk/hs/rev/69416bbe5e84 > > (19) 8130265: gctests/LargeObjects/large001 fails with > OutOfMemoryError: Java heap space > http://hg.openjdk.java.net/jdk/hs/rev/6714a3872d8f > > (20) 8067460: G1: TestResourceManagementFlagWithCommercialBuild.java > failed on embedded platform > http://hg.openjdk.java.net/jdk/hs/rev/da47c3cc5c98 > > (21) 8059492: Wrong spelling in assert: "Not initialied properly?" > http://hg.openjdk.java.net/jdk/hs/rev/3eee985a97e7 > > (22) 8011152: Precision problems on sflt builds > http://hg.openjdk.java.net/jdk/hs/rev/b2bf9afdd360 > From mark.reinhold at oracle.com Mon Nov 27 22:04:48 2017 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Mon, 27 Nov 2017 14:04:48 -0800 Subject: JEP proposed to target JDK 10 (2017/11/16) In-Reply-To: <20171116140429.837282412@eggemoggin.niobe.net> References: <20171116140429.837282412@eggemoggin.niobe.net> Message-ID: <20171127140448.205496591@eggemoggin.niobe.net> 2017/11/16 14:04:29 -0800, mark.reinhold at oracle.com: > The following JEP has been placed into the "Proposed to Target" state > by its owner after discussion and review: > > 310: Application Class-Data Sharing > http://openjdk.java.net/jeps/310 > > Feedback on this proposal is more than welcome, as are reasoned > objections. If no such objections are raised by 23:00 UTC on Thursday, > 23 November, or if they're raised and then satisfactorily answered, then > per the JEP 2.0 process proposal [1] I'll target this JEP to JDK 10. Hearing no objections, I've targeted this JEP to JDK 10. - Mark From mark.reinhold at oracle.com Mon Nov 27 22:08:51 2017 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Mon, 27 Nov 2017 14:08:51 -0800 Subject: JEP proposed to target JDK 10 (2017/11/27) Message-ID: <20171127140851.148860946@eggemoggin.niobe.net> The following JEP has been placed into the "Proposed to Target" state by its owner after discussion and review: 313: Remove the Native-Header Generation Tool (javah) http://openjdk.java.net/jeps/313 Feedback on this proposal is more than welcome, as are reasoned objections. If no such objections are raised by 23:00 UTC on Monday, 4 December, or if they're raised and then satisfactorily answered, then per the JEP 2.0 process proposal [1] I'll target this JEP to JDK 10. - Mark [1] http://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html From david.holmes at oracle.com Tue Nov 28 05:11:20 2017 From: david.holmes at oracle.com (David Holmes) Date: Tue, 28 Nov 2017 15:11:20 +1000 Subject: CFV: New JDK Committer: John Paul Adrian Glaubitz In-Reply-To: References: Message-ID: Vote: yes David On 23/11/2017 12:44 AM, coleen.phillimore at oracle.com wrote: > I hereby nominate John Paul Adrian Glaubitz (glaubitz) to JDK Committer. > > Adrian works for SUSE as a member of the Public Cloud Team but > contributes patches to OpenJDK in his free time as an individual > contributor. He enjoys working on various architectures that exist in > Debian. He is working to reduce the necessary patches to get OpenJDK > build on downstream distributions since this helps to relieve the > maintenance burden of the OpenJDK maintainers in Debian and SUSE. Adrian > has contributed 16 changes [3] to OpenJDK, primarily timely and > appreciated Hotspot patches to fix the Zero interpreter on multiple > platforms. > > Votes are due by December 6, 2017. > > Only current JDK Committers [1] are eligible to vote on this nomination. > > Votes must be cast in the open by replying to this mailing list. For > Lazy Consensus voting instructions, see [2]. > > Thanks, > Coleen > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/bylaws#lazy-consensus > > [3] List of changes: > > http://hg.openjdk.java.net/jdk/hs/rev/827e4ac05579 > 8191663: Zero variant broken after 8189170 and 8189871 > > http://hg.openjdk.java.net/jdk/hs/rev/0ad8a90268a7 > 8191333: Zero variant broken after 8189941 > > http://hg.openjdk.java.net/jdk/hs/rev/b140fe4ff916 > 8190570: Zero fails to build on linux-sparc due undefined reference > > http://hg.openjdk.java.net/jdk/hs/rev/0f7dce1e7690 > 8186578: Zero fails to build on linux-sparc due to sparc-specific code > > http://hg.openjdk.java.net/jdk/hs/rev/9c0137e5e37a > 8187590: Zero runtime can lock-up on linux-alpha > > http://hg.openjdk.java.net/jdk/hs/rev/4cc46bb5057b > 8186855: Multiple platforms broken after 8186476: Generalize Atomic::add > with templates > > http://hg.openjdk.java.net/jdk/hs/rev/b7849991ae55 > 8186723: Add SuperH as new architecture for linux > > http://hg.openjdk.java.net/jdk/hs/rev/89fb7df32425 > 8186655: Identifier strings for PowerPC 64 LE and PowerPC 64 are swapped > > http://hg.openjdk.java.net/jdk/hs/rev/3cd94e2be178 > 8186443: Missing stdint.h for zero builds > > http://hg.openjdk.java.net/jdk/hs/rev/a8488a8b37fb > 8186786: Name collisions with autoconf definitions on alpha and sh > > http://hg.openjdk.java.net/jdk/hs/rev/a4fa3280b8df > 8186313: Additional platform definitions to support Zero builds > > http://hg.openjdk.java.net/jdk/hs/rev/6e1b59330482 > 8186433: Compiler flag -arch=sparc should not be passed on linux-sparc > > http://hg.openjdk.java.net/jdk/hs/rev/f4ded11e0f74 > 8186221: Define CPU search_string for M68K > > http://hg.openjdk.java.net/jdk/hs/rev/f5a564180f37 > 8182165: The header atomic_linux_sparc.inline.hpp should be named > atomic_linux_sparc.hpp > > http://hg.openjdk.java.net/jdk/hs/rev/ff7b9f61209e > 8182164: checkByteBuffer has the wrong signature > > http://hg.openjdk.java.net/jdk/hs/rev/32434b633549 > 8182163: Missing #include "logging/log.hpp" in vm_version_linux_sparc.cpp > From david.holmes at oracle.com Tue Nov 28 05:12:34 2017 From: david.holmes at oracle.com (David Holmes) Date: Tue, 28 Nov 2017 15:12:34 +1000 Subject: CFV: New JDK Committer: Ujwal Vangapally In-Reply-To: References: Message-ID: <0639306c-6d83-4b6d-6609-4ca45774fc55@oracle.com> Vote: yes David On 23/11/2017 12:24 PM, jesper.wilhelmsson at oracle.com wrote: > Hi, > > I hereby nominate Ujwal Vangapally (uvangapally) to JDK Committer. > > Ujwal works in the Monitor and Management team at Oracle and has contributed 14 changes to the OpenJDK. Ujwal has picked up and solved critical issues in the JMX area and is currently also responsible for analysing the M&M part of the HotSpot integration test results which (if you ask me) is a contribution in itself. > > Votes are due by December 7, 2017. > > Only current JDK Committers [1] are eligible to vote on this nomination. > > Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [2]. > > Thanks, > /Jesper > > [1] http://openjdk.java.net/census > > [2] http://openjdk.java.net/bylaws#lazy-consensus > > [3] List of changes: > > (1) 8191313: Deprecate RMIConnectorServer.CREDENTIAL_TYPES > http://hg.openjdk.java.net/jdk/hs/rev/49e605998d2b > > (2) 8024352: MBeanOperationInfo accepts any int value as "impact" > http://hg.openjdk.java.net/jdk/hs/rev/da4fb7d2f917 > > (3) 8044122: MBean access to the PID > http://hg.openjdk.java.net/jdk/hs/rev/fa213afbaadb > > (4) 8185003: JMX: Add a version of ThreadMXBean.dumpAllThreads with a maxDepth argument > http://hg.openjdk.java.net/jdk/hs/rev/68d46cb9be45 > > (5) 8186224: javax/management/remote/mandatory/subjectDelegation/* fail with java.security.AccessControlException > http://hg.openjdk.java.net/jdk/hs/rev/7c8ff90abc22 > > (6) 8181895: javax management docs contain links to technotes > http://hg.openjdk.java.net/jdk/hs/rev/f51c14dc540f > > (7) 8183899: JMXConnectorFactory link to ServiceLoader gives 404 > http://hg.openjdk.java.net/jdk/hs/rev/880c6fdf23e7 > > (8) 8178508: Co-locate remaining MM tests > http://hg.openjdk.java.net/jdk/hs/rev/e7cbd383f71b > > (9) 8175845: Provide javadoc descriptions for jdk.hotspot.agent module > http://hg.openjdk.java.net/jdk/hs/rev/265e40f06a2d > http://hg.openjdk.java.net/jdk/hs/rev/1e2ad0809162 > > (10) 6515161: If remote removeNotificationListener gets SecurityException, client no longer gets notifications > http://hg.openjdk.java.net/jdk/hs/rev/adbeae0f677e > > (11) 8130084: javax/management/MBeanServer/NotifDeadlockTest.java timed out > http://hg.openjdk.java.net/jdk/hs/rev/ff2246213f7b > > (12) 8170861: Remove DcmdMBeanPermissionsTest.java from ProblemList > http://hg.openjdk.java.net/jdk/hs/rev/b2e2caf26552 > > (13) 8168141: javax/management/remote/mandatory/notif/EmptyDomainNotificationTest.java: No notif received! > http://hg.openjdk.java.net/jdk/hs/rev/d2c15c981e72 > > (14) 8165765: Unexpected ID for RMI connection > http://hg.openjdk.java.net/jdk/hs/rev/3729cdfc89f6 > From harsha.wardhana.b at oracle.com Tue Nov 28 05:46:57 2017 From: harsha.wardhana.b at oracle.com (Harsha Wardhana B) Date: Tue, 28 Nov 2017 11:16:57 +0530 Subject: CFV: New JDK Committer: Ujwal Vangapally In-Reply-To: References: Message-ID: <52515958-4b4d-a399-9707-c2e5de803139@oracle.com> Vote: yes Thanks, Harsha On Thursday 23 November 2017 07:54 AM, jesper.wilhelmsson at oracle.com wrote: > Hi, > > I hereby nominate Ujwal Vangapally (uvangapally) to JDK Committer. > > Ujwal works in the Monitor and Management team at Oracle and has contributed 14 changes to the OpenJDK. Ujwal has picked up and solved critical issues in the JMX area and is currently also responsible for analysing the M&M part of the HotSpot integration test results which (if you ask me) is a contribution in itself. > > Votes are due by December 7, 2017. > > Only current JDK Committers [1] are eligible to vote on this nomination. > > Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [2]. > > Thanks, > /Jesper > > [1] http://openjdk.java.net/census > > [2] http://openjdk.java.net/bylaws#lazy-consensus > > [3] List of changes: > > (1) 8191313: Deprecate RMIConnectorServer.CREDENTIAL_TYPES > http://hg.openjdk.java.net/jdk/hs/rev/49e605998d2b > > (2) 8024352: MBeanOperationInfo accepts any int value as "impact" > http://hg.openjdk.java.net/jdk/hs/rev/da4fb7d2f917 > > (3) 8044122: MBean access to the PID > http://hg.openjdk.java.net/jdk/hs/rev/fa213afbaadb > > (4) 8185003: JMX: Add a version of ThreadMXBean.dumpAllThreads with a maxDepth argument > http://hg.openjdk.java.net/jdk/hs/rev/68d46cb9be45 > > (5) 8186224: javax/management/remote/mandatory/subjectDelegation/* fail with java.security.AccessControlException > http://hg.openjdk.java.net/jdk/hs/rev/7c8ff90abc22 > > (6) 8181895: javax management docs contain links to technotes > http://hg.openjdk.java.net/jdk/hs/rev/f51c14dc540f > > (7) 8183899: JMXConnectorFactory link to ServiceLoader gives 404 > http://hg.openjdk.java.net/jdk/hs/rev/880c6fdf23e7 > > (8) 8178508: Co-locate remaining MM tests > http://hg.openjdk.java.net/jdk/hs/rev/e7cbd383f71b > > (9) 8175845: Provide javadoc descriptions for jdk.hotspot.agent module > http://hg.openjdk.java.net/jdk/hs/rev/265e40f06a2d > http://hg.openjdk.java.net/jdk/hs/rev/1e2ad0809162 > > (10) 6515161: If remote removeNotificationListener gets SecurityException, client no longer gets notifications > http://hg.openjdk.java.net/jdk/hs/rev/adbeae0f677e > > (11) 8130084: javax/management/MBeanServer/NotifDeadlockTest.java timed out > http://hg.openjdk.java.net/jdk/hs/rev/ff2246213f7b > > (12) 8170861: Remove DcmdMBeanPermissionsTest.java from ProblemList > http://hg.openjdk.java.net/jdk/hs/rev/b2e2caf26552 > > (13) 8168141: javax/management/remote/mandatory/notif/EmptyDomainNotificationTest.java: No notif received! > http://hg.openjdk.java.net/jdk/hs/rev/d2c15c981e72 > > (14) 8165765: Unexpected ID for RMI connection > http://hg.openjdk.java.net/jdk/hs/rev/3729cdfc89f6 > From kim.barrett at oracle.com Tue Nov 28 06:50:46 2017 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 28 Nov 2017 01:50:46 -0500 Subject: CFV: New JDK Committer: John Paul Adrian Glaubitz In-Reply-To: References: Message-ID: <2971B2AF-691C-4D07-AB67-62D7D656C8E5@oracle.com> vote: yes > On Nov 22, 2017, at 9:44 AM, coleen.phillimore at oracle.com wrote: > > I hereby nominate John Paul Adrian Glaubitz (glaubitz) to JDK Committer. > > Adrian works for SUSE as a member of the Public Cloud Team but contributes patches to OpenJDK in his free time as an individual contributor. He enjoys working on various architectures that exist in Debian. He is working to reduce the necessary patches to get OpenJDK build on downstream distributions since this helps to relieve the maintenance burden of the OpenJDK maintainers in Debian and SUSE. Adrian has contributed 16 changes [3] to OpenJDK, primarily timely and appreciated Hotspot patches to fix the Zero interpreter on multiple platforms. > > Votes are due by December 6, 2017. > > Only current JDK Committers [1] are eligible to vote on this nomination. > > Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [2]. From kim.barrett at oracle.com Tue Nov 28 06:52:39 2017 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 28 Nov 2017 01:52:39 -0500 Subject: CFV: New JDK Committer: Alexander Harlap In-Reply-To: <1511449925.2477.20.camel@oracle.com> References: <1511449925.2477.20.camel@oracle.com> Message-ID: <8305F246-7695-467E-9F0C-3AD26C4FEFAC@oracle.com> vote: yes > On Nov 23, 2017, at 10:12 AM, Thomas Schatzl wrote: > > I hereby nominate Alexander Harlap (aharlap) to JDK Committer. > > Alexander works for Oracle as a member of the Garbage Collection team, > and has in total contributed 22 changesets in various areas of the > Hotspot VM [3]. > > Votes are due by December 7, 2017. > > Only current JDK Committers [1] are eligible to vote on this > nomination. > > Votes must be cast in the open by replying to this mailing list. For > Lazy Consensus voting instructions, see [2]. From magnus.ihse.bursie at oracle.com Tue Nov 28 11:44:23 2017 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 28 Nov 2017 12:44:23 +0100 Subject: CFV: New JDK Committer: John Paul Adrian Glaubitz In-Reply-To: References: Message-ID: <0248b43c-d02d-b9be-e746-b8245a7721bb@oracle.com> Vote: yes /Magnus On 2017-11-22 15:44, coleen.phillimore at oracle.com wrote: > I hereby nominate John Paul Adrian Glaubitz (glaubitz) to JDK Committer. > > Adrian works for SUSE as a member of the Public Cloud Team but > contributes patches to OpenJDK in his free time as an individual > contributor. He enjoys working on various architectures that exist in > Debian. He is working to reduce the necessary patches to get OpenJDK > build on downstream distributions since this helps to relieve the > maintenance burden of the OpenJDK maintainers in Debian and SUSE.? > Adrian has contributed 16 changes [3] to OpenJDK, primarily timely and > appreciated Hotspot patches to fix the Zero interpreter on multiple > platforms. > > Votes are due by December 6, 2017. > > Only current JDK Committers [1] are eligible to vote on this nomination. > > Votes must be cast in the open by replying to this mailing list. For > Lazy Consensus voting instructions, see [2]. > > Thanks, > Coleen > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/bylaws#lazy-consensus > > [3] List of changes: > > http://hg.openjdk.java.net/jdk/hs/rev/827e4ac05579 > 8191663: Zero variant broken after 8189170 and 8189871 > > http://hg.openjdk.java.net/jdk/hs/rev/0ad8a90268a7 > 8191333: Zero variant broken after 8189941 > > http://hg.openjdk.java.net/jdk/hs/rev/b140fe4ff916 > 8190570: Zero fails to build on linux-sparc due undefined reference > > http://hg.openjdk.java.net/jdk/hs/rev/0f7dce1e7690 > 8186578: Zero fails to build on linux-sparc due to sparc-specific code > > http://hg.openjdk.java.net/jdk/hs/rev/9c0137e5e37a > 8187590: Zero runtime can lock-up on linux-alpha > > http://hg.openjdk.java.net/jdk/hs/rev/4cc46bb5057b > 8186855: Multiple platforms broken after 8186476: Generalize > Atomic::add with templates > > http://hg.openjdk.java.net/jdk/hs/rev/b7849991ae55 > 8186723: Add SuperH as new architecture for linux > > http://hg.openjdk.java.net/jdk/hs/rev/89fb7df32425 > 8186655: Identifier strings for PowerPC 64 LE and PowerPC 64 are swapped > > http://hg.openjdk.java.net/jdk/hs/rev/3cd94e2be178 > 8186443: Missing stdint.h for zero builds > > http://hg.openjdk.java.net/jdk/hs/rev/a8488a8b37fb > 8186786: Name collisions with autoconf definitions on alpha and sh > > http://hg.openjdk.java.net/jdk/hs/rev/a4fa3280b8df > 8186313: Additional platform definitions to support Zero builds > > http://hg.openjdk.java.net/jdk/hs/rev/6e1b59330482 > 8186433: Compiler flag -arch=sparc should not be passed on linux-sparc > > http://hg.openjdk.java.net/jdk/hs/rev/f4ded11e0f74 > 8186221: Define CPU search_string for M68K > > http://hg.openjdk.java.net/jdk/hs/rev/f5a564180f37 > 8182165: The header atomic_linux_sparc.inline.hpp should be named > atomic_linux_sparc.hpp > > http://hg.openjdk.java.net/jdk/hs/rev/ff7b9f61209e > 8182164: checkByteBuffer has the wrong signature > > http://hg.openjdk.java.net/jdk/hs/rev/32434b633549 > 8182163: Missing #include "logging/log.hpp" in vm_version_linux_sparc.cpp > From Roger.Riggs at Oracle.com Tue Nov 28 15:45:51 2017 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Tue, 28 Nov 2017 10:45:51 -0500 Subject: CFV: New JDK Committer: Alexander Harlap In-Reply-To: <1511449925.2477.20.camel@oracle.com> References: <1511449925.2477.20.camel@oracle.com> Message-ID: <41ad090d-8c77-0324-9046-072a948b70c7@Oracle.com> Vote: Yes On 11/23/2017 10:12 AM, Thomas Schatzl wrote: > I hereby nominate Alexander Harlap (aharlap) to JDK Committer. > From Roger.Riggs at Oracle.com Tue Nov 28 15:48:16 2017 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Tue, 28 Nov 2017 10:48:16 -0500 Subject: CFV: New JDK Committer: Ujwal Vangapally In-Reply-To: References: Message-ID: <2852e075-8271-735b-c501-9652ba3125c9@Oracle.com> Vote: Yes On 11/22/2017 9:24 PM, jesper.wilhelmsson at oracle.com wrote: > Hi, > > I hereby nominate Ujwal Vangapally (uvangapally) to JDK Committer. > From jiangli.zhou at oracle.com Tue Nov 28 17:16:53 2017 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Tue, 28 Nov 2017 09:16:53 -0800 Subject: CFV: New JDK Committer: John Paul Adrian Glaubitz In-Reply-To: References: Message-ID: <168D0F62-B72F-48EC-B0B6-AF7979DB96AC@oracle.com> Vote: yes Thanks, Jiangli > On Nov 22, 2017, at 6:44 AM, coleen.phillimore at oracle.com wrote: > > I hereby nominate John Paul Adrian Glaubitz (glaubitz) to JDK Committer. > > Adrian works for SUSE as a member of the Public Cloud Team but contributes patches to OpenJDK in his free time as an individual contributor. He enjoys working on various architectures that exist in Debian. He is working to reduce the necessary patches to get OpenJDK build on downstream distributions since this helps to relieve the maintenance burden of the OpenJDK maintainers in Debian and SUSE. Adrian has contributed 16 changes [3] to OpenJDK, primarily timely and appreciated Hotspot patches to fix the Zero interpreter on multiple platforms. > > Votes are due by December 6, 2017. > > Only current JDK Committers [1] are eligible to vote on this nomination. > > Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [2]. > > Thanks, > Coleen > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/bylaws#lazy-consensus > [3] List of changes: > > http://hg.openjdk.java.net/jdk/hs/rev/827e4ac05579 > 8191663: Zero variant broken after 8189170 and 8189871 > > http://hg.openjdk.java.net/jdk/hs/rev/0ad8a90268a7 > 8191333: Zero variant broken after 8189941 > > http://hg.openjdk.java.net/jdk/hs/rev/b140fe4ff916 > 8190570: Zero fails to build on linux-sparc due undefined reference > > http://hg.openjdk.java.net/jdk/hs/rev/0f7dce1e7690 > 8186578: Zero fails to build on linux-sparc due to sparc-specific code > > http://hg.openjdk.java.net/jdk/hs/rev/9c0137e5e37a > 8187590: Zero runtime can lock-up on linux-alpha > > http://hg.openjdk.java.net/jdk/hs/rev/4cc46bb5057b > 8186855: Multiple platforms broken after 8186476: Generalize Atomic::add with templates > > http://hg.openjdk.java.net/jdk/hs/rev/b7849991ae55 > 8186723: Add SuperH as new architecture for linux > > http://hg.openjdk.java.net/jdk/hs/rev/89fb7df32425 > 8186655: Identifier strings for PowerPC 64 LE and PowerPC 64 are swapped > > http://hg.openjdk.java.net/jdk/hs/rev/3cd94e2be178 > 8186443: Missing stdint.h for zero builds > > http://hg.openjdk.java.net/jdk/hs/rev/a8488a8b37fb > 8186786: Name collisions with autoconf definitions on alpha and sh > > http://hg.openjdk.java.net/jdk/hs/rev/a4fa3280b8df > 8186313: Additional platform definitions to support Zero builds > > http://hg.openjdk.java.net/jdk/hs/rev/6e1b59330482 > 8186433: Compiler flag -arch=sparc should not be passed on linux-sparc > > http://hg.openjdk.java.net/jdk/hs/rev/f4ded11e0f74 > 8186221: Define CPU search_string for M68K > > http://hg.openjdk.java.net/jdk/hs/rev/f5a564180f37 > 8182165: The header atomic_linux_sparc.inline.hpp should be named atomic_linux_sparc.hpp > > http://hg.openjdk.java.net/jdk/hs/rev/ff7b9f61209e > 8182164: checkByteBuffer has the wrong signature > > http://hg.openjdk.java.net/jdk/hs/rev/32434b633549 > 8182163: Missing #include "logging/log.hpp" in vm_version_linux_sparc.cpp > From george.triantafillou at oracle.com Tue Nov 28 18:27:23 2017 From: george.triantafillou at oracle.com (George Triantafillou) Date: Tue, 28 Nov 2017 13:27:23 -0500 Subject: CFV: New JDK Committer: John Paul Adrian Glaubitz In-Reply-To: References: Message-ID: <8d9bb121-54b2-fe94-9ee5-2575ef35b2d9@oracle.com> Vote: yes On 11/22/2017 9:44 AM, coleen.phillimore at oracle.com wrote: > I hereby nominate John Paul Adrian Glaubitz (glaubitz) to JDK Committer. > > Adrian works for SUSE as a member of the Public Cloud Team but > contributes patches to OpenJDK in his free time as an individual > contributor. He enjoys working on various architectures that exist in > Debian. He is working to reduce the necessary patches to get OpenJDK > build on downstream distributions since this helps to relieve the > maintenance burden of the OpenJDK maintainers in Debian and SUSE.? > Adrian has contributed 16 changes [3] to OpenJDK, primarily timely and > appreciated Hotspot patches to fix the Zero interpreter on multiple > platforms. > > Votes are due by December 6, 2017. > > Only current JDK Committers [1] are eligible to vote on this nomination. > > Votes must be cast in the open by replying to this mailing list. For > Lazy Consensus voting instructions, see [2]. > > Thanks, > Coleen > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/bylaws#lazy-consensus > > [3] List of changes: > > http://hg.openjdk.java.net/jdk/hs/rev/827e4ac05579 > 8191663: Zero variant broken after 8189170 and 8189871 > > http://hg.openjdk.java.net/jdk/hs/rev/0ad8a90268a7 > 8191333: Zero variant broken after 8189941 > > http://hg.openjdk.java.net/jdk/hs/rev/b140fe4ff916 > 8190570: Zero fails to build on linux-sparc due undefined reference > > http://hg.openjdk.java.net/jdk/hs/rev/0f7dce1e7690 > 8186578: Zero fails to build on linux-sparc due to sparc-specific code > > http://hg.openjdk.java.net/jdk/hs/rev/9c0137e5e37a > 8187590: Zero runtime can lock-up on linux-alpha > > http://hg.openjdk.java.net/jdk/hs/rev/4cc46bb5057b > 8186855: Multiple platforms broken after 8186476: Generalize > Atomic::add with templates > > http://hg.openjdk.java.net/jdk/hs/rev/b7849991ae55 > 8186723: Add SuperH as new architecture for linux > > http://hg.openjdk.java.net/jdk/hs/rev/89fb7df32425 > 8186655: Identifier strings for PowerPC 64 LE and PowerPC 64 are swapped > > http://hg.openjdk.java.net/jdk/hs/rev/3cd94e2be178 > 8186443: Missing stdint.h for zero builds > > http://hg.openjdk.java.net/jdk/hs/rev/a8488a8b37fb > 8186786: Name collisions with autoconf definitions on alpha and sh > > http://hg.openjdk.java.net/jdk/hs/rev/a4fa3280b8df > 8186313: Additional platform definitions to support Zero builds > > http://hg.openjdk.java.net/jdk/hs/rev/6e1b59330482 > 8186433: Compiler flag -arch=sparc should not be passed on linux-sparc > > http://hg.openjdk.java.net/jdk/hs/rev/f4ded11e0f74 > 8186221: Define CPU search_string for M68K > > http://hg.openjdk.java.net/jdk/hs/rev/f5a564180f37 > 8182165: The header atomic_linux_sparc.inline.hpp should be named > atomic_linux_sparc.hpp > > http://hg.openjdk.java.net/jdk/hs/rev/ff7b9f61209e > 8182164: checkByteBuffer has the wrong signature > > http://hg.openjdk.java.net/jdk/hs/rev/32434b633549 > 8182163: Missing #include "logging/log.hpp" in vm_version_linux_sparc.cpp > From mark.reinhold at oracle.com Tue Nov 28 22:44:40 2017 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Tue, 28 Nov 2017 14:44:40 -0800 Subject: JEP proposed to target JDK 10 (2017/11/28) Message-ID: <20171128144440.468654491@eggemoggin.niobe.net> The following JEP has been placed into the "Proposed to Target" state by its owner after discussion and review: 317: Experimental Java-Based JIT Compiler http://openjdk.java.net/jeps/317 Feedback on this proposal is more than welcome, as are reasoned objections. If no such objections are raised by 23:00 UTC on Tuesday, 5 December, or if they're raised and then satisfactorily answered, then per the JEP 2.0 process proposal [1] I'll target this JEP to JDK 10. - Mark [1] http://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html From jai.forums2013 at gmail.com Wed Nov 29 07:48:37 2017 From: jai.forums2013 at gmail.com (Jaikiran Pai) Date: Wed, 29 Nov 2017 13:18:37 +0530 Subject: Proposal: Newer version-string scheme for the Java SE Platform and the JDK In-Reply-To: <20171102151148.49900EBFB8@eggemoggin.niobe.net> Message-ID: >> (1) Bearing in mind that no version-string scheme is ideal,is this scheme acceptable? Yes. On a related note, how do these new proposed changes fit in with the newly introduced (since Java 9) Runtime.Version class[1]? Given that the javadoc and even the API names make use of the terms major(), minor() etc... will they (the methods) be deprecated and these new named methods introduced? [1] https://docs.oracle.com/javase/9/docs/api/java/lang/Runtime.Version.html -Jaikiran From mark.reinhold at oracle.com Wed Nov 29 15:00:24 2017 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Wed, 29 Nov 2017 07:00:24 -0800 Subject: JEP proposed to target JDK 10 (2017/11/20) In-Reply-To: <20171120140230.959870819@eggemoggin.niobe.net> References: <20171120140230.959870819@eggemoggin.niobe.net> Message-ID: <20171129070024.970956349@eggemoggin.niobe.net> 2017/11/20 14:02:30 -0800, mark.reinhold at oracle.com: > The following JEP has been placed into the "Proposed to Target" state > by its owner after discussion and review: > > 316: Heap Allocation on Alternative Memory Devices > http://openjdk.java.net/jeps/316 > > Feedback on this proposal is more than welcome, as are reasoned > objections. If no such objections are raised by 23:00 UTC on Monday, > 27 November, or if they're raised and then satisfactorily answered, then > per the JEP 2.0 process proposal [1] I'll target this JEP to JDK 10. Hearing no objections, I've targeted this JEP to JDK 10. - Mark From devnexen at gmail.com Thu Nov 30 17:06:04 2017 From: devnexen at gmail.com (David CARLIER) Date: Thu, 30 Nov 2017 17:06:04 +0000 Subject: [PATCH] Mere code changes to silence some warnings Message-ID: Hi dear list, Here a tiny patch to address few compilation warnings, two concerns UB with define e.g #define A it is usually better this form #if #define A 1 ... Few types comparison miusmatches as well. Hope is all good ... tested full build. -------------- next part -------------- diff --git a/src/hotspot/os/linux/os_linux.cpp b/src/hotspot/os/linux/os_linux.cpp --- a/src/hotspot/os/linux/os_linux.cpp +++ b/src/hotspot/os/linux/os_linux.cpp @@ -2153,7 +2153,7 @@ } p = OSContainer::cpu_cpuset_memory_nodes(); - if (p < 0) + if (!p) st->print("cpu_memory_nodes() failed\n"); else { st->print("cpu_memory_nodes: %s\n", p); diff --git a/src/hotspot/share/gc/g1/heapRegionSet.hpp b/src/hotspot/share/gc/g1/heapRegionSet.hpp --- a/src/hotspot/share/gc/g1/heapRegionSet.hpp +++ b/src/hotspot/share/gc/g1/heapRegionSet.hpp @@ -50,7 +50,11 @@ // HEAP_REGION_SET_FORCE_VERIFY to be 1, or in builds in which // asserts are compiled in. #ifndef HEAP_REGION_SET_FORCE_VERIFY -#define HEAP_REGION_SET_FORCE_VERIFY defined(ASSERT) +#if defined(ASSERT) +#define HEAP_REGION_SET_FORCE_VERIFY 1 +#else +#define HEAP_REGION_SET_FORCE_VERIFY 0 +#endif #endif // HEAP_REGION_SET_FORCE_VERIFY class HRSMtSafeChecker : public CHeapObj { diff --git a/src/hotspot/share/oops/accessBackend.cpp b/src/hotspot/share/oops/accessBackend.cpp --- a/src/hotspot/share/oops/accessBackend.cpp +++ b/src/hotspot/share/oops/accessBackend.cpp @@ -172,18 +172,3 @@ Copy::conjoint_jlongs_atomic(src, dst, length); } } - -template void AccessInternal::arraycopy_conjoint(jbyte* src, jbyte* dst, size_t length); -template void AccessInternal::arraycopy_conjoint(jshort* src, jshort* dst, size_t length); -template void AccessInternal::arraycopy_conjoint(jint* src, jint* dst, size_t length); -template void AccessInternal::arraycopy_conjoint(jlong* src, jlong* dst, size_t length); - -template void AccessInternal::arraycopy_arrayof_conjoint(jbyte* src, jbyte* dst, size_t length); -template void AccessInternal::arraycopy_arrayof_conjoint(jshort* src, jshort* dst, size_t length); -template void AccessInternal::arraycopy_arrayof_conjoint(jint* src, jint* dst, size_t length); -template void AccessInternal::arraycopy_arrayof_conjoint(jlong* src, jlong* dst, size_t length); - -template void AccessInternal::arraycopy_conjoint_atomic(jbyte* src, jbyte* dst, size_t length); -template void AccessInternal::arraycopy_conjoint_atomic(jshort* src, jshort* dst, size_t length); -template void AccessInternal::arraycopy_conjoint_atomic(jint* src, jint* dst, size_t length); -template void AccessInternal::arraycopy_conjoint_atomic(jlong* src, jlong* dst, size_t length); diff --git a/src/hotspot/share/utilities/nativeCallStack.cpp b/src/hotspot/share/utilities/nativeCallStack.cpp --- a/src/hotspot/share/utilities/nativeCallStack.cpp +++ b/src/hotspot/share/utilities/nativeCallStack.cpp @@ -37,7 +37,11 @@ // to call os::get_native_stack. A tail call is used if _NMT_NOINLINE_ is not defined // (which means this is not a slowdebug build), and we are on 64-bit (except Windows). // This is not necessarily a rule, but what has been obvserved to date. -#define TAIL_CALL (!defined(_NMT_NOINLINE_) && !defined(WINDOWS) && defined(_LP64)) +#if (!defined(_NMT_NOINLINE_) && !defined(WINDOWS) && defined(_LP64)) +#define TAIL_CALL 1 +#else +#define TAIL_CALL 0 +#endif #if !TAIL_CALL toSkip++; #if (defined(_NMT_NOINLINE_) && defined(BSD) && defined(_LP64)) diff --git a/src/java.base/share/native/libfdlibm/e_sqrt.c b/src/java.base/share/native/libfdlibm/e_sqrt.c --- a/src/java.base/share/native/libfdlibm/e_sqrt.c +++ b/src/java.base/share/native/libfdlibm/e_sqrt.c @@ -171,7 +171,7 @@ t = s0; if((t Thanks for all the comments on my earlier proposal [1]. Here's a draft JEP, based on that proposal and the feedback: http://openjdk.java.net/jeps/8192828 Further comments welcome! - Mark [1] http://mail.openjdk.java.net/pipermail/jdk-dev/2017-November/000089.html From mark.reinhold at oracle.com Thu Nov 30 22:32:44 2017 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Thu, 30 Nov 2017 14:32:44 -0800 Subject: JEP proposed to target JDK *11* (2017/11/30) Message-ID: <20171130143244.451070172@eggemoggin.niobe.net> The following JEP is Proposed to Target JDK *11*: 309: Dynamic Class-File Constants http://openjdk.java.net/jeps/309 My understanding is that Lois intends to merge this work into the JDK main line shortly after we fork it to stabilize JDK 10. Feedback on this proposal is more than welcome, as are reasoned objections. If no such objections are raised by 23:00 UTC on Thursday, 7 December, or if they're raised and then satisfactorily answered, then per the JEP 2.0 process proposal [1] I'll target this JEP to JDK 11. - Mark [1] http://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html From mark.reinhold at oracle.com Thu Nov 30 22:52:23 2017 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Thu, 30 Nov 2017 14:52:23 -0800 (PST) Subject: JEP 320: Remove the Java EE and CORBA Modules Message-ID: <20171130225223.6748710B927@eggemoggin.niobe.net> New JEP Candidate: http://openjdk.java.net/jeps/320 - Mark