From jini at zeus.net.au Sun Mar 1 10:06:43 2020 From: jini at zeus.net.au (jini at zeus.net.au) Date: Sun, 1 Mar 2020 20:06:43 +1000 Subject: Fwd: [p2-dev] Pack200 tools and api In-Reply-To: <2d8ce18c-526e-7574-42e3-0d872f61a980@zeus.net.au> References: <2d8ce18c-526e-7574-42e3-0d872f61a980@zeus.net.au> Message-ID: <6001b1c2-3925-e267-4264-c72218ea0108@zeus.net.au> Hello, I've just created a project on github, to maintain and update the java implementation of Pack200.?? I haven't got the jtreg tests set up and running yet, I've used jtreg with ant scripts in the past, but would like to get them running with maven if possible, if someone has experience doing that, it would be much appreciated, so people don't need to download and install jtreg manually. Also I'd like to make the implementation available as an OSGi service or using a service provider. Of course I'll be adding support for new bytecodes as well. Anyone feel like helping, the code is available here, with preserved git history, branched from OpenJDK14-26. https://github.com/pfirmstone/Pack200-ex-openjdk Regards, Peter. From peter.firmstone at zeus.net.au Sun Mar 1 01:19:05 2020 From: peter.firmstone at zeus.net.au (Peter Firmstone) Date: Sun, 1 Mar 2020 11:19:05 +1000 Subject: Pack200 tools and api Message-ID: <2d8ce18c-526e-7574-42e3-0d872f61a980@zeus.net.au> Hello, I've just created a project on github, to maintain and update the java implementation of Pack200.?? I haven't got the jtreg tests set up and running yet, I've used jtreg with ant scripts in the past, but would like to get them running with maven if possible, if someone has experience doing that, it would be much appreciated, so people don't need to download and install jtreg manually. Also I'd like to make the implementation available as an OSGi service or using a service provider. Of course I'll be adding support for new bytecodes as well. Anyone feel like helping, the code is available here, with preserved git history, branched from OpenJDK14-26. https://github.com/pfirmstone/Pack200-ex-openjdk Regards, Peter. From RAJAN.HALADE at ORACLE.COM Mon Mar 2 06:08:42 2020 From: RAJAN.HALADE at ORACLE.COM (Rajan Halade) Date: Sun, 1 Mar 2020 22:08:42 -0800 Subject: Result: New JDK Reviewer: John Jiang Message-ID: Voting for John Jiang [1] is now closed. Yes: 13 Veto: 0 Abstain: 0 According to the Bylaws definition of Three-Vote Consensus, this is sufficient to approve the nomination. Rajan Halade [1] https://mail.openjdk.java.net/pipermail/jdk-dev/2020-February/003892.html Thanks, Rajan From alexey at azul.com Mon Mar 2 08:49:27 2020 From: alexey at azul.com (Alexey Bakhtin) Date: Mon, 2 Mar 2020 08:49:27 +0000 Subject: JDK-8239787 : AArch64: String.indexOf may incorrectly handle empty strings In-Reply-To: <8a1d245a-e964-56eb-dd38-cc59b2340a10@oracle.com> References: <79b0df3b-4617-e40c-d50e-6074181b1515@azul.com> <5E28E330-9047-472D-8E84-E453C9B27B0B@azul.com> <8a1d245a-e964-56eb-dd38-cc59b2340a10@oracle.com> Message-ID: Hello Leonid, Thank you for review. This issue was found in aarch64 version of string intrinsic. Intrinsics for other platforms are not affected. However, this test applicable for all platforms, so I've excluded platform restriction for this test. The rest findings are also fixed. Webrev: http://cr.openjdk.java.net/~bae/8239787/webrev.02/ Thank you Alexey > On 29 Feb 2020, at 00:12, Leonid Mesnik wrote: > > Hi > > I have few comments about added test: > > 1. Are there any reasons to limit to aarch64 only? If it is valid for other platforms then let run it on these platforms also. > > 2. Please fix whit spaces in lines 33,34; > > 3. The meaningful directory names are preferred rather than bugid. Not a strict requirement but usually it increase readability. > > Leonid > > On 2/28/20 3:47 AM, Alexey Bakhtin wrote: >> Hello Yuri, >> >> Here is webrev with fix and new jtreg test : >> http://cr.openjdk.java.net/~bae/8239787/webrev.01/ >> >> Thank you >> Alexey >> >>> On 28 Feb 2020, at 11:45, Yuri Nesterenko wrote: >>> >>> /Hi Alexey, could you please provide a regression test with this fix? >>> Thanks, --yan From anton.tarasov at jetbrains.com Mon Mar 2 14:01:07 2020 From: anton.tarasov at jetbrains.com (Anton Tarasov) Date: Mon, 2 Mar 2020 17:01:07 +0300 Subject: Result: New JDK Commiter: Dmitry Batrak Message-ID: Voting for Dmitry Batrak [1] is now closed. Yes: 4 Veto: 0 Abstain: 0 According to the Bylaws definition of Lazy Consensus, this is sufficient to approve the nomination. With regards, Anton Tarasov [1] https://mail.openjdk.java.net/pipermail/jdk-dev/2020-February/003911.html From Roger.Riggs at oracle.com Mon Mar 2 14:58:53 2020 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Mon, 2 Mar 2020 09:58:53 -0500 Subject: New JDK Reviewer: Sangheon Kim In-Reply-To: References: Message-ID: <38f46b05-0ff9-710e-342a-61ef3f549a85@oracle.com> Vote: yes On 2/26/20 3:16 PM, Kim Barrett wrote: > I hereby nominate Sangheon Kim to JDK Reviewer. From Roger.Riggs at oracle.com Mon Mar 2 15:02:50 2020 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Mon, 2 Mar 2020 10:02:50 -0500 Subject: CFV: New JDK Reviewer: Lutz Schmidt In-Reply-To: References: Message-ID: <97bfa2c8-da21-d0a5-7072-43c69cba0584@oracle.com> Vote: Yes On 2/19/20 8:15 AM, Langer, Christoph wrote: > I hereby nominate Lutz Schmidt (lucy) to JDK Reviewer. From volker.simonis at gmail.com Mon Mar 2 15:26:09 2020 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 2 Mar 2020 16:26:09 +0100 Subject: New JDK Reviewer: Sangheon Kim In-Reply-To: References: Message-ID: Vote: yes On Wed, Feb 26, 2020 at 9:16 PM Kim Barrett wrote: > > I hereby nominate Sangheon Kim to JDK Reviewer. > > Sangheon is a member of Oracle's GC team, mostly working on G1, > including the recent JEP 345: NUMA-Aware Memory Allocation for G1. He > has contributed more than 70 commits [3]. He is also a frequent > contributor of reviews. > > Votes are due by March 12, 2020. > > 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]. > > Thanks, > Kim Barrett > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#reviewer-vote > [3] https://hg.openjdk.java.net/jdk/jdk/search/?rev=(author(%22sangheki%22)%20or%20desc(%22Contributed-by%3A%20sangheon.kim%40oracle.com%22))%20and%20not%20merge()&revcount=80 > From leonid.mesnik at oracle.com Mon Mar 2 17:39:57 2020 From: leonid.mesnik at oracle.com (Leonid Mesnik) Date: Mon, 2 Mar 2020 09:39:57 -0800 Subject: JDK-8239787 : AArch64: String.indexOf may incorrectly handle empty strings In-Reply-To: References: <79b0df3b-4617-e40c-d50e-6074181b1515@azul.com> <5E28E330-9047-472D-8E84-E453C9B27B0B@azul.com> <8a1d245a-e964-56eb-dd38-cc59b2340a10@oracle.com> Message-ID: Thank you for fixing this. Looks good. (I am not a 'R'eviewer) Leonid On 3/2/20 12:49 AM, Alexey Bakhtin wrote: > Hello Leonid, > > Thank you for review. > This issue was found in aarch64 version of string intrinsic. > Intrinsics for other platforms are not affected. However, this test > applicable for all platforms, so I've excluded platform restriction > for this test. > The rest findings are also fixed. > > Webrev: http://cr.openjdk.java.net/~bae/8239787/webrev.02/ > > Thank you > Alexey > >> On 29 Feb 2020, at 00:12, Leonid Mesnik > > wrote: >> >> Hi >> >> I have few comments about added test: >> >> 1. Are there any reasons to limit to aarch64 only? If it is valid for >> other platforms then let run it on these platforms also. >> >> 2. Please fix whit spaces in lines 33,34; >> >> 3. The meaningful directory names are preferred rather than bugid. >> Not a strict requirement but usually it increase readability. >> >> Leonid >> >> On 2/28/20 3:47 AM, Alexey Bakhtin wrote: >>> Hello Yuri, >>> >>> Here is webrev with fix and new jtreg test : >>> http://cr.openjdk.java.net/~bae/8239787/webrev.01/ >>> >>> Thank you >>> Alexey >>> >>>> On 28 Feb 2020, at 11:45, Yuri Nesterenko wrote: >>>> >>>> /Hi Alexey, could you please provide a regression test with this fix? >>>> Thanks, --yan > From aph at redhat.com Mon Mar 2 17:45:32 2020 From: aph at redhat.com (Andrew Haley) Date: Mon, 2 Mar 2020 17:45:32 +0000 Subject: JDK-8239787 : AArch64: String.indexOf may incorrectly handle empty strings In-Reply-To: References: <79b0df3b-4617-e40c-d50e-6074181b1515@azul.com> <5E28E330-9047-472D-8E84-E453C9B27B0B@azul.com> <8a1d245a-e964-56eb-dd38-cc59b2340a10@oracle.com> Message-ID: <7a296f80-ed19-ed64-b2d1-abb891cc44a4@redhat.com> On 3/2/20 8:49 AM, Alexey Bakhtin wrote: > Webrev: http://cr.openjdk.java.net/~bae/8239787/webrev.02/ I'm not sure about this: + * Please contact Azul Systems, 385 Moffett Park Drive, Suite 115, Sunnyvale, + * CA 94089 USA or visit www.azul.com if you need additional information or + * have any questions. The usual thing is to copyright the file yourself but leave the rest of the copyright notice alone. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From alexey at azul.com Tue Mar 3 10:45:05 2020 From: alexey at azul.com (Alexey Bakhtin) Date: Tue, 3 Mar 2020 10:45:05 +0000 Subject: JDK-8239787 : AArch64: String.indexOf may incorrectly handle empty strings In-Reply-To: <7a296f80-ed19-ed64-b2d1-abb891cc44a4@redhat.com> References: <79b0df3b-4617-e40c-d50e-6074181b1515@azul.com> <5E28E330-9047-472D-8E84-E453C9B27B0B@azul.com> <8a1d245a-e964-56eb-dd38-cc59b2340a10@oracle.com> <7a296f80-ed19-ed64-b2d1-abb891cc44a4@redhat.com> Message-ID: Hello Andrew, You are right, thank you. Fixed copyright: http://cr.openjdk.java.net/~bae/8239787/webrev.03/ Regards Alexey > On 2 Mar 2020, at 20:45, Andrew Haley wrote: > > On 3/2/20 8:49 AM, Alexey Bakhtin wrote: >> Webrev: http://cr.openjdk.java.net/~bae/8239787/webrev.02/ > > I'm not sure about this: > > + * Please contact Azul Systems, 385 Moffett Park Drive, Suite 115, Sunnyvale, > + * CA 94089 USA or visit www.azul.com if you need additional information or > + * have any questions. > > The usual thing is to copyright the file yourself but leave the rest of > the copyright notice alone. > > -- > Andrew Haley (he/him) > Java Platform Lead Engineer > Red Hat UK Ltd. > https://keybase.io/andrewhaley > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From aph at redhat.com Tue Mar 3 15:35:23 2020 From: aph at redhat.com (Andrew Haley) Date: Tue, 3 Mar 2020 15:35:23 +0000 Subject: JDK-8239787 : AArch64: String.indexOf may incorrectly handle empty strings In-Reply-To: References: <79b0df3b-4617-e40c-d50e-6074181b1515@azul.com> <5E28E330-9047-472D-8E84-E453C9B27B0B@azul.com> <8a1d245a-e964-56eb-dd38-cc59b2340a10@oracle.com> <7a296f80-ed19-ed64-b2d1-abb891cc44a4@redhat.com> Message-ID: <01d93522-6945-c328-fd36-7696993e16ac@redhat.com> On 3/3/20 10:45 AM, Alexey Bakhtin wrote: > You are right, thank you. Fixed copyright: > > http://cr.openjdk.java.net/~bae/8239787/webrev.03/ OK, thanks. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From christoph.langer at sap.com Tue Mar 3 20:41:21 2020 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 3 Mar 2020 20:41:21 +0000 Subject: New JDK Reviewer: Sangheon Kim In-Reply-To: References: Message-ID: Vote:yes /Christoph > -----Original Message----- > From: jdk-dev On Behalf Of Kim > Barrett > Sent: Mittwoch, 26. Februar 2020 21:17 > To: jdk-dev > Subject: New JDK Reviewer: Sangheon Kim > > I hereby nominate Sangheon Kim to JDK Reviewer. > > Sangheon is a member of Oracle's GC team, mostly working on G1, > including the recent JEP 345: NUMA-Aware Memory Allocation for G1. He > has contributed more than 70 commits [3]. He is also a frequent > contributor of reviews. > > Votes are due by March 12, 2020. > > 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]. > > Thanks, > Kim Barrett > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#reviewer-vote > [3] > https://hg.openjdk.java.net/jdk/jdk/search/?rev=(author(%22sangheki%22) > %20or%20desc(%22Contributed- > by%3A%20sangheon.kim%40oracle.com%22))%20and%20not%20merge()&r > evcount=80 From alex.buckley at oracle.com Tue Mar 3 21:15:31 2020 From: alex.buckley at oracle.com (Alex Buckley) Date: Tue, 3 Mar 2020 13:15:31 -0800 Subject: Preview APIs in the Java Platform Message-ID: <952661d4-3f1d-2a05-a178-e11b37141cf7@oracle.com> Java 14 will be the third release to contain preview language features. The idea of shipping non-final language features -- conceived by JEP 12 in 2018 -- is turning out well, producing better final features. This made us wonder if incubation -- conceived by JEP 11 in 2016 -- is the right channel for shipping non-final APIs, and if the recent introduction of APIs associated with preview language features (such as `java.lang.Record`) is a signpost to a better channel. Incubation follows the tenor of the old triennial release model, where features were chosen at the start of a release and their evolving implementations were shipped in the JDK's Early Access (EA) binaries for years before General Availability (GA). To signal that an API is non-final both before and after GA, incubation places it in the `jdk.incubator` namespace. Unfortunately, this distorts the API and its implementation [1][2], and means that signatures in `java.*` cannot refer to the new API even if such integration is desirable. These problems are not significant for user-level libraries such as the HTTP2 client API which incubated in JDK 9, but they are significant for lower level libraries which need a privileged relationship with `java.base`, such as the Memory Access API which incubated in JDK 14. [1] https://mail.openjdk.java.net/pipermail/panama-dev/2019-June/005884.html [2] https://bugs.openjdk.java.net/browse/JDK-8237349 In the new biannual release model, features are targeted to a release only when they are ready. Until then, they evolve in OpenJDK projects such as Panama and Valhalla, watching JDK releases sail by every six months. There is broad public awareness of these projects, and they generally offer EA binaries, so there is good potential for feedback in the time before a feature is targeted to a release. Also, because OpenJDK projects are blueprints for the future Java Platform, they can place non-final APIs directly in `java.base` and refer to them from signatures in `java.*`. This makes projects' EA binaries look more polished and should produce higher quality feedback. Ultimately, though, the best way to provoke feedback on a feature is to ship it in the GA binary of a JDK feature release. This approach has worked well for preview language features, where the Java community has accepted the idea of non-final features that are disabled by default and can thus be changed in response to feedback. Ideally, we want a way to ship highly-evolved but non-final APIs in a JDK feature release, without distorting the API by relocating its packages and modules, and without misleading developers about its status. Most "preview principles" carry over from language features to APIs: 1. A _preview API_ is a new method, field, class, package, or module in the Java Platform whose design, specification, and implementation are semantically complete, but which would benefit from a period of broad exposure and evaluation before achieving either final and permanent status in the Java Platform or else being refined or removed. We would recast the quality bar for all preview features from "95% done now" to "100% done within a year". This recognizes two points: first, our experience that two rounds of preview is normal, and second, the fact that an API has a larger surface area than a language/VM feature and thus undergoes more syntactic polishing on its way to final status. 2. A preview API will often reside in the `java.base` module, but may reside in another `java.*` module, including one introduced just for the preview API. For example, the HTTP2 client API could have previewed in the `java.net.http` module, where it ended up after incubation. A JEP that introduces many packages may designate them all as preview APIs and place them in different `java.*` modules as it sees fit. 3. Preview APIs are unavailable by default. To use them, a developer "opts in" in the same way as for preview language features: `--release N --enable-preview` at compile time. The class files of the developer's program are marked to depend on the preview APIs of Java version N, as if the program had used preview language features. Accordingly, the class files must be executed with `--enable-preview` at run time, and only the same JDK version. Java 14 already has "APIs associated with preview language features" that work this way, such as `java.lang.Record`. In future, such APIs would simply be cast as preview APIs. The existing private mechanism that identifies them to `javac` and `javadoc` -- `@jdk.internal.PreviewFeature` -- will be used for all preview APIs. 4. The class files of a preview API itself are _not_ marked. There are no changes to how the JDK is compiled, and every class file in the JDK will have a 0 minor_version as before. To allow for intra-JDK use of a preview API, code in the same module as a preview API is _not_ required to "opt in" in order to use the API. That is, when `--enable-preview` is missing, the effect of using a preview API element is a compile-time error _only for code in other modules_. This is similar to how the effect of using an `@Deprecated` element is a warning _only for code that is not itself deprecated_. Beyond APIs, incubation has been used for tools, e.g., `jdk.incubator.jpackage` in JDK 14. However, it has little real meaning there. A tool that's good enough to ship in a JDK feature release has already achieved a high level of quality and is ready for a final round of polishing for its command line options. As long as the tool displays a suitable message about its non-final status, it can legitimately be called a "preview tool" and placed in a module in the ordinary `jdk` namespace rather than the `jdk.incubator` namespace. We don't propose to deprecate incubation or delete JEP 11. It may be useful in future for non-final APIs that wish to live at arms' length from the JDK, outside the `java` namespace. I intend to update JEP 12 to incorporate preview APIs in the near future, hopefully in time for 15 so that projects such as Panama can benefit from them. Alex From bill.shannon at oracle.com Wed Mar 4 18:26:15 2020 From: bill.shannon at oracle.com (Bill Shannon) Date: Wed, 4 Mar 2020 10:26:15 -0800 Subject: Preview APIs in the Java Platform In-Reply-To: <952661d4-3f1d-2a05-a178-e11b37141cf7@oracle.com> References: <952661d4-3f1d-2a05-a178-e11b37141cf7@oracle.com> Message-ID: Alex, do you see any problems with using these new features with "layered products"? For example, could some Jakarta EE APIs mark modules as "preview" and take advantage of the same compiler and runtime support that's available to JDK modules? Is there anything that limits this support to java.* modules? Alex Buckley wrote on 3/3/20 1:15 PM: > Java 14 will be the third release to contain preview language features. The idea > of shipping non-final language features -- conceived by JEP 12 in 2018 -- is > turning out well, producing better final features. This made us wonder if > incubation -- conceived by JEP 11 in 2016 -- is the right channel for shipping > non-final APIs, and if the recent introduction of APIs associated with preview > language features (such as `java.lang.Record`) is a signpost to a better channel. > > Incubation follows the tenor of the old triennial release model, where features > were chosen at the start of a release and their evolving implementations were > shipped in the JDK's Early Access (EA) binaries for years before General > Availability (GA). To signal that an API is non-final both before and after GA, > incubation places it in the `jdk.incubator` namespace. Unfortunately, this > distorts the API and its implementation [1][2], and means that signatures in > `java.*` cannot refer to the new API even if such integration is desirable. > These problems are not significant for user-level libraries such as the HTTP2 > client API which incubated in JDK 9, but they are significant for lower level > libraries which need a privileged relationship with `java.base`, such as the > Memory Access API which incubated in JDK 14. > > [1] https://mail.openjdk.java.net/pipermail/panama-dev/2019-June/005884.html > [2] https://bugs.openjdk.java.net/browse/JDK-8237349 > > In the new biannual release model, features are targeted to a release only when > they are ready. Until then, they evolve in OpenJDK projects such as Panama and > Valhalla, watching JDK releases sail by every six months. There is broad public > awareness of these projects, and they generally offer EA binaries, so there is > good potential for feedback in the time before a feature is targeted to a > release. Also, because OpenJDK projects are blueprints for the future Java > Platform, they can place non-final APIs directly in `java.base` and refer to > them from signatures in `java.*`. This makes projects' EA binaries look more > polished and should produce higher quality feedback. > > Ultimately, though, the best way to provoke feedback on a feature is to ship it > in the GA binary of a JDK feature release. This approach has worked well for > preview language features, where the Java community has accepted the idea of > non-final features that are disabled by default and can thus be changed in > response to feedback. Ideally, we want a way to ship highly-evolved but > non-final APIs in a JDK feature release, without distorting the API by > relocating its packages and modules, and without misleading developers about its > status. > > > Most "preview principles" carry over from language features to APIs: > > 1. A _preview API_ is a new method, field, class, package, or module in the Java > Platform whose design, specification, and implementation are semantically > complete, but which would benefit from a period of broad exposure and evaluation > before achieving either final and permanent status in the Java Platform or else > being refined or removed. > > We would recast the quality bar for all preview features from "95% done now" to > "100% done within a year". This recognizes two points: first, our experience > that two rounds of preview is normal, and second, the fact that an API has a > larger surface area than a language/VM feature and thus undergoes more syntactic > polishing on its way to final status. > > 2. A preview API will often reside in the `java.base` module, but may reside in > another `java.*` module, including one introduced just for the preview API. For > example, the HTTP2 client API could have previewed in the `java.net.http` > module, where it ended up after incubation. > > A JEP that introduces many packages may designate them all as preview APIs and > place them in different `java.*` modules as it sees fit. > > 3. Preview APIs are unavailable by default. To use them, a developer "opts in" > in the same way as for preview language features: `--release N --enable-preview` > at compile time. The class files of the developer's program are marked to depend > on the preview APIs of Java version N, as if the program had used preview > language features. Accordingly, the class files must be executed with > `--enable-preview` at run time, and only the same JDK version. > > Java 14 already has "APIs associated with preview language features" that work > this way, such as `java.lang.Record`. In future, such APIs would simply be cast > as preview APIs. The existing private mechanism that identifies them to `javac` > and `javadoc` -- `@jdk.internal.PreviewFeature` -- will be used for all preview > APIs. > > 4. The class files of a preview API itself are _not_ marked. There are no > changes to how the JDK is compiled, and every class file in the JDK will have a > 0 minor_version as before. > > To allow for intra-JDK use of a preview API, code in the same module as a > preview API is _not_ required to "opt in" in order to use the API. That is, when > `--enable-preview` is missing, the effect of using a preview API element is a > compile-time error _only for code in other modules_. This is similar to how the > effect of using an `@Deprecated` element is a warning _only for code that is not > itself deprecated_. > > > Beyond APIs, incubation has been used for tools, e.g., `jdk.incubator.jpackage` > in JDK 14. However, it has little real meaning there. A tool that's good enough > to ship in a JDK feature release has already achieved a high level of quality > and is ready for a final round of polishing for its command line options. As > long as the tool displays a suitable message about its non-final status, it can > legitimately be called a "preview tool" and placed in a module in the ordinary > `jdk` namespace rather than the `jdk.incubator` namespace. > > > We don't propose to deprecate incubation or delete JEP 11. It may be useful in > future for non-final APIs that wish to live at arms' length from the JDK, > outside the `java` namespace. > > I intend to update JEP 12 to incorporate preview APIs in the near future, > hopefully in time for 15 so that projects such as Panama can benefit from them. > > > Alex From alex.buckley at oracle.com Wed Mar 4 19:22:24 2020 From: alex.buckley at oracle.com (Alex Buckley) Date: Wed, 4 Mar 2020 11:22:24 -0800 Subject: Preview APIs in the Java Platform In-Reply-To: References: <952661d4-3f1d-2a05-a178-e11b37141cf7@oracle.com> Message-ID: We are emphatically not proposing a mechanism for "Any API that is written in Java can be made 'unavailable by default' by its author." We are proposing a mechanism for "An API in the Java SE Platform can be made 'unavailable by default' by the Java SE Platform Spec." Our mechanism exists solely to support preview features in Java SE. Per JEP 12, preview features embody precise commitments about quality and readiness that we've signed up for when evolving the Java language, JVM, and SE API. We have no expectation that other platforms -- be they other languages on the JVM, or other APIs which sit above the SE API -- will share those commitments for their own evolution. Other platforms have no guarantee at all that the idea of preview features, and the commitments they represent, will evolve in a way that's useful or workable for those platforms. Especially with Java 14, the entire Java developer community is becoming aware of the high quality, carefully delivered nature of preview features in Java SE. If we opened up the mechanism so that API authors could use it, they would do so -- and each would make slightly different commitments about quality and readiness. The preview concept would soon find itself in the same place as the semantic versioning concept: a simple "standard" for API authors to follow in theory, but a widely abused and mis-applied concept in practice. We are not going to take the risk of the preview concept being diluted, because it's something that every Java developer should recognize and understand when they peruse the latest "What's new in Java XX" article. Alex On 3/4/2020 10:26 AM, Bill Shannon wrote: > Alex, do you see any problems with using these new features with > "layered products"? > > For example, could some Jakarta EE APIs mark modules as "preview" > and take advantage of the same compiler and runtime support that's > available to JDK modules? > > Is there anything that limits this support to java.* modules? > > > Alex Buckley wrote on 3/3/20 1:15 PM: >> Java 14 will be the third release to contain preview language features. The idea >> of shipping non-final language features -- conceived by JEP 12 in 2018 -- is >> turning out well, producing better final features. This made us wonder if >> incubation -- conceived by JEP 11 in 2016 -- is the right channel for shipping >> non-final APIs, and if the recent introduction of APIs associated with preview >> language features (such as `java.lang.Record`) is a signpost to a better channel. >> >> Incubation follows the tenor of the old triennial release model, where features >> were chosen at the start of a release and their evolving implementations were >> shipped in the JDK's Early Access (EA) binaries for years before General >> Availability (GA). To signal that an API is non-final both before and after GA, >> incubation places it in the `jdk.incubator` namespace. Unfortunately, this >> distorts the API and its implementation [1][2], and means that signatures in >> `java.*` cannot refer to the new API even if such integration is desirable. >> These problems are not significant for user-level libraries such as the HTTP2 >> client API which incubated in JDK 9, but they are significant for lower level >> libraries which need a privileged relationship with `java.base`, such as the >> Memory Access API which incubated in JDK 14. >> >> [1] https://mail.openjdk.java.net/pipermail/panama-dev/2019-June/005884.html >> [2] https://bugs.openjdk.java.net/browse/JDK-8237349 >> >> In the new biannual release model, features are targeted to a release only when >> they are ready. Until then, they evolve in OpenJDK projects such as Panama and >> Valhalla, watching JDK releases sail by every six months. There is broad public >> awareness of these projects, and they generally offer EA binaries, so there is >> good potential for feedback in the time before a feature is targeted to a >> release. Also, because OpenJDK projects are blueprints for the future Java >> Platform, they can place non-final APIs directly in `java.base` and refer to >> them from signatures in `java.*`. This makes projects' EA binaries look more >> polished and should produce higher quality feedback. >> >> Ultimately, though, the best way to provoke feedback on a feature is to ship it >> in the GA binary of a JDK feature release. This approach has worked well for >> preview language features, where the Java community has accepted the idea of >> non-final features that are disabled by default and can thus be changed in >> response to feedback. Ideally, we want a way to ship highly-evolved but >> non-final APIs in a JDK feature release, without distorting the API by >> relocating its packages and modules, and without misleading developers about its >> status. >> >> >> Most "preview principles" carry over from language features to APIs: >> >> 1. A _preview API_ is a new method, field, class, package, or module in the Java >> Platform whose design, specification, and implementation are semantically >> complete, but which would benefit from a period of broad exposure and evaluation >> before achieving either final and permanent status in the Java Platform or else >> being refined or removed. >> >> We would recast the quality bar for all preview features from "95% done now" to >> "100% done within a year". This recognizes two points: first, our experience >> that two rounds of preview is normal, and second, the fact that an API has a >> larger surface area than a language/VM feature and thus undergoes more syntactic >> polishing on its way to final status. >> >> 2. A preview API will often reside in the `java.base` module, but may reside in >> another `java.*` module, including one introduced just for the preview API. For >> example, the HTTP2 client API could have previewed in the `java.net.http` >> module, where it ended up after incubation. >> >> A JEP that introduces many packages may designate them all as preview APIs and >> place them in different `java.*` modules as it sees fit. >> >> 3. Preview APIs are unavailable by default. To use them, a developer "opts in" >> in the same way as for preview language features: `--release N --enable-preview` >> at compile time. The class files of the developer's program are marked to depend >> on the preview APIs of Java version N, as if the program had used preview >> language features. Accordingly, the class files must be executed with >> `--enable-preview` at run time, and only the same JDK version. >> >> Java 14 already has "APIs associated with preview language features" that work >> this way, such as `java.lang.Record`. In future, such APIs would simply be cast >> as preview APIs. The existing private mechanism that identifies them to `javac` >> and `javadoc` -- `@jdk.internal.PreviewFeature` -- will be used for all preview >> APIs. >> >> 4. The class files of a preview API itself are _not_ marked. There are no >> changes to how the JDK is compiled, and every class file in the JDK will have a >> 0 minor_version as before. >> >> To allow for intra-JDK use of a preview API, code in the same module as a >> preview API is _not_ required to "opt in" in order to use the API. That is, when >> `--enable-preview` is missing, the effect of using a preview API element is a >> compile-time error _only for code in other modules_. This is similar to how the >> effect of using an `@Deprecated` element is a warning _only for code that is not >> itself deprecated_. >> >> >> Beyond APIs, incubation has been used for tools, e.g., `jdk.incubator.jpackage` >> in JDK 14. However, it has little real meaning there. A tool that's good enough >> to ship in a JDK feature release has already achieved a high level of quality >> and is ready for a final round of polishing for its command line options. As >> long as the tool displays a suitable message about its non-final status, it can >> legitimately be called a "preview tool" and placed in a module in the ordinary >> `jdk` namespace rather than the `jdk.incubator` namespace. >> >> >> We don't propose to deprecate incubation or delete JEP 11. It may be useful in >> future for non-final APIs that wish to live at arms' length from the JDK, >> outside the `java` namespace. >> >> I intend to update JEP 12 to incorporate preview APIs in the near future, >> hopefully in time for 15 so that projects such as Panama can benefit from them. >> >> >> Alex From bill.shannon at oracle.com Wed Mar 4 19:35:35 2020 From: bill.shannon at oracle.com (Bill Shannon) Date: Wed, 4 Mar 2020 11:35:35 -0800 Subject: Preview APIs in the Java Platform In-Reply-To: References: <952661d4-3f1d-2a05-a178-e11b37141cf7@oracle.com> Message-ID: <0ac9ff09-53b6-105b-341a-566e46323b0e@oracle.com> That's unfortunate. It seemed like the mechanism could be useful for other projects, even if the policy for use of that mechanism wasn't identical to the Java SE policy. Would you recommend that we propose a similar but different mechanism in Java SE that could be used by layered products? Or do you believe that layered products should be allowed to introduce preview features similar to Java SE? Or perhaps you see a way to support the needs of layered products without any changes to Java SE? Alex Buckley wrote on 3/4/20 11:22 AM: > We are emphatically not proposing a mechanism for "Any API that is written in > Java can be made 'unavailable by default' by its author." > > We are proposing a mechanism for "An API in the Java SE Platform can be made > 'unavailable by default' by the Java SE Platform Spec." > > Our mechanism exists solely to support preview features in Java SE. Per JEP 12, > preview features embody precise commitments about quality and readiness that > we've signed up for when evolving the Java language, JVM, and SE API. We have no > expectation that other platforms -- be they other languages on the JVM, or other > APIs which sit above the SE API -- will share those commitments for their own > evolution. Other platforms have no guarantee at all that the idea of preview > features, and the commitments they represent, will evolve in a way that's useful > or workable for those platforms. > > Especially with Java 14, the entire Java developer community is becoming aware > of the high quality, carefully delivered nature of preview features in Java SE. > If we opened up the mechanism so that API authors could use it, they would do so > -- and each would make slightly different commitments about quality and > readiness. The preview concept would soon find itself in the same place as the > semantic versioning concept: a simple "standard" for API authors to follow in > theory, but a widely abused and mis-applied concept in practice. We are not > going to take the risk of the preview concept being diluted, because it's > something that every Java developer should recognize and understand when they > peruse the latest "What's new in Java XX" article. > > Alex > > On 3/4/2020 10:26 AM, Bill Shannon wrote: >> Alex, do you see any problems with using these new features with >> "layered products"? >> >> For example, could some Jakarta EE APIs mark modules as "preview" >> and take advantage of the same compiler and runtime support that's >> available to JDK modules? >> >> Is there anything that limits this support to java.* modules? >> >> >> Alex Buckley wrote on 3/3/20 1:15 PM: >>> Java 14 will be the third release to contain preview language features. The idea >>> of shipping non-final language features -- conceived by JEP 12 in 2018 -- is >>> turning out well, producing better final features. This made us wonder if >>> incubation -- conceived by JEP 11 in 2016 -- is the right channel for shipping >>> non-final APIs, and if the recent introduction of APIs associated with preview >>> language features (such as `java.lang.Record`) is a signpost to a better >>> channel. >>> >>> Incubation follows the tenor of the old triennial release model, where features >>> were chosen at the start of a release and their evolving implementations were >>> shipped in the JDK's Early Access (EA) binaries for years before General >>> Availability (GA). To signal that an API is non-final both before and after GA, >>> incubation places it in the `jdk.incubator` namespace. Unfortunately, this >>> distorts the API and its implementation [1][2], and means that signatures in >>> `java.*` cannot refer to the new API even if such integration is desirable. >>> These problems are not significant for user-level libraries such as the HTTP2 >>> client API which incubated in JDK 9, but they are significant for lower level >>> libraries which need a privileged relationship with `java.base`, such as the >>> Memory Access API which incubated in JDK 14. >>> >>> [1] https://mail.openjdk.java.net/pipermail/panama-dev/2019-June/005884.html >>> [2] https://bugs.openjdk.java.net/browse/JDK-8237349 >>> >>> In the new biannual release model, features are targeted to a release only when >>> they are ready. Until then, they evolve in OpenJDK projects such as Panama and >>> Valhalla, watching JDK releases sail by every six months. There is broad public >>> awareness of these projects, and they generally offer EA binaries, so there is >>> good potential for feedback in the time before a feature is targeted to a >>> release. Also, because OpenJDK projects are blueprints for the future Java >>> Platform, they can place non-final APIs directly in `java.base` and refer to >>> them from signatures in `java.*`. This makes projects' EA binaries look more >>> polished and should produce higher quality feedback. >>> >>> Ultimately, though, the best way to provoke feedback on a feature is to ship it >>> in the GA binary of a JDK feature release. This approach has worked well for >>> preview language features, where the Java community has accepted the idea of >>> non-final features that are disabled by default and can thus be changed in >>> response to feedback. Ideally, we want a way to ship highly-evolved but >>> non-final APIs in a JDK feature release, without distorting the API by >>> relocating its packages and modules, and without misleading developers about its >>> status. >>> >>> >>> Most "preview principles" carry over from language features to APIs: >>> >>> 1. A _preview API_ is a new method, field, class, package, or module in the Java >>> Platform whose design, specification, and implementation are semantically >>> complete, but which would benefit from a period of broad exposure and evaluation >>> before achieving either final and permanent status in the Java Platform or else >>> being refined or removed. >>> >>> We would recast the quality bar for all preview features from "95% done now" to >>> "100% done within a year". This recognizes two points: first, our experience >>> that two rounds of preview is normal, and second, the fact that an API has a >>> larger surface area than a language/VM feature and thus undergoes more syntactic >>> polishing on its way to final status. >>> >>> 2. A preview API will often reside in the `java.base` module, but may reside in >>> another `java.*` module, including one introduced just for the preview API. For >>> example, the HTTP2 client API could have previewed in the `java.net.http` >>> module, where it ended up after incubation. >>> >>> A JEP that introduces many packages may designate them all as preview APIs and >>> place them in different `java.*` modules as it sees fit. >>> >>> 3. Preview APIs are unavailable by default. To use them, a developer "opts in" >>> in the same way as for preview language features: `--release N --enable-preview` >>> at compile time. The class files of the developer's program are marked to depend >>> on the preview APIs of Java version N, as if the program had used preview >>> language features. Accordingly, the class files must be executed with >>> `--enable-preview` at run time, and only the same JDK version. >>> >>> Java 14 already has "APIs associated with preview language features" that work >>> this way, such as `java.lang.Record`. In future, such APIs would simply be cast >>> as preview APIs. The existing private mechanism that identifies them to `javac` >>> and `javadoc` -- `@jdk.internal.PreviewFeature` -- will be used for all preview >>> APIs. >>> >>> 4. The class files of a preview API itself are _not_ marked. There are no >>> changes to how the JDK is compiled, and every class file in the JDK will have a >>> 0 minor_version as before. >>> >>> To allow for intra-JDK use of a preview API, code in the same module as a >>> preview API is _not_ required to "opt in" in order to use the API. That is, when >>> `--enable-preview` is missing, the effect of using a preview API element is a >>> compile-time error _only for code in other modules_. This is similar to how the >>> effect of using an `@Deprecated` element is a warning _only for code that is not >>> itself deprecated_. >>> >>> >>> Beyond APIs, incubation has been used for tools, e.g., `jdk.incubator.jpackage` >>> in JDK 14. However, it has little real meaning there. A tool that's good enough >>> to ship in a JDK feature release has already achieved a high level of quality >>> and is ready for a final round of polishing for its command line options. As >>> long as the tool displays a suitable message about its non-final status, it can >>> legitimately be called a "preview tool" and placed in a module in the ordinary >>> `jdk` namespace rather than the `jdk.incubator` namespace. >>> >>> >>> We don't propose to deprecate incubation or delete JEP 11. It may be useful in >>> future for non-final APIs that wish to live at arms' length from the JDK, >>> outside the `java` namespace. >>> >>> I intend to update JEP 12 to incorporate preview APIs in the near future, >>> hopefully in time for 15 so that projects such as Panama can benefit from them. >>> >>> >>> Alex From youngty1997 at gmail.com Wed Mar 4 20:10:39 2020 From: youngty1997 at gmail.com (Ty Young) Date: Wed, 4 Mar 2020 14:10:39 -0600 Subject: Preview APIs in the Java Platform In-Reply-To: References: <952661d4-3f1d-2a05-a178-e11b37141cf7@oracle.com> Message-ID: <13d85524-3ad3-10a6-a8bf-fbb7985dda63@gmail.com> On 3/4/20 1:22 PM, Alex Buckley wrote: > We are emphatically not proposing a mechanism for "Any API that is > written in Java can be made 'unavailable by default' by its author." > > We are proposing a mechanism for "An API in the Java SE Platform can > be made 'unavailable by default' by the Java SE Platform Spec." > > Our mechanism exists solely to support preview features in Java SE. > Per JEP 12, preview features embody precise commitments about quality > and readiness that we've signed up for when evolving the Java > language, JVM, and SE API. We have no expectation that other platforms > -- be they other languages on the JVM, or other APIs which sit above > the SE API -- will share those commitments for their own evolution. > Other platforms have no guarantee at all that the idea of preview > features, and the commitments they represent, will evolve in a way > that's useful or workable for those platforms. ...and yet the Java module system was released, which was only primarily made for internal JDK/JRE use and has been largely ignored outside of it. Many people on social media have publicly stated they won't use it nor do they see a reason ever to. Twitter, IIRC, said that they don't think the module system had the features that are expected of such a system. It has been publicly said by multiple JDK developers now in regards to features like var that (in essence) it isn't the JDK developers responsibility to police code quality, only to provide the tools to write the code. (and then ironically use better code quality as a bullet point advantage of some new feature like the new switch-case expressions... but I digress) Yet you're saying, based on your own assumptions, that no one will use it or if they do use it will be abused. Since when did JDK developers start caring about either of those? Instead of making assumptions, please actually ask people what they think. I've been asking Maurizio for a general module system update(much to his annoyance) for Project Panama which is currently a preview API and has "unsafe" operations within it for native memory access. Build systems and IDEs suck at handling command line arguments. They don't recognize them at all or are very slow to reload and realize the arguments exist. > > Especially with Java 14, the entire Java developer community is > becoming aware of the high quality, carefully delivered nature of > preview features in Java SE. If we opened up the mechanism so that API > authors could use it, they would do so -- and each would make slightly > different commitments about quality and readiness. The preview concept > would soon find itself in the same place as the semantic versioning > concept: a simple "standard" for API authors to follow in theory, but > a widely abused and mis-applied concept in practice. We are not going > to take the risk of the preview concept being diluted, because it's > something that every Java developer should recognize and understand > when they peruse the latest "What's new in Java XX" article. "slightly different commitments about quality and readiness" is exactly where you are now. String literals have been pulled and modified while other preview features have sailed by with no issues AFAIK. > > Alex > > On 3/4/2020 10:26 AM, Bill Shannon wrote: >> Alex, do you see any problems with using these new features with >> "layered products"? >> >> For example, could some Jakarta EE APIs mark modules as "preview" >> and take advantage of the same compiler and runtime support that's >> available to JDK modules? >> >> Is there anything that limits this support to java.* modules? >> >> >> Alex Buckley wrote on 3/3/20 1:15 PM: >>> Java 14 will be the third release to contain preview language >>> features. The idea >>> of shipping non-final language features -- conceived by JEP 12 in >>> 2018 -- is >>> turning out well, producing better final features. This made us >>> wonder if >>> incubation -- conceived by JEP 11 in 2016 -- is the right channel >>> for shipping >>> non-final APIs, and if the recent introduction of APIs associated >>> with preview >>> language features (such as `java.lang.Record`) is a signpost to a >>> better channel. >>> >>> Incubation follows the tenor of the old triennial release model, >>> where features >>> were chosen at the start of a release and their evolving >>> implementations were >>> shipped in the JDK's Early Access (EA) binaries for years before >>> General >>> Availability (GA). To signal that an API is non-final both before >>> and after GA, >>> incubation places it in the `jdk.incubator` namespace. >>> Unfortunately, this >>> distorts the API and its implementation [1][2], and means that >>> signatures in >>> `java.*` cannot refer to the new API even if such integration is >>> desirable. >>> These problems are not significant for user-level libraries such as >>> the HTTP2 >>> client API which incubated in JDK 9, but they are significant for >>> lower level >>> libraries which need a privileged relationship with `java.base`, >>> such as the >>> Memory Access API which incubated in JDK 14. >>> >>> [1] >>> https://mail.openjdk.java.net/pipermail/panama-dev/2019-June/005884.html >>> >>> [2] https://bugs.openjdk.java.net/browse/JDK-8237349 >>> >>> In the new biannual release model, features are targeted to a >>> release only when >>> they are ready. Until then, they evolve in OpenJDK projects such as >>> Panama and >>> Valhalla, watching JDK releases sail by every six months. There is >>> broad public >>> awareness of these projects, and they generally offer EA binaries, >>> so there is >>> good potential for feedback in the time before a feature is targeted >>> to a >>> release. Also, because OpenJDK projects are blueprints for the >>> future Java >>> Platform, they can place non-final APIs directly in `java.base` and >>> refer to >>> them from signatures in `java.*`. This makes projects' EA binaries >>> look more >>> polished and should produce higher quality feedback. >>> >>> Ultimately, though, the best way to provoke feedback on a feature is >>> to ship it >>> in the GA binary of a JDK feature release. This approach has worked >>> well for >>> preview language features, where the Java community has accepted the >>> idea of >>> non-final features that are disabled by default and can thus be >>> changed in >>> response to feedback. Ideally, we want a way to ship highly-evolved but >>> non-final APIs in a JDK feature release, without distorting the API by >>> relocating its packages and modules, and without misleading >>> developers about its >>> status. >>> >>> >>> Most "preview principles" carry over from language features to APIs: >>> >>> 1. A _preview API_ is a new method, field, class, package, or module >>> in the Java >>> Platform whose design, specification, and implementation are >>> semantically >>> complete, but which would benefit from a period of broad exposure >>> and evaluation >>> before achieving either final and permanent status in the Java >>> Platform or else >>> being refined or removed. >>> >>> We would recast the quality bar for all preview features from "95% >>> done now" to >>> "100% done within a year". This recognizes two points: first, our >>> experience >>> that two rounds of preview is normal, and second, the fact that an >>> API has a >>> larger surface area than a language/VM feature and thus undergoes >>> more syntactic >>> polishing on its way to final status. >>> >>> 2. A preview API will often reside in the `java.base` module, but >>> may reside in >>> another `java.*` module, including one introduced just for the >>> preview API. For >>> example, the HTTP2 client API could have previewed in the >>> `java.net.http` >>> module, where it ended up after incubation. >>> >>> A JEP that introduces many packages may designate them all as >>> preview APIs and >>> place them in different `java.*` modules as it sees fit. >>> >>> 3. Preview APIs are unavailable by default. To use them, a developer >>> "opts in" >>> in the same way as for preview language features: `--release N >>> --enable-preview` >>> at compile time. The class files of the developer's program are >>> marked to depend >>> on the preview APIs of Java version N, as if the program had used >>> preview >>> language features. Accordingly, the class files must be executed with >>> `--enable-preview` at run time, and only the same JDK version. >>> >>> Java 14 already has "APIs associated with preview language features" >>> that work >>> this way, such as `java.lang.Record`. In future, such APIs would >>> simply be cast >>> as preview APIs. The existing private mechanism that identifies them >>> to `javac` >>> and `javadoc` -- `@jdk.internal.PreviewFeature` -- will be used for >>> all preview >>> APIs. >>> >>> 4. The class files of a preview API itself are _not_ marked. There >>> are no >>> changes to how the JDK is compiled, and every class file in the JDK >>> will have a >>> 0 minor_version as before. >>> >>> To allow for intra-JDK use of a preview API, code in the same module >>> as a >>> preview API is _not_ required to "opt in" in order to use the API. >>> That is, when >>> `--enable-preview` is missing, the effect of using a preview API >>> element is a >>> compile-time error _only for code in other modules_. This is similar >>> to how the >>> effect of using an `@Deprecated` element is a warning _only for code >>> that is not >>> itself deprecated_. >>> >>> >>> Beyond APIs, incubation has been used for tools, e.g., >>> `jdk.incubator.jpackage` >>> in JDK 14. However, it has little real meaning there. A tool that's >>> good enough >>> to ship in a JDK feature release has already achieved a high level >>> of quality >>> and is ready for a final round of polishing for its command line >>> options. As >>> long as the tool displays a suitable message about its non-final >>> status, it can >>> legitimately be called a "preview tool" and placed in a module in >>> the ordinary >>> `jdk` namespace rather than the `jdk.incubator` namespace. >>> >>> >>> We don't propose to deprecate incubation or delete JEP 11. It may be >>> useful in >>> future for non-final APIs that wish to live at arms' length from the >>> JDK, >>> outside the `java` namespace. >>> >>> I intend to update JEP 12 to incorporate preview APIs in the near >>> future, >>> hopefully in time for 15 so that projects such as Panama can benefit >>> from them. >>> >>> >>> Alex From rschmitt at pobox.com Wed Mar 4 20:19:34 2020 From: rschmitt at pobox.com (Ryan Schmitt) Date: Wed, 4 Mar 2020 12:19:34 -0800 Subject: Preview APIs in the Java Platform In-Reply-To: <0ac9ff09-53b6-105b-341a-566e46323b0e@oracle.com> References: <952661d4-3f1d-2a05-a178-e11b37141cf7@oracle.com> <0ac9ff09-53b6-105b-341a-566e46323b0e@oracle.com> Message-ID: Might I suggest a @java.lang.Unstable or @java.lang.Experimental annotation, to go with @Deprecated? It seems that every non-trivial project eventually has to make their own stability annotations, and standard ones in the JDK would at least allow IDEs to render unstable usages differently (analogous to how uses of deprecated APIs are struck through). On Wed, Mar 4, 2020 at 11:36 AM Bill Shannon wrote: > That's unfortunate. > > It seemed like the mechanism could be useful for other projects, even if > the policy for use of that mechanism wasn't identical to the Java SE > policy. > > Would you recommend that we propose a similar but different mechanism in > Java SE that could be used by layered products? > > Or do you believe that layered products should be allowed to introduce > preview features similar to Java SE? > > Or perhaps you see a way to support the needs of layered products without > any changes to Java SE? > > > Alex Buckley wrote on 3/4/20 11:22 AM: > > We are emphatically not proposing a mechanism for "Any API that is > written in > > Java can be made 'unavailable by default' by its author." > > > > We are proposing a mechanism for "An API in the Java SE Platform can be > made > > 'unavailable by default' by the Java SE Platform Spec." > > > > Our mechanism exists solely to support preview features in Java SE. Per > JEP 12, > > preview features embody precise commitments about quality and readiness > that > > we've signed up for when evolving the Java language, JVM, and SE API. We > have no > > expectation that other platforms -- be they other languages on the JVM, > or other > > APIs which sit above the SE API -- will share those commitments for > their own > > evolution. Other platforms have no guarantee at all that the idea of > preview > > features, and the commitments they represent, will evolve in a way > that's useful > > or workable for those platforms. > > > > Especially with Java 14, the entire Java developer community is becoming > aware > > of the high quality, carefully delivered nature of preview features in > Java SE. > > If we opened up the mechanism so that API authors could use it, they > would do so > > -- and each would make slightly different commitments about quality and > > readiness. The preview concept would soon find itself in the same place > as the > > semantic versioning concept: a simple "standard" for API authors to > follow in > > theory, but a widely abused and mis-applied concept in practice. We are > not > > going to take the risk of the preview concept being diluted, because it's > > something that every Java developer should recognize and understand when > they > > peruse the latest "What's new in Java XX" article. > > > > Alex > > > > On 3/4/2020 10:26 AM, Bill Shannon wrote: > >> Alex, do you see any problems with using these new features with > >> "layered products"? > >> > >> For example, could some Jakarta EE APIs mark modules as "preview" > >> and take advantage of the same compiler and runtime support that's > >> available to JDK modules? > >> > >> Is there anything that limits this support to java.* modules? > >> > >> > >> Alex Buckley wrote on 3/3/20 1:15 PM: > >>> Java 14 will be the third release to contain preview language > features. The idea > >>> of shipping non-final language features -- conceived by JEP 12 in 2018 > -- is > >>> turning out well, producing better final features. This made us wonder > if > >>> incubation -- conceived by JEP 11 in 2016 -- is the right channel for > shipping > >>> non-final APIs, and if the recent introduction of APIs associated with > preview > >>> language features (such as `java.lang.Record`) is a signpost to a > better > >>> channel. > >>> > >>> Incubation follows the tenor of the old triennial release model, where > features > >>> were chosen at the start of a release and their evolving > implementations were > >>> shipped in the JDK's Early Access (EA) binaries for years before > General > >>> Availability (GA). To signal that an API is non-final both before and > after GA, > >>> incubation places it in the `jdk.incubator` namespace. Unfortunately, > this > >>> distorts the API and its implementation [1][2], and means that > signatures in > >>> `java.*` cannot refer to the new API even if such integration is > desirable. > >>> These problems are not significant for user-level libraries such as > the HTTP2 > >>> client API which incubated in JDK 9, but they are significant for > lower level > >>> libraries which need a privileged relationship with `java.base`, such > as the > >>> Memory Access API which incubated in JDK 14. > >>> > >>> [1] > https://mail.openjdk.java.net/pipermail/panama-dev/2019-June/005884.html > >>> [2] https://bugs.openjdk.java.net/browse/JDK-8237349 > >>> > >>> In the new biannual release model, features are targeted to a release > only when > >>> they are ready. Until then, they evolve in OpenJDK projects such as > Panama and > >>> Valhalla, watching JDK releases sail by every six months. There is > broad public > >>> awareness of these projects, and they generally offer EA binaries, so > there is > >>> good potential for feedback in the time before a feature is targeted > to a > >>> release. Also, because OpenJDK projects are blueprints for the future > Java > >>> Platform, they can place non-final APIs directly in `java.base` and > refer to > >>> them from signatures in `java.*`. This makes projects' EA binaries > look more > >>> polished and should produce higher quality feedback. > >>> > >>> Ultimately, though, the best way to provoke feedback on a feature is > to ship it > >>> in the GA binary of a JDK feature release. This approach has worked > well for > >>> preview language features, where the Java community has accepted the > idea of > >>> non-final features that are disabled by default and can thus be > changed in > >>> response to feedback. Ideally, we want a way to ship highly-evolved but > >>> non-final APIs in a JDK feature release, without distorting the API by > >>> relocating its packages and modules, and without misleading developers > about its > >>> status. > >>> > >>> > >>> Most "preview principles" carry over from language features to APIs: > >>> > >>> 1. A _preview API_ is a new method, field, class, package, or module > in the Java > >>> Platform whose design, specification, and implementation are > semantically > >>> complete, but which would benefit from a period of broad exposure and > evaluation > >>> before achieving either final and permanent status in the Java > Platform or else > >>> being refined or removed. > >>> > >>> We would recast the quality bar for all preview features from "95% > done now" to > >>> "100% done within a year". This recognizes two points: first, our > experience > >>> that two rounds of preview is normal, and second, the fact that an API > has a > >>> larger surface area than a language/VM feature and thus undergoes more > syntactic > >>> polishing on its way to final status. > >>> > >>> 2. A preview API will often reside in the `java.base` module, but may > reside in > >>> another `java.*` module, including one introduced just for the preview > API. For > >>> example, the HTTP2 client API could have previewed in the > `java.net.http` > >>> module, where it ended up after incubation. > >>> > >>> A JEP that introduces many packages may designate them all as preview > APIs and > >>> place them in different `java.*` modules as it sees fit. > >>> > >>> 3. Preview APIs are unavailable by default. To use them, a developer > "opts in" > >>> in the same way as for preview language features: `--release N > --enable-preview` > >>> at compile time. The class files of the developer's program are marked > to depend > >>> on the preview APIs of Java version N, as if the program had used > preview > >>> language features. Accordingly, the class files must be executed with > >>> `--enable-preview` at run time, and only the same JDK version. > >>> > >>> Java 14 already has "APIs associated with preview language features" > that work > >>> this way, such as `java.lang.Record`. In future, such APIs would > simply be cast > >>> as preview APIs. The existing private mechanism that identifies them > to `javac` > >>> and `javadoc` -- `@jdk.internal.PreviewFeature` -- will be used for > all preview > >>> APIs. > >>> > >>> 4. The class files of a preview API itself are _not_ marked. There are > no > >>> changes to how the JDK is compiled, and every class file in the JDK > will have a > >>> 0 minor_version as before. > >>> > >>> To allow for intra-JDK use of a preview API, code in the same module > as a > >>> preview API is _not_ required to "opt in" in order to use the API. > That is, when > >>> `--enable-preview` is missing, the effect of using a preview API > element is a > >>> compile-time error _only for code in other modules_. This is similar > to how the > >>> effect of using an `@Deprecated` element is a warning _only for code > that is not > >>> itself deprecated_. > >>> > >>> > >>> Beyond APIs, incubation has been used for tools, e.g., > `jdk.incubator.jpackage` > >>> in JDK 14. However, it has little real meaning there. A tool that's > good enough > >>> to ship in a JDK feature release has already achieved a high level of > quality > >>> and is ready for a final round of polishing for its command line > options. As > >>> long as the tool displays a suitable message about its non-final > status, it can > >>> legitimately be called a "preview tool" and placed in a module in the > ordinary > >>> `jdk` namespace rather than the `jdk.incubator` namespace. > >>> > >>> > >>> We don't propose to deprecate incubation or delete JEP 11. It may be > useful in > >>> future for non-final APIs that wish to live at arms' length from the > JDK, > >>> outside the `java` namespace. > >>> > >>> I intend to update JEP 12 to incorporate preview APIs in the near > future, > >>> hopefully in time for 15 so that projects such as Panama can benefit > from them. > >>> > >>> > >>> Alex > From bill.shannon at oracle.com Wed Mar 4 20:25:54 2020 From: bill.shannon at oracle.com (Bill Shannon) Date: Wed, 4 Mar 2020 12:25:54 -0800 Subject: Preview APIs in the Java Platform In-Reply-To: References: <952661d4-3f1d-2a05-a178-e11b37141cf7@oracle.com> <0ac9ff09-53b6-105b-341a-566e46323b0e@oracle.com> Message-ID: <8c3b2200-5d44-f2b0-da53-0d49f3a9c3a6@oracle.com> It needs more than just the annotation, it needs the compiler and runtime support to go with it. Ryan Schmitt wrote on 3/4/20 12:19 PM: > Might I suggest a @java.lang.Unstable or?@java.lang.Experimental annotation, > to go with?@Deprecated? It seems that every non-trivial project eventually has > to make their own stability annotations, and standard ones in the JDK would at > least allow IDEs to render unstable usages differently (analogous to how uses > of deprecated APIs are struck through). > > On Wed, Mar 4, 2020 at 11:36 AM Bill Shannon > wrote: > > That's unfortunate. > > It seemed like the mechanism could be useful for other projects, even if > the policy for use of that mechanism wasn't identical to the Java SE policy. > > Would you recommend that we propose a similar but different mechanism in > Java SE that could be used by layered products? > > Or do you believe that layered products should be allowed to introduce > preview features similar to Java SE? > > Or perhaps you see a way to support the needs of layered products without > any changes to Java SE? > > > Alex Buckley wrote on 3/4/20 11:22 AM: > > We are emphatically not proposing a mechanism for "Any API that is > written in > > Java can be made 'unavailable by default' by its author." > > > > We are proposing a mechanism for "An API in the Java SE Platform can be made > > 'unavailable by default' by the Java SE Platform Spec." > > > > Our mechanism exists solely to support preview features in Java SE. Per > JEP 12, > > preview features embody precise commitments about quality and readiness that > > we've signed up for when evolving the Java language, JVM, and SE API. We > have no > > expectation that other platforms -- be they other languages on the JVM, > or other > > APIs which sit above the SE API -- will share those commitments for > their own > > evolution. Other platforms have no guarantee at all that the idea of preview > > features, and the commitments they represent, will evolve in a way > that's useful > > or workable for those platforms. > > > > Especially with Java 14, the entire Java developer community is becoming > aware > > of the high quality, carefully delivered nature of preview features in > Java SE. > > If we opened up the mechanism so that API authors could use it, they > would do so > > -- and each would make slightly different commitments about quality and > > readiness. The preview concept would soon find itself in the same place > as the > > semantic versioning concept: a simple "standard" for API authors to > follow in > > theory, but a widely abused and mis-applied concept in practice. We are not > > going to take the risk of the preview concept being diluted, because it's > > something that every Java developer should recognize and understand when > they > > peruse the latest "What's new in Java XX" article. > > > > Alex > > > > On 3/4/2020 10:26 AM, Bill Shannon wrote: > >> Alex, do you see any problems with using these new features with > >> "layered products"? > >> > >> For example, could some Jakarta EE APIs mark modules as "preview" > >> and take advantage of the same compiler and runtime support that's > >> available to JDK modules? > >> > >> Is there anything that limits this support to java.* modules? > >> > >> > >> Alex Buckley wrote on 3/3/20 1:15 PM: > >>> Java 14 will be the third release to contain preview language > features. The idea > >>> of shipping non-final language features -- conceived by JEP 12 in 2018 > -- is > >>> turning out well, producing better final features. This made us wonder if > >>> incubation -- conceived by JEP 11 in 2016 -- is the right channel for > shipping > >>> non-final APIs, and if the recent introduction of APIs associated with > preview > >>> language features (such as `java.lang.Record`) is a signpost to a better > >>> channel. > >>> > >>> Incubation follows the tenor of the old triennial release model, where > features > >>> were chosen at the start of a release and their evolving > implementations were > >>> shipped in the JDK's Early Access (EA) binaries for years before General > >>> Availability (GA). To signal that an API is non-final both before and > after GA, > >>> incubation places it in the `jdk.incubator` namespace. Unfortunately, this > >>> distorts the API and its implementation [1][2], and means that > signatures in > >>> `java.*` cannot refer to the new API even if such integration is > desirable. > >>> These problems are not significant for user-level libraries such as > the HTTP2 > >>> client API which incubated in JDK 9, but they are significant for > lower level > >>> libraries which need a privileged relationship with `java.base`, such > as the > >>> Memory Access API which incubated in JDK 14. > >>> > >>> [1] > https://mail.openjdk.java.net/pipermail/panama-dev/2019-June/005884.html > >>> [2] https://bugs.openjdk.java.net/browse/JDK-8237349 > >>> > >>> In the new biannual release model, features are targeted to a release > only when > >>> they are ready. Until then, they evolve in OpenJDK projects such as > Panama and > >>> Valhalla, watching JDK releases sail by every six months. There is > broad public > >>> awareness of these projects, and they generally offer EA binaries, so > there is > >>> good potential for feedback in the time before a feature is targeted to a > >>> release. Also, because OpenJDK projects are blueprints for the future Java > >>> Platform, they can place non-final APIs directly in `java.base` and > refer to > >>> them from signatures in `java.*`. This makes projects' EA binaries > look more > >>> polished and should produce higher quality feedback. > >>> > >>> Ultimately, though, the best way to provoke feedback on a feature is > to ship it > >>> in the GA binary of a JDK feature release. This approach has worked > well for > >>> preview language features, where the Java community has accepted the > idea of > >>> non-final features that are disabled by default and can thus be changed in > >>> response to feedback. Ideally, we want a way to ship highly-evolved but > >>> non-final APIs in a JDK feature release, without distorting the API by > >>> relocating its packages and modules, and without misleading developers > about its > >>> status. > >>> > >>> > >>> Most "preview principles" carry over from language features to APIs: > >>> > >>> 1. A _preview API_ is a new method, field, class, package, or module > in the Java > >>> Platform whose design, specification, and implementation are semantically > >>> complete, but which would benefit from a period of broad exposure and > evaluation > >>> before achieving either final and permanent status in the Java > Platform or else > >>> being refined or removed. > >>> > >>> We would recast the quality bar for all preview features from "95% > done now" to > >>> "100% done within a year". This recognizes two points: first, our > experience > >>> that two rounds of preview is normal, and second, the fact that an API > has a > >>> larger surface area than a language/VM feature and thus undergoes more > syntactic > >>> polishing on its way to final status. > >>> > >>> 2. A preview API will often reside in the `java.base` module, but may > reside in > >>> another `java.*` module, including one introduced just for the preview > API. For > >>> example, the HTTP2 client API could have previewed in the `java.net.http` > >>> module, where it ended up after incubation. > >>> > >>> A JEP that introduces many packages may designate them all as preview > APIs and > >>> place them in different `java.*` modules as it sees fit. > >>> > >>> 3. Preview APIs are unavailable by default. To use them, a developer > "opts in" > >>> in the same way as for preview language features: `--release N > --enable-preview` > >>> at compile time. The class files of the developer's program are marked > to depend > >>> on the preview APIs of Java version N, as if the program had used preview > >>> language features. Accordingly, the class files must be executed with > >>> `--enable-preview` at run time, and only the same JDK version. > >>> > >>> Java 14 already has "APIs associated with preview language features" > that work > >>> this way, such as `java.lang.Record`. In future, such APIs would > simply be cast > >>> as preview APIs. The existing private mechanism that identifies them > to `javac` > >>> and `javadoc` -- `@jdk.internal.PreviewFeature` -- will be used for > all preview > >>> APIs. > >>> > >>> 4. The class files of a preview API itself are _not_ marked. There are no > >>> changes to how the JDK is compiled, and every class file in the JDK > will have a > >>> 0 minor_version as before. > >>> > >>> To allow for intra-JDK use of a preview API, code in the same module as a > >>> preview API is _not_ required to "opt in" in order to use the API. > That is, when > >>> `--enable-preview` is missing, the effect of using a preview API > element is a > >>> compile-time error _only for code in other modules_. This is similar > to how the > >>> effect of using an `@Deprecated` element is a warning _only for code > that is not > >>> itself deprecated_. > >>> > >>> > >>> Beyond APIs, incubation has been used for tools, e.g., > `jdk.incubator.jpackage` > >>> in JDK 14. However, it has little real meaning there. A tool that's > good enough > >>> to ship in a JDK feature release has already achieved a high level of > quality > >>> and is ready for a final round of polishing for its command line > options. As > >>> long as the tool displays a suitable message about its non-final > status, it can > >>> legitimately be called a "preview tool" and placed in a module in the > ordinary > >>> `jdk` namespace rather than the `jdk.incubator` namespace. > >>> > >>> > >>> We don't propose to deprecate incubation or delete JEP 11. It may be > useful in > >>> future for non-final APIs that wish to live at arms' length from the JDK, > >>> outside the `java` namespace. > >>> > >>> I intend to update JEP 12 to incorporate preview APIs in the near future, > >>> hopefully in time for 15 so that projects such as Panama can benefit > from them. > >>> > >>> > >>> Alex > From alex.buckley at oracle.com Wed Mar 4 20:35:02 2020 From: alex.buckley at oracle.com (Alex Buckley) Date: Wed, 4 Mar 2020 12:35:02 -0800 Subject: Preview APIs in the Java Platform In-Reply-To: <0ac9ff09-53b6-105b-341a-566e46323b0e@oracle.com> References: <952661d4-3f1d-2a05-a178-e11b37141cf7@oracle.com> <0ac9ff09-53b6-105b-341a-566e46323b0e@oracle.com> Message-ID: The heart of "preview features" is the policy story, whereby Java's stewards feel it's acceptable to trade off a feature's compatibility in the short term [being non-final, it may change] in order to improve its quality in the long term. The technical story, whereby `javac` and `java` have a mechanism to control the use of preview features, is a sideshow. I don't wish to use the jdk-dev list to discuss hypotheticals about what a non-JDK project might do to support its own evolution. Alex On 3/4/2020 11:35 AM, Bill Shannon wrote: > That's unfortunate. > > It seemed like the mechanism could be useful for other projects, even if > the policy for use of that mechanism wasn't identical to the Java SE policy. > > Would you recommend that we propose a similar but different mechanism in > Java SE that could be used by layered products? > > Or do you believe that layered products should be allowed to introduce > preview features similar to Java SE? > > Or perhaps you see a way to support the needs of layered products without > any changes to Java SE? From alex.buckley at oracle.com Wed Mar 4 20:52:25 2020 From: alex.buckley at oracle.com (Alex Buckley) Date: Wed, 4 Mar 2020 12:52:25 -0800 Subject: Preview APIs in the Java Platform In-Reply-To: <13d85524-3ad3-10a6-a8bf-fbb7985dda63@gmail.com> References: <952661d4-3f1d-2a05-a178-e11b37141cf7@oracle.com> <13d85524-3ad3-10a6-a8bf-fbb7985dda63@gmail.com> Message-ID: <8b2c77df-4a42-08fb-10dc-3b5503bbd1f3@oracle.com> On 3/4/2020 12:10 PM, Ty Young wrote: >> Especially with Java 14, the entire Java developer community is >> becoming aware of the high quality, carefully delivered nature of >> preview features in Java SE. If we opened up the mechanism so that API >> authors could use it, they would do so -- and each would make slightly >> different commitments about quality and readiness. The preview concept >> would soon find itself in the same place as the semantic versioning >> concept: a simple "standard" for API authors to follow in theory, but >> a widely abused and mis-applied concept in practice. We are not going >> to take the risk of the preview concept being diluted, because it's >> something that every Java developer should recognize and understand >> when they peruse the latest "What's new in Java XX" article. > > "slightly different commitments about quality and readiness" is exactly > where you are now. String literals have been pulled and modified while > other preview features have sailed by with no issues AFAIK. I have no idea what point is being made here. Raw String Literals (JEP 326) were going to ship in JDK 12 as a preview feature, but we were worried that they didn't meet the completeness bar set out in JEP 12, so we didn't ship them in JDK 12. In contrast, Switch Expressions (JEP 325) did meet the completeness bar, so we shipped them in JDK 12 as a preview feature. We have the same commitment to quality and readiness all day every day, which means some features make preview and some don't. Alex From youngty1997 at gmail.com Thu Mar 5 04:03:10 2020 From: youngty1997 at gmail.com (Ty Young) Date: Wed, 4 Mar 2020 22:03:10 -0600 Subject: Preview APIs in the Java Platform In-Reply-To: <8b2c77df-4a42-08fb-10dc-3b5503bbd1f3@oracle.com> References: <952661d4-3f1d-2a05-a178-e11b37141cf7@oracle.com> <13d85524-3ad3-10a6-a8bf-fbb7985dda63@gmail.com> <8b2c77df-4a42-08fb-10dc-3b5503bbd1f3@oracle.com> Message-ID: <0250e67f-7d83-96de-225e-a6c0eacfd95c@gmail.com> On 3/4/20 2:52 PM, Alex Buckley wrote: > On 3/4/2020 12:10 PM, Ty Young wrote: >>> Especially with Java 14, the entire Java developer community is >>> becoming aware of the high quality, carefully delivered nature of >>> preview features in Java SE. If we opened up the mechanism so that >>> API authors could use it, they would do so -- and each would make >>> slightly different commitments about quality and readiness. The >>> preview concept would soon find itself in the same place as the >>> semantic versioning concept: a simple "standard" for API authors to >>> follow in theory, but a widely abused and mis-applied concept in >>> practice. We are not going to take the risk of the preview concept >>> being diluted, because it's something that every Java developer >>> should recognize and understand when they peruse the latest "What's >>> new in Java XX" article. >> >> "slightly different commitments about quality and readiness" is >> exactly where you are now. String literals have been pulled and >> modified while other preview features have sailed by with no issues >> AFAIK. > > I have no idea what point is being made here. Raw String Literals (JEP > 326) were going to ship in JDK 12 as a preview feature, but we were > worried that they didn't meet the completeness bar set out in JEP 12, > so we didn't ship them in JDK 12. In contrast, Switch Expressions (JEP > 325) did meet the completeness bar, so we shipped them in JDK 12 as a > preview feature. We have the same commitment to quality and readiness > all day every day, which means some features make preview and some don't. The point was that there was no concrete time frame from when a feature marked as preview would be delivered. There might be, as unlikely as it may be, that a feature goes through 4 different JDK versions before being released. Which is in itself is fine, but you're arguing that these features can't be implemented because JDK developers somehow have some godly acute senses as to the readiness of a feature that third party developers somehow lacks. The fact that string literals had to be pulled, even if just once, proves this isn't the case(not that, I hope, any JDK developer would claim anyway). and then making excuses as to why they won't be added based on hypotheticals pulled out of thin air when people are telling you point blank that they want these features. You've released the module system which was primarily made for the JDK and you've never cared about how a language feature like var would be abused, so why now? > > Alex From forax at univ-mlv.fr Thu Mar 5 08:18:06 2020 From: forax at univ-mlv.fr (Remi Forax) Date: Thu, 5 Mar 2020 09:18:06 +0100 (CET) Subject: Preview APIs in the Java Platform In-Reply-To: References: <952661d4-3f1d-2a05-a178-e11b37141cf7@oracle.com> Message-ID: <731186418.92411.1583396286089.JavaMail.zimbra@u-pem.fr> Hi Bill, I think you don't understand how preview APIs work, as a user, using a preview API requires --enable-preview at compile time so the generated bytecodes will be tagged with the minor version of the classfile being equals to 65 535 (in violation of semver BTW), so the only way to use a jar containing such classfiles is to use --enable-preview at runtime. So as a user it means once you use a preview API, you can not re-distribute your work, you can not by example upload such jar on Maven Central. Why JakartaEE will want such restriction on their own APIs ? It's overly restrictive. It only makes sense for language features, not on APIs apart if they are required by a language feature. regards, R?mi ----- Mail original ----- > De: "Bill Shannon" > ?: "Alex Buckley" , "jdk-dev" > Envoy?: Mercredi 4 Mars 2020 19:26:15 > Objet: Re: Preview APIs in the Java Platform > Alex, do you see any problems with using these new features with > "layered products"? > > For example, could some Jakarta EE APIs mark modules as "preview" > and take advantage of the same compiler and runtime support that's > available to JDK modules? > > Is there anything that limits this support to java.* modules? > > > Alex Buckley wrote on 3/3/20 1:15 PM: >> Java 14 will be the third release to contain preview language features. The idea >> of shipping non-final language features -- conceived by JEP 12 in 2018 -- is >> turning out well, producing better final features. This made us wonder if >> incubation -- conceived by JEP 11 in 2016 -- is the right channel for shipping >> non-final APIs, and if the recent introduction of APIs associated with preview >> language features (such as `java.lang.Record`) is a signpost to a better >> channel. >> >> Incubation follows the tenor of the old triennial release model, where features >> were chosen at the start of a release and their evolving implementations were >> shipped in the JDK's Early Access (EA) binaries for years before General >> Availability (GA). To signal that an API is non-final both before and after GA, >> incubation places it in the `jdk.incubator` namespace. Unfortunately, this >> distorts the API and its implementation [1][2], and means that signatures in >> `java.*` cannot refer to the new API even if such integration is desirable. >> These problems are not significant for user-level libraries such as the HTTP2 >> client API which incubated in JDK 9, but they are significant for lower level >> libraries which need a privileged relationship with `java.base`, such as the >> Memory Access API which incubated in JDK 14. >> >> [1] https://mail.openjdk.java.net/pipermail/panama-dev/2019-June/005884.html >> [2] https://bugs.openjdk.java.net/browse/JDK-8237349 >> >> In the new biannual release model, features are targeted to a release only when >> they are ready. Until then, they evolve in OpenJDK projects such as Panama and >> Valhalla, watching JDK releases sail by every six months. There is broad public >> awareness of these projects, and they generally offer EA binaries, so there is >> good potential for feedback in the time before a feature is targeted to a >> release. Also, because OpenJDK projects are blueprints for the future Java >> Platform, they can place non-final APIs directly in `java.base` and refer to >> them from signatures in `java.*`. This makes projects' EA binaries look more >> polished and should produce higher quality feedback. >> >> Ultimately, though, the best way to provoke feedback on a feature is to ship it >> in the GA binary of a JDK feature release. This approach has worked well for >> preview language features, where the Java community has accepted the idea of >> non-final features that are disabled by default and can thus be changed in >> response to feedback. Ideally, we want a way to ship highly-evolved but >> non-final APIs in a JDK feature release, without distorting the API by >> relocating its packages and modules, and without misleading developers about its >> status. >> >> >> Most "preview principles" carry over from language features to APIs: >> >> 1. A _preview API_ is a new method, field, class, package, or module in the Java >> Platform whose design, specification, and implementation are semantically >> complete, but which would benefit from a period of broad exposure and evaluation >> before achieving either final and permanent status in the Java Platform or else >> being refined or removed. >> >> We would recast the quality bar for all preview features from "95% done now" to >> "100% done within a year". This recognizes two points: first, our experience >> that two rounds of preview is normal, and second, the fact that an API has a >> larger surface area than a language/VM feature and thus undergoes more syntactic >> polishing on its way to final status. >> >> 2. A preview API will often reside in the `java.base` module, but may reside in >> another `java.*` module, including one introduced just for the preview API. For >> example, the HTTP2 client API could have previewed in the `java.net.http` >> module, where it ended up after incubation. >> >> A JEP that introduces many packages may designate them all as preview APIs and >> place them in different `java.*` modules as it sees fit. >> >> 3. Preview APIs are unavailable by default. To use them, a developer "opts in" >> in the same way as for preview language features: `--release N --enable-preview` >> at compile time. The class files of the developer's program are marked to depend >> on the preview APIs of Java version N, as if the program had used preview >> language features. Accordingly, the class files must be executed with >> `--enable-preview` at run time, and only the same JDK version. >> >> Java 14 already has "APIs associated with preview language features" that work >> this way, such as `java.lang.Record`. In future, such APIs would simply be cast >> as preview APIs. The existing private mechanism that identifies them to `javac` >> and `javadoc` -- `@jdk.internal.PreviewFeature` -- will be used for all preview >> APIs. >> >> 4. The class files of a preview API itself are _not_ marked. There are no >> changes to how the JDK is compiled, and every class file in the JDK will have a >> 0 minor_version as before. >> >> To allow for intra-JDK use of a preview API, code in the same module as a >> preview API is _not_ required to "opt in" in order to use the API. That is, when >> `--enable-preview` is missing, the effect of using a preview API element is a >> compile-time error _only for code in other modules_. This is similar to how the >> effect of using an `@Deprecated` element is a warning _only for code that is not >> itself deprecated_. >> >> >> Beyond APIs, incubation has been used for tools, e.g., `jdk.incubator.jpackage` >> in JDK 14. However, it has little real meaning there. A tool that's good enough >> to ship in a JDK feature release has already achieved a high level of quality >> and is ready for a final round of polishing for its command line options. As >> long as the tool displays a suitable message about its non-final status, it can >> legitimately be called a "preview tool" and placed in a module in the ordinary >> `jdk` namespace rather than the `jdk.incubator` namespace. >> >> >> We don't propose to deprecate incubation or delete JEP 11. It may be useful in >> future for non-final APIs that wish to live at arms' length from the JDK, >> outside the `java` namespace. >> >> I intend to update JEP 12 to incorporate preview APIs in the near future, >> hopefully in time for 15 so that projects such as Panama can benefit from them. >> >> > > Alex From forax at univ-mlv.fr Thu Mar 5 08:31:19 2020 From: forax at univ-mlv.fr (Remi Forax) Date: Thu, 5 Mar 2020 09:31:19 +0100 (CET) Subject: Preview APIs in the Java Platform In-Reply-To: References: <952661d4-3f1d-2a05-a178-e11b37141cf7@oracle.com> Message-ID: <933718041.105759.1583397079416.JavaMail.zimbra@u-pem.fr> Hi Alex, I really don't like your dilution argument which is condescending. And given how Java twist semver, i don't think that using it as an example helps to understand your point. I believe that opposing the preview API mechanism and the incubation module is a mistake, both are useful at different level. If you are not adding feature to the language, the preview API is useless because it requires a very specific JVM version (and not a version or upward), it's not something you want when you publish an API even an experimental one. I thing the "preview API" mechanism is the wrong name, it should be named "preview language feature API" because it's only useful for APIs that are required by a language feature. regards, R?mi ----- Mail original ----- > De: "Alex Buckley" > ?: "jdk-dev" > Envoy?: Mercredi 4 Mars 2020 20:22:24 > Objet: Re: Preview APIs in the Java Platform > We are emphatically not proposing a mechanism for "Any API that is > written in Java can be made 'unavailable by default' by its author." > > We are proposing a mechanism for "An API in the Java SE Platform can be > made 'unavailable by default' by the Java SE Platform Spec." > > Our mechanism exists solely to support preview features in Java SE. Per > JEP 12, preview features embody precise commitments about quality and > readiness that we've signed up for when evolving the Java language, JVM, > and SE API. We have no expectation that other platforms -- be they other > languages on the JVM, or other APIs which sit above the SE API -- will > share those commitments for their own evolution. Other platforms have no > guarantee at all that the idea of preview features, and the commitments > they represent, will evolve in a way that's useful or workable for those > platforms. > > Especially with Java 14, the entire Java developer community is becoming > aware of the high quality, carefully delivered nature of preview > features in Java SE. If we opened up the mechanism so that API authors > could use it, they would do so -- and each would make slightly different > commitments about quality and readiness. The preview concept would soon > find itself in the same place as the semantic versioning concept: a > simple "standard" for API authors to follow in theory, but a widely > abused and mis-applied concept in practice. We are not going to take the > risk of the preview concept being diluted, because it's something that > every Java developer should recognize and understand when they peruse > the latest "What's new in Java XX" article. > > Alex > > On 3/4/2020 10:26 AM, Bill Shannon wrote: >> Alex, do you see any problems with using these new features with >> "layered products"? >> >> For example, could some Jakarta EE APIs mark modules as "preview" >> and take advantage of the same compiler and runtime support that's >> available to JDK modules? >> >> Is there anything that limits this support to java.* modules? >> >> >> Alex Buckley wrote on 3/3/20 1:15 PM: >>> Java 14 will be the third release to contain preview language features. The idea >>> of shipping non-final language features -- conceived by JEP 12 in 2018 -- is >>> turning out well, producing better final features. This made us wonder if >>> incubation -- conceived by JEP 11 in 2016 -- is the right channel for shipping >>> non-final APIs, and if the recent introduction of APIs associated with preview >>> language features (such as `java.lang.Record`) is a signpost to a better >>> channel. >>> >>> Incubation follows the tenor of the old triennial release model, where features >>> were chosen at the start of a release and their evolving implementations were >>> shipped in the JDK's Early Access (EA) binaries for years before General >>> Availability (GA). To signal that an API is non-final both before and after GA, >>> incubation places it in the `jdk.incubator` namespace. Unfortunately, this >>> distorts the API and its implementation [1][2], and means that signatures in >>> `java.*` cannot refer to the new API even if such integration is desirable. >>> These problems are not significant for user-level libraries such as the HTTP2 >>> client API which incubated in JDK 9, but they are significant for lower level >>> libraries which need a privileged relationship with `java.base`, such as the >>> Memory Access API which incubated in JDK 14. >>> >>> [1] https://mail.openjdk.java.net/pipermail/panama-dev/2019-June/005884.html >>> [2] https://bugs.openjdk.java.net/browse/JDK-8237349 >>> >>> In the new biannual release model, features are targeted to a release only when >>> they are ready. Until then, they evolve in OpenJDK projects such as Panama and >>> Valhalla, watching JDK releases sail by every six months. There is broad public >>> awareness of these projects, and they generally offer EA binaries, so there is >>> good potential for feedback in the time before a feature is targeted to a >>> release. Also, because OpenJDK projects are blueprints for the future Java >>> Platform, they can place non-final APIs directly in `java.base` and refer to >>> them from signatures in `java.*`. This makes projects' EA binaries look more >>> polished and should produce higher quality feedback. >>> >>> Ultimately, though, the best way to provoke feedback on a feature is to ship it >>> in the GA binary of a JDK feature release. This approach has worked well for >>> preview language features, where the Java community has accepted the idea of >>> non-final features that are disabled by default and can thus be changed in >>> response to feedback. Ideally, we want a way to ship highly-evolved but >>> non-final APIs in a JDK feature release, without distorting the API by >>> relocating its packages and modules, and without misleading developers about its >>> status. >>> >>> >>> Most "preview principles" carry over from language features to APIs: >>> >>> 1. A _preview API_ is a new method, field, class, package, or module in the Java >>> Platform whose design, specification, and implementation are semantically >>> complete, but which would benefit from a period of broad exposure and evaluation >>> before achieving either final and permanent status in the Java Platform or else >>> being refined or removed. >>> >>> We would recast the quality bar for all preview features from "95% done now" to >>> "100% done within a year". This recognizes two points: first, our experience >>> that two rounds of preview is normal, and second, the fact that an API has a >>> larger surface area than a language/VM feature and thus undergoes more syntactic >>> polishing on its way to final status. >>> >>> 2. A preview API will often reside in the `java.base` module, but may reside in >>> another `java.*` module, including one introduced just for the preview API. For >>> example, the HTTP2 client API could have previewed in the `java.net.http` >>> module, where it ended up after incubation. >>> >>> A JEP that introduces many packages may designate them all as preview APIs and >>> place them in different `java.*` modules as it sees fit. >>> >>> 3. Preview APIs are unavailable by default. To use them, a developer "opts in" >>> in the same way as for preview language features: `--release N --enable-preview` >>> at compile time. The class files of the developer's program are marked to depend >>> on the preview APIs of Java version N, as if the program had used preview >>> language features. Accordingly, the class files must be executed with >>> `--enable-preview` at run time, and only the same JDK version. >>> >>> Java 14 already has "APIs associated with preview language features" that work >>> this way, such as `java.lang.Record`. In future, such APIs would simply be cast >>> as preview APIs. The existing private mechanism that identifies them to `javac` >>> and `javadoc` -- `@jdk.internal.PreviewFeature` -- will be used for all preview >>> APIs. >>> >>> 4. The class files of a preview API itself are _not_ marked. There are no >>> changes to how the JDK is compiled, and every class file in the JDK will have a >>> 0 minor_version as before. >>> >>> To allow for intra-JDK use of a preview API, code in the same module as a >>> preview API is _not_ required to "opt in" in order to use the API. That is, when >>> `--enable-preview` is missing, the effect of using a preview API element is a >>> compile-time error _only for code in other modules_. This is similar to how the >>> effect of using an `@Deprecated` element is a warning _only for code that is not >>> itself deprecated_. >>> >>> >>> Beyond APIs, incubation has been used for tools, e.g., `jdk.incubator.jpackage` >>> in JDK 14. However, it has little real meaning there. A tool that's good enough >>> to ship in a JDK feature release has already achieved a high level of quality >>> and is ready for a final round of polishing for its command line options. As >>> long as the tool displays a suitable message about its non-final status, it can >>> legitimately be called a "preview tool" and placed in a module in the ordinary >>> `jdk` namespace rather than the `jdk.incubator` namespace. >>> >>> >>> We don't propose to deprecate incubation or delete JEP 11. It may be useful in >>> future for non-final APIs that wish to live at arms' length from the JDK, >>> outside the `java` namespace. >>> >>> I intend to update JEP 12 to incorporate preview APIs in the near future, >>> hopefully in time for 15 so that projects such as Panama can benefit from them. >>> >>> > >> Alex From christoph.langer at sap.com Thu Mar 5 09:17:00 2020 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 5 Mar 2020 09:17:00 +0000 Subject: Result: New JDK Reviewer: Lutz Schmidt Message-ID: Voting for Lutz Schmidt [1] is now closed. Yes: 14 Veto: 0 Abstain: 0 According to the Bylaws definition of Three-Vote Consensus, this is sufficient to approve the nomination. Christoph Langer [1] https://mail.openjdk.java.net/pipermail/jdk-dev/2020-February/003916.html From alex.buckley at oracle.com Thu Mar 5 15:54:54 2020 From: alex.buckley at oracle.com (Alex Buckley) Date: Thu, 5 Mar 2020 07:54:54 -0800 Subject: Preview APIs in the Java Platform In-Reply-To: <933718041.105759.1583397079416.JavaMail.zimbra@u-pem.fr> References: <952661d4-3f1d-2a05-a178-e11b37141cf7@oracle.com> <933718041.105759.1583397079416.JavaMail.zimbra@u-pem.fr> Message-ID: <542ab27c-1862-443a-8232-a990c5052d34@oracle.com> We already have APIs associated with preview language features -- `java.lang.Record`, `java.lang.String::stripIndent`, and `java.lang.String::translateEscapes` in 14. The new proposal is about extending our preview "brand" for Java SE features (with its promises of quality and readiness and openness to feedback) to APIs in the Platform that are not associated with any language features. For example, if we were doing the HTTP2 client API today, we might well do it as a preview API: a preview module `java.net.http` with new types, plus preview methods in `java.base` whose signatures mention the new types. The Memory Access API which is incubating in 14 would also be better off as a preview API -- no need for Maurizio to spend time moving it to `jdk.incubator` (I'm significantly underselling how much of a pain that actually was), and a more "real" feel for people trying it out. Forthcoming changes to the Thread API by Loom would also benefit. I agree that incubation is useful when an API has not reached the level of quality and readiness associated with the preview "brand", yet would still benefit from the greater exposure that comes from shipping in a JDK feature release. Programs that choose to use an incubating API in JDK N do not have their class files tagged to run only on JDK N, but in all likelihood such programs will fail on JDK N+1 because of changes in the incubating API -- so the "requires very specific JVM version" angle is, in practice, common to incubating and preview APIs. Alex On 3/5/2020 12:31 AM, Remi Forax wrote: > Hi Alex, > I really don't like your dilution argument which is condescending. > And given how Java twist semver, i don't think that using it as an example helps to understand your point. > > I believe that opposing the preview API mechanism and the incubation module is a mistake, both are useful at different level. > If you are not adding feature to the language, the preview API is useless because it requires a very specific JVM version (and not a version or upward), > it's not something you want when you publish an API even an experimental one. > > I thing the "preview API" mechanism is the wrong name, it should be named "preview language feature API" because it's only useful for APIs that are required by a language feature. > > regards, > R?mi > > ----- Mail original ----- >> De: "Alex Buckley" >> ?: "jdk-dev" >> Envoy?: Mercredi 4 Mars 2020 20:22:24 >> Objet: Re: Preview APIs in the Java Platform > >> We are emphatically not proposing a mechanism for "Any API that is >> written in Java can be made 'unavailable by default' by its author." >> >> We are proposing a mechanism for "An API in the Java SE Platform can be >> made 'unavailable by default' by the Java SE Platform Spec." >> >> Our mechanism exists solely to support preview features in Java SE. Per >> JEP 12, preview features embody precise commitments about quality and >> readiness that we've signed up for when evolving the Java language, JVM, >> and SE API. We have no expectation that other platforms -- be they other >> languages on the JVM, or other APIs which sit above the SE API -- will >> share those commitments for their own evolution. Other platforms have no >> guarantee at all that the idea of preview features, and the commitments >> they represent, will evolve in a way that's useful or workable for those >> platforms. >> >> Especially with Java 14, the entire Java developer community is becoming >> aware of the high quality, carefully delivered nature of preview >> features in Java SE. If we opened up the mechanism so that API authors >> could use it, they would do so -- and each would make slightly different >> commitments about quality and readiness. The preview concept would soon >> find itself in the same place as the semantic versioning concept: a >> simple "standard" for API authors to follow in theory, but a widely >> abused and mis-applied concept in practice. We are not going to take the >> risk of the preview concept being diluted, because it's something that >> every Java developer should recognize and understand when they peruse >> the latest "What's new in Java XX" article. >> >> Alex >> >> On 3/4/2020 10:26 AM, Bill Shannon wrote: >>> Alex, do you see any problems with using these new features with >>> "layered products"? >>> >>> For example, could some Jakarta EE APIs mark modules as "preview" >>> and take advantage of the same compiler and runtime support that's >>> available to JDK modules? >>> >>> Is there anything that limits this support to java.* modules? >>> >>> >>> Alex Buckley wrote on 3/3/20 1:15 PM: >>>> Java 14 will be the third release to contain preview language features. The idea >>>> of shipping non-final language features -- conceived by JEP 12 in 2018 -- is >>>> turning out well, producing better final features. This made us wonder if >>>> incubation -- conceived by JEP 11 in 2016 -- is the right channel for shipping >>>> non-final APIs, and if the recent introduction of APIs associated with preview >>>> language features (such as `java.lang.Record`) is a signpost to a better >>>> channel. >>>> >>>> Incubation follows the tenor of the old triennial release model, where features >>>> were chosen at the start of a release and their evolving implementations were >>>> shipped in the JDK's Early Access (EA) binaries for years before General >>>> Availability (GA). To signal that an API is non-final both before and after GA, >>>> incubation places it in the `jdk.incubator` namespace. Unfortunately, this >>>> distorts the API and its implementation [1][2], and means that signatures in >>>> `java.*` cannot refer to the new API even if such integration is desirable. >>>> These problems are not significant for user-level libraries such as the HTTP2 >>>> client API which incubated in JDK 9, but they are significant for lower level >>>> libraries which need a privileged relationship with `java.base`, such as the >>>> Memory Access API which incubated in JDK 14. >>>> >>>> [1] https://mail.openjdk.java.net/pipermail/panama-dev/2019-June/005884.html >>>> [2] https://bugs.openjdk.java.net/browse/JDK-8237349 >>>> >>>> In the new biannual release model, features are targeted to a release only when >>>> they are ready. Until then, they evolve in OpenJDK projects such as Panama and >>>> Valhalla, watching JDK releases sail by every six months. There is broad public >>>> awareness of these projects, and they generally offer EA binaries, so there is >>>> good potential for feedback in the time before a feature is targeted to a >>>> release. Also, because OpenJDK projects are blueprints for the future Java >>>> Platform, they can place non-final APIs directly in `java.base` and refer to >>>> them from signatures in `java.*`. This makes projects' EA binaries look more >>>> polished and should produce higher quality feedback. >>>> >>>> Ultimately, though, the best way to provoke feedback on a feature is to ship it >>>> in the GA binary of a JDK feature release. This approach has worked well for >>>> preview language features, where the Java community has accepted the idea of >>>> non-final features that are disabled by default and can thus be changed in >>>> response to feedback. Ideally, we want a way to ship highly-evolved but >>>> non-final APIs in a JDK feature release, without distorting the API by >>>> relocating its packages and modules, and without misleading developers about its >>>> status. >>>> >>>> >>>> Most "preview principles" carry over from language features to APIs: >>>> >>>> 1. A _preview API_ is a new method, field, class, package, or module in the Java >>>> Platform whose design, specification, and implementation are semantically >>>> complete, but which would benefit from a period of broad exposure and evaluation >>>> before achieving either final and permanent status in the Java Platform or else >>>> being refined or removed. >>>> >>>> We would recast the quality bar for all preview features from "95% done now" to >>>> "100% done within a year". This recognizes two points: first, our experience >>>> that two rounds of preview is normal, and second, the fact that an API has a >>>> larger surface area than a language/VM feature and thus undergoes more syntactic >>>> polishing on its way to final status. >>>> >>>> 2. A preview API will often reside in the `java.base` module, but may reside in >>>> another `java.*` module, including one introduced just for the preview API. For >>>> example, the HTTP2 client API could have previewed in the `java.net.http` >>>> module, where it ended up after incubation. >>>> >>>> A JEP that introduces many packages may designate them all as preview APIs and >>>> place them in different `java.*` modules as it sees fit. >>>> >>>> 3. Preview APIs are unavailable by default. To use them, a developer "opts in" >>>> in the same way as for preview language features: `--release N --enable-preview` >>>> at compile time. The class files of the developer's program are marked to depend >>>> on the preview APIs of Java version N, as if the program had used preview >>>> language features. Accordingly, the class files must be executed with >>>> `--enable-preview` at run time, and only the same JDK version. >>>> >>>> Java 14 already has "APIs associated with preview language features" that work >>>> this way, such as `java.lang.Record`. In future, such APIs would simply be cast >>>> as preview APIs. The existing private mechanism that identifies them to `javac` >>>> and `javadoc` -- `@jdk.internal.PreviewFeature` -- will be used for all preview >>>> APIs. >>>> >>>> 4. The class files of a preview API itself are _not_ marked. There are no >>>> changes to how the JDK is compiled, and every class file in the JDK will have a >>>> 0 minor_version as before. >>>> >>>> To allow for intra-JDK use of a preview API, code in the same module as a >>>> preview API is _not_ required to "opt in" in order to use the API. That is, when >>>> `--enable-preview` is missing, the effect of using a preview API element is a >>>> compile-time error _only for code in other modules_. This is similar to how the >>>> effect of using an `@Deprecated` element is a warning _only for code that is not >>>> itself deprecated_. >>>> >>>> >>>> Beyond APIs, incubation has been used for tools, e.g., `jdk.incubator.jpackage` >>>> in JDK 14. However, it has little real meaning there. A tool that's good enough >>>> to ship in a JDK feature release has already achieved a high level of quality >>>> and is ready for a final round of polishing for its command line options. As >>>> long as the tool displays a suitable message about its non-final status, it can >>>> legitimately be called a "preview tool" and placed in a module in the ordinary >>>> `jdk` namespace rather than the `jdk.incubator` namespace. >>>> >>>> >>>> We don't propose to deprecate incubation or delete JEP 11. It may be useful in >>>> future for non-final APIs that wish to live at arms' length from the JDK, >>>> outside the `java` namespace. >>>> >>>> I intend to update JEP 12 to incorporate preview APIs in the near future, >>>> hopefully in time for 15 so that projects such as Panama can benefit from them. >>>> >>>> >>>> Alex From youngty1997 at gmail.com Thu Mar 5 17:12:59 2020 From: youngty1997 at gmail.com (Ty Young) Date: Thu, 5 Mar 2020 11:12:59 -0600 Subject: Throwing exceptions from records Message-ID: <12f84ea7-ad1f-58ef-6711-8e4e07910707@gmail.com> Hi, Is there a way in JDK 14 records to throw exceptions from a constructor? Currently I have dozens of classes that I want to convert to records but am unable to due to there being no way to have a constructor that throws exceptions. I'm not able to find any examples of how records and exceptions are supposed to work together online either... From forax at univ-mlv.fr Thu Mar 5 18:21:51 2020 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Thu, 5 Mar 2020 19:21:51 +0100 (CET) Subject: Preview APIs in the Java Platform In-Reply-To: <542ab27c-1862-443a-8232-a990c5052d34@oracle.com> References: <952661d4-3f1d-2a05-a178-e11b37141cf7@oracle.com> <933718041.105759.1583397079416.JavaMail.zimbra@u-pem.fr> <542ab27c-1862-443a-8232-a990c5052d34@oracle.com> Message-ID: <870467369.520132.1583432511411.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "Alex Buckley" > ?: "Remi Forax" , "jdk-dev" > Envoy?: Jeudi 5 Mars 2020 16:54:54 > Objet: Re: Preview APIs in the Java Platform > We already have APIs associated with preview language features -- > `java.lang.Record`, `java.lang.String::stripIndent`, and > `java.lang.String::translateEscapes` in 14. The new proposal is about > extending our preview "brand" for Java SE features (with its promises of > quality and readiness and openness to feedback) to APIs in the Platform > that are not associated with any language features. > > For example, if we were doing the HTTP2 client API today, we might well > do it as a preview API: a preview module `java.net.http` with new types, > plus preview methods in `java.base` whose signatures mention the new > types. The Memory Access API which is incubating in 14 would also be > better off as a preview API -- no need for Maurizio to spend time moving > it to `jdk.incubator` (I'm significantly underselling how much of a pain > that actually was), and a more "real" feel for people trying it out. > Forthcoming changes to the Thread API by Loom would also benefit. I agree that adding a public API in java.base is not covered by the incubator api. For the http2 client, having a backlink from java.base to the module java.net.http is not a correct way to design thing, the module system doesn't allow circularity. For the foreign memory api, it is more low level that the nio buffer api and heavily use unsafe which are both inside java.base, that's why it's a PITA. That said, the trick to have the implementation in java.base in a package that is only exported to an incubator module and the API in the incubator module works. For loom (and for valhalla), I believe that using the preview API is not the right mechanism to do thing because you will want to be able to enable/disable them separately given that they both impact the VM in a different ways. Moreover there are 2 looms, you have "loom the fiber" and "loom the continuation" and you may want to expose one ("loom the fiber") without exposing the other ("loom the continuation"), which also suggest different flags. > > I agree that incubation is useful when an API has not reached the level > of quality and readiness associated with the preview "brand", yet would > still benefit from the greater exposure that comes from shipping in a > JDK feature release. > > Programs that choose to use an incubating API in JDK N do not have their > class files tagged to run only on JDK N, but in all likelihood such > programs will fail on JDK N+1 because of changes in the incubating API > -- so the "requires very specific JVM version" angle is, in practice, > common to incubating and preview APIs. yes, but there is a difference between the VM refusing to read the bytecode and the VM throwing a NoSuchMethodError because the API has changed. > > Alex R?mi > > On 3/5/2020 12:31 AM, Remi Forax wrote: >> Hi Alex, >> I really don't like your dilution argument which is condescending. >> And given how Java twist semver, i don't think that using it as an example helps >> to understand your point. >> >> I believe that opposing the preview API mechanism and the incubation module is a >> mistake, both are useful at different level. >> If you are not adding feature to the language, the preview API is useless >> because it requires a very specific JVM version (and not a version or upward), >> it's not something you want when you publish an API even an experimental one. >> >> I thing the "preview API" mechanism is the wrong name, it should be named >> "preview language feature API" because it's only useful for APIs that are >> required by a language feature. >> >> regards, >> R?mi >> >> ----- Mail original ----- >>> De: "Alex Buckley" >>> ?: "jdk-dev" >>> Envoy?: Mercredi 4 Mars 2020 20:22:24 >>> Objet: Re: Preview APIs in the Java Platform >> >>> We are emphatically not proposing a mechanism for "Any API that is >>> written in Java can be made 'unavailable by default' by its author." >>> >>> We are proposing a mechanism for "An API in the Java SE Platform can be >>> made 'unavailable by default' by the Java SE Platform Spec." >>> >>> Our mechanism exists solely to support preview features in Java SE. Per >>> JEP 12, preview features embody precise commitments about quality and >>> readiness that we've signed up for when evolving the Java language, JVM, >>> and SE API. We have no expectation that other platforms -- be they other >>> languages on the JVM, or other APIs which sit above the SE API -- will >>> share those commitments for their own evolution. Other platforms have no >>> guarantee at all that the idea of preview features, and the commitments >>> they represent, will evolve in a way that's useful or workable for those >>> platforms. >>> >>> Especially with Java 14, the entire Java developer community is becoming >>> aware of the high quality, carefully delivered nature of preview >>> features in Java SE. If we opened up the mechanism so that API authors >>> could use it, they would do so -- and each would make slightly different >>> commitments about quality and readiness. The preview concept would soon >>> find itself in the same place as the semantic versioning concept: a >>> simple "standard" for API authors to follow in theory, but a widely >>> abused and mis-applied concept in practice. We are not going to take the >>> risk of the preview concept being diluted, because it's something that >>> every Java developer should recognize and understand when they peruse >>> the latest "What's new in Java XX" article. >>> >>> Alex >>> >>> On 3/4/2020 10:26 AM, Bill Shannon wrote: >>>> Alex, do you see any problems with using these new features with >>>> "layered products"? >>>> >>>> For example, could some Jakarta EE APIs mark modules as "preview" >>>> and take advantage of the same compiler and runtime support that's >>>> available to JDK modules? >>>> >>>> Is there anything that limits this support to java.* modules? >>>> >>>> >>>> Alex Buckley wrote on 3/3/20 1:15 PM: >>>>> Java 14 will be the third release to contain preview language features. The idea >>>>> of shipping non-final language features -- conceived by JEP 12 in 2018 -- is >>>>> turning out well, producing better final features. This made us wonder if >>>>> incubation -- conceived by JEP 11 in 2016 -- is the right channel for shipping >>>>> non-final APIs, and if the recent introduction of APIs associated with preview >>>>> language features (such as `java.lang.Record`) is a signpost to a better >>>>> channel. >>>>> >>>>> Incubation follows the tenor of the old triennial release model, where features >>>>> were chosen at the start of a release and their evolving implementations were >>>>> shipped in the JDK's Early Access (EA) binaries for years before General >>>>> Availability (GA). To signal that an API is non-final both before and after GA, >>>>> incubation places it in the `jdk.incubator` namespace. Unfortunately, this >>>>> distorts the API and its implementation [1][2], and means that signatures in >>>>> `java.*` cannot refer to the new API even if such integration is desirable. >>>>> These problems are not significant for user-level libraries such as the HTTP2 >>>>> client API which incubated in JDK 9, but they are significant for lower level >>>>> libraries which need a privileged relationship with `java.base`, such as the >>>>> Memory Access API which incubated in JDK 14. >>>>> >>>>> [1] https://mail.openjdk.java.net/pipermail/panama-dev/2019-June/005884.html >>>>> [2] https://bugs.openjdk.java.net/browse/JDK-8237349 >>>>> >>>>> In the new biannual release model, features are targeted to a release only when >>>>> they are ready. Until then, they evolve in OpenJDK projects such as Panama and >>>>> Valhalla, watching JDK releases sail by every six months. There is broad public >>>>> awareness of these projects, and they generally offer EA binaries, so there is >>>>> good potential for feedback in the time before a feature is targeted to a >>>>> release. Also, because OpenJDK projects are blueprints for the future Java >>>>> Platform, they can place non-final APIs directly in `java.base` and refer to >>>>> them from signatures in `java.*`. This makes projects' EA binaries look more >>>>> polished and should produce higher quality feedback. >>>>> >>>>> Ultimately, though, the best way to provoke feedback on a feature is to ship it >>>>> in the GA binary of a JDK feature release. This approach has worked well for >>>>> preview language features, where the Java community has accepted the idea of >>>>> non-final features that are disabled by default and can thus be changed in >>>>> response to feedback. Ideally, we want a way to ship highly-evolved but >>>>> non-final APIs in a JDK feature release, without distorting the API by >>>>> relocating its packages and modules, and without misleading developers about its >>>>> status. >>>>> >>>>> >>>>> Most "preview principles" carry over from language features to APIs: >>>>> >>>>> 1. A _preview API_ is a new method, field, class, package, or module in the Java >>>>> Platform whose design, specification, and implementation are semantically >>>>> complete, but which would benefit from a period of broad exposure and evaluation >>>>> before achieving either final and permanent status in the Java Platform or else >>>>> being refined or removed. >>>>> >>>>> We would recast the quality bar for all preview features from "95% done now" to >>>>> "100% done within a year". This recognizes two points: first, our experience >>>>> that two rounds of preview is normal, and second, the fact that an API has a >>>>> larger surface area than a language/VM feature and thus undergoes more syntactic >>>>> polishing on its way to final status. >>>>> >>>>> 2. A preview API will often reside in the `java.base` module, but may reside in >>>>> another `java.*` module, including one introduced just for the preview API. For >>>>> example, the HTTP2 client API could have previewed in the `java.net.http` >>>>> module, where it ended up after incubation. >>>>> >>>>> A JEP that introduces many packages may designate them all as preview APIs and >>>>> place them in different `java.*` modules as it sees fit. >>>>> >>>>> 3. Preview APIs are unavailable by default. To use them, a developer "opts in" >>>>> in the same way as for preview language features: `--release N --enable-preview` >>>>> at compile time. The class files of the developer's program are marked to depend >>>>> on the preview APIs of Java version N, as if the program had used preview >>>>> language features. Accordingly, the class files must be executed with >>>>> `--enable-preview` at run time, and only the same JDK version. >>>>> >>>>> Java 14 already has "APIs associated with preview language features" that work >>>>> this way, such as `java.lang.Record`. In future, such APIs would simply be cast >>>>> as preview APIs. The existing private mechanism that identifies them to `javac` >>>>> and `javadoc` -- `@jdk.internal.PreviewFeature` -- will be used for all preview >>>>> APIs. >>>>> >>>>> 4. The class files of a preview API itself are _not_ marked. There are no >>>>> changes to how the JDK is compiled, and every class file in the JDK will have a >>>>> 0 minor_version as before. >>>>> >>>>> To allow for intra-JDK use of a preview API, code in the same module as a >>>>> preview API is _not_ required to "opt in" in order to use the API. That is, when >>>>> `--enable-preview` is missing, the effect of using a preview API element is a >>>>> compile-time error _only for code in other modules_. This is similar to how the >>>>> effect of using an `@Deprecated` element is a warning _only for code that is not >>>>> itself deprecated_. >>>>> >>>>> >>>>> Beyond APIs, incubation has been used for tools, e.g., `jdk.incubator.jpackage` >>>>> in JDK 14. However, it has little real meaning there. A tool that's good enough >>>>> to ship in a JDK feature release has already achieved a high level of quality >>>>> and is ready for a final round of polishing for its command line options. As >>>>> long as the tool displays a suitable message about its non-final status, it can >>>>> legitimately be called a "preview tool" and placed in a module in the ordinary >>>>> `jdk` namespace rather than the `jdk.incubator` namespace. >>>>> >>>>> >>>>> We don't propose to deprecate incubation or delete JEP 11. It may be useful in >>>>> future for non-final APIs that wish to live at arms' length from the JDK, >>>>> outside the `java` namespace. >>>>> >>>>> I intend to update JEP 12 to incorporate preview APIs in the near future, >>>>> hopefully in time for 15 so that projects such as Panama can benefit from them. >>>>> >>>>> > >>>> Alex From alex.buckley at oracle.com Thu Mar 5 17:16:47 2020 From: alex.buckley at oracle.com (Alex Buckley) Date: Thu, 5 Mar 2020 09:16:47 -0800 Subject: Throwing exceptions from records In-Reply-To: <12f84ea7-ad1f-58ef-6711-8e4e07910707@gmail.com> References: <12f84ea7-ad1f-58ef-6711-8e4e07910707@gmail.com> Message-ID: <35a8dba6-84e3-4f2d-c7bd-2cec37656070@oracle.com> Per JEP 359, the list for record-related discussion is amber-dev. bcc'ing jdk-dev off this thread. On 3/5/2020 9:12 AM, Ty Young wrote: > Hi, > > > Is there a way in JDK 14 records to throw exceptions from a constructor? > Currently I have dozens of classes that I want to convert to records but > am unable to due to there being no way to have a constructor that throws > exceptions. I'm not able to find any examples of how records and > exceptions are supposed to work together online either... From alex.buckley at oracle.com Thu Mar 5 18:44:54 2020 From: alex.buckley at oracle.com (Alex Buckley) Date: Thu, 5 Mar 2020 10:44:54 -0800 Subject: Preview APIs in the Java Platform In-Reply-To: <870467369.520132.1583432511411.JavaMail.zimbra@u-pem.fr> References: <952661d4-3f1d-2a05-a178-e11b37141cf7@oracle.com> <933718041.105759.1583397079416.JavaMail.zimbra@u-pem.fr> <542ab27c-1862-443a-8232-a990c5052d34@oracle.com> <870467369.520132.1583432511411.JavaMail.zimbra@u-pem.fr> Message-ID: <2b5c6f16-3a52-cd5a-903b-66e910ec1bc2@oracle.com> On 3/5/2020 10:21 AM, forax at univ-mlv.fr wrote: > I agree that adding a public API in java.base is not covered by the > incubator api. Right. We see that as a problem to be solved. Shipping in java.base but in an EA binary has low uptake; shipping in jdk.incubator.foo in a GA binary has low uptake. > For the http2 client, having a backlink from java.base to the module > java.net.http is not a correct way to design thing, the module system > doesn't allow circularity. True, I shouldn't have raised that for a preview API in its own module. I was thinking about how having Memory Access in java.base would enable integration with java.lang.invoke signatures. > For the foreign memory api, it is more low level that the nio buffer > api and heavily use unsafe which are both inside java.base, that's > why it's a PITA. That said, the trick to have the implementation in > java.base in a package that is only exported to an incubator module > and the API in the incubator module works. It works, but it was a pain for Maurizio to have to refactor everything, add helper classes in java.base, etc, to accommodate the move to an incubator module. And he'll have to move it all back when Memory Access goes final! This API churn is confusing to understand. (Yes, I know that it's just a matter of changing some imports, but that's too literal a way of looking at the world. An API which changes its packages twice -- from java.* in EA, to jdk.incubator in GA, to java.* in a later GA -- is going to confuse people.) > For loom (and for valhalla), I believe that using the preview API is > not the right mechanism to do thing because you will want to be able > to enable/disable them separately given that they both impact the VM > in a different ways. Moreover there are 2 looms, you have "loom the > fiber" and "loom the continuation" and you may want to expose one > ("loom the fiber") without exposing the other ("loom the > continuation"), which also suggest different flags. Preview features are not experimental in any way. If Project Loom still has "2 looms" in flight, then it's experimental, and is not ready to preview. >> Programs that choose to use an incubating API in JDK N do not have >> their class files tagged to run only on JDK N, but in all >> likelihood such programs will fail on JDK N+1 because of changes in >> the incubating API -- so the "requires very specific JVM version" >> angle is, in practice, common to incubating and preview APIs. > > yes, but there is a difference between the VM refusing to read the > bytecode and the VM throwing a NoSuchMethodError because the API has > changed. Yes. Literally, you are correct. Conceptually, this means that neither a program which uses an incubating API of JDK N, nor a program which uses a preview API of JDK N, can expect to run successfully on JDK N+1. Alex From maurizio.cimadamore at oracle.com Thu Mar 5 18:47:41 2020 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Thu, 5 Mar 2020 18:47:41 +0000 Subject: Preview APIs in the Java Platform In-Reply-To: <952661d4-3f1d-2a05-a178-e11b37141cf7@oracle.com> References: <952661d4-3f1d-2a05-a178-e11b37141cf7@oracle.com> Message-ID: On 03/03/2020 21:15, Alex Buckley wrote: > I intend to update JEP 12 to incorporate preview APIs in the near > future, hopefully in time for 15 so that projects such as Panama can > benefit from them. Thanks for looking at this Alex. During the development of JEP 370 (memory access API [1]) we ran into some issues when trying to make the API fit in the (rather strict) incubating module rules. While using the memory access API is relatively easy (an --add-modules "jdk.incubator.foreign" will do the trick) the number of hacks we had to put in place in order to make the whole thing work was, I think, rather unfortunate. The main issue we faced is that, at its core, the memory access API adds a new kind of VarHandle - and all the logic for dealing with VarHandles is in java.base - but since incubating APIs had to live in their own separate module, we had to find ways to "split" the API and to create proxy interfaces [2] which java.base could then use in order to workaround the fact that the memory access API is defined in a module which is not available (for obvious reasons) from java.base. Now, sometimes these hacks just result in a less-than-ideal implementation? - e.g. where the code is more cluttered than we'd like; but in the case of Panama we ran into actual performance bottlenecks [3] whose root cause was, precisely, the fact that we had to split the API into two pieces. So I welcome any change which (a) brings Java SE API at the same level as the language and VM features (by allowing such APIs to also be 'preview') and (b) allows development of future APIs not go through the twist and turns we had to go through when developing the memory access API. Cheers Maurizio [1] - https://openjdk.java.net/jeps/370 [2] - http://hg.openjdk.java.net/jdk/jdk/file/fbbcf9125cef/src/java.base/share/classes/jdk/internal/access/foreign [3] - https://bugs.openjdk.java.net/browse/JDK-8237349 From forax at univ-mlv.fr Thu Mar 5 20:31:19 2020 From: forax at univ-mlv.fr (Remi Forax) Date: Thu, 5 Mar 2020 21:31:19 +0100 (CET) Subject: Preview APIs in the Java Platform In-Reply-To: References: <952661d4-3f1d-2a05-a178-e11b37141cf7@oracle.com> Message-ID: <1826042880.559881.1583440279384.JavaMail.zimbra@u-pem.fr> Hi Maurizio, ----- Mail original ----- > De: "Maurizio Cimadamore" > ?: "Alex Buckley" , "jdk-dev" > Envoy?: Jeudi 5 Mars 2020 19:47:41 > Objet: Re: Preview APIs in the Java Platform > On 03/03/2020 21:15, Alex Buckley wrote: >> I intend to update JEP 12 to incorporate preview APIs in the near >> future, hopefully in time for 15 so that projects such as Panama can >> benefit from them. > > Thanks for looking at this Alex. > > During the development of JEP 370 (memory access API [1]) we ran into > some issues when trying to make the API fit in the (rather strict) > incubating module rules. While using the memory access API is relatively > easy (an --add-modules "jdk.incubator.foreign" will do the trick) the > number of hacks we had to put in place in order to make the whole thing > work was, I think, rather unfortunate. The main issue we faced is that, > at its core, the memory access API adds a new kind of VarHandle - and > all the logic for dealing with VarHandles is in java.base - but since > incubating APIs had to live in their own separate module, we had to find > ways to "split" the API and to create proxy interfaces [2] which > java.base could then use in order to workaround the fact that the memory > access API is defined in a module which is not available (for obvious > reasons) from java.base. > > Now, sometimes these hacks just result in a less-than-ideal > implementation? - e.g. where the code is more cluttered than we'd like; > but in the case of Panama we ran into actual performance bottlenecks [3] > whose root cause was, precisely, the fact that we had to split the API > into two pieces. > > So I welcome any change which (a) brings Java SE API at the same level > as the language and VM features (by allowing such APIs to also be > 'preview') and (b) allows development of future APIs not go through the > twist and turns we had to go through when developing the memory access API. You only see your side of the coin, let me talk about the other side. I've a code that run on Java 13 using Unsafe to clean a ByteBuffer, the jdk 14 introduces the incubator module jdk.incubator.foreign, so i've written a code that uses a segment instead of unsafe if I detect that jdk.incubator.foreign is available, this code is compiled with the jdk 14 and works with the jdk 14 and jdk 15 (at least for now). Now, let suppose that the memory access API is implemented using the proposed preview API, if i want to be able to use it for jdk 14 and 15, i need to first detect if --enable-preview is set (there is no API for that), and i need the same class to be compiled once per jdk, so one for jdk14 with preview enabled and one for jdk15 with preview enabled. But there is no version of javac able to compile those two classes at the same time. If i'm me, i will use bytecode patching but i'm pretty sure nobody sane will do that, so in practice very few people will test your API in real life. > > Cheers > Maurizio regards, R?mi > > [1] - https://openjdk.java.net/jeps/370 > [2] - > http://hg.openjdk.java.net/jdk/jdk/file/fbbcf9125cef/src/java.base/share/classes/jdk/internal/access/foreign > [3] - https://bugs.openjdk.java.net/browse/JDK-8237349 From forax at univ-mlv.fr Thu Mar 5 20:54:49 2020 From: forax at univ-mlv.fr (Remi Forax) Date: Thu, 5 Mar 2020 21:54:49 +0100 (CET) Subject: Preview APIs in the Java Platform In-Reply-To: <2b5c6f16-3a52-cd5a-903b-66e910ec1bc2@oracle.com> References: <952661d4-3f1d-2a05-a178-e11b37141cf7@oracle.com> <933718041.105759.1583397079416.JavaMail.zimbra@u-pem.fr> <542ab27c-1862-443a-8232-a990c5052d34@oracle.com> <870467369.520132.1583432511411.JavaMail.zimbra@u-pem.fr> <2b5c6f16-3a52-cd5a-903b-66e910ec1bc2@oracle.com> Message-ID: <1898183423.563155.1583441689008.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "Alex Buckley" > ?: "jdk-dev" > Envoy?: Jeudi 5 Mars 2020 19:44:54 > Objet: Re: Preview APIs in the Java Platform > On 3/5/2020 10:21 AM, forax at univ-mlv.fr wrote: >> I agree that adding a public API in java.base is not covered by the >> incubator api. > > Right. We see that as a problem to be solved. Shipping in java.base but > in an EA binary has low uptake; shipping in jdk.incubator.foo in a GA > binary has low uptake. > [...] > >> For the foreign memory api, it is more low level that the nio buffer >> api and heavily use unsafe which are both inside java.base, that's >> why it's a PITA. That said, the trick to have the implementation in >> java.base in a package that is only exported to an incubator module >> and the API in the incubator module works. > > It works, but it was a pain for Maurizio to have to refactor everything, > add helper classes in java.base, etc, to accommodate the move to an > incubator module. And he'll have to move it all back when Memory Access > goes final! This API churn is confusing to understand. (Yes, I know that > it's just a matter of changing some imports, but that's too literal a > way of looking at the world. An API which changes its packages twice -- > from java.* in EA, to jdk.incubator in GA, to java.* in a later GA -- is > going to confuse people.) I believe the choice is between pain for the implementor (using an incubator module) and pain for the users (using the preview API). > >> For loom (and for valhalla), I believe that using the preview API is >> not the right mechanism to do thing because you will want to be able >> to enable/disable them separately given that they both impact the VM >> in a different ways. Moreover there are 2 looms, you have "loom the >> fiber" and "loom the continuation" and you may want to expose one >> ("loom the fiber") without exposing the other ("loom the >> continuation"), which also suggest different flags. > > Preview features are not experimental in any way. If Project Loom still > has "2 looms" in flight, then it's experimental, and is not ready to > preview. yes, maybe. > >>> Programs that choose to use an incubating API in JDK N do not have >>> their class files tagged to run only on JDK N, but in all >>> likelihood such programs will fail on JDK N+1 because of changes in >>> the incubating API -- so the "requires very specific JVM version" >>> angle is, in practice, common to incubating and preview APIs. >> >> yes, but there is a difference between the VM refusing to read the >> bytecode and the VM throwing a NoSuchMethodError because the API has >> changed. > > Yes. Literally, you are correct. Conceptually, this means that neither a > program which uses an incubating API of JDK N, nor a program which uses > a preview API of JDK N, can expect to run successfully on JDK N+1. No, because with an incubating module, there is a subset of the API that works for JDK N and JDK N+1. See my answer to Maurizio. > > Alex R?mi From alex.buckley at oracle.com Thu Mar 5 21:04:14 2020 From: alex.buckley at oracle.com (Alex Buckley) Date: Thu, 5 Mar 2020 13:04:14 -0800 Subject: Preview APIs in the Java Platform In-Reply-To: <1826042880.559881.1583440279384.JavaMail.zimbra@u-pem.fr> References: <952661d4-3f1d-2a05-a178-e11b37141cf7@oracle.com> <1826042880.559881.1583440279384.JavaMail.zimbra@u-pem.fr> Message-ID: On 3/5/2020 12:31 PM, Remi Forax wrote: > I've a code that run on Java 13 using Unsafe to clean a ByteBuffer, > the jdk 14 introduces the incubator module jdk.incubator.foreign, so > i've written a code that uses a segment instead of unsafe if I detect > that jdk.incubator.foreign is available, this code is compiled with > the jdk 14 and works with the jdk 14 and jdk 15 (at least for now). I hope this code isn't something you're shipping to other people. Incubating APIs are meant to be used for personal exploration, not to build libraries that check the user's runtime and dive into incubating APIs if available. > Now, let suppose that the memory access API is implemented using the > proposed preview API, if i want to be able to use it for jdk 14 and > 15, i need to first detect if --enable-preview is set (there is no > API for that), and i need the same class to be compiled once per jdk, > so one for jdk14 with preview enabled and one for jdk15 with preview > enabled. But there is no version of javac able to compile those two > classes at the same time. So, run javac twice? And use an MRJAR to ship both class files? Wait, why am I saying this -- you know it perfectly well. You have a scenario involving support for multiple JDKs in one codebase that will get harder for you if we ship preview APIs instead of incubating APIs. That's unfortunate, but your scenario isn't one we wish to support. > If i'm me, i will use bytecode patching but i'm pretty sure nobody > sane will do that, so in practice very few people will test your API > in real life. OK, got it. Alex From alex.buckley at oracle.com Thu Mar 5 21:12:04 2020 From: alex.buckley at oracle.com (Alex Buckley) Date: Thu, 5 Mar 2020 13:12:04 -0800 Subject: Preview APIs in the Java Platform In-Reply-To: <1898183423.563155.1583441689008.JavaMail.zimbra@u-pem.fr> References: <952661d4-3f1d-2a05-a178-e11b37141cf7@oracle.com> <933718041.105759.1583397079416.JavaMail.zimbra@u-pem.fr> <542ab27c-1862-443a-8232-a990c5052d34@oracle.com> <870467369.520132.1583432511411.JavaMail.zimbra@u-pem.fr> <2b5c6f16-3a52-cd5a-903b-66e910ec1bc2@oracle.com> <1898183423.563155.1583441689008.JavaMail.zimbra@u-pem.fr> Message-ID: <5a0b136f-4beb-4b9e-d0ed-0f3aeccabbf9@oracle.com> On 3/5/2020 12:54 PM, Remi Forax wrote: >>> yes, but there is a difference between the VM refusing to read the >>> bytecode and the VM throwing a NoSuchMethodError because the API has >>> changed. >> >> Yes. Literally, you are correct. Conceptually, this means that neither a >> program which uses an incubating API of JDK N, nor a program which uses >> a preview API of JDK N, can expect to run successfully on JDK N+1. > > No, because with an incubating module, there is a subset of the API that works for JDK N and JDK N+1. There is no such promise stated or implied in JEP 11. Incubating APIs are the experimental, anything-can-change artifact that you're always assuming preview features are. If Panama stayed with incubation, then jdk.incubator.foreign in JDK 15 could be completely different than in JDK 14. Programs that program against jdk.incubator.foreign on 14 have no guarantee of running on 15, end of story. Alex From maurizio.cimadamore at oracle.com Thu Mar 5 21:19:00 2020 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Thu, 5 Mar 2020 21:19:00 +0000 Subject: Preview APIs in the Java Platform In-Reply-To: <1826042880.559881.1583440279384.JavaMail.zimbra@u-pem.fr> References: <952661d4-3f1d-2a05-a178-e11b37141cf7@oracle.com> <1826042880.559881.1583440279384.JavaMail.zimbra@u-pem.fr> Message-ID: <2de3392e-d4e9-1ff1-5049-ab4ac012635d@oracle.com> On 05/03/2020 20:31, Remi Forax wrote: > Hi Maurizio, > > ----- Mail original ----- >> De: "Maurizio Cimadamore" >> ?: "Alex Buckley" , "jdk-dev" >> Envoy?: Jeudi 5 Mars 2020 19:47:41 >> Objet: Re: Preview APIs in the Java Platform >> On 03/03/2020 21:15, Alex Buckley wrote: >>> I intend to update JEP 12 to incorporate preview APIs in the near >>> future, hopefully in time for 15 so that projects such as Panama can >>> benefit from them. >> Thanks for looking at this Alex. >> >> During the development of JEP 370 (memory access API [1]) we ran into >> some issues when trying to make the API fit in the (rather strict) >> incubating module rules. While using the memory access API is relatively >> easy (an --add-modules "jdk.incubator.foreign" will do the trick) the >> number of hacks we had to put in place in order to make the whole thing >> work was, I think, rather unfortunate. The main issue we faced is that, >> at its core, the memory access API adds a new kind of VarHandle - and >> all the logic for dealing with VarHandles is in java.base - but since >> incubating APIs had to live in their own separate module, we had to find >> ways to "split" the API and to create proxy interfaces [2] which >> java.base could then use in order to workaround the fact that the memory >> access API is defined in a module which is not available (for obvious >> reasons) from java.base. >> >> Now, sometimes these hacks just result in a less-than-ideal >> implementation? - e.g. where the code is more cluttered than we'd like; >> but in the case of Panama we ran into actual performance bottlenecks [3] >> whose root cause was, precisely, the fact that we had to split the API >> into two pieces. >> >> So I welcome any change which (a) brings Java SE API at the same level >> as the language and VM features (by allowing such APIs to also be >> 'preview') and (b) allows development of future APIs not go through the >> twist and turns we had to go through when developing the memory access API. > You only see your side of the coin, let me talk about the other side. > > I've a code that run on Java 13 using Unsafe to clean a ByteBuffer, the jdk 14 introduces the incubator module jdk.incubator.foreign, so i've written a code that uses a segment instead of unsafe if I detect that jdk.incubator.foreign is available, this code is compiled with the jdk 14 and works with the jdk 14 and jdk 15 (at least for now). > Now, let suppose that the memory access API is implemented using the proposed preview API, if i want to be able to use it for jdk 14 and 15, i need to first detect if --enable-preview is set (there is no API for that), and i need the same class to be compiled once per jdk, so one for jdk14 with preview enabled and one for jdk15 with preview enabled. But there is no version of javac able to compile those two classes at the same time. > > If i'm me, i will use bytecode patching but i'm pretty sure nobody sane will do that, so in practice very few people will test your API in real life. I see where you are coming from. Our intention is that a preview API such as the memory access API will be used to make 'experiments' (e.g. try to rewrite parts of framework XYZ to use it instead of Unsafe), then report feedback, then throw away the results (in a way - they might even persist in some obscure GitHub repo, but you see what I mean, I hope). Here you seem to describe some use cases where you have some code that is production-like (maybe not in the sense of quality of the code, but in the sense that you expect it to just work and to be able to distribute it), and yet you are introducing a coupling with a part of the Java SE API which is not yet fully baked (whether you call that incubating or preview, the essence is the same). So, let's consider this mental experiment: what if the name of the incubating module kept changing on each release? Wouldn't you end up with a similar problem? What if the set of classes available in a given incubating module changes when going from Java N to N + 1? What if we rename MemorySegment to MemoryRegion? Wouldn't you still need to recompile? I hope you see my point: you seem to assume that incubating has stronger stability guarantees than it actually has. The preview feature mechanism, in this case, prevents (by design) from relying on the (wrong) assumption that the your code might work unchanged from version to version. Will this prevent people from creating programs where they play with memory segments and layouts and report back feedback? I don't think so. Will this prevent a bigger project from giving JEP 370 a try and temporarily enable preview features/APIs in a fork to do few experiments? Again, I don't think so. Cheers Maurizio > >> Cheers >> Maurizio > regards, > R?mi > >> [1] - https://openjdk.java.net/jeps/370 >> [2] - >> http://hg.openjdk.java.net/jdk/jdk/file/fbbcf9125cef/src/java.base/share/classes/jdk/internal/access/foreign >> [3] - https://bugs.openjdk.java.net/browse/JDK-8237349 From bill.shannon at oracle.com Thu Mar 5 21:27:28 2020 From: bill.shannon at oracle.com (Bill Shannon) Date: Thu, 5 Mar 2020 13:27:28 -0800 Subject: Preview APIs in the Java Platform In-Reply-To: <731186418.92411.1583396286089.JavaMail.zimbra@u-pem.fr> References: <952661d4-3f1d-2a05-a178-e11b37141cf7@oracle.com> <731186418.92411.1583396286089.JavaMail.zimbra@u-pem.fr> Message-ID: <72435f09-ed0a-9543-d419-b511806a2218@oracle.com> Remi Forax wrote on 3/5/20 12:18 AM: > Hi Bill, > I think you don't understand how preview APIs work, > as a user, using a preview API requires --enable-preview at compile time so the generated bytecodes will be tagged with the minor version of the classfile being equals to 65 535 (in violation of semver BTW), > so the only way to use a jar containing such classfiles is to use --enable-preview at runtime. > > So as a user it means once you use a preview API, you can not re-distribute your work, you can not by example upload such jar on Maven Central. Why not? Doesn't it just mean that anyone who wants to use my preview jar has to use --enable-preview at runtime? > Why JakartaEE will want such restriction on their own APIs ? For exactly the same reason the JDK wants such restriction. Is that so hard to imagine? > It's overly restrictive. It only makes sense for language features, not on APIs apart if they are required by a language feature. My understanding of the proposed change was to handle API features like language features and not isolate them in some incubator package but instead mark them so that they're only usable at runtime if you "opt in" to the preview-ness of the feature. From luke.hutch at gmail.com Fri Mar 6 01:03:35 2020 From: luke.hutch at gmail.com (Luke Hutchison) Date: Thu, 5 Mar 2020 18:03:35 -0700 Subject: Java memory model question Message-ID: Under the Java memory model, is it fair to assume that memory reads and writes can only be reorderered within a method, but not across method boundaries? (Define "method" here as what's left after any inlining has taken place.) Specifically I'm wondering: if a thread X launches a parallel stream that writes at most once to each independent element of an array, can it be assumed that when the stream processing ends, X will always read the value of all written array elements? In other words, can the termination of the stream be seen as a memory ordering barrier (in a weak sense)? I'm not asking whether the following code is advisable, only whether there's any chance of the main thread reading an old value from the array. int N = 50; String[] strValues = new String[N]; IntStream.range(0, N) .parallel() .forEach(i -> strValues[i] = Integer.toString(i)); // (*) Are the new strValues[i] all guaranteed to be visible here? for (String strValue : strValues) { System.out.println(strValue); } From david.holmes at oracle.com Fri Mar 6 02:09:36 2020 From: david.holmes at oracle.com (David Holmes) Date: Fri, 6 Mar 2020 12:09:36 +1000 Subject: Java memory model question In-Reply-To: References: Message-ID: Hi Luke, Probably a question better asked on concurrency-interest at cs.oswego.edu On 6/03/2020 11:03 am, Luke Hutchison wrote: > Under the Java memory model, is it fair to assume that memory reads and > writes can only be reorderered within a method, but not across method > boundaries? (Define "method" here as what's left after any inlining has > taken place.) No. Theoretically you could inline the entire program into a single "method". Method entry/exit don't in themselves define synchronization points. > Specifically I'm wondering: if a thread X launches a parallel stream that > writes at most once to each independent element of an array, can it be > assumed that when the stream processing ends, X will always read the value > of all written array elements? In other words, can the termination of the > stream be seen as a memory ordering barrier (in a weak sense)? I would have expected this to be explicitly stated somewhere in the streams documentation, but I don't see it. My expectation is that terminal operations would act as synchronization points. > I'm not asking whether the following code is advisable, only whether > there's any chance of the main thread reading an old value from the array. > > int N = 50; > String[] strValues = new String[N]; > IntStream.range(0, N) > .parallel() > .forEach(i -> strValues[i] = Integer.toString(i)); > // (*) Are the new strValues[i] all guaranteed to be visible here? > for (String strValue : strValues) { > System.out.println(strValue); > } I would expect that code to be fine. parallel() would not be usable otherwise. Cheers, David From brian.goetz at oracle.com Fri Mar 6 07:46:31 2020 From: brian.goetz at oracle.com (Brian Goetz) Date: Fri, 6 Mar 2020 07:46:31 +0000 Subject: Java memory model question In-Reply-To: References: Message-ID: <2C3115B4-1D3C-4D4A-ACB3-85F075A9319E@oracle.com> No, but this is a common myth. Method boundaries are not part of the JMM, and the JIT regularly makes optimizations that have the effect of reordering operations across method boundaries. Sent from my iPad > On Mar 6, 2020, at 1:04 AM, Luke Hutchison wrote: > > ?Under the Java memory model, is it fair to assume that memory reads and > writes can only be reorderered within a method, but not across method > boundaries? (Define "method" here as what's left after any inlining has > taken place.) > > Specifically I'm wondering: if a thread X launches a parallel stream that > writes at most once to each independent element of an array, can it be > assumed that when the stream processing ends, X will always read the value > of all written array elements? In other words, can the termination of the > stream be seen as a memory ordering barrier (in a weak sense)? > > I'm not asking whether the following code is advisable, only whether > there's any chance of the main thread reading an old value from the array. > > int N = 50; > String[] strValues = new String[N]; > IntStream.range(0, N) > .parallel() > .forEach(i -> strValues[i] = Integer.toString(i)); > // (*) Are the new strValues[i] all guaranteed to be visible here? > for (String strValue : strValues) { > System.out.println(strValue); > } From luke.hutch at gmail.com Fri Mar 6 10:27:31 2020 From: luke.hutch at gmail.com (Luke Hutchison) Date: Fri, 6 Mar 2020 03:27:31 -0700 Subject: Java memory model question In-Reply-To: <2C3115B4-1D3C-4D4A-ACB3-85F075A9319E@oracle.com> References: <2C3115B4-1D3C-4D4A-ACB3-85F075A9319E@oracle.com> Message-ID: On Fri, Mar 6, 2020 at 12:46 AM Brian Goetz wrote: > No, but this is a common myth. Method boundaries are not part of the > JMM, and the JIT regularly makes optimizations that have the effect of > reordering operations across method boundaries. > Thanks. That's pretty interesting, but I can't think of an optimization that would have that effect. Can you give an example? On Thu, Mar 5, 2020 at 7:09 PM David Holmes wrote: > Probably a question better asked on concurrency-interest at cs.oswego.edu Thanks, I didn't know about that list. > can the termination of the > > stream be seen as a memory ordering barrier (in a weak sense)? > > I would have expected this to be explicitly stated somewhere in the > streams documentation, but I don't see it. My expectation is that > terminal operations would act as synchronization points. > Right, although I wasn't asking about "high-level concurrency" (i.e. coordination between threads), but rather "low-level concurrency" (memory operation ordering). The question arises from the Java limitation that fields can be marked volatile, but if the field is of array type, then the individual elements of the array cannot be marked volatile. There's no "element-wise volatile" array unless you resort to using an AtomicReferenceArray, which creates a wrapper object per array element, which is wasteful on computation and space. I understand that the lack of "element-wise volatile" arrays means that threads can end up reading stale values if two or more threads are reading from and writing to the same array elements. However for this example, I specifically exclude that issue by ensuring that there's only ever either zero readers / one writer, or any number of readers / zero writers (every array element is only written once by any thread, then after the end of the stream, there are zero writers). I'm really just asking if there is some "macro-scale memory operation reordering" that could somehow occur across the synchronization barrier at the end of the stream. I don't know how deep the rabbit hole of memory operation reordering goes. I have to assume this is not the case, because the worker threads should all go quiescent at the end of the stream, so should have flushed their values out to at least L1 cache, and the CPU should ensure cache coherency between all cores beyond that point. But I want to make sure that can be guaranteed. In practice I have never seen this pattern fail, and it's exceptionally useful to be able to write to disjoint array elements from an IntStream.range(0, N) parallel stream, particularly as a pattern to very quickly parallelize orignially-serial code to have maximum efficiency, by simply replacing for loops that have no dependencies between operations with parallel streams -- but I have been nervous to use this pattern since I realized that arrays cannot have volatile elements. Logically my brain tells me the fear is unfounded, but I wanted to double check. From chris.hegarty at oracle.com Fri Mar 6 11:58:03 2020 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 6 Mar 2020 11:58:03 +0000 Subject: Preview APIs in the Java Platform In-Reply-To: <2de3392e-d4e9-1ff1-5049-ab4ac012635d@oracle.com> References: <952661d4-3f1d-2a05-a178-e11b37141cf7@oracle.com> <1826042880.559881.1583440279384.JavaMail.zimbra@u-pem.fr> <2de3392e-d4e9-1ff1-5049-ab4ac012635d@oracle.com> Message-ID: >>> ... >>> On 03/03/2020 21:15, Alex Buckley wrote: >>>> I intend to update JEP 12 to incorporate preview APIs in the near >>>> future, hopefully in time for 15 so that projects such as Panama can >>>> benefit from them. When working on the HTTP Client ( incubated in JDK 9, re-incubated in JDK 10, and standardized in Java 11 ), it would have been cosmetically nice to have been able to locate the API in java.net.http from the beginning, but in reality having it in its own incubator module/package didn't burden the implementation all that much. As was said previously, this is because the HTTP Client is largely a "user-level" library, which has very little ( if any ) coupling with java.base. When working on JEP 11 ( Incubator Modules ), we knew that features requiring tight coupling with java.base ( or the VM itself ) would likely emerge, and that squeezing such features into the incubation mechanism would require some "implementation pain". This seemed like an acceptable trade-off at the time, to enable the opportunity to better solicit feedback for such features. Remember, all this predates JEP 12. Fast forward to where we are now, and given the issues that the Foreign Memory API has had to deal with to squeeze into incubation, maybe there is a better way of achieving the goal - to gather feedback before standardizing. With the move to already have Preview Feature related API elements in java.*, then it seems ( to me ) a natural progression to expand this to, what are effectively, Preview APIs. Would HTTP Client have previewed ( rather than incubated )? Impossible to say for sure, but as one of the developers working on the feature, it is my opinion that we would not have previewed HTTP Client in 9. The reason being that I do not think the feature would meet the higher completeness level required by Preview. If Preview was an option back in the 9 time frame, then, again this is just my opinion, I think I would have held off incubating in 9 and iterated a little longer so that it could preview in 10. ( yes, while I said it would have been "cosmetically nice" to have used java.net.http from the beginning, avoiding the temporary incubation name would likely have avoided some developer confusion, which for me, on balance, would have been worth doing ) --- If there is a specific issue with recognising if preview features are enabled or not, then maybe that issue can be addressed by adding a property, API, or some such, that will reveal the enable-preview status at run-time. -Chris. From volker.simonis at gmail.com Fri Mar 6 13:23:03 2020 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 6 Mar 2020 14:23:03 +0100 Subject: Preview APIs in the Java Platform In-Reply-To: References: <952661d4-3f1d-2a05-a178-e11b37141cf7@oracle.com> <1826042880.559881.1583440279384.JavaMail.zimbra@u-pem.fr> <2de3392e-d4e9-1ff1-5049-ab4ac012635d@oracle.com> Message-ID: There's one major difference between the "Preview" and the "Incubator" approach which doesn't seemed to have been covered in this thread. "Preview" features have "Java SE" scope. They are, though not final, still part of the Java SE specification. As such they require a complete TCK and they have to be agreed upon in the corresponding JCP Expert Group and voted on in the JCP Executive Committee. Finally, because they are part of the SE specification, they have to be implemented by all Java implementations, no matter if they are based on the OpenJDK or not. "Incubator" features are a much more "lightweight" approach of introducing new APIs. Because they are not in the "Java SE" scope, they neither need to pass through the JCP nor do they require a complete TCK (although it would always be nice to have one). Finally, other Java vendors are not required to ship and support the same set of incubator modules like the OpenJDK and because the "jdk." package is not restricted like the "java." package they could even decide to "incubate" own features before even proposing them for inclusion into the OpenJDK (see [1]). [1] https://mail.openjdk.java.net/pipermail/jdk9-dev/2016-December/thread.html#5319 On Fri, Mar 6, 2020 at 12:58 PM Chris Hegarty wrote: > > > >>> ... > >>> On 03/03/2020 21:15, Alex Buckley wrote: > >>>> I intend to update JEP 12 to incorporate preview APIs in the near > >>>> future, hopefully in time for 15 so that projects such as Panama can > >>>> benefit from them. > > > When working on the HTTP Client ( incubated in JDK 9, re-incubated in > JDK 10, and standardized in Java 11 ), it would have been cosmetically > nice to have been able to locate the API in java.net.http from the > beginning, but in reality having it in its own incubator module/package > didn't burden the implementation all that much. As was said previously, > this is because the HTTP Client is largely a "user-level" library, which > has very little ( if any ) coupling with java.base. > > When working on JEP 11 ( Incubator Modules ), we knew that features > requiring tight coupling with java.base ( or the VM itself ) would > likely emerge, and that squeezing such features into the incubation > mechanism would require some "implementation pain". This seemed like an > acceptable trade-off at the time, to enable the opportunity to better > solicit feedback for such features. Remember, all this predates JEP 12. > > Fast forward to where we are now, and given the issues that the Foreign > Memory API has had to deal with to squeeze into incubation, maybe there > is a better way of achieving the goal - to gather feedback before > standardizing. With the move to already have Preview Feature related > API elements in java.*, then it seems ( to me ) a natural progression > to expand this to, what are effectively, Preview APIs. > > Would HTTP Client have previewed ( rather than incubated )? Impossible > to say for sure, but as one of the developers working on the feature, it > is my opinion that we would not have previewed HTTP Client in 9. The > reason being that I do not think the feature would meet the higher > completeness level required by Preview. If Preview was an option back > in the 9 time frame, then, again this is just my opinion, I think I > would have held off incubating in 9 and iterated a little longer so that > it could preview in 10. ( yes, while I said it would have been > "cosmetically nice" to have used java.net.http from the beginning, > avoiding the temporary incubation name would likely have avoided some > developer confusion, which for me, on balance, would have been worth > doing ) > > --- > > If there is a specific issue with recognising if preview features are > enabled or not, then maybe that issue can be addressed by adding a > property, API, or some such, that will reveal the enable-preview status > at run-time. > > -Chris. > From aph at redhat.com Fri Mar 6 13:52:21 2020 From: aph at redhat.com (Andrew Haley) Date: Fri, 6 Mar 2020 13:52:21 +0000 Subject: Java memory model question In-Reply-To: References: <2C3115B4-1D3C-4D4A-ACB3-85F075A9319E@oracle.com> Message-ID: <0700b162-3616-bea8-5b4d-2ce37376acb6@redhat.com> On 3/6/20 10:27 AM, Luke Hutchison wrote: > On Fri, Mar 6, 2020 at 12:46 AM Brian Goetz wrote: > >> No, but this is a common myth. Method boundaries are not part of the >> JMM, and the JIT regularly makes optimizations that have the effect of >> reordering operations across method boundaries. > > Thanks. That's pretty interesting, but I can't think of an optimization > that would have that effect. Can you give an example? Inside an optimizer in intermediate form, unrelated operations are often unordered: that is to say, they may be emitted in any order. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From david.lloyd at redhat.com Fri Mar 6 14:50:40 2020 From: david.lloyd at redhat.com (David Lloyd) Date: Fri, 6 Mar 2020 08:50:40 -0600 Subject: Java memory model question In-Reply-To: <0700b162-3616-bea8-5b4d-2ce37376acb6@redhat.com> References: <2C3115B4-1D3C-4D4A-ACB3-85F075A9319E@oracle.com> <0700b162-3616-bea8-5b4d-2ce37376acb6@redhat.com> Message-ID: On Fri, Mar 6, 2020 at 7:53 AM Andrew Haley wrote: > > On 3/6/20 10:27 AM, Luke Hutchison wrote: > > On Fri, Mar 6, 2020 at 12:46 AM Brian Goetz wrote: > > > >> No, but this is a common myth. Method boundaries are not part of the > >> JMM, and the JIT regularly makes optimizations that have the effect of > >> reordering operations across method boundaries. > > > > Thanks. That's pretty interesting, but I can't think of an optimization > > that would have that effect. Can you give an example? > > Inside an optimizer in intermediate form, unrelated operations are > often unordered: that is to say, they may be emitted in any order. This is a really nice (if a little old) primer by Alexey Shipilev which talks about program order which might be helpful: https://shipilev.net/blog/2014/jmm-pragmatics/ -- - DML From hboehm at google.com Fri Mar 6 16:17:49 2020 From: hboehm at google.com (Hans Boehm) Date: Fri, 6 Mar 2020 08:17:49 -0800 Subject: Java memory model question In-Reply-To: <0700b162-3616-bea8-5b4d-2ce37376acb6@redhat.com> References: <2C3115B4-1D3C-4D4A-ACB3-85F075A9319E@oracle.com> <0700b162-3616-bea8-5b4d-2ce37376acb6@redhat.com> Message-ID: On Fri, Mar 6, 2020 at 5:52 AM Andrew Haley wrote: > On 3/6/20 10:27 AM, Luke Hutchison wrote: > > On Fri, Mar 6, 2020 at 12:46 AM Brian Goetz > wrote: > > > >> No, but this is a common myth. Method boundaries are not part of the > >> JMM, and the JIT regularly makes optimizations that have the effect of > >> reordering operations across method boundaries. > > > > Thanks. That's pretty interesting, but I can't think of an optimization > > that would have that effect. Can you give an example? > > Inside an optimizer in intermediate form, unrelated operations are > often unordered: that is to say, they may be emitted in any order. > > We should also mention that a lot of hardware is very happy to reorder memory accesses across method boundaries. If the method was inlined, or in the event of a tail call, those may no longer even be visible at that point. Be careful with spurious insertions of "volatile", even where that's possible. It may have a large performance impact. On x86, it may not be that bad, since it primarily affects stores. On some architectures, it also affects loads a lot. (Java volatile is very different from C and C++ volatile, which has much less impact on performance, and officially has nothing to do with threads.) I haven't searched through the documentation, but currently this sounds to me like a streams documentation bug. Streams operations must clearly ensure the necessary ordering. From paul.sandoz at oracle.com Fri Mar 6 20:24:44 2020 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 6 Mar 2020 12:24:44 -0800 Subject: Java memory model question In-Reply-To: References: Message-ID: <0D886DF9-96DC-4597-A33E-F7F349D8C9A5@oracle.com> > On Mar 5, 2020, at 6:09 PM, David Holmes wrote: > >> Specifically I'm wondering: if a thread X launches a parallel stream that >> writes at most once to each independent element of an array, can it be >> assumed that when the stream processing ends, X will always read the value >> of all written array elements? In other words, can the termination of the >> stream be seen as a memory ordering barrier (in a weak sense)? > > I would have expected this to be explicitly stated somewhere in the streams documentation, but I don't see it. My expectation is that terminal operations would act as synchronization points. > Yeah, there is effectively an implicit ?actions taken by each operation happen-before actions following the completion of the terminal operation in another thread?. We are relying on the following with F/J usage: *

Memory consistency effects: Actions in a thread prior to the * submission of a {@code Runnable} or {@code Callable} task to an * {@code ExecutorService} * happen-before * any actions taken by that task, which in turn happen-before the * result is retrieved via {@code Future.get()}. This is only called out more explicitly with respect to elements for ordered actions by forEachOrdered and the escape-hatch iterator. We could ad something at the end of the Stream doc. Paul. From luke.hutch at gmail.com Fri Mar 6 20:55:09 2020 From: luke.hutch at gmail.com (Luke Hutchison) Date: Fri, 6 Mar 2020 13:55:09 -0700 Subject: Java memory model question In-Reply-To: <0D886DF9-96DC-4597-A33E-F7F349D8C9A5@oracle.com> References: <0D886DF9-96DC-4597-A33E-F7F349D8C9A5@oracle.com> Message-ID: On Fri, Mar 6, 2020 at 1:24 PM Paul Sandoz wrote: > We could ad something at the end of the Stream doc. > Thanks. It seems like an obvious conclusion to draw that all work in a stream will terminate before control is returned to the caller. However, a parallel stream involves submitting work to a thread pool, and it should always be spelled out whether launching work in other threads is asynchronous or synchronous/blocking. From alex.buckley at oracle.com Sat Mar 7 00:41:03 2020 From: alex.buckley at oracle.com (Alex Buckley) Date: Fri, 6 Mar 2020 16:41:03 -0800 Subject: Preview APIs in the Java Platform In-Reply-To: References: <952661d4-3f1d-2a05-a178-e11b37141cf7@oracle.com> <1826042880.559881.1583440279384.JavaMail.zimbra@u-pem.fr> <2de3392e-d4e9-1ff1-5049-ab4ac012635d@oracle.com> Message-ID: <26a26a4c-ce58-bc00-57f8-84ca121eabba@oracle.com> On 3/6/2020 5:23 AM, Volker Simonis wrote: > There's one major difference between the "Preview" and the "Incubator" > approach which doesn't seemed to have been covered in this thread. Of course you're right that preview APIs (and preview features more broadly) are part of Java SE, while incubating APIs are "just" a JDK-specific API in a JDK-specific module. The reason we compare them directly is because both represent a channel to the same thing: a complete, stable, high-quality API in Java SE. The point I took from Chris's mail is that if an API is good enough to be considered for incubation, then it's probably not very far away from being ready to preview. (Incubation was never about allowing half-baked APIs out into the world -- there was every expectation of good quality regardless of the non-SE status, though no guarantee of stability.) In theory, you could incubate an API for a few releases and then preview, but there's an explanation tax if you do that, so in reality, it's more efficient to hang back and offer Project-specific EA binaries (the true "lightweight" approach to introducing new APIs) until you're ready to preview. Alex From forax at univ-mlv.fr Sat Mar 7 10:21:18 2020 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Sat, 7 Mar 2020 11:21:18 +0100 (CET) Subject: Preview APIs in the Java Platform In-Reply-To: <72435f09-ed0a-9543-d419-b511806a2218@oracle.com> References: <952661d4-3f1d-2a05-a178-e11b37141cf7@oracle.com> <731186418.92411.1583396286089.JavaMail.zimbra@u-pem.fr> <72435f09-ed0a-9543-d419-b511806a2218@oracle.com> Message-ID: <908879404.1158730.1583576478133.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "Bill Shannon" > ?: "Remi Forax" > Cc: "Alex Buckley" , "jdk-dev" > Envoy?: Jeudi 5 Mars 2020 22:27:28 > Objet: Re: Preview APIs in the Java Platform > Remi Forax wrote on 3/5/20 12:18 AM: >> Hi Bill, >> I think you don't understand how preview APIs work, >> as a user, using a preview API requires --enable-preview at compile time so the >> generated bytecodes will be tagged with the minor version of the classfile >> being equals to 65 535 (in violation of semver BTW), >> so the only way to use a jar containing such classfiles is to use >> --enable-preview at runtime. >> >> So as a user it means once you use a preview API, you can not re-distribute your >> work, you can not by example upload such jar on Maven Central. > > Why not? Doesn't it just mean that anyone who wants to use my preview > jar has to use --enable-preview at runtime? and have all their dependencies compatible with a very specific version of the JVM. The issue is that in term of dependencies, it's like Python2/Python3, you have to wait for all dependencies that are using --enable-preview to use the same JDK. In fact, it's worst that Python2/Python3 because it's not a once in a lifetime change but an every 6 months change due to the Java release cadence. Practically, you are waiting for a blue moon so your application can compile/run. > >> Why JakartaEE will want such restriction on their own APIs ? > > For exactly the same reason the JDK wants such restriction. > Is that so hard to imagine? Given the drawbacks of the preview APIs, yes ! Unlike the JDK that has no external dependency, any applications JakartaEE will end up in the 10th circle of hell, the dependency hell. [...] R?mi From david.holmes at oracle.com Sat Mar 7 13:30:25 2020 From: david.holmes at oracle.com (David Holmes) Date: Sat, 7 Mar 2020 23:30:25 +1000 Subject: Java memory model question In-Reply-To: References: <2C3115B4-1D3C-4D4A-ACB3-85F075A9319E@oracle.com> Message-ID: <357aa2ec-be29-a076-e97d-9228dd09d732@oracle.com> On 6/03/2020 8:27 pm, Luke Hutchison wrote: > On Fri, Mar 6, 2020 at 12:46 AM Brian Goetz wrote: > >> No, but this is a common myth. Method boundaries are not part of the >> JMM, and the JIT regularly makes optimizations that have the effect of >> reordering operations across method boundaries. >> > > Thanks. That's pretty interesting, but I can't think of an optimization > that would have that effect. Can you give an example? > > On Thu, Mar 5, 2020 at 7:09 PM David Holmes wrote: > >> Probably a question better asked on concurrency-interest at cs.oswego.edu > > > Thanks, I didn't know about that list. > >> can the termination of the >>> stream be seen as a memory ordering barrier (in a weak sense)? >> >> I would have expected this to be explicitly stated somewhere in the >> streams documentation, but I don't see it. My expectation is that >> terminal operations would act as synchronization points. >> > > Right, although I wasn't asking about "high-level concurrency" (i.e. > coordination between threads), but rather "low-level concurrency" (memory > operation ordering). I hope you see now that is an artificial distinction. When it comes to the JMM the only thing that counts is happens-before, and the synchronization actions that allow you to reason about that. > The question arises from the Java limitation that > fields can be marked volatile, but if the field is of array type, then the > individual elements of the array cannot be marked volatile. There's no "volatile" is irrelevant in the context you described. The correctness neither depends on, nor is achieved by the actual writing of the array elements. As has been outlined by others the higher-level semantics ensure that the array stores happen-before the worker threads indicate they are done, which happens-before the main thread can proceed to access them. David ----- > "element-wise volatile" array unless you resort to using an > AtomicReferenceArray, which creates a wrapper object per array element, > which is wasteful on computation and space. > > I understand that the lack of "element-wise volatile" arrays means that > threads can end up reading stale values if two or more threads are reading > from and writing to the same array elements. However for this example, I > specifically exclude that issue by ensuring that there's only ever either > zero readers / one writer, or any number of readers / zero writers (every > array element is only written once by any thread, then after the end of the > stream, there are zero writers). > > I'm really just asking if there is some "macro-scale memory operation > reordering" that could somehow occur across the synchronization barrier at > the end of the stream. I don't know how deep the rabbit hole of memory > operation reordering goes. > > I have to assume this is not the case, because the worker threads should > all go quiescent at the end of the stream, so should have flushed their > values out to at least L1 cache, and the CPU should ensure cache coherency > between all cores beyond that point. But I want to make sure that can be > guaranteed. > > In practice I have never seen this pattern fail, and it's exceptionally > useful to be able to write to disjoint array elements from an > IntStream.range(0, N) parallel stream, particularly as a pattern to very > quickly parallelize orignially-serial code to have maximum efficiency, by > simply replacing for loops that have no dependencies between operations > with parallel streams -- but I have been nervous to use this pattern since > I realized that arrays cannot have volatile elements. Logically my brain > tells me the fear is unfounded, but I wanted to double check. > From luke.hutch at gmail.com Sat Mar 7 16:22:13 2020 From: luke.hutch at gmail.com (Luke Hutchison) Date: Sat, 7 Mar 2020 09:22:13 -0700 Subject: Java memory model question In-Reply-To: <357aa2ec-be29-a076-e97d-9228dd09d732@oracle.com> References: <2C3115B4-1D3C-4D4A-ACB3-85F075A9319E@oracle.com> <357aa2ec-be29-a076-e97d-9228dd09d732@oracle.com> Message-ID: Great explanations. Thanks everyone for the responses! On Sat, Mar 7, 2020, 6:32 AM David Holmes wrote: > On 6/03/2020 8:27 pm, Luke Hutchison wrote: > > On Fri, Mar 6, 2020 at 12:46 AM Brian Goetz > wrote: > > > >> No, but this is a common myth. Method boundaries are not part of the > >> JMM, and the JIT regularly makes optimizations that have the effect of > >> reordering operations across method boundaries. > >> > > > > Thanks. That's pretty interesting, but I can't think of an optimization > > that would have that effect. Can you give an example? > > > > On Thu, Mar 5, 2020 at 7:09 PM David Holmes > wrote: > > > >> Probably a question better asked on concurrency-interest at cs.oswego.edu > > > > > > Thanks, I didn't know about that list. > > > >> can the termination of the > >>> stream be seen as a memory ordering barrier (in a weak sense)? > >> > >> I would have expected this to be explicitly stated somewhere in the > >> streams documentation, but I don't see it. My expectation is that > >> terminal operations would act as synchronization points. > >> > > > > Right, although I wasn't asking about "high-level concurrency" (i.e. > > coordination between threads), but rather "low-level concurrency" (memory > > operation ordering). > > I hope you see now that is an artificial distinction. When it comes to > the JMM the only thing that counts is happens-before, and the > synchronization actions that allow you to reason about that. > > > The question arises from the Java limitation that > > fields can be marked volatile, but if the field is of array type, then > the > > individual elements of the array cannot be marked volatile. There's no > > "volatile" is irrelevant in the context you described. The correctness > neither depends on, nor is achieved by the actual writing of the array > elements. As has been outlined by others the higher-level semantics > ensure that the array stores happen-before the worker threads indicate > they are done, which happens-before the main thread can proceed to > access them. > > David > ----- > > > "element-wise volatile" array unless you resort to using an > > AtomicReferenceArray, which creates a wrapper object per array element, > > which is wasteful on computation and space. > > > > I understand that the lack of "element-wise volatile" arrays means that > > threads can end up reading stale values if two or more threads are > reading > > from and writing to the same array elements. However for this example, I > > specifically exclude that issue by ensuring that there's only ever either > > zero readers / one writer, or any number of readers / zero writers (every > > array element is only written once by any thread, then after the end of > the > > stream, there are zero writers). > > > > I'm really just asking if there is some "macro-scale memory operation > > reordering" that could somehow occur across the synchronization barrier > at > > the end of the stream. I don't know how deep the rabbit hole of memory > > operation reordering goes. > > > > I have to assume this is not the case, because the worker threads should > > all go quiescent at the end of the stream, so should have flushed their > > values out to at least L1 cache, and the CPU should ensure cache > coherency > > between all cores beyond that point. But I want to make sure that can be > > guaranteed. > > > > In practice I have never seen this pattern fail, and it's exceptionally > > useful to be able to write to disjoint array elements from an > > IntStream.range(0, N) parallel stream, particularly as a pattern to very > > quickly parallelize orignially-serial code to have maximum efficiency, by > > simply replacing for loops that have no dependencies between operations > > with parallel streams -- but I have been nervous to use this pattern > since > > I realized that arrays cannot have volatile elements. Logically my brain > > tells me the fear is unfounded, but I wanted to double check. > > > From bill.shannon at oracle.com Sat Mar 7 19:41:32 2020 From: bill.shannon at oracle.com (Bill Shannon) Date: Sat, 7 Mar 2020 11:41:32 -0800 Subject: Preview APIs in the Java Platform In-Reply-To: <908879404.1158730.1583576478133.JavaMail.zimbra@u-pem.fr> References: <952661d4-3f1d-2a05-a178-e11b37141cf7@oracle.com> <731186418.92411.1583396286089.JavaMail.zimbra@u-pem.fr> <72435f09-ed0a-9543-d419-b511806a2218@oracle.com> <908879404.1158730.1583576478133.JavaMail.zimbra@u-pem.fr> Message-ID: forax at univ-mlv.fr wrote on 3/7/20 2:21 AM: > ----- Mail original ----- >> De: "Bill Shannon" >> ?: "Remi Forax" >> Cc: "Alex Buckley" , "jdk-dev" >> Envoy?: Jeudi 5 Mars 2020 22:27:28 >> Objet: Re: Preview APIs in the Java Platform > >> Remi Forax wrote on 3/5/20 12:18 AM: >>> Hi Bill, >>> I think you don't understand how preview APIs work, >>> as a user, using a preview API requires --enable-preview at compile time so the >>> generated bytecodes will be tagged with the minor version of the classfile >>> being equals to 65 535 (in violation of semver BTW), >>> so the only way to use a jar containing such classfiles is to use >>> --enable-preview at runtime. >>> >>> So as a user it means once you use a preview API, you can not re-distribute your >>> work, you can not by example upload such jar on Maven Central. >> >> Why not? Doesn't it just mean that anyone who wants to use my preview >> jar has to use --enable-preview at runtime? > > and have all their dependencies compatible with a very specific version of the JVM. It would be more useful if I could specify *what* they need to be compatible with, but just requiring them to opt in to the feature is a good start. > The issue is that in term of dependencies, it's like Python2/Python3, you have to wait for all dependencies that are using --enable-preview to use the same JDK. > In fact, it's worst that Python2/Python3 because it's not a once in a lifetime change but an every 6 months change due to the Java release cadence. > Practically, you are waiting for a blue moon so your application can compile/run. If the current feature is not sufficient for this use case, what can we do to make it sufficient for this use case? >>> Why JakartaEE will want such restriction on their own APIs ? >> >> For exactly the same reason the JDK wants such restriction. >> Is that so hard to imagine? > > Given the drawbacks of the preview APIs, yes ! > Unlike the JDK that has no external dependency, any applications JakartaEE will end up in the 10th circle of hell, the dependency hell. So let's work together and find a better solution to both our problems! From mark at talios.com Mon Mar 9 02:51:25 2020 From: mark at talios.com (Mark Derricutt) Date: Mon, 09 Mar 2020 15:51:25 +1300 Subject: Preview APIs in the Java Platform In-Reply-To: <731186418.92411.1583396286089.JavaMail.zimbra@u-pem.fr> References: <952661d4-3f1d-2a05-a178-e11b37141cf7@oracle.com> <731186418.92411.1583396286089.JavaMail.zimbra@u-pem.fr> Message-ID: <27BAC982-3590-4B2D-9A2B-2FB644C31196@talios.com> On 5 Mar 2020, at 21:18, Remi Forax wrote: > So as a user it means once you use a preview API, you can not re-distribute your work, you can not by example upload such jar on Maven Central I'd say in part this isn't all that much different than the problems one faces already with Maven Central. If you release your library compiled for release 11/12/13/14 (or 8 back in the day when it was new) then users of those dependencies will get broken, and you have to rerelease or find some other solution. The Maven model/pom files have no means to express JVM version in their dependencies other than using a classifier. Or one could go, with tooling support the direction sbt in scala went with a version numbering scheme ontop of mavens that included the JDK. Using a classifier might be the simplest means - such as `com.example.foolib-1.2-previewjdk14`. Mark --- "The ease with which a change can be implemented has no relevance at all to whether it is the right change for the (Java) Platform for all time." — Mark Reinhold. Mark Derricutt http://www.chaliceofblood.net http://www.theoryinpractice.net http://twitter.com/talios http://facebook.com/mderricutt From cedric.champeau at gmail.com Mon Mar 9 07:24:48 2020 From: cedric.champeau at gmail.com (=?UTF-8?Q?C=C3=A9dric_Champeau?=) Date: Mon, 9 Mar 2020 08:24:48 +0100 Subject: Preview APIs in the Java Platform In-Reply-To: <27BAC982-3590-4B2D-9A2B-2FB644C31196@talios.com> References: <952661d4-3f1d-2a05-a178-e11b37141cf7@oracle.com> <731186418.92411.1583396286089.JavaMail.zimbra@u-pem.fr> <27BAC982-3590-4B2D-9A2B-2FB644C31196@talios.com> Message-ID: Le lun. 9 mars 2020 ? 03:51, Mark Derricutt a ?crit : > > > The Maven model/pom files have no means to express JVM version in their > dependencies other than using a classifier. Or one could go, with tooling > support the direction sbt in scala went with a version numbering scheme > ontop of mavens that included the JDK. > > Using a classifier might be the simplest means - such as > `com.example.foolib-1.2-previewjdk14`. > > They shouldn't do this. They should use Gradle module metadata which has been designed for this and understands what the JVM version means. Classifiers are ugly, they have no semantics associated, and that's why people get transparently upgraded from a JRE version of Guava to Android, just because the version number happens to be higher. Please stop recommending classifiers or version numbers for things they are not designed to do. Use real metadata and tools which can handle that. Neither Maven nor Sbt do. We have quite a few blog posts at https://blog.gradle.org which explain this, I'm sad when such poor solutions are recommended. That said, to come back to the topic, I agree that libraries published with experimental features should not be published on Maven Central. It's like the GPL: once you publish such a library, you're forcing all your consumers to do the same. It also forces them to configure their build tools and IDE differently, just because by accident they would transitively use a library which happened to activate an experimental feature. Again Gradle module metadata could help there, but we don't have an attribute to model the fact that a variant of a library uses experimental features. We could do this, not too hard, but I'm not convinced it's a good idea. Long story short, I think experimental features or APIs should be limited to your toy projects, but certainly not used by mainstream libraries. As a consumer, I don't want my project to suddenly break because an experimental API changed in a new JDK release, or that the JVM changed the implementation, or that the bytecode format changed between two releases of the experimental feature. I think the comparison with newer JDK releases (it's the same as if a library is compiled for a newer version of the JDK) is not correct, because we're talking about things which are deemed unstable, and promoted as such. If they were stable, they wouldn't be experimental. For Gradle we're thinking about modeling experimental as a first class citizen so that people can be warned when they do such a thing as publishing with experimental on. You must absolutely be aware of what you do. From andrew_m_leonard at uk.ibm.com Mon Mar 9 10:06:35 2020 From: andrew_m_leonard at uk.ibm.com (Andrew Leonard) Date: Mon, 9 Mar 2020 10:06:35 +0000 Subject: JDK14 spec query : MethodHandles:dropLookupMode(int) Message-ID: Thank you Mandy for raising the bug, I have one more query please, we may want to add to the bug that I am not sure about: testDropLookupMode() in test/jdk/java/lang/invoke/modules/m3/jdk/test/ModuleAccessTest.java : public void testDropLookupMode() throws Exception { Lookup lookup = MethodHandles.privateLookupIn(m5.type1, m4.lookup); assertTrue((lookup.lookupModes() & MODULE) == 0); <--- MODULE doesn't exist ... Lookup lookup3 = lookup.dropLookupMode(MODULE); ---> assertTrue(lookup3.lookupModes() == (lookup.lookupModes() & ~(PROTECTED|PRIVATE|PACKAGE))); Based on the expected result above, does it mean PRIVATE, PACKAGE should be dropped whether or not MODULE exists in the access mode (PROTECTED is dropped by default) ? If so, the document should be updated to explicitly clarify the exception case? Thanks, Andrew Andrew Leonard Java Runtimes Development IBM Hursley IBM United Kingdom Ltd internet email: andrew_m_leonard at uk.ibm.com Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From neugens at redhat.com Mon Mar 9 11:34:06 2020 From: neugens at redhat.com (Mario Torre) Date: Mon, 9 Mar 2020 12:34:06 +0100 Subject: RFC: 8240738: nested comment in JVM.java and other minor formatting errors Message-ID: Hi all, This is just a simple cosmetic fix for: https://bugs.openjdk.java.net/browse/JDK-8240738 The Webrev is here: http://cr.openjdk.java.net/~neugens/JDK-8240738/webrev.00/ The "worst" offender is the nested comment, but I took the opportunity to cleanup some of the rest of the code as well, removing whitespaces or fixing some minor formatting. Cheers, Mario -- Mario Torre Associate Manager, Software Engineering Red Hat GmbH 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From david.holmes at oracle.com Mon Mar 9 12:41:45 2020 From: david.holmes at oracle.com (David Holmes) Date: Mon, 9 Mar 2020 22:41:45 +1000 Subject: RFC: 8240738: nested comment in JVM.java and other minor formatting errors In-Reply-To: References: Message-ID: <03b6ffd4-7d3f-b52c-a0dc-aae9380d4531@oracle.com> Hi Mario, JFR code should be reviewed on hotspot-jfr-dev. Thanks, David On 9/03/2020 9:34 pm, Mario Torre wrote: > Hi all, > > This is just a simple cosmetic fix for: > > https://bugs.openjdk.java.net/browse/JDK-8240738 > > The Webrev is here: > > http://cr.openjdk.java.net/~neugens/JDK-8240738/webrev.00/ > > The "worst" offender is the nested comment, but I took the > opportunity to cleanup some of the rest of the code as well, removing > whitespaces or fixing some minor formatting. > > Cheers, > Mario > From neugens at redhat.com Mon Mar 9 12:50:39 2020 From: neugens at redhat.com (Mario Torre) Date: Mon, 9 Mar 2020 13:50:39 +0100 Subject: RFC: 8240738: nested comment in JVM.java and other minor formatting errors In-Reply-To: <03b6ffd4-7d3f-b52c-a0dc-aae9380d4531@oracle.com> References: <03b6ffd4-7d3f-b52c-a0dc-aae9380d4531@oracle.com> Message-ID: Hi David, Thanks, I'll send forward the email there. Cheers, Mario On Mon, Mar 9, 2020 at 1:42 PM David Holmes wrote: > > Hi Mario, > > JFR code should be reviewed on hotspot-jfr-dev. > > Thanks, > David > > On 9/03/2020 9:34 pm, Mario Torre wrote: > > Hi all, > > > > This is just a simple cosmetic fix for: > > > > https://bugs.openjdk.java.net/browse/JDK-8240738 > > > > The Webrev is here: > > > > http://cr.openjdk.java.net/~neugens/JDK-8240738/webrev.00/ > > > > The "worst" offender is the nested comment, but I took the > > opportunity to cleanup some of the rest of the code as well, removing > > whitespaces or fixing some minor formatting. > > > > Cheers, > > Mario > > > -- Mario Torre Associate Manager, Software Engineering Red Hat GmbH 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From chris.hegarty at oracle.com Mon Mar 9 14:51:44 2020 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 9 Mar 2020 14:51:44 +0000 Subject: JDK14 spec query : MethodHandles:dropLookupMode(int) In-Reply-To: References: Message-ID: <50FE58F1-0B6D-4003-A0C6-6AF21C759012@oracle.com> Andrew, > On 9 Mar 2020, at 10:06, Andrew Leonard wrote: > > Thank you Mandy for raising the bug, I have one more query please, we may want to add to the bug that I am not sure about: > testDropLookupMode() in test/jdk/java/lang/invoke/modules/m3/jdk/test/ModuleAccessTest.java : > public void testDropLookupMode() throws Exception { > Lookup lookup = MethodHandles.privateLookupIn(m5.type1, m4.lookup); > assertTrue((lookup.lookupModes() & MODULE) == 0); <--- MODULE doesn't exist > ... > Lookup lookup3 = lookup.dropLookupMode(MODULE); > ---> assertTrue(lookup3.lookupModes() == (lookup.lookupModes() & ~(PROTECTED|PRIVATE|PACKAGE))); > > > Based on the expected result above, does it mean PRIVATE, PACKAGE should be dropped whether > or not MODULE exists in the access mode (PROTECTED is dropped by default) ? > If so, the document should be updated to explicitly clarify the exception case? I agree that this scenario would benefit from being clarified ( possibly as part of the existing issue [1] ). -Chris. [1] https://bugs.openjdk.java.net/browse/JDK-8240242 From mandy.chung at oracle.com Mon Mar 9 16:37:10 2020 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 9 Mar 2020 09:37:10 -0700 Subject: JDK14 spec query : MethodHandles:dropLookupMode(int) In-Reply-To: References: Message-ID: <0168f9ad-6968-185e-50e5-ffe609a6be32@oracle.com> I have bcc'ed jdk-dev and add core-libs-dev mailing list where this thread should be discussed. The spec says: "When dropping|PACKAGE|then the resulting lookup will not have|PACKAGE|or|PRIVATE|access.When dropping|MODULE|then the resulting lookup will not have|MODULE|,|PACKAGE|, or|PRIVATE|access. If|PUBLIC|is dropped then the resulting lookup has no access." @throws IAE if modeToDrop is a valid mode. I found the spec is quite clear that there is no condition to require the modeToDrop must exist. Mandy [1] https://bugs.openjdk.java.net/browse/JDK-8226916 On 3/9/20 3:06 AM, Andrew Leonard wrote: > Thank you Mandy for raising the bug, I have one more query please, we > may want to add to the bug that I am not sure about: > *testDropLookupMode*() in > test/jdk/java/lang/invoke/modules/m3/jdk/test/ModuleAccessTest.java: > > ?public void testDropLookupMode() throws Exception { > ? ? ? ?Lookup lookup = MethodHandles.privateLookupIn(m5.type1, m4.lookup); > ? ? ? ?assertTrue((lookup.lookupModes() & MODULE) == 0); <--- MODULE > doesn't exist > ? ? ? ?... > ? ? ? ?Lookup lookup3 = lookup.dropLookupMode(MODULE); > ---> assertTrue(lookup3.lookupModes() == (lookup.lookupModes() & > ~(PROTECTED|PRIVATE|PACKAGE))); > > > Based on the expected result above, does it mean PRIVATE, PACKAGE > should be dropped whether > or not MODULE exists in the access mode (PROTECTED is dropped by > default) ? > If so, the document should be updated to explicitly clarify the > exception case? > > Thanks, > Andrew > > Andrew Leonard > Java Runtimes Development > IBM Hursley > IBM United Kingdom Ltd > internet email: andrew_m_leonard at uk.ibm.com > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with > number 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From alex.buckley at oracle.com Mon Mar 9 18:45:31 2020 From: alex.buckley at oracle.com (Alex Buckley) Date: Mon, 9 Mar 2020 11:45:31 -0700 Subject: Preview APIs in the Java Platform In-Reply-To: References: <952661d4-3f1d-2a05-a178-e11b37141cf7@oracle.com> <731186418.92411.1583396286089.JavaMail.zimbra@u-pem.fr> <27BAC982-3590-4B2D-9A2B-2FB644C31196@talios.com> Message-ID: <828820b1-a220-f478-4ecd-82d4fb076661@oracle.com> C?dric, On 3/9/2020 12:24 AM, C?dric Champeau wrote: > That said, to come back to the topic, I agree that libraries > published with experimental features should not be published on Maven > Central. ... Long story short, I think experimental features or APIs > should be limited to your toy projects, but certainly not used by > mainstream libraries. As a consumer, I don't want my project to > suddenly break because an experimental API changed in a new JDK > release, or that the JVM changed the implementation, or that the > bytecode format changed between two releases of the experimental > feature. I think the comparison with newer JDK releases (it's the > same as if a library is compiled for a newer version of the JDK) is > not correct, because we're talking about things which are deemed > unstable, and promoted as such. If they were stable, they wouldn't be > experimental. I agree with the thrust of your message -- an artifact that needs preview features to be enabled is for personal use only, and should not be distributed -- but is there anything I can do to stop you saying "experimental features" when you talk about preview features? It's going to confuse users because JEP 12 says they are different things: ----- The key properties of a preview language or VM [OR API] feature are: - Not experimental. A language or VM [OR API] feature that is considered experimental, risky, incomplete, or unstable must not be previewed in a JDK feature release. An experimental feature must be iterated and stabilized in its own project, which in turn produces binaries that are clearly distinguished from binaries of the JDK Project. For the purpose of comparison, if an experimental feature is considered 25% "done", then a preview feature should be at least 95% "done". To make a further comparison, the level of completeness and stability expected for a preview language or VM [OR API] feature is considerably higher than the level expected for an incubating API. ----- Alex From alex.buckley at oracle.com Mon Mar 9 19:43:28 2020 From: alex.buckley at oracle.com (Alex Buckley) Date: Mon, 9 Mar 2020 12:43:28 -0700 Subject: Preview APIs in the Java Platform In-Reply-To: References: <952661d4-3f1d-2a05-a178-e11b37141cf7@oracle.com> <731186418.92411.1583396286089.JavaMail.zimbra@u-pem.fr> <72435f09-ed0a-9543-d419-b511806a2218@oracle.com> <908879404.1158730.1583576478133.JavaMail.zimbra@u-pem.fr> Message-ID: On 3/7/2020 11:41 AM, Bill Shannon wrote: > If the current feature is not sufficient for this use case, what can we do to > make it sufficient for this use case? My colleagues and I plan to deliver the "preview API" feature that I described for Java SE as soon as possible. It is probably best to see how it works in practice -- both the release model and the JDK mechanism -- before diving too deeply into other use cases for the mechanism, especially when Jakarta EE hasn't signed up to the model in the first place. Alex From zrlw at sina.com Tue Mar 10 02:50:19 2020 From: zrlw at sina.com (zrlw at sina.com) Date: Tue, 10 Mar 2020 10:50:19 +0800 Subject: Suggestion: write out MethodParameters attribute in JvmtiClassFileReconstituter.cpp's write_method_info() Message-ID: <20200310025019.0897816600EE@webmail.sinamail.sina.com.cn> Hello, The class file bytes will be sent to a javaagent which registered ClassFileTransformer functions, but the retransformed classes bytes doesn't have MethodParameters attributes if the javaagent calling Instrumentation.retransformClasses, it will cause Mybatis can't get parameter names if not set parameter annotation @Param and throw BingExceptions if the sql statements using parameter names instead of arg0,arg1,...I suggest that write out method parameters attribute in JvmtiClassFileReconstituter.cpp's write_method_info(),https://github.com/jmockit/jmockit1/issues/659 Regards, Lao Wei. From Alan.Bateman at oracle.com Tue Mar 10 08:11:14 2020 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 10 Mar 2020 08:11:14 +0000 Subject: Suggestion: write out MethodParameters attribute in JvmtiClassFileReconstituter.cpp's write_method_info() In-Reply-To: <20200310025019.0897816600EE@webmail.sinamail.sina.com.cn> References: <20200310025019.0897816600EE@webmail.sinamail.sina.com.cn> Message-ID: On 10/03/2020 02:50, zrlw at sina.com wrote: > Hello, > The class file bytes will be sent to a javaagent which registered ClassFileTransformer functions, but the retransformed classes bytes doesn't have MethodParameters attributes if the javaagent calling Instrumentation.retransformClasses, it will cause Mybatis can't get parameter names if not set parameter annotation @Param and throw BingExceptions if the sql statements using parameter names instead of arg0,arg1,...I suggest that write out method parameters attribute in JvmtiClassFileReconstituter.cpp's write_method_info(),https://github.com/jmockit/jmockit1/issues/659 > Regards, > Lao Wei. Can you, or one of the JMockit maintainers, bring a test case to serviceability-dev for discussion? I can see how there may be issues there but having a reproducer would help with a bug report and discussion. -Alan. From aph at redhat.com Thu Mar 12 13:46:56 2020 From: aph at redhat.com (Andrew Haley) Date: Thu, 12 Mar 2020 13:46:56 +0000 Subject: CFV: New JDK Committer: Chihiro Ito Message-ID: I hereby nominate Chihiro Ito to JDK Committer. Chihiro Ito has contributed 12 significant fixes to OpenJDK. Votes are due by March 27, 2020. 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, Anton // http://openjdk.java.net/census#ant [1] http://openjdk.java.net/census [2] http://openjdk.java.net/projects/#committer-vote [3] List of changes: [2] List of changes: http://hg.openjdk.java.net/jdk/jdk/search/?rev=keyword%28chihiro.ito%29%20%7C%20author%28cito%29&revcount=20 8222489: jcmd VM.system_properties gives unusable paths on Windows http://hg.openjdk.java.net/jdk/jdk/rev/faa4916a3379 8219904: ClassCastException when calling FlightRecorderMXBean#getRecordings() http://hg.openjdk.java.net/jdk/jdk/rev/f965bceba123 8232594: Make the output of the JFR command duration more user friendly http://hg.openjdk.java.net/jdk/jdk/rev/43eee1237934 8223697: jfr tool can't format duration values greater than 1 minute http://hg.openjdk.java.net/jdk/jdk/rev/a6c56d661d75 8225694: Destination option missing in FlightRecorderMXBeanImpl http://hg.openjdk.java.net/jdk/jdk/rev/8ca46e186a63 8231317: jdk/jfr/jcmd/TestJcmdConfigure.java fails with "java.lang.RuntimeException: assertTrue: expected true, was false" http://hg.openjdk.java.net/jdk/jdk/rev/cfef85f63f47 8216565: Specifying the same path creates a new directory in JFR.configure http://hg.openjdk.java.net/jdk/jdk/rev/046533575954 8214236: sun.gc.collector.2.name should be changed http://hg.openjdk.java.net/jdk/jdk/rev/5ef581e59d91 8221569: JFR tool produces incorrect output when both --categories and --events are specified http://hg.openjdk.java.net/jdk/jdk/rev/1e83e1a600cb 8181647: jhsdb jstack could not output thread name http://hg.openjdk.java.net/jdk/jdk/rev/26b8de0359a0 8166191: Missing spaces in log message during heap expansion http://hg.openjdk.java.net/jdk/jdk/rev/9c1f0551e0a2 8180654: Apply UL to PrintCodeCacheOnCompilation http://hg.openjdk.java.net/jdk/jdk/rev/f10c8f2b4651 -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From thomas.stuefe at gmail.com Thu Mar 12 13:50:41 2020 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 12 Mar 2020 14:50:41 +0100 Subject: CFV: New JDK Committer: Chihiro Ito In-Reply-To: References: Message-ID: Vote: yes. On Thu, Mar 12, 2020 at 2:47 PM Andrew Haley wrote: > I hereby nominate Chihiro Ito to JDK Committer. > > Chihiro Ito has contributed 12 significant fixes to OpenJDK. > > Votes are due by March 27, 2020. > > 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, > Anton // http://openjdk.java.net/census#ant > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] List of changes: > > [2] List of changes: > > http://hg.openjdk.java.net/jdk/jdk/search/?rev=keyword%28chihiro.ito%29%20%7C%20author%28cito%29&revcount=20 > > 8222489: jcmd VM.system_properties gives unusable paths on Windows > http://hg.openjdk.java.net/jdk/jdk/rev/faa4916a3379 > > 8219904: ClassCastException when calling > FlightRecorderMXBean#getRecordings() > http://hg.openjdk.java.net/jdk/jdk/rev/f965bceba123 > > 8232594: Make the output of the JFR command duration more user friendly > http://hg.openjdk.java.net/jdk/jdk/rev/43eee1237934 > > 8223697: jfr tool can't format duration values greater than 1 minute > http://hg.openjdk.java.net/jdk/jdk/rev/a6c56d661d75 > > 8225694: Destination option missing in FlightRecorderMXBeanImpl > http://hg.openjdk.java.net/jdk/jdk/rev/8ca46e186a63 > > 8231317: jdk/jfr/jcmd/TestJcmdConfigure.java fails with > "java.lang.RuntimeException: assertTrue: expected true, was false" > http://hg.openjdk.java.net/jdk/jdk/rev/cfef85f63f47 > > 8216565: Specifying the same path creates a new directory in JFR.configure > http://hg.openjdk.java.net/jdk/jdk/rev/046533575954 > > 8214236: sun.gc.collector.2.name should be changed > http://hg.openjdk.java.net/jdk/jdk/rev/5ef581e59d91 > > 8221569: JFR tool produces incorrect output when both --categories and > --events are specified > http://hg.openjdk.java.net/jdk/jdk/rev/1e83e1a600cb > > 8181647: jhsdb jstack could not output thread name > http://hg.openjdk.java.net/jdk/jdk/rev/26b8de0359a0 > > 8166191: Missing spaces in log message during heap expansion > http://hg.openjdk.java.net/jdk/jdk/rev/9c1f0551e0a2 > > 8180654: Apply UL to PrintCodeCacheOnCompilation > http://hg.openjdk.java.net/jdk/jdk/rev/f10c8f2b4651 > > -- > Andrew Haley (he/him) > Java Platform Lead Engineer > Red Hat UK Ltd. > https://keybase.io/andrewhaley > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 > > From zgu at redhat.com Thu Mar 12 13:52:45 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Thu, 12 Mar 2020 09:52:45 -0400 Subject: CFV: New JDK Committer: Chihiro Ito In-Reply-To: References: Message-ID: <1c198b42-5dd0-fa4e-5ad1-8c8657099881@redhat.com> Vote: yes -Zhengyu On 3/12/20 9:46 AM, Andrew Haley wrote: > I hereby nominate Chihiro Ito to JDK Committer. > > Chihiro Ito has contributed 12 significant fixes to OpenJDK. > > Votes are due by March 27, 2020. > > 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, > Anton // http://openjdk.java.net/census#ant > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] List of changes: > > [2] List of changes: > http://hg.openjdk.java.net/jdk/jdk/search/?rev=keyword%28chihiro.ito%29%20%7C%20author%28cito%29&revcount=20 > > 8222489: jcmd VM.system_properties gives unusable paths on Windows > http://hg.openjdk.java.net/jdk/jdk/rev/faa4916a3379 > > 8219904: ClassCastException when calling > FlightRecorderMXBean#getRecordings() > http://hg.openjdk.java.net/jdk/jdk/rev/f965bceba123 > > 8232594: Make the output of the JFR command duration more user friendly > http://hg.openjdk.java.net/jdk/jdk/rev/43eee1237934 > > 8223697: jfr tool can't format duration values greater than 1 minute > http://hg.openjdk.java.net/jdk/jdk/rev/a6c56d661d75 > > 8225694: Destination option missing in FlightRecorderMXBeanImpl > http://hg.openjdk.java.net/jdk/jdk/rev/8ca46e186a63 > > 8231317: jdk/jfr/jcmd/TestJcmdConfigure.java fails with > "java.lang.RuntimeException: assertTrue: expected true, was false" > http://hg.openjdk.java.net/jdk/jdk/rev/cfef85f63f47 > > 8216565: Specifying the same path creates a new directory in JFR.configure > http://hg.openjdk.java.net/jdk/jdk/rev/046533575954 > > 8214236: sun.gc.collector.2.name should be changed > http://hg.openjdk.java.net/jdk/jdk/rev/5ef581e59d91 > > 8221569: JFR tool produces incorrect output when both --categories and > --events are specified > http://hg.openjdk.java.net/jdk/jdk/rev/1e83e1a600cb > > 8181647: jhsdb jstack could not output thread name > http://hg.openjdk.java.net/jdk/jdk/rev/26b8de0359a0 > > 8166191: Missing spaces in log message during heap expansion > http://hg.openjdk.java.net/jdk/jdk/rev/9c1f0551e0a2 > > 8180654: Apply UL to PrintCodeCacheOnCompilation > http://hg.openjdk.java.net/jdk/jdk/rev/f10c8f2b4651 > From neugens.limasoftware at gmail.com Thu Mar 12 13:59:45 2020 From: neugens.limasoftware at gmail.com (Mario Torre) Date: Thu, 12 Mar 2020 14:59:45 +0100 Subject: CFV: New JDK Committer: Chihiro Ito In-Reply-To: References: Message-ID: Vote: Yes, Cheers, Mario Il giorno gio 12 mar 2020 alle ore 14:48 Andrew Haley ha scritto: > > I hereby nominate Chihiro Ito to JDK Committer. > > Chihiro Ito has contributed 12 significant fixes to OpenJDK. > > Votes are due by March 27, 2020. > > 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, > Anton // http://openjdk.java.net/census#ant > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] List of changes: > > [2] List of changes: > http://hg.openjdk.java.net/jdk/jdk/search/?rev=keyword%28chihiro.ito%29%20%7C%20author%28cito%29&revcount=20 > > 8222489: jcmd VM.system_properties gives unusable paths on Windows > http://hg.openjdk.java.net/jdk/jdk/rev/faa4916a3379 > > 8219904: ClassCastException when calling > FlightRecorderMXBean#getRecordings() > http://hg.openjdk.java.net/jdk/jdk/rev/f965bceba123 > > 8232594: Make the output of the JFR command duration more user friendly > http://hg.openjdk.java.net/jdk/jdk/rev/43eee1237934 > > 8223697: jfr tool can't format duration values greater than 1 minute > http://hg.openjdk.java.net/jdk/jdk/rev/a6c56d661d75 > > 8225694: Destination option missing in FlightRecorderMXBeanImpl > http://hg.openjdk.java.net/jdk/jdk/rev/8ca46e186a63 > > 8231317: jdk/jfr/jcmd/TestJcmdConfigure.java fails with > "java.lang.RuntimeException: assertTrue: expected true, was false" > http://hg.openjdk.java.net/jdk/jdk/rev/cfef85f63f47 > > 8216565: Specifying the same path creates a new directory in JFR.configure > http://hg.openjdk.java.net/jdk/jdk/rev/046533575954 > > 8214236: sun.gc.collector.2.name should be changed > http://hg.openjdk.java.net/jdk/jdk/rev/5ef581e59d91 > > 8221569: JFR tool produces incorrect output when both --categories and > --events are specified > http://hg.openjdk.java.net/jdk/jdk/rev/1e83e1a600cb > > 8181647: jhsdb jstack could not output thread name > http://hg.openjdk.java.net/jdk/jdk/rev/26b8de0359a0 > > 8166191: Missing spaces in log message during heap expansion > http://hg.openjdk.java.net/jdk/jdk/rev/9c1f0551e0a2 > > 8180654: Apply UL to PrintCodeCacheOnCompilation > http://hg.openjdk.java.net/jdk/jdk/rev/f10c8f2b4651 > > -- > Andrew Haley (he/him) > Java Platform Lead Engineer > Red Hat UK Ltd. > https://keybase.io/andrewhaley > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 > -- 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 sgehwolf at redhat.com Thu Mar 12 14:16:26 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Thu, 12 Mar 2020 15:16:26 +0100 Subject: CFV: New JDK Committer: Chihiro Ito In-Reply-To: References: Message-ID: <397aa3c443da56d81a54e94db866566ced385d33.camel@redhat.com> Vote: yes. On Thu, 2020-03-12 at 13:46 +0000, Andrew Haley wrote: > I hereby nominate Chihiro Ito to JDK Committer. > > Chihiro Ito has contributed 12 significant fixes to OpenJDK. > > Votes are due by March 27, 2020. > > 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, > Anton // http://openjdk.java.net/census#ant > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] List of changes: > > [2] List of changes: > http://hg.openjdk.java.net/jdk/jdk/search/?rev=keyword%28chihiro.ito%29%20%7C%20author%28cito%29&revcount=20 > > 8222489: jcmd VM.system_properties gives unusable paths on Windows > http://hg.openjdk.java.net/jdk/jdk/rev/faa4916a3379 > > 8219904: ClassCastException when calling > FlightRecorderMXBean#getRecordings() > http://hg.openjdk.java.net/jdk/jdk/rev/f965bceba123 > > 8232594: Make the output of the JFR command duration more user friendly > http://hg.openjdk.java.net/jdk/jdk/rev/43eee1237934 > > 8223697: jfr tool can't format duration values greater than 1 minute > http://hg.openjdk.java.net/jdk/jdk/rev/a6c56d661d75 > > 8225694: Destination option missing in FlightRecorderMXBeanImpl > http://hg.openjdk.java.net/jdk/jdk/rev/8ca46e186a63 > > 8231317: jdk/jfr/jcmd/TestJcmdConfigure.java fails with > "java.lang.RuntimeException: assertTrue: expected true, was false" > http://hg.openjdk.java.net/jdk/jdk/rev/cfef85f63f47 > > 8216565: Specifying the same path creates a new directory in JFR.configure > http://hg.openjdk.java.net/jdk/jdk/rev/046533575954 > > 8214236: sun.gc.collector.2.name should be changed > http://hg.openjdk.java.net/jdk/jdk/rev/5ef581e59d91 > > 8221569: JFR tool produces incorrect output when both --categories and > --events are specified > http://hg.openjdk.java.net/jdk/jdk/rev/1e83e1a600cb > > 8181647: jhsdb jstack could not output thread name > http://hg.openjdk.java.net/jdk/jdk/rev/26b8de0359a0 > > 8166191: Missing spaces in log message during heap expansion > http://hg.openjdk.java.net/jdk/jdk/rev/9c1f0551e0a2 > > 8180654: Apply UL to PrintCodeCacheOnCompilation > http://hg.openjdk.java.net/jdk/jdk/rev/f10c8f2b4651 > From adinn at redhat.com Thu Mar 12 14:21:48 2020 From: adinn at redhat.com (Andrew Dinn) Date: Thu, 12 Mar 2020 14:21:48 +0000 Subject: CFV: New JDK Committer: Chihiro Ito In-Reply-To: References: Message-ID: <05f4ddde-6d87-7de4-c338-7cd5b4ca8efa@redhat.com> Vote: yes On 12/03/2020 13:46, Andrew Haley wrote: > I hereby nominate Chihiro Ito to JDK Committer. > > Chihiro Ito has contributed 12 significant fixes to OpenJDK. > > Votes are due by March 27, 2020. > > 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, > Anton // http://openjdk.java.net/census#ant > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] List of changes: > > [2] List of changes: > http://hg.openjdk.java.net/jdk/jdk/search/?rev=keyword%28chihiro.ito%29%20%7C%20author%28cito%29&revcount=20 > > 8222489: jcmd VM.system_properties gives unusable paths on Windows > http://hg.openjdk.java.net/jdk/jdk/rev/faa4916a3379 > > 8219904: ClassCastException when calling > FlightRecorderMXBean#getRecordings() > http://hg.openjdk.java.net/jdk/jdk/rev/f965bceba123 > > 8232594: Make the output of the JFR command duration more user friendly > http://hg.openjdk.java.net/jdk/jdk/rev/43eee1237934 > > 8223697: jfr tool can't format duration values greater than 1 minute > http://hg.openjdk.java.net/jdk/jdk/rev/a6c56d661d75 > > 8225694: Destination option missing in FlightRecorderMXBeanImpl > http://hg.openjdk.java.net/jdk/jdk/rev/8ca46e186a63 > > 8231317: jdk/jfr/jcmd/TestJcmdConfigure.java fails with > "java.lang.RuntimeException: assertTrue: expected true, was false" > http://hg.openjdk.java.net/jdk/jdk/rev/cfef85f63f47 > > 8216565: Specifying the same path creates a new directory in JFR.configure > http://hg.openjdk.java.net/jdk/jdk/rev/046533575954 > > 8214236: sun.gc.collector.2.name should be changed > http://hg.openjdk.java.net/jdk/jdk/rev/5ef581e59d91 > > 8221569: JFR tool produces incorrect output when both --categories and > --events are specified > http://hg.openjdk.java.net/jdk/jdk/rev/1e83e1a600cb > > 8181647: jhsdb jstack could not output thread name > http://hg.openjdk.java.net/jdk/jdk/rev/26b8de0359a0 > > 8166191: Missing spaces in log message during heap expansion > http://hg.openjdk.java.net/jdk/jdk/rev/9c1f0551e0a2 > > 8180654: Apply UL to PrintCodeCacheOnCompilation > http://hg.openjdk.java.net/jdk/jdk/rev/f10c8f2b4651 > -- 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 From suenaga at oss.nttdata.com Thu Mar 12 14:29:49 2020 From: suenaga at oss.nttdata.com (Yasumasa Suenaga) Date: Thu, 12 Mar 2020 23:29:49 +0900 Subject: CFV: New JDK Committer: Chihiro Ito In-Reply-To: References: Message-ID: Vote: yes Yasumasa On 2020/03/12 22:46, Andrew Haley wrote: > I hereby nominate Chihiro Ito to JDK Committer. > > Chihiro Ito has contributed 12 significant fixes to OpenJDK. > > Votes are due by March 27, 2020. > > 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, > Anton // http://openjdk.java.net/census#ant > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] List of changes: > > [2] List of changes: > http://hg.openjdk.java.net/jdk/jdk/search/?rev=keyword%28chihiro.ito%29%20%7C%20author%28cito%29&revcount=20 > > 8222489: jcmd VM.system_properties gives unusable paths on Windows > http://hg.openjdk.java.net/jdk/jdk/rev/faa4916a3379 > > 8219904: ClassCastException when calling > FlightRecorderMXBean#getRecordings() > http://hg.openjdk.java.net/jdk/jdk/rev/f965bceba123 > > 8232594: Make the output of the JFR command duration more user friendly > http://hg.openjdk.java.net/jdk/jdk/rev/43eee1237934 > > 8223697: jfr tool can't format duration values greater than 1 minute > http://hg.openjdk.java.net/jdk/jdk/rev/a6c56d661d75 > > 8225694: Destination option missing in FlightRecorderMXBeanImpl > http://hg.openjdk.java.net/jdk/jdk/rev/8ca46e186a63 > > 8231317: jdk/jfr/jcmd/TestJcmdConfigure.java fails with > "java.lang.RuntimeException: assertTrue: expected true, was false" > http://hg.openjdk.java.net/jdk/jdk/rev/cfef85f63f47 > > 8216565: Specifying the same path creates a new directory in JFR.configure > http://hg.openjdk.java.net/jdk/jdk/rev/046533575954 > > 8214236: sun.gc.collector.2.name should be changed > http://hg.openjdk.java.net/jdk/jdk/rev/5ef581e59d91 > > 8221569: JFR tool produces incorrect output when both --categories and > --events are specified > http://hg.openjdk.java.net/jdk/jdk/rev/1e83e1a600cb > > 8181647: jhsdb jstack could not output thread name > http://hg.openjdk.java.net/jdk/jdk/rev/26b8de0359a0 > > 8166191: Missing spaces in log message during heap expansion > http://hg.openjdk.java.net/jdk/jdk/rev/9c1f0551e0a2 > > 8180654: Apply UL to PrintCodeCacheOnCompilation > http://hg.openjdk.java.net/jdk/jdk/rev/f10c8f2b4651 > From eric.caspole at oracle.com Thu Mar 12 14:47:05 2020 From: eric.caspole at oracle.com (Eric Caspole) Date: Thu, 12 Mar 2020 10:47:05 -0400 Subject: CFV: New JDK Committer: Chihiro Ito In-Reply-To: References: Message-ID: <4704d82d-1b51-abce-f469-e42f7b7b1833@oracle.com> Vote: yes On 3/12/20 09:46, Andrew Haley wrote: > I hereby nominate Chihiro Ito to JDK Committer. > > Chihiro Ito has contributed 12 significant fixes to OpenJDK. > > Votes are due by March 27, 2020. > > 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, > Anton // http://openjdk.java.net/census#ant > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] List of changes: > > [2] List of changes: > http://hg.openjdk.java.net/jdk/jdk/search/?rev=keyword%28chihiro.ito%29%20%7C%20author%28cito%29&revcount=20 > > 8222489: jcmd VM.system_properties gives unusable paths on Windows > http://hg.openjdk.java.net/jdk/jdk/rev/faa4916a3379 > > 8219904: ClassCastException when calling > FlightRecorderMXBean#getRecordings() > http://hg.openjdk.java.net/jdk/jdk/rev/f965bceba123 > > 8232594: Make the output of the JFR command duration more user friendly > http://hg.openjdk.java.net/jdk/jdk/rev/43eee1237934 > > 8223697: jfr tool can't format duration values greater than 1 minute > http://hg.openjdk.java.net/jdk/jdk/rev/a6c56d661d75 > > 8225694: Destination option missing in FlightRecorderMXBeanImpl > http://hg.openjdk.java.net/jdk/jdk/rev/8ca46e186a63 > > 8231317: jdk/jfr/jcmd/TestJcmdConfigure.java fails with > "java.lang.RuntimeException: assertTrue: expected true, was false" > http://hg.openjdk.java.net/jdk/jdk/rev/cfef85f63f47 > > 8216565: Specifying the same path creates a new directory in JFR.configure > http://hg.openjdk.java.net/jdk/jdk/rev/046533575954 > > 8214236: sun.gc.collector.2.name should be changed > http://hg.openjdk.java.net/jdk/jdk/rev/5ef581e59d91 > > 8221569: JFR tool produces incorrect output when both --categories and > --events are specified > http://hg.openjdk.java.net/jdk/jdk/rev/1e83e1a600cb > > 8181647: jhsdb jstack could not output thread name > http://hg.openjdk.java.net/jdk/jdk/rev/26b8de0359a0 > > 8166191: Missing spaces in log message during heap expansion > http://hg.openjdk.java.net/jdk/jdk/rev/9c1f0551e0a2 > > 8180654: Apply UL to PrintCodeCacheOnCompilation > http://hg.openjdk.java.net/jdk/jdk/rev/f10c8f2b4651 > From felix.yang at huawei.com Fri Mar 13 06:03:15 2020 From: felix.yang at huawei.com (Yangfei (Felix)) Date: Fri, 13 Mar 2020 06:03:15 +0000 Subject: New JDK Committer: Chihiro Ito In-Reply-To: References: Message-ID: Vote: yes > -----Original Message----- > From: jdk-dev [mailto:jdk-dev-bounces at openjdk.java.net] On Behalf Of Andrew > Haley > Sent: Thursday, March 12, 2020 9:47 PM > To: jdk-dev at openjdk.java.net > Subject: CFV: New JDK Committer: Chihiro Ito > > I hereby nominate Chihiro Ito to JDK Committer. > > Chihiro Ito has contributed 12 significant fixes to OpenJDK. > > Votes are due by March 27, 2020. > > 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, > Anton // http://openjdk.java.net/census#ant > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] List of changes: > > [2] List of changes: > http://hg.openjdk.java.net/jdk/jdk/search/?rev=keyword%28chihiro.ito%29%20 > %7C%20author%28cito%29&revcount=20 > > 8222489: jcmd VM.system_properties gives unusable paths on Windows > http://hg.openjdk.java.net/jdk/jdk/rev/faa4916a3379 > > 8219904: ClassCastException when calling > FlightRecorderMXBean#getRecordings() > http://hg.openjdk.java.net/jdk/jdk/rev/f965bceba123 > > 8232594: Make the output of the JFR command duration more user friendly > http://hg.openjdk.java.net/jdk/jdk/rev/43eee1237934 > > 8223697: jfr tool can't format duration values greater than 1 minute > http://hg.openjdk.java.net/jdk/jdk/rev/a6c56d661d75 > > 8225694: Destination option missing in FlightRecorderMXBeanImpl > http://hg.openjdk.java.net/jdk/jdk/rev/8ca46e186a63 > > 8231317: jdk/jfr/jcmd/TestJcmdConfigure.java fails with > "java.lang.RuntimeException: assertTrue: expected true, was false" > http://hg.openjdk.java.net/jdk/jdk/rev/cfef85f63f47 > > 8216565: Specifying the same path creates a new directory in JFR.configure > http://hg.openjdk.java.net/jdk/jdk/rev/046533575954 > > 8214236: sun.gc.collector.2.name should be changed > http://hg.openjdk.java.net/jdk/jdk/rev/5ef581e59d91 > > 8221569: JFR tool produces incorrect output when both --categories and > --events are specified http://hg.openjdk.java.net/jdk/jdk/rev/1e83e1a600cb > > 8181647: jhsdb jstack could not output thread name > http://hg.openjdk.java.net/jdk/jdk/rev/26b8de0359a0 > > 8166191: Missing spaces in log message during heap expansion > http://hg.openjdk.java.net/jdk/jdk/rev/9c1f0551e0a2 > > 8180654: Apply UL to PrintCodeCacheOnCompilation > http://hg.openjdk.java.net/jdk/jdk/rev/f10c8f2b4651 > > -- > Andrew Haley (he/him) > Java Platform Lead Engineer > Red Hat UK Ltd. https://keybase.io/andrewhaley > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From jiefu at tencent.com Fri Mar 13 06:12:38 2020 From: jiefu at tencent.com (=?utf-8?B?amllZnUo5YKF5p2wKQ==?=) Date: Fri, 13 Mar 2020 06:12:38 +0000 Subject: New JDK Committer: Chihiro Ito(Internet mail) In-Reply-To: References: Message-ID: <8486A7DF-B9CB-497E-9925-C1CCF9AB5AE7@tencent.com> Vote: yes Best regards, Jie ?On 2020/3/12, 9:49 PM, "jdk-dev on behalf of Andrew Haley" wrote: I hereby nominate Chihiro Ito to JDK Committer. Chihiro Ito has contributed 12 significant fixes to OpenJDK. Votes are due by March 27, 2020. 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, Anton // http://openjdk.java.net/census#ant [1] http://openjdk.java.net/census [2] http://openjdk.java.net/projects/#committer-vote [3] List of changes: [2] List of changes: http://hg.openjdk.java.net/jdk/jdk/search/?rev=keyword%28chihiro.ito%29%20%7C%20author%28cito%29&revcount=20 8222489: jcmd VM.system_properties gives unusable paths on Windows http://hg.openjdk.java.net/jdk/jdk/rev/faa4916a3379 8219904: ClassCastException when calling FlightRecorderMXBean#getRecordings() http://hg.openjdk.java.net/jdk/jdk/rev/f965bceba123 8232594: Make the output of the JFR command duration more user friendly http://hg.openjdk.java.net/jdk/jdk/rev/43eee1237934 8223697: jfr tool can't format duration values greater than 1 minute http://hg.openjdk.java.net/jdk/jdk/rev/a6c56d661d75 8225694: Destination option missing in FlightRecorderMXBeanImpl http://hg.openjdk.java.net/jdk/jdk/rev/8ca46e186a63 8231317: jdk/jfr/jcmd/TestJcmdConfigure.java fails with "java.lang.RuntimeException: assertTrue: expected true, was false" http://hg.openjdk.java.net/jdk/jdk/rev/cfef85f63f47 8216565: Specifying the same path creates a new directory in JFR.configure http://hg.openjdk.java.net/jdk/jdk/rev/046533575954 8214236: sun.gc.collector.2.name should be changed http://hg.openjdk.java.net/jdk/jdk/rev/5ef581e59d91 8221569: JFR tool produces incorrect output when both --categories and --events are specified http://hg.openjdk.java.net/jdk/jdk/rev/1e83e1a600cb 8181647: jhsdb jstack could not output thread name http://hg.openjdk.java.net/jdk/jdk/rev/26b8de0359a0 8166191: Missing spaces in log message during heap expansion http://hg.openjdk.java.net/jdk/jdk/rev/9c1f0551e0a2 8180654: Apply UL to PrintCodeCacheOnCompilation http://hg.openjdk.java.net/jdk/jdk/rev/f10c8f2b4651 -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From ningsheng.jian at arm.com Fri Mar 13 10:38:15 2020 From: ningsheng.jian at arm.com (Ningsheng Jian) Date: Fri, 13 Mar 2020 18:38:15 +0800 Subject: CFV: New JDK Committer: Chihiro Ito In-Reply-To: References: Message-ID: <33aa3959-c164-4946-ba1a-78cb312d3662@arm.com> Vote: yes Regards, Ningsheng On 3/12/20 9:46 PM, Andrew Haley wrote: > I hereby nominate Chihiro Ito to JDK Committer. > > Chihiro Ito has contributed 12 significant fixes to OpenJDK. > > Votes are due by March 27, 2020. > > 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, > Anton // http://openjdk.java.net/census#ant > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] List of changes: > > [2] List of changes: > http://hg.openjdk.java.net/jdk/jdk/search/?rev=keyword%28chihiro.ito%29%20%7C%20author%28cito%29&revcount=20 > > 8222489: jcmd VM.system_properties gives unusable paths on Windows > http://hg.openjdk.java.net/jdk/jdk/rev/faa4916a3379 > > 8219904: ClassCastException when calling > FlightRecorderMXBean#getRecordings() > http://hg.openjdk.java.net/jdk/jdk/rev/f965bceba123 > > 8232594: Make the output of the JFR command duration more user friendly > http://hg.openjdk.java.net/jdk/jdk/rev/43eee1237934 > > 8223697: jfr tool can't format duration values greater than 1 minute > http://hg.openjdk.java.net/jdk/jdk/rev/a6c56d661d75 > > 8225694: Destination option missing in FlightRecorderMXBeanImpl > http://hg.openjdk.java.net/jdk/jdk/rev/8ca46e186a63 > > 8231317: jdk/jfr/jcmd/TestJcmdConfigure.java fails with > "java.lang.RuntimeException: assertTrue: expected true, was false" > http://hg.openjdk.java.net/jdk/jdk/rev/cfef85f63f47 > > 8216565: Specifying the same path creates a new directory in JFR.configure > http://hg.openjdk.java.net/jdk/jdk/rev/046533575954 > > 8214236: sun.gc.collector.2.name should be changed > http://hg.openjdk.java.net/jdk/jdk/rev/5ef581e59d91 > > 8221569: JFR tool produces incorrect output when both --categories and > --events are specified > http://hg.openjdk.java.net/jdk/jdk/rev/1e83e1a600cb > > 8181647: jhsdb jstack could not output thread name > http://hg.openjdk.java.net/jdk/jdk/rev/26b8de0359a0 > > 8166191: Missing spaces in log message during heap expansion > http://hg.openjdk.java.net/jdk/jdk/rev/9c1f0551e0a2 > > 8180654: Apply UL to PrintCodeCacheOnCompilation > http://hg.openjdk.java.net/jdk/jdk/rev/f10c8f2b4651 > From david.buck at oracle.com Fri Mar 13 10:59:23 2020 From: david.buck at oracle.com (David Buck) Date: Fri, 13 Mar 2020 19:59:23 +0900 Subject: CFV: New JDK Committer: Chihiro Ito In-Reply-To: References: Message-ID: <4c05b1f3-5dad-b862-3fc1-9a60587fd942@oracle.com> vote: yes Cheers, -Buck On 2020/03/12 22:46, Andrew Haley wrote: > I hereby nominate Chihiro Ito to JDK Committer. > > Chihiro Ito has contributed 12 significant fixes to OpenJDK. > > Votes are due by March 27, 2020. > > 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, > Anton // http://openjdk.java.net/census#ant > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] List of changes: > > [2] List of changes: > http://hg.openjdk.java.net/jdk/jdk/search/?rev=keyword%28chihiro.ito%29%20%7C%20author%28cito%29&revcount=20 > > 8222489: jcmd VM.system_properties gives unusable paths on Windows > http://hg.openjdk.java.net/jdk/jdk/rev/faa4916a3379 > > 8219904: ClassCastException when calling > FlightRecorderMXBean#getRecordings() > http://hg.openjdk.java.net/jdk/jdk/rev/f965bceba123 > > 8232594: Make the output of the JFR command duration more user friendly > http://hg.openjdk.java.net/jdk/jdk/rev/43eee1237934 > > 8223697: jfr tool can't format duration values greater than 1 minute > http://hg.openjdk.java.net/jdk/jdk/rev/a6c56d661d75 > > 8225694: Destination option missing in FlightRecorderMXBeanImpl > http://hg.openjdk.java.net/jdk/jdk/rev/8ca46e186a63 > > 8231317: jdk/jfr/jcmd/TestJcmdConfigure.java fails with > "java.lang.RuntimeException: assertTrue: expected true, was false" > http://hg.openjdk.java.net/jdk/jdk/rev/cfef85f63f47 > > 8216565: Specifying the same path creates a new directory in JFR.configure > http://hg.openjdk.java.net/jdk/jdk/rev/046533575954 > > 8214236: sun.gc.collector.2.name should be changed > http://hg.openjdk.java.net/jdk/jdk/rev/5ef581e59d91 > > 8221569: JFR tool produces incorrect output when both --categories and > --events are specified > http://hg.openjdk.java.net/jdk/jdk/rev/1e83e1a600cb > > 8181647: jhsdb jstack could not output thread name > http://hg.openjdk.java.net/jdk/jdk/rev/26b8de0359a0 > > 8166191: Missing spaces in log message during heap expansion > http://hg.openjdk.java.net/jdk/jdk/rev/9c1f0551e0a2 > > 8180654: Apply UL to PrintCodeCacheOnCompilation > http://hg.openjdk.java.net/jdk/jdk/rev/f10c8f2b4651 > -- External Email Recipient Confirmation Process - Oracle Internal Only From christoph.langer at sap.com Sun Mar 15 13:47:59 2020 From: christoph.langer at sap.com (Langer, Christoph) Date: Sun, 15 Mar 2020 13:47:59 +0000 Subject: CFV: New JDK Committer: Chihiro Ito In-Reply-To: References: Message-ID: Vote: yes /Christoph > -----Original Message----- > From: jdk-dev On Behalf Of Andrew > Haley > Sent: Donnerstag, 12. M?rz 2020 14:47 > To: jdk-dev at openjdk.java.net > Subject: CFV: New JDK Committer: Chihiro Ito > > I hereby nominate Chihiro Ito to JDK Committer. > > Chihiro Ito has contributed 12 significant fixes to OpenJDK. > > Votes are due by March 27, 2020. > > 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, > Anton // http://openjdk.java.net/census#ant > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] List of changes: > > [2] List of changes: > http://hg.openjdk.java.net/jdk/jdk/search/?rev=keyword%28chihiro.ito%29 > %20%7C%20author%28cito%29&revcount=20 > > 8222489: jcmd VM.system_properties gives unusable paths on Windows > http://hg.openjdk.java.net/jdk/jdk/rev/faa4916a3379 > > 8219904: ClassCastException when calling > FlightRecorderMXBean#getRecordings() > http://hg.openjdk.java.net/jdk/jdk/rev/f965bceba123 > > 8232594: Make the output of the JFR command duration more user friendly > http://hg.openjdk.java.net/jdk/jdk/rev/43eee1237934 > > 8223697: jfr tool can't format duration values greater than 1 minute > http://hg.openjdk.java.net/jdk/jdk/rev/a6c56d661d75 > > 8225694: Destination option missing in FlightRecorderMXBeanImpl > http://hg.openjdk.java.net/jdk/jdk/rev/8ca46e186a63 > > 8231317: jdk/jfr/jcmd/TestJcmdConfigure.java fails with > "java.lang.RuntimeException: assertTrue: expected true, was false" > http://hg.openjdk.java.net/jdk/jdk/rev/cfef85f63f47 > > 8216565: Specifying the same path creates a new directory in JFR.configure > http://hg.openjdk.java.net/jdk/jdk/rev/046533575954 > > 8214236: sun.gc.collector.2.name should be changed > http://hg.openjdk.java.net/jdk/jdk/rev/5ef581e59d91 > > 8221569: JFR tool produces incorrect output when both --categories and > --events are specified > http://hg.openjdk.java.net/jdk/jdk/rev/1e83e1a600cb > > 8181647: jhsdb jstack could not output thread name > http://hg.openjdk.java.net/jdk/jdk/rev/26b8de0359a0 > > 8166191: Missing spaces in log message during heap expansion > http://hg.openjdk.java.net/jdk/jdk/rev/9c1f0551e0a2 > > 8180654: Apply UL to PrintCodeCacheOnCompilation > http://hg.openjdk.java.net/jdk/jdk/rev/f10c8f2b4651 > > -- > Andrew Haley (he/him) > Java Platform Lead Engineer > Red Hat UK Ltd. > https://keybase.io/andrewhaley > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From volker.simonis at gmail.com Sun Mar 15 19:32:05 2020 From: volker.simonis at gmail.com (Volker Simonis) Date: Sun, 15 Mar 2020 20:32:05 +0100 Subject: CFV: New JDK Committer: Chihiro Ito In-Reply-To: References: Message-ID: Vote: yes Andrew Haley schrieb am Do., 12. M?rz 2020, 14:47: > I hereby nominate Chihiro Ito to JDK Committer. > > Chihiro Ito has contributed 12 significant fixes to OpenJDK. > > Votes are due by March 27, 2020. > > 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, > Anton // http://openjdk.java.net/census#ant > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] List of changes: > > [2] List of changes: > > http://hg.openjdk.java.net/jdk/jdk/search/?rev=keyword%28chihiro.ito%29%20%7C%20author%28cito%29&revcount=20 > > 8222489: jcmd VM.system_properties gives unusable paths on Windows > http://hg.openjdk.java.net/jdk/jdk/rev/faa4916a3379 > > 8219904: ClassCastException when calling > FlightRecorderMXBean#getRecordings() > http://hg.openjdk.java.net/jdk/jdk/rev/f965bceba123 > > 8232594: Make the output of the JFR command duration more user friendly > http://hg.openjdk.java.net/jdk/jdk/rev/43eee1237934 > > 8223697: jfr tool can't format duration values greater than 1 minute > http://hg.openjdk.java.net/jdk/jdk/rev/a6c56d661d75 > > 8225694: Destination option missing in FlightRecorderMXBeanImpl > http://hg.openjdk.java.net/jdk/jdk/rev/8ca46e186a63 > > 8231317: jdk/jfr/jcmd/TestJcmdConfigure.java fails with > "java.lang.RuntimeException: assertTrue: expected true, was false" > http://hg.openjdk.java.net/jdk/jdk/rev/cfef85f63f47 > > 8216565: Specifying the same path creates a new directory in JFR.configure > http://hg.openjdk.java.net/jdk/jdk/rev/046533575954 > > 8214236: sun.gc.collector.2.name should be changed > http://hg.openjdk.java.net/jdk/jdk/rev/5ef581e59d91 > > 8221569: JFR tool produces incorrect output when both --categories and > --events are specified > http://hg.openjdk.java.net/jdk/jdk/rev/1e83e1a600cb > > 8181647: jhsdb jstack could not output thread name > http://hg.openjdk.java.net/jdk/jdk/rev/26b8de0359a0 > > 8166191: Missing spaces in log message during heap expansion > http://hg.openjdk.java.net/jdk/jdk/rev/9c1f0551e0a2 > > 8180654: Apply UL to PrintCodeCacheOnCompilation > http://hg.openjdk.java.net/jdk/jdk/rev/f10c8f2b4651 > > -- > Andrew Haley (he/him) > Java Platform Lead Engineer > Red Hat UK Ltd. > https://keybase.io/andrewhaley > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 > > From Sergey.Bylokhov at oracle.com Mon Mar 16 03:21:27 2020 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Sun, 15 Mar 2020 20:21:27 -0700 Subject: CFV: New JDK Reviewer: Pankaj Bansal Message-ID: <8058c801-ffb6-25ae-76b0-b2687335b908@oracle.com> I hereby nominate Pankaj Bansal to JDK Reviewer. Pankaj is currently a JDK Committer and a member of the client team at Oracle. He has made 45 contributions to JDK: http://hg.openjdk.java.net/jdk/client/log?revcount=2000&rev=(author(%22pbansal%22)+or+desc(%22pankaj.b.bansal%40oracle.com%22))+and+not+merge() Votes are due by March 30, 2020. Only current JDK Reviewer [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]. Sergey Bylokhov [1] http://openjdk.java.net/census#jdk [2] http://openjdk.java.net/projects/#reviewer-vote From volker.simonis at gmail.com Mon Mar 16 06:11:13 2020 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 16 Mar 2020 07:11:13 +0100 Subject: CFV: New JDK Reviewer: Pankaj Bansal In-Reply-To: <8058c801-ffb6-25ae-76b0-b2687335b908@oracle.com> References: <8058c801-ffb6-25ae-76b0-b2687335b908@oracle.com> Message-ID: Vote: yes Sergey Bylokhov schrieb am Mo., 16. M?rz 2020, 04:21: > I hereby nominate Pankaj Bansal to JDK Reviewer. > > Pankaj is currently a JDK Committer and a member of the client team at > Oracle. > He has made 45 contributions to JDK: > > > http://hg.openjdk.java.net/jdk/client/log?revcount=2000&rev=(author(%22pbansal%22)+or+desc(%22pankaj.b.bansal%40oracle.com%22))+and+not+merge() > > Votes are due by March 30, 2020. > > Only current JDK Reviewer [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]. > > Sergey Bylokhov > > [1] http://openjdk.java.net/census#jdk > [2] http://openjdk.java.net/projects/#reviewer-vote > From adinn at redhat.com Mon Mar 16 09:46:10 2020 From: adinn at redhat.com (Andrew Dinn) Date: Mon, 16 Mar 2020 09:46:10 +0000 Subject: CFV: New JDK Reviewer: Pankaj Bansal In-Reply-To: <8058c801-ffb6-25ae-76b0-b2687335b908@oracle.com> References: <8058c801-ffb6-25ae-76b0-b2687335b908@oracle.com> Message-ID: Vote: yes On 16/03/2020 03:21, Sergey Bylokhov wrote: > I hereby nominate Pankaj Bansal to JDK Reviewer. > > Pankaj is currently a JDK Committer and a member of the client team at > Oracle. > He has made 45 contributions to JDK: > > http://hg.openjdk.java.net/jdk/client/log?revcount=2000&rev=(author(%22pbansal%22)+or+desc(%22pankaj.b.bansal%40oracle.com%22))+and+not+merge() > > > Votes are due by March 30, 2020. > > Only current JDK Reviewer [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]. > > Sergey Bylokhov > > [1] http://openjdk.java.net/census#jdk > [2] http://openjdk.java.net/projects/#reviewer-vote > -- 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 From dmitry.markov at oracle.com Mon Mar 16 10:07:52 2020 From: dmitry.markov at oracle.com (Dmitry Markov) Date: Mon, 16 Mar 2020 10:07:52 +0000 Subject: CFV: New JDK Reviewer: Pankaj Bansal In-Reply-To: <8058c801-ffb6-25ae-76b0-b2687335b908@oracle.com> References: <8058c801-ffb6-25ae-76b0-b2687335b908@oracle.com> Message-ID: Vote: Yes Thanks, Dmitry > On 16 Mar 2020, at 03:21, Sergey Bylokhov wrote: > > I hereby nominate Pankaj Bansal to JDK Reviewer. > > Pankaj is currently a JDK Committer and a member of the client team at Oracle. > He has made 45 contributions to JDK: > > http://hg.openjdk.java.net/jdk/client/log?revcount=2000&rev=(author(%22pbansal%22)+or+desc(%22pankaj.b.bansal%40oracle.com%22))+and+not+merge() > > Votes are due by March 30, 2020. > > Only current JDK Reviewer [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]. > > Sergey Bylokhov > > [1] http://openjdk.java.net/census#jdk > [2] http://openjdk.java.net/projects/#reviewer-vote From prasanta.sadhukhan at oracle.com Mon Mar 16 11:43:08 2020 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Mon, 16 Mar 2020 17:13:08 +0530 Subject: CFV: New JDK Reviewer: Pankaj Bansal In-Reply-To: <8058c801-ffb6-25ae-76b0-b2687335b908@oracle.com> References: <8058c801-ffb6-25ae-76b0-b2687335b908@oracle.com> Message-ID: <5557c9df-9df6-6665-3586-792044a23e44@oracle.com> Vote: yes On 16-Mar-20 8:51 AM, Sergey Bylokhov wrote: > I hereby nominate Pankaj Bansal to JDK Reviewer. > > Pankaj is currently a JDK Committer and a member of the client team at > Oracle. > He has made 45 contributions to JDK: > > http://hg.openjdk.java.net/jdk/client/log?revcount=2000&rev=(author(%22pbansal%22)+or+desc(%22pankaj.b.bansal%40oracle.com%22))+and+not+merge() > > > Votes are due by March 30, 2020. > > Only current JDK Reviewer [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]. > > Sergey Bylokhov > > [1] http://openjdk.java.net/census#jdk > [2] http://openjdk.java.net/projects/#reviewer-vote From Roger.Riggs at oracle.com Mon Mar 16 14:36:36 2020 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Mon, 16 Mar 2020 10:36:36 -0400 Subject: CFV: New jdk Reviewer: John Jiang In-Reply-To: References: Message-ID: Vote: Yes On 2/12/20 1:47 PM, Rajan Halade wrote: > I hereby nominate John Jiang to JDK Reviewer. From Roger.Riggs at oracle.com Mon Mar 16 15:19:45 2020 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Mon, 16 Mar 2020 11:19:45 -0400 Subject: CFV: New JDK Committer: Chihiro Ito In-Reply-To: References: Message-ID: Vote: Yes On 3/12/20 9:46 AM, Andrew Haley wrote: > I hereby nominate Chihiro Ito to JDK Committer. From daniel.fuchs at oracle.com Mon Mar 16 15:40:18 2020 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Mon, 16 Mar 2020 15:40:18 +0000 Subject: CFV: New JDK Committer: Chihiro Ito In-Reply-To: References: Message-ID: <9e1a098d-b63c-4261-ff37-123f015978cd@oracle.com> Vote: yes best regards, -- daniel On 12/03/2020 13:46, Andrew Haley wrote: > I hereby nominate Chihiro Ito to JDK Committer. > > Chihiro Ito has contributed 12 significant fixes to OpenJDK. > > Votes are due by March 27, 2020. From philip.race at oracle.com Mon Mar 16 16:26:32 2020 From: philip.race at oracle.com (Philip Race) Date: Mon, 16 Mar 2020 09:26:32 -0700 Subject: CFV: New JDK Reviewer: Pankaj Bansal In-Reply-To: <8058c801-ffb6-25ae-76b0-b2687335b908@oracle.com> References: <8058c801-ffb6-25ae-76b0-b2687335b908@oracle.com> Message-ID: <5E6FA8B8.8050605@oracle.com> Vote: yes -phil. From JAYATHIRTH.D.V at ORACLE.COM Mon Mar 16 16:53:41 2020 From: JAYATHIRTH.D.V at ORACLE.COM (Jayathirth D v) Date: Mon, 16 Mar 2020 22:23:41 +0530 Subject: CFV: New JDK Reviewer: Pankaj Bansal In-Reply-To: <8058c801-ffb6-25ae-76b0-b2687335b908@oracle.com> References: <8058c801-ffb6-25ae-76b0-b2687335b908@oracle.com> Message-ID: <10BE7828-2225-4DDE-BDAB-16E964009165@ORACLE.COM> Vote: Yes Thanks, Jay > On 16-Mar-2020, at 8:51 AM, Sergey Bylokhov wrote: > > I hereby nominate Pankaj Bansal to JDK Reviewer. > > Pankaj is currently a JDK Committer and a member of the client team at Oracle. > He has made 45 contributions to JDK: > > http://hg.openjdk.java.net/jdk/client/log?revcount=2000&rev=(author(%22pbansal%22)+or+desc(%22pankaj.b.bansal%40oracle.com%22))+and+not+merge() > > Votes are due by March 30, 2020. > > Only current JDK Reviewer [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]. > > Sergey Bylokhov > > [1] http://openjdk.java.net/census#jdk > [2] http://openjdk.java.net/projects/#reviewer-vote From alexey.ivanov at oracle.com Mon Mar 16 17:19:26 2020 From: alexey.ivanov at oracle.com (Alexey Ivanov) Date: Mon, 16 Mar 2020 17:19:26 +0000 Subject: CFV: New JDK Reviewer: Pankaj Bansal In-Reply-To: <8058c801-ffb6-25ae-76b0-b2687335b908@oracle.com> References: <8058c801-ffb6-25ae-76b0-b2687335b908@oracle.com> Message-ID: <4dc13b26-cdd3-6ca8-b8cd-65b6b6761906@oracle.com> Vote: yes On 16/03/2020 03:21, Sergey Bylokhov wrote: > I hereby nominate Pankaj Bansal to JDK Reviewer. > > Pankaj is currently a JDK Committer and a member of the client team at > Oracle. > He has made 45 contributions to JDK: -- Regards, Alexey From Roger.Riggs at oracle.com Mon Mar 16 19:41:45 2020 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Mon, 16 Mar 2020 15:41:45 -0400 Subject: CFV: New JDK Reviewer: Hamlin Li Message-ID: I hereby nominate Hamlin Li to JDK Reviewer. Hamlin is currently a JDK Committer and a member of the software quality team at Oracle. Hamlin has more than 130 contributions [3]. Hamlin has improved test quality, expanded code coverage, and tracked down intermittent failures in Core Library subsystems including Compact Strings, Stack Walking, Platform Logging, NIO, and RMI. Votes are due by March 31st, 2020. 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]. Roger Riggs [1] http://openjdk.java.net/census#jdk [2] http://openjdk.java.net/projects/#reviewer-vote [3] http://hg.openjdk.java.net/jdk/jdk/search/?rev=%28keyword%28%22huaming.li%40oracle.com%22%29%20or%20author%28mli%29%29&revcount=400 From daniel.fuchs at oracle.com Mon Mar 16 19:43:26 2020 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Mon, 16 Mar 2020 19:43:26 +0000 Subject: CFV: New JDK Reviewer: Hamlin Li In-Reply-To: References: Message-ID: <21d9a8a7-df3c-4169-a5b3-8917cdf5bb44@oracle.com> Vote: yes best regards, -- daniel On 16/03/2020 19:41, Roger Riggs wrote: > I hereby nominate Hamlin Li to JDK Reviewer. From brent.christian at oracle.com Mon Mar 16 19:50:45 2020 From: brent.christian at oracle.com (Brent Christian) Date: Mon, 16 Mar 2020 12:50:45 -0700 Subject: CFV: New JDK Reviewer: Hamlin Li In-Reply-To: References: Message-ID: Vote: Yes -Brent On 3/16/20 12:41 PM, Roger Riggs wrote: > I hereby nominate Hamlin Li to JDK Reviewer. > From chris.hegarty at oracle.com Mon Mar 16 20:26:30 2020 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 16 Mar 2020 20:26:30 +0000 Subject: CFV: New JDK Reviewer: Hamlin Li In-Reply-To: References: Message-ID: <0EE2FE20-0116-4634-96C1-904D2FE550D4@oracle.com> Vote: YES -Chris > On 16 Mar 2020, at 19:41, Roger Riggs wrote: > > ?I hereby nominate Hamlin Li to JDK Reviewer. > > Hamlin is currently a JDK Committer and a member of the software quality team at Oracle. > Hamlin has more than 130 contributions [3]. > > Hamlin has improved test quality, expanded code coverage, and tracked down > intermittent failures in Core Library subsystems including Compact Strings, Stack Walking, > Platform Logging, NIO, and RMI. > > Votes are due by March 31st, 2020. > > 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]. > > Roger Riggs > > [1] http://openjdk.java.net/census#jdk > [2] http://openjdk.java.net/projects/#reviewer-vote > [3] http://hg.openjdk.java.net/jdk/jdk/search/?rev=%28keyword%28%22huaming.li%40oracle.com%22%29%20or%20author%28mli%29%29&revcount=400 From xuelei.fan at oracle.com Mon Mar 16 20:43:12 2020 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Mon, 16 Mar 2020 13:43:12 -0700 Subject: CFV: New JDK Reviewer: Hamlin Li In-Reply-To: References: Message-ID: Vote: yes. On 3/16/2020 12:41 PM, Roger Riggs wrote: > I hereby nominate Hamlin Li to JDK Reviewer. > > Hamlin is currently a JDK Committer and a member of the software quality > team at Oracle. > Hamlin has more than 130 contributions [3]. > > Hamlin has improved test quality, expanded code coverage, and tracked down > intermittent failures in Core Library subsystems including Compact > Strings, Stack Walking, > Platform Logging, NIO, and RMI. > > Votes are due by March 31st, 2020. > > 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]. > > Roger Riggs > > [1] http://openjdk.java.net/census#jdk > [2] http://openjdk.java.net/projects/#reviewer-vote > [3] > http://hg.openjdk.java.net/jdk/jdk/search/?rev=%28keyword%28%22huaming.li%40oracle.com%22%29%20or%20author%28mli%29%29&revcount=400 > From sha.jiang at oracle.com Mon Mar 16 22:52:36 2020 From: sha.jiang at oracle.com (sha.jiang at oracle.com) Date: Tue, 17 Mar 2020 06:52:36 +0800 Subject: CFV: New JDK Reviewer: Hamlin Li In-Reply-To: References: Message-ID: <12f1780f-36dc-720a-78a7-dcc1c32319ab@oracle.com> Vote: Yes Best regards, John Jiang On 2020/3/17 03:41, Roger Riggs wrote: > I hereby nominate Hamlin Li to JDK Reviewer. > > Hamlin is currently a JDK Committer and a member of the software > quality team at Oracle. > Hamlin has more than 130 contributions [3]. > > Hamlin has improved test quality, expanded code coverage, and tracked > down > intermittent failures in Core Library subsystems including Compact > Strings, Stack Walking, > Platform Logging, NIO, and RMI. > > Votes are due by March 31st, 2020. > > 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]. > > Roger Riggs > > [1] http://openjdk.java.net/census#jdk > [2] http://openjdk.java.net/projects/#reviewer-vote > [3] > http://hg.openjdk.java.net/jdk/jdk/search/?rev=%28keyword%28%22huaming.li%40oracle.com%22%29%20or%20author%28mli%29%29&revcount=400 > From roger.riggs at oracle.com Mon Mar 16 22:58:08 2020 From: roger.riggs at oracle.com (Roger Riggs) Date: Mon, 16 Mar 2020 18:58:08 -0400 Subject: CFV: New JDK Reviewer: Hamlin Li In-Reply-To: References: Message-ID: <884212bc-5fc3-41ad-9206-181343dd2bcf@oracle.com> Vote: Yes On 3/16/20 3:41 PM, Roger Riggs wrote: > I hereby nominate Hamlin Li to JDK Reviewer. From huizhe.wang at oracle.com Mon Mar 16 23:21:04 2020 From: huizhe.wang at oracle.com (Joe Wang) Date: Mon, 16 Mar 2020 16:21:04 -0700 Subject: CFV: New JDK Reviewer: Hamlin Li In-Reply-To: References: Message-ID: <10fccc70-776e-a241-d8d5-ccd1f0d430df@oracle.com> Vote: Yes Joe? (joehw) On 3/16/20 12:41 PM, Roger Riggs wrote: > I hereby nominate Hamlin Li to JDK Reviewer. From weijun.wang at oracle.com Tue Mar 17 03:07:14 2020 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 17 Mar 2020 11:07:14 +0800 Subject: CFV: New JDK Reviewer: Hamlin Li In-Reply-To: References: Message-ID: <7D34A990-7AAA-46AF-AEFE-46D6765967E3@oracle.com> Vote: yes --weijun > On Mar 17, 2020, at 3:41 AM, Roger Riggs wrote: > > I hereby nominate Hamlin Li to JDK Reviewer. From kim.barrett at oracle.com Tue Mar 17 03:36:15 2020 From: kim.barrett at oracle.com (Kim Barrett) Date: Mon, 16 Mar 2020 23:36:15 -0400 Subject: Result: New JDK Reviewer: Sangheon Kim Message-ID: Voting for Sangheon Kim [1][2] is now closed. Yes: 25 Veto: 0 Abstain: 0 According to the Bylaws definition of Three-Vote Consensus, this is sufficient to approve the nomination. Kim Barrett [1] https://mail.openjdk.java.net/pipermail/jdk-dev/2020-February/003939.html [2] https://mail.openjdk.java.net/pipermail/jdk-dev/2020-March/003983.html From Alan.Bateman at oracle.com Tue Mar 17 07:42:25 2020 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 17 Mar 2020 07:42:25 +0000 Subject: CFV: New JDK Reviewer: Hamlin Li In-Reply-To: References: Message-ID: Vote: yes From christoph.langer at sap.com Tue Mar 17 08:27:43 2020 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 17 Mar 2020 08:27:43 +0000 Subject: CFV: New JDK Reviewer: Hamlin Li In-Reply-To: References: Message-ID: Vote: yes /Christoph > -----Original Message----- > From: jdk-dev On Behalf Of Roger > Riggs > Sent: Montag, 16. M?rz 2020 20:42 > To: jdk-dev at openjdk.java.net > Subject: CFV: New JDK Reviewer: Hamlin Li > > I hereby nominate Hamlin Li to JDK Reviewer. > > Hamlin is currently a JDK Committer and a member of the software quality > team at Oracle. > Hamlin has more than 130 contributions [3]. > > Hamlin has improved test quality, expanded code coverage, and tracked > down > intermittent failures in Core Library subsystems including Compact > Strings, Stack Walking, > Platform Logging, NIO, and RMI. > > Votes are due by March 31st, 2020. > > 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]. > > Roger Riggs > > [1] http://openjdk.java.net/census#jdk > [2] http://openjdk.java.net/projects/#reviewer-vote > [3] > http://hg.openjdk.java.net/jdk/jdk/search/?rev=%28keyword%28%22huami > ng.li%40oracle.com%22%29%20or%20author%28mli%29%29&revcount=400 From christoph.langer at sap.com Tue Mar 17 08:28:21 2020 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 17 Mar 2020 08:28:21 +0000 Subject: CFV: New JDK Reviewer: Pankaj Bansal In-Reply-To: <8058c801-ffb6-25ae-76b0-b2687335b908@oracle.com> References: <8058c801-ffb6-25ae-76b0-b2687335b908@oracle.com> Message-ID: Vote: yes /Christoph > -----Original Message----- > From: jdk-dev On Behalf Of Sergey > Bylokhov > Sent: Montag, 16. M?rz 2020 04:21 > To: jdk-dev at openjdk.java.net > Subject: CFV: New JDK Reviewer: Pankaj Bansal > > I hereby nominate Pankaj Bansal to JDK Reviewer. > > Pankaj is currently a JDK Committer and a member of the client team at > Oracle. > He has made 45 contributions to JDK: > > http://hg.openjdk.java.net/jdk/client/log?revcount=2000&rev=(author(%22 > pbansal%22)+or+desc(%22pankaj.b.bansal%40oracle.com%22))+and+not+m > erge() > > Votes are due by March 30, 2020. > > Only current JDK Reviewer [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]. > > Sergey Bylokhov > > [1] http://openjdk.java.net/census#jdk > [2] http://openjdk.java.net/projects/#reviewer-vote From christoph.langer at sap.com Tue Mar 17 08:36:32 2020 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 17 Mar 2020 08:36:32 +0000 Subject: Issue with hgupdater Message-ID: Hi (ops team), seems like currently hgupdater is not working. Looks like no bugs get resolved after pushes through all mercurial repository. Are you aware of that issue? Any outlook when this should be fixed? Thanks Christoph From david.holmes at oracle.com Tue Mar 17 08:43:51 2020 From: david.holmes at oracle.com (David Holmes) Date: Tue, 17 Mar 2020 18:43:51 +1000 Subject: Issue with hgupdater In-Reply-To: References: Message-ID: <167594fa-9d98-d05a-7b4e-24c4d3cb214f@oracle.com> Hi Christoph, It is a known issue. I don't know if there is an ETA for a fix yet. Cheers, David On 17/03/2020 6:36 pm, Langer, Christoph wrote: > Hi (ops team), > > seems like currently hgupdater is not working. Looks like no bugs get resolved after pushes through all mercurial repository. > > Are you aware of that issue? Any outlook when this should be fixed? > > Thanks > Christoph > > > > From adinn at redhat.com Tue Mar 17 08:48:24 2020 From: adinn at redhat.com (Andrew Dinn) Date: Tue, 17 Mar 2020 08:48:24 +0000 Subject: CFV: New JDK Reviewer: Hamlin Li In-Reply-To: References: Message-ID: <9039813a-dec6-5cdf-ed04-8cb54aa33ced@redhat.com> Vote: yes On 16/03/2020 19:41, Roger Riggs wrote: > I hereby nominate Hamlin Li to JDK Reviewer. > > Hamlin is currently a JDK Committer and a member of the software quality > team at Oracle. > Hamlin has more than 130 contributions [3]. > > Hamlin has improved test quality, expanded code coverage, and tracked down > intermittent failures in Core Library subsystems including Compact > Strings, Stack Walking, > Platform Logging, NIO, and RMI. > > Votes are due by March 31st, 2020. > > 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]. > > Roger Riggs > > [1] http://openjdk.java.net/census#jdk > [2] http://openjdk.java.net/projects/#reviewer-vote > [3] > http://hg.openjdk.java.net/jdk/jdk/search/?rev=%28keyword%28%22huaming.li%40oracle.com%22%29%20or%20author%28mli%29%29&revcount=400 > -- 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 From christoph.langer at sap.com Tue Mar 17 08:55:39 2020 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 17 Mar 2020 08:55:39 +0000 Subject: Issue with hgupdater In-Reply-To: <167594fa-9d98-d05a-7b4e-24c4d3cb214f@oracle.com> References: <167594fa-9d98-d05a-7b4e-24c4d3cb214f@oracle.com> Message-ID: Thanks for the confirmation, David. I hope it doesn't take too long ?? > -----Original Message----- > From: David Holmes > Sent: Dienstag, 17. M?rz 2020 09:44 > To: Langer, Christoph ; jdk- > dev at openjdk.java.net; ops at openjdk.java.net > Subject: Re: Issue with hgupdater > > Hi Christoph, > > It is a known issue. I don't know if there is an ETA for a fix yet. > > Cheers, > David > > On 17/03/2020 6:36 pm, Langer, Christoph wrote: > > Hi (ops team), > > > > seems like currently hgupdater is not working. Looks like no bugs get > resolved after pushes through all mercurial repository. > > > > Are you aware of that issue? Any outlook when this should be fixed? > > > > Thanks > > Christoph > > > > > > > > From thomas.stuefe at gmail.com Tue Mar 17 09:37:38 2020 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Tue, 17 Mar 2020 10:37:38 +0100 Subject: CFV: New JDK Reviewer: Hamlin Li In-Reply-To: References: Message-ID: Vote: yes On Mon, Mar 16, 2020 at 8:42 PM Roger Riggs wrote: > I hereby nominate Hamlin Li to JDK Reviewer. > > Hamlin is currently a JDK Committer and a member of the software quality > team at Oracle. > Hamlin has more than 130 contributions [3]. > > Hamlin has improved test quality, expanded code coverage, and tracked down > intermittent failures in Core Library subsystems including Compact > Strings, Stack Walking, > Platform Logging, NIO, and RMI. > > Votes are due by March 31st, 2020. > > 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]. > > Roger Riggs > > [1] http://openjdk.java.net/census#jdk > [2] http://openjdk.java.net/projects/#reviewer-vote > [3] > > http://hg.openjdk.java.net/jdk/jdk/search/?rev=%28keyword%28%22huaming.li%40oracle.com%22%29%20or%20author%28mli%29%29&revcount=400 > > From mandy.chung at oracle.com Tue Mar 17 16:08:26 2020 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 17 Mar 2020 09:08:26 -0700 Subject: CFV: New JDK Reviewer: Hamlin Li In-Reply-To: References: Message-ID: <805cb03b-382e-adc7-cdb5-fe6035e436d3@oracle.com> Vote: yes Mandy On 3/16/20 12:41 PM, Roger Riggs wrote: > I hereby nominate Hamlin Li to JDK Reviewer. > > Hamlin is currently a JDK Committer and a member of the software > quality team at Oracle. > Hamlin has more than 130 contributions [3]. > > Hamlin has improved test quality, expanded code coverage, and tracked > down > intermittent failures in Core Library subsystems including Compact > Strings, Stack Walking, > Platform Logging, NIO, and RMI. > > Votes are due by March 31st, 2020. > > 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]. > > Roger Riggs > > [1] http://openjdk.java.net/census#jdk > [2] http://openjdk.java.net/projects/#reviewer-vote > [3] > http://hg.openjdk.java.net/jdk/jdk/search/?rev=%28keyword%28%22huaming.li%40oracle.com%22%29%20or%20author%28mli%29%29&revcount=400 > From harold.seigel at oracle.com Tue Mar 17 16:10:30 2020 From: harold.seigel at oracle.com (Harold Seigel) Date: Tue, 17 Mar 2020 12:10:30 -0400 Subject: CFV: New JDK Reviewer: Hamlin Li In-Reply-To: References: Message-ID: <144fb6c6-8d04-0075-7fcd-cb330655255b@oracle.com> Vote: yes Harold On 3/16/2020 3:41 PM, Roger Riggs wrote: > I hereby nominate Hamlin Li to JDK Reviewer. > > Hamlin is currently a JDK Committer and a member of the software > quality team at Oracle. > Hamlin has more than 130 contributions [3]. > > Hamlin has improved test quality, expanded code coverage, and tracked > down > intermittent failures in Core Library subsystems including Compact > Strings, Stack Walking, > Platform Logging, NIO, and RMI. > > Votes are due by March 31st, 2020. > > 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]. > > Roger Riggs > > [1] http://openjdk.java.net/census#jdk > [2] http://openjdk.java.net/projects/#reviewer-vote > [3] > http://hg.openjdk.java.net/jdk/jdk/search/?rev=%28keyword%28%22huaming.li%40oracle.com%22%29%20or%20author%28mli%29%29&revcount=400 > From mark.reinhold at oracle.com Tue Mar 17 17:37:28 2020 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Tue, 17 Mar 2020 18:37:28 +0100 (CET) Subject: Java 14 / JDK 14: General Availability Message-ID: <20200317173728.431F631A381@eggemoggin.niobe.net> JDK 14, the reference implementation of Java 14, is now Generally Available. We?ve identified no P1 bugs since we promoted build 36 over five weeks ago so that?s the official GA release, ready for production use. GPL-licensed OpenJDK builds from Oracle are available here: https://jdk.java.net/14 Builds from other implementors will no doubt be available soon. This release includes sixteen features [1]: 305: Pattern Matching for instanceof (Preview) 343: Packaging Tool (Incubator) 345: NUMA-Aware Memory Allocation for G1 349: JFR Event Streaming 352: Non-Volatile Mapped Byte Buffers 358: Helpful NullPointerExceptions 359: Records (Preview) 361: Switch Expressions (Standard) 362: Deprecate the Solaris and SPARC Ports 363: Remove the Concurrent Mark Sweep (CMS) Garbage Collector 364: ZGC on macOS 365: ZGC on Windows 366: Deprecate the ParallelScavenge + SerialOld GC Combination 367: Remove the Pack200 Tools and API 368: Text Blocks (Second Preview) 370: Foreign-Memory Access API (Incubator) along with, as usual, hundreds of smaller enhancements and thousands of bug fixes. Thanks to everyone who contributed to JDK 14, whether by creating features or enhancements, fixing bugs, or downloading and testing the early-access builds. - Mark [1] https://openjdk.java.net/projects/jdk/14 From gnu.andrew at redhat.com Wed Mar 18 05:03:27 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 18 Mar 2020 05:03:27 +0000 Subject: Java 14 / JDK 14: General Availability In-Reply-To: <20200317173728.431F631A381@eggemoggin.niobe.net> References: <20200317173728.431F631A381@eggemoggin.niobe.net> Message-ID: <3ecf534b-f9b1-cd30-cf4b-ee1ee6f349a5@redhat.com> On 17/03/2020 17:37, mark.reinhold at oracle.com wrote: > JDK 14, the reference implementation of Java 14, is now Generally > Available. We?ve identified no P1 bugs since we promoted build 36 > over five weeks ago so that?s the official GA release, ready for > production use. > > GPL-licensed OpenJDK builds from Oracle are available here: > > https://jdk.java.net/14 > > Builds from other implementors will no doubt be available soon. > > This release includes sixteen features [1]: > > 305: Pattern Matching for instanceof (Preview) > 343: Packaging Tool (Incubator) > 345: NUMA-Aware Memory Allocation for G1 > 349: JFR Event Streaming > 352: Non-Volatile Mapped Byte Buffers > 358: Helpful NullPointerExceptions > 359: Records (Preview) > 361: Switch Expressions (Standard) > 362: Deprecate the Solaris and SPARC Ports > 363: Remove the Concurrent Mark Sweep (CMS) Garbage Collector > 364: ZGC on macOS > 365: ZGC on Windows > 366: Deprecate the ParallelScavenge + SerialOld GC Combination > 367: Remove the Pack200 Tools and API > 368: Text Blocks (Second Preview) > 370: Foreign-Memory Access API (Incubator) > > along with, as usual, hundreds of smaller enhancements and thousands > of bug fixes. > > Thanks to everyone who contributed to JDK 14, whether by creating > features or enhancements, fixing bugs, or downloading and testing > the early-access builds. > > - Mark > > > [1] https://openjdk.java.net/projects/jdk/14 > Is this going to be pushed to https://hg.openjdk.java.net/jdk-updates/jdk14u/? I don't see the expected *-ga tag as yet. Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From jesper.wilhelmsson at oracle.com Wed Mar 18 09:49:25 2020 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Wed, 18 Mar 2020 10:49:25 +0100 Subject: Java 14 / JDK 14: General Availability In-Reply-To: <3ecf534b-f9b1-cd30-cf4b-ee1ee6f349a5@redhat.com> References: <20200317173728.431F631A381@eggemoggin.niobe.net> <3ecf534b-f9b1-cd30-cf4b-ee1ee6f349a5@redhat.com> Message-ID: > On 18 Mar 2020, at 06:03, Andrew Hughes wrote: > > I don't see the expected *-ga tag as yet. Fixed. /Jesper > > Thanks, > -- > Andrew :) > > Senior Free Java Software Engineer > Red Hat, Inc. (http://www.redhat.com) > > PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) > Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 > From philip.race at oracle.com Wed Mar 18 19:13:55 2020 From: philip.race at oracle.com (Philip Race) Date: Wed, 18 Mar 2020 12:13:55 -0700 Subject: CFV: New JDK Committer: Alexey Semenyuk Message-ID: <5E7272F3.902@oracle.com> I hereby nominate Alexey Semenyuk (alexey.semenyuk at oracle.com) to JDK committer. Alexey is a member of the JDK software development team at Oracle and has contributed 12 fixes [1] in the JDK project, first in the areas of code coverage, build and installers, and recently he was one of the principal contributors to the jpackage tool implementation [2] Votes are due by 1pm PDT, April 1st, 2020. Only current JDK Committers [3] 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 [4]. -phil [1] http://hg.openjdk.java.net/jdk/jdk/search/?rev=%28keyword%28%22alexey.semenyuk%40oracle.com%22%29%20or%20author%28asemenyu%29%29&revcount=400 2 months ago asemenyuk 8236132: Add missing properties to msi installers 2 months ago asemenyuk 8232077: Investigate if default behavior should allow downgrade scenario 2 months ago asemenyuk 8233578: Document configurable parameters of msi packages 3 months ago asemenyuk 8236138: Add tests for jmod applications 3 months ago asemenyuk 8236134: files missing in putback to JDK-8233270 3 months ago asemenyuk 8233270: Add support to jtreg helpers to unpack packages 3 months ago asemenyuk 8235728: JDK-8212780 breaks builds with a custom X11 include path 3 months ago asemenyuk 8233270: Add support to jtreg helpers to unpack packages [*] 3 months ago asemenyuk 8230933: Default icon is not set for additional launchers [*] 2017-03-30 asemenyuk 8177770: Need more precise control on build system logging 3 months ago herrick 8212780: Packaging Tool Implementation 2016-10-17 asemenyuk 8168093: Need a way for the launcher to query the JRE location using Windows registry. [*] Not showing up in search, changeset is here :- https://hg.openjdk.java.net/jdk/jdk/rev/1b1a7893c78a [2] jpackage: http://hg.openjdk.java.net/jdk/jdk/rev/9f9e7c969f78 (also listed above) [3] http://openjdk.java.net/census [4] http://openjdk.java.net/projects/#committer-vote From philip.race at oracle.com Wed Mar 18 19:14:56 2020 From: philip.race at oracle.com (Philip Race) Date: Wed, 18 Mar 2020 12:14:56 -0700 Subject: CFV: New JDK Committer: Alexey Semenyuk In-Reply-To: <5E7272F3.902@oracle.com> References: <5E7272F3.902@oracle.com> Message-ID: <5E727330.5040708@oracle.com> Vote: yes -phil. From andy.herrick at oracle.com Wed Mar 18 19:14:22 2020 From: andy.herrick at oracle.com (Andy Herrick) Date: Wed, 18 Mar 2020 15:14:22 -0400 Subject: CFV: New JDK Committer: Alexey Semenyuk In-Reply-To: <5E7272F3.902@oracle.com> References: <5E7272F3.902@oracle.com> Message-ID: vote: yes /Andy On 3/18/2020 3:13 PM, Philip Race wrote: > > I hereby nominate Alexey Semenyuk (alexey.semenyuk at oracle.com) to JDK > committer. > > Alexey is a member of the JDK software development team at Oracle and has > contributed 12 fixes [1] in the JDK project, first in the areas of > code coverage, build and installers, > and recently he was one of the principal contributors to the jpackage > tool implementation [2] > > Votes are due by 1pm PDT, April 1st, 2020. > Only current JDK Committers [3] 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 [4]. > > -phil > > [1] > http://hg.openjdk.java.net/jdk/jdk/search/?rev=%28keyword%28%22alexey.semenyuk%40oracle.com%22%29%20or%20author%28asemenyu%29%29&revcount=400 > > > 2 months ago???? asemenyuk???? 8236132: Add missing properties to msi > installers > 2 months ago???? asemenyuk???? 8232077: Investigate if default > behavior should allow downgrade scenario > 2 months ago???? asemenyuk???? 8233578: Document configurable > parameters of msi packages > 3 months ago???? asemenyuk???? 8236138: Add tests for jmod applications > 3 months ago???? asemenyuk???? 8236134: files missing in putback to > JDK-8233270 > 3 months ago???? asemenyuk???? 8233270: Add support to jtreg helpers > to unpack packages > 3 months ago???? asemenyuk???? 8235728: JDK-8212780 breaks builds with > a custom X11 include path > 3 months ago???? asemenyuk???? 8233270: Add support to jtreg helpers > to unpack packages? [*] > 3 months ago???? asemenyuk???? 8230933: Default icon is not set for > additional launchers [*] > 2017-03-30?????? asemenyuk???? 8177770: Need more precise control on > build system logging > 3 months ago?????? herrick???? 8212780: Packaging Tool Implementation > 2016-10-17?????? asemenyuk???? 8168093: Need a way for the launcher to > query the JRE location using Windows registry. > > [*] Not showing up in search, changeset is here :- > https://hg.openjdk.java.net/jdk/jdk/rev/1b1a7893c78a > > [2] jpackage:? http://hg.openjdk.java.net/jdk/jdk/rev/9f9e7c969f78 > (also listed above) > > [3] http://openjdk.java.net/census > > [4] http://openjdk.java.net/projects/#committer-vote From harold.seigel at oracle.com Wed Mar 18 19:31:31 2020 From: harold.seigel at oracle.com (Harold Seigel) Date: Wed, 18 Mar 2020 15:31:31 -0400 Subject: CFV: New JDK Committer: Alexey Semenyuk In-Reply-To: <5E7272F3.902@oracle.com> References: <5E7272F3.902@oracle.com> Message-ID: <92f2605c-cdf8-5301-6a19-f4f4b3118aac@oracle.com> Vote: yes Harold On 3/18/2020 3:13 PM, Philip Race wrote: > > I hereby nominate Alexey Semenyuk (alexey.semenyuk at oracle.com) to JDK > committer. > > Alexey is a member of the JDK software development team at Oracle and has > contributed 12 fixes [1] in the JDK project, first in the areas of > code coverage, build and installers, > and recently he was one of the principal contributors to the jpackage > tool implementation [2] > > Votes are due by 1pm PDT, April 1st, 2020. > Only current JDK Committers [3] 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 [4]. > > -phil > > [1] > http://hg.openjdk.java.net/jdk/jdk/search/?rev=%28keyword%28%22alexey.semenyuk%40oracle.com%22%29%20or%20author%28asemenyu%29%29&revcount=400 > > > 2 months ago???? asemenyuk???? 8236132: Add missing properties to msi > installers > 2 months ago???? asemenyuk???? 8232077: Investigate if default > behavior should allow downgrade scenario > 2 months ago???? asemenyuk???? 8233578: Document configurable > parameters of msi packages > 3 months ago???? asemenyuk???? 8236138: Add tests for jmod applications > 3 months ago???? asemenyuk???? 8236134: files missing in putback to > JDK-8233270 > 3 months ago???? asemenyuk???? 8233270: Add support to jtreg helpers > to unpack packages > 3 months ago???? asemenyuk???? 8235728: JDK-8212780 breaks builds with > a custom X11 include path > 3 months ago???? asemenyuk???? 8233270: Add support to jtreg helpers > to unpack packages? [*] > 3 months ago???? asemenyuk???? 8230933: Default icon is not set for > additional launchers [*] > 2017-03-30?????? asemenyuk???? 8177770: Need more precise control on > build system logging > 3 months ago?????? herrick???? 8212780: Packaging Tool Implementation > 2016-10-17?????? asemenyuk???? 8168093: Need a way for the launcher to > query the JRE location using Windows registry. > > [*] Not showing up in search, changeset is here :- > https://hg.openjdk.java.net/jdk/jdk/rev/1b1a7893c78a > > [2] jpackage:? http://hg.openjdk.java.net/jdk/jdk/rev/9f9e7c969f78 > (also listed above) > > [3] http://openjdk.java.net/census > > [4] http://openjdk.java.net/projects/#committer-vote From christoph.langer at sap.com Thu Mar 19 07:11:36 2020 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 19 Mar 2020 07:11:36 +0000 Subject: CFV: New JDK Committer: Alexey Semenyuk In-Reply-To: <5E7272F3.902@oracle.com> References: <5E7272F3.902@oracle.com> Message-ID: Vote:yes /Christoph > -----Original Message----- > From: jdk-dev On Behalf Of Philip > Race > Sent: Mittwoch, 18. M?rz 2020 20:14 > To: jdk-dev at openjdk.java.net > Subject: CFV: New JDK Committer: Alexey Semenyuk > > > I hereby nominate Alexey Semenyuk (alexey.semenyuk at oracle.com) to JDK > committer. > > Alexey is a member of the JDK software development team at Oracle and > has > contributed 12 fixes [1] in the JDK project, first in the areas of code > coverage, build and installers, > and recently he was one of the principal contributors to the jpackage > tool implementation [2] > > Votes are due by 1pm PDT, April 1st, 2020. > Only current JDK Committers [3] 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 [4]. > > -phil > > [1] > http://hg.openjdk.java.net/jdk/jdk/search/?rev=%28keyword%28%22alexe > y.semenyuk%40oracle.com%22%29%20or%20author%28asemenyu%29%29& > revcount=400 > > 2 months ago asemenyuk 8236132: Add missing properties to msi > installers > 2 months ago asemenyuk 8232077: Investigate if default behavior > should allow downgrade scenario > 2 months ago asemenyuk 8233578: Document configurable parameters > of msi packages > 3 months ago asemenyuk 8236138: Add tests for jmod applications > 3 months ago asemenyuk 8236134: files missing in putback to > JDK-8233270 > 3 months ago asemenyuk 8233270: Add support to jtreg helpers to > unpack packages > 3 months ago asemenyuk 8235728: JDK-8212780 breaks builds with a > custom X11 include path > 3 months ago asemenyuk 8233270: Add support to jtreg helpers to > unpack packages [*] > 3 months ago asemenyuk 8230933: Default icon is not set for > additional launchers [*] > 2017-03-30 asemenyuk 8177770: Need more precise control on > build system logging > 3 months ago herrick 8212780: Packaging Tool Implementation > 2016-10-17 asemenyuk 8168093: Need a way for the launcher to > query the JRE location using Windows registry. > > [*] Not showing up in search, changeset is here :- > https://hg.openjdk.java.net/jdk/jdk/rev/1b1a7893c78a > > [2] jpackage: http://hg.openjdk.java.net/jdk/jdk/rev/9f9e7c969f78 (also > listed above) > > [3] http://openjdk.java.net/census > > [4] http://openjdk.java.net/projects/#committer-vote From christoph.langer at sap.com Thu Mar 19 09:12:39 2020 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 19 Mar 2020 09:12:39 +0000 Subject: Anybody working on a solution to the mailing list problems (a.k.a JDK-8213225)? Message-ID: Hi all, some of you might be aware that there exist issues with mails delivered through the OpenJDK mailing lists. Presumably from mail addresses of organizations outside Oracle to other mail addresses outside Oracle. An issue was raised back in 2018 already by Martin Buchholz [0] but it seems there is no outcome yet and it's hard for me to see in which direction the investigation is going. But it must be kind of important, as it has 26!! watchers to date. The issue reports that mails would end up in the spam folder although they shouldn't. As long as only that would happen, I could kind of live with it. However, lately I recognized that me (and my colleagues using the SAP mail system) wouldn't receive mails from other parties like google.com [1], datadoghq.com [2] or alibaba-inc.com [3]. There might be others which I'm not aware of. This is an unacceptable situation, since I wouldn't become aware of some discussions at all or don't get the possibility to reply directly to some mails! Maybe this complete rejection of mails (rather than accepting these as spam) is due to some recent change in the SAP mail system infrastructure. But to be able to debug it, me and the colleagues from SAP's IT department need some help from folks who run the OpenJDK mailing lists at Oracle. I've already asked for help at ops at o.j.n but didn't get any replies. So I'm posting my request again, publicly, on jdk-dev. Please help with both, the (seemingly SAP specific?) issue of not receiving some mails at all and also the problem of wrongly classifying mails as SPAM. Desperately looking forward to any help! Thanks Christoph [0] https://bugs.openjdk.java.net/browse/JDK-8213225 [1] https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-March/065046.html [2] https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2020-March/002642.html [3] https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2020-March/002735.html From neugens at redhat.com Thu Mar 19 09:22:23 2020 From: neugens at redhat.com (Mario Torre) Date: Thu, 19 Mar 2020 10:22:23 +0100 Subject: Anybody working on a solution to the mailing list problems (a.k.a JDK-8213225)? In-Reply-To: References: Message-ID: I?m having similar issues with my @gmail account FWIW. Most messages land in spam, even when I instructed gmail they are legit. I don?t know if I also miss any though because of course I would have not received them ;) Cheers, Mario On Thursday, March 19, 2020, Langer, Christoph wrote: > Hi all, > > some of you might be aware that there exist issues with mails delivered > through the OpenJDK mailing lists. Presumably from mail addresses of > organizations outside Oracle to other mail addresses outside Oracle. > > An issue was raised back in 2018 already by Martin Buchholz [0] but it > seems there is no outcome yet and it's hard for me to see in which > direction the investigation is going. But it must be kind of important, as > it has 26!! watchers to date. > > The issue reports that mails would end up in the spam folder although they > shouldn't. As long as only that would happen, I could kind of live with it. > However, lately I recognized that me (and my colleagues using the SAP mail > system) wouldn't receive mails from other parties like google.com [1], > datadoghq.com [2] or alibaba-inc.com [3]. There might be others which I'm > not aware of. > This is an unacceptable situation, since I wouldn't become aware of some > discussions at all or don't get the possibility to reply directly to some > mails! > > Maybe this complete rejection of mails (rather than accepting these as > spam) is due to some recent change in the SAP mail system infrastructure. > But to be able to debug it, me and the colleagues from SAP's IT department > need some help from folks who run the OpenJDK mailing lists at Oracle. I've > already asked for help at ops at o.j.n but didn't get any > replies. So I'm posting my request again, publicly, on jdk-dev. > > Please help with both, the (seemingly SAP specific?) issue of not > receiving some mails at all and also the problem of wrongly classifying > mails as SPAM. > > Desperately looking forward to any help! > > Thanks > Christoph > > [0] https://bugs.openjdk.java.net/browse/JDK-8213225 > [1] https://mail.openjdk.java.net/pipermail/core-libs-dev/2020- > March/065046.html > [2] https://mail.openjdk.java.net/pipermail/jdk-updates-dev/ > 2020-March/002642.html > [3] https://mail.openjdk.java.net/pipermail/jdk-updates-dev/ > 2020-March/002735.html > > -- Mario Torre Associate Manager, Software Engineering Red Hat GmbH <https://www.redhat.com>
9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From adinn at redhat.com Thu Mar 19 09:34:51 2020 From: adinn at redhat.com (Andrew Dinn) Date: Thu, 19 Mar 2020 09:34:51 +0000 Subject: CFV: New JDK Committer: Alexey Semenyuk In-Reply-To: <5E7272F3.902@oracle.com> References: <5E7272F3.902@oracle.com> Message-ID: <85d4c2a7-7164-2ed7-2af3-89986ca55fee@redhat.com> Vote: yes On 18/03/2020 19:13, Philip Race wrote: > > I hereby nominate Alexey Semenyuk (alexey.semenyuk at oracle.com) to JDK > committer. > > Alexey is a member of the JDK software development team at Oracle and has > contributed 12 fixes [1] in the JDK project, first in the areas of code > coverage, build and installers, > and recently he was one of the principal contributors to the jpackage > tool implementation [2] > > Votes are due by 1pm PDT, April 1st, 2020. > Only current JDK Committers [3] 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 [4]. > > -phil > > [1] > http://hg.openjdk.java.net/jdk/jdk/search/?rev=%28keyword%28%22alexey.semenyuk%40oracle.com%22%29%20or%20author%28asemenyu%29%29&revcount=400 > > > 2 months ago???? asemenyuk???? 8236132: Add missing properties to msi > installers > 2 months ago???? asemenyuk???? 8232077: Investigate if default behavior > should allow downgrade scenario > 2 months ago???? asemenyuk???? 8233578: Document configurable parameters > of msi packages > 3 months ago???? asemenyuk???? 8236138: Add tests for jmod applications > 3 months ago???? asemenyuk???? 8236134: files missing in putback to > JDK-8233270 > 3 months ago???? asemenyuk???? 8233270: Add support to jtreg helpers to > unpack packages > 3 months ago???? asemenyuk???? 8235728: JDK-8212780 breaks builds with a > custom X11 include path > 3 months ago???? asemenyuk???? 8233270: Add support to jtreg helpers to > unpack packages? [*] > 3 months ago???? asemenyuk???? 8230933: Default icon is not set for > additional launchers [*] > 2017-03-30?????? asemenyuk???? 8177770: Need more precise control on > build system logging > 3 months ago?????? herrick???? 8212780: Packaging Tool Implementation > 2016-10-17?????? asemenyuk???? 8168093: Need a way for the launcher to > query the JRE location using Windows registry. > > [*] Not showing up in search, changeset is here :- > https://hg.openjdk.java.net/jdk/jdk/rev/1b1a7893c78a > > [2] jpackage:? http://hg.openjdk.java.net/jdk/jdk/rev/9f9e7c969f78 (also > listed above) > > [3] http://openjdk.java.net/census > > [4] http://openjdk.java.net/projects/#committer-vote > -- 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 From martijnverburg at gmail.com Thu Mar 19 10:12:28 2020 From: martijnverburg at gmail.com (Martijn Verburg) Date: Thu, 19 Mar 2020 10:12:28 +0000 Subject: Anybody working on a solution to the mailing list problems (a.k.a JDK-8213225)? In-Reply-To: References: Message-ID: FWIW - all emails from google and twitter and sap domains that come through these mailing lists always enter my gmail SPAM filter. Unfortunately I?ve been unable to get Google to respond to this particular issue (which I get as I am a random free user of gmail like ~1billion other folks ). On Thu, 19 Mar 2020 at 09:23, Mario Torre wrote: > I?m having similar issues with my @gmail account FWIW. Most messages land > in spam, even when I instructed gmail they are legit. > > I don?t know if I also miss any though because of course I would have not > received them ;) > > Cheers, > Mario > > On Thursday, March 19, 2020, Langer, Christoph > wrote: > > > Hi all, > > > > some of you might be aware that there exist issues with mails delivered > > through the OpenJDK mailing lists. Presumably from mail addresses of > > organizations outside Oracle to other mail addresses outside Oracle. > > > > An issue was raised back in 2018 already by Martin Buchholz [0] but it > > seems there is no outcome yet and it's hard for me to see in which > > direction the investigation is going. But it must be kind of important, > as > > it has 26!! watchers to date. > > > > The issue reports that mails would end up in the spam folder although > they > > shouldn't. As long as only that would happen, I could kind of live with > it. > > However, lately I recognized that me (and my colleagues using the SAP > mail > > system) wouldn't receive mails from other parties like google.com [1], > > datadoghq.com [2] or alibaba-inc.com [3]. There might be others which > I'm > > not aware of. > > This is an unacceptable situation, since I wouldn't become aware of some > > discussions at all or don't get the possibility to reply directly to some > > mails! > > > > Maybe this complete rejection of mails (rather than accepting these as > > spam) is due to some recent change in the SAP mail system infrastructure. > > But to be able to debug it, me and the colleagues from SAP's IT > department > > need some help from folks who run the OpenJDK mailing lists at Oracle. > I've > > already asked for help at ops at o.j.n but didn't get any > > replies. So I'm posting my request again, publicly, on jdk-dev. > > > > Please help with both, the (seemingly SAP specific?) issue of not > > receiving some mails at all and also the problem of wrongly classifying > > mails as SPAM. > > > > Desperately looking forward to any help! > > > > Thanks > > Christoph > > > > [0] https://bugs.openjdk.java.net/browse/JDK-8213225 > > [1] https://mail.openjdk.java.net/pipermail/core-libs-dev/2020- > > March/065046.html > > [2] https://mail.openjdk.java.net/pipermail/jdk-updates-dev/ > > 2020-March/002642.html > > [3] https://mail.openjdk.java.net/pipermail/jdk-updates-dev/ > > 2020-March/002735.html > > > > > > -- > Mario Torre > Associate Manager, Software Engineering > Red Hat GmbH <https://www.redhat.com>
9704 A60C B4BE A8B8 0F30 > 9205 5D7E 4952 3F65 7898 > -- Cheers, Martijn (Sent from Gmail Mobile) From volker.simonis at gmail.com Thu Mar 19 10:44:50 2020 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 19 Mar 2020 11:44:50 +0100 Subject: CFV: New JDK Committer: Alexey Semenyuk In-Reply-To: <5E7272F3.902@oracle.com> References: <5E7272F3.902@oracle.com> Message-ID: Vote: yes Philip Race schrieb am Mi., 18. M?rz 2020, 20:12: > > I hereby nominate Alexey Semenyuk (alexey.semenyuk at oracle.com) to JDK > committer. > > Alexey is a member of the JDK software development team at Oracle and has > contributed 12 fixes [1] in the JDK project, first in the areas of code > coverage, build and installers, > and recently he was one of the principal contributors to the jpackage > tool implementation [2] > > Votes are due by 1pm PDT, April 1st, 2020. > Only current JDK Committers [3] 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 [4]. > > -phil > > [1] > > http://hg.openjdk.java.net/jdk/jdk/search/?rev=%28keyword%28%22alexey.semenyuk%40oracle.com%22%29%20or%20author%28asemenyu%29%29&revcount=400 > > 2 months ago asemenyuk 8236132: Add missing properties to msi > installers > 2 months ago asemenyuk 8232077: Investigate if default behavior > should allow downgrade scenario > 2 months ago asemenyuk 8233578: Document configurable parameters > of msi packages > 3 months ago asemenyuk 8236138: Add tests for jmod applications > 3 months ago asemenyuk 8236134: files missing in putback to > JDK-8233270 > 3 months ago asemenyuk 8233270: Add support to jtreg helpers to > unpack packages > 3 months ago asemenyuk 8235728: JDK-8212780 breaks builds with a > custom X11 include path > 3 months ago asemenyuk 8233270: Add support to jtreg helpers to > unpack packages [*] > 3 months ago asemenyuk 8230933: Default icon is not set for > additional launchers [*] > 2017-03-30 asemenyuk 8177770: Need more precise control on > build system logging > 3 months ago herrick 8212780: Packaging Tool Implementation > 2016-10-17 asemenyuk 8168093: Need a way for the launcher to > query the JRE location using Windows registry. > > [*] Not showing up in search, changeset is here :- > https://hg.openjdk.java.net/jdk/jdk/rev/1b1a7893c78a > > [2] jpackage: http://hg.openjdk.java.net/jdk/jdk/rev/9f9e7c969f78 (also > listed above) > > [3] http://openjdk.java.net/census > > [4] http://openjdk.java.net/projects/#committer-vote > From aoqi at loongson.cn Thu Mar 19 11:40:52 2020 From: aoqi at loongson.cn (Ao Qi) Date: Thu, 19 Mar 2020 19:40:52 +0800 Subject: Anybody working on a solution to the mailing list problems (a.k.a JDK-8213225)? In-Reply-To: References: Message-ID: On Thu, Mar 19, 2020 at 5:12 PM Langer, Christoph wrote: > > Hi all, > > some of you might be aware that there exist issues with mails delivered through the OpenJDK mailing lists. Presumably from mail addresses of organizations outside Oracle to other mail addresses outside Oracle. > > An issue was raised back in 2018 already by Martin Buchholz [0] but it seems there is no outcome yet and it's hard for me to see in which direction the investigation is going. But it must be kind of important, as it has 26!! watchers to date. > > The issue reports that mails would end up in the spam folder although they shouldn't. As long as only that would happen, I could kind of live with it. However, lately I recognized that me (and my colleagues using the SAP mail system) wouldn't receive mails from other parties like google.com [1], datadoghq.com [2] or alibaba-inc.com [3]. There might be others which I'm not aware of. FYI, I received [1] and [2]. I and another colleague (both using @loongson.cn) didn't receive [3]. Cheers, Ao Qi > This is an unacceptable situation, since I wouldn't become aware of some discussions at all or don't get the possibility to reply directly to some mails! > > Maybe this complete rejection of mails (rather than accepting these as spam) is due to some recent change in the SAP mail system infrastructure. But to be able to debug it, me and the colleagues from SAP's IT department need some help from folks who run the OpenJDK mailing lists at Oracle. I've already asked for help at ops at o.j.n but didn't get any replies. So I'm posting my request again, publicly, on jdk-dev. > > Please help with both, the (seemingly SAP specific?) issue of not receiving some mails at all and also the problem of wrongly classifying mails as SPAM. > > Desperately looking forward to any help! > > Thanks > Christoph > > [0] https://bugs.openjdk.java.net/browse/JDK-8213225 > [1] https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-March/065046.html > [2] https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2020-March/002642.html > [3] https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2020-March/002735.html From dmitry.markov at oracle.com Thu Mar 19 11:52:10 2020 From: dmitry.markov at oracle.com (Dmitry Markov) Date: Thu, 19 Mar 2020 11:52:10 +0000 Subject: CFV: New JDK Committer: Alexey Semenyuk In-Reply-To: <5E7272F3.902@oracle.com> References: <5E7272F3.902@oracle.com> Message-ID: <312FF5F3-021A-4E7B-9EFB-32EB4825EC2B@oracle.com> Vote: Yes Thanks, Dmitry > On 18 Mar 2020, at 19:13, Philip Race wrote: > > > I hereby nominate Alexey Semenyuk (alexey.semenyuk at oracle.com) to JDK committer. > > Alexey is a member of the JDK software development team at Oracle and has > contributed 12 fixes [1] in the JDK project, first in the areas of code coverage, build and installers, > and recently he was one of the principal contributors to the jpackage tool implementation [2] > > Votes are due by 1pm PDT, April 1st, 2020. > Only current JDK Committers [3] 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 [4]. > > -phil > > [1] > http://hg.openjdk.java.net/jdk/jdk/search/?rev=%28keyword%28%22alexey.semenyuk%40oracle.com%22%29%20or%20author%28asemenyu%29%29&revcount=400 > > 2 months ago asemenyuk 8236132: Add missing properties to msi installers > 2 months ago asemenyuk 8232077: Investigate if default behavior should allow downgrade scenario > 2 months ago asemenyuk 8233578: Document configurable parameters of msi packages > 3 months ago asemenyuk 8236138: Add tests for jmod applications > 3 months ago asemenyuk 8236134: files missing in putback to JDK-8233270 > 3 months ago asemenyuk 8233270: Add support to jtreg helpers to unpack packages > 3 months ago asemenyuk 8235728: JDK-8212780 breaks builds with a custom X11 include path > 3 months ago asemenyuk 8233270: Add support to jtreg helpers to unpack packages [*] > 3 months ago asemenyuk 8230933: Default icon is not set for additional launchers [*] > 2017-03-30 asemenyuk 8177770: Need more precise control on build system logging > 3 months ago herrick 8212780: Packaging Tool Implementation > 2016-10-17 asemenyuk 8168093: Need a way for the launcher to query the JRE location using Windows registry. > > [*] Not showing up in search, changeset is here :- > https://hg.openjdk.java.net/jdk/jdk/rev/1b1a7893c78a > > [2] jpackage: http://hg.openjdk.java.net/jdk/jdk/rev/9f9e7c969f78 (also listed above) > > [3] http://openjdk.java.net/census > > [4] http://openjdk.java.net/projects/#committer-vote From roger.riggs at oracle.com Thu Mar 19 13:00:53 2020 From: roger.riggs at oracle.com (Roger Riggs) Date: Thu, 19 Mar 2020 09:00:53 -0400 Subject: CFV: New JDK Committer: Alexey Semenyuk In-Reply-To: <5E7272F3.902@oracle.com> References: <5E7272F3.902@oracle.com> Message-ID: <7430dc56-0372-33f2-1b27-bc3a0c4b6f64@oracle.com> Vote: Yes On 3/18/20 3:13 PM, Philip Race wrote: > I hereby nominate Alexey Semenyuk (alexey.semenyuk at oracle.com) to JDK > committer. From roger.riggs at oracle.com Thu Mar 19 13:09:45 2020 From: roger.riggs at oracle.com (Roger Riggs) Date: Thu, 19 Mar 2020 09:09:45 -0400 Subject: CFV: New JDK Reviewer: Pankaj Bansal In-Reply-To: <8058c801-ffb6-25ae-76b0-b2687335b908@oracle.com> References: <8058c801-ffb6-25ae-76b0-b2687335b908@oracle.com> Message-ID: <6a32ce5d-3a9d-3914-dfa7-c66ff5c16599@oracle.com> Vote: Yes On 3/15/20 11:21 PM, Sergey Bylokhov wrote: > I hereby nominate Pankaj Bansal to JDK Reviewer. From goetz.lindenmaier at sap.com Thu Mar 19 13:56:28 2020 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 19 Mar 2020 13:56:28 +0000 Subject: CFV: New JDK Committer: Alexey Semenyuk In-Reply-To: <5E7272F3.902@oracle.com> References: <5E7272F3.902@oracle.com> Message-ID: Vote: yes Best regards, Goetz. > -----Original Message----- > From: jdk-dev On Behalf Of Philip > Race > Sent: Wednesday, March 18, 2020 8:14 PM > To: jdk-dev at openjdk.java.net > Subject: CFV: New JDK Committer: Alexey Semenyuk > > > I hereby nominate Alexey Semenyuk (alexey.semenyuk at oracle.com) to JDK > committer. > > Alexey is a member of the JDK software development team at Oracle and > has > contributed 12 fixes [1] in the JDK project, first in the areas of code > coverage, build and installers, > and recently he was one of the principal contributors to the jpackage > tool implementation [2] > > Votes are due by 1pm PDT, April 1st, 2020. > Only current JDK Committers [3] 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 [4]. > > -phil > > [1] > http://hg.openjdk.java.net/jdk/jdk/search/?rev=%28keyword%28%22alexe > y.semenyuk%40oracle.com%22%29%20or%20author%28asemenyu%29%29& > revcount=400 > > 2 months ago asemenyuk 8236132: Add missing properties to msi > installers > 2 months ago asemenyuk 8232077: Investigate if default behavior > should allow downgrade scenario > 2 months ago asemenyuk 8233578: Document configurable parameters > of msi packages > 3 months ago asemenyuk 8236138: Add tests for jmod applications > 3 months ago asemenyuk 8236134: files missing in putback to > JDK-8233270 > 3 months ago asemenyuk 8233270: Add support to jtreg helpers to > unpack packages > 3 months ago asemenyuk 8235728: JDK-8212780 breaks builds with a > custom X11 include path > 3 months ago asemenyuk 8233270: Add support to jtreg helpers to > unpack packages [*] > 3 months ago asemenyuk 8230933: Default icon is not set for > additional launchers [*] > 2017-03-30 asemenyuk 8177770: Need more precise control on > build system logging > 3 months ago herrick 8212780: Packaging Tool Implementation > 2016-10-17 asemenyuk 8168093: Need a way for the launcher to > query the JRE location using Windows registry. > > [*] Not showing up in search, changeset is here :- > https://hg.openjdk.java.net/jdk/jdk/rev/1b1a7893c78a > > [2] jpackage: http://hg.openjdk.java.net/jdk/jdk/rev/9f9e7c969f78 (also > listed above) > > [3] http://openjdk.java.net/census > > [4] http://openjdk.java.net/projects/#committer-vote From magnus.ihse.bursie at oracle.com Thu Mar 19 17:24:07 2020 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 19 Mar 2020 18:24:07 +0100 Subject: CFV: New JDK Committer: Alexey Semenyuk In-Reply-To: <5E7272F3.902@oracle.com> References: <5E7272F3.902@oracle.com> Message-ID: <80b3a351-49c4-d015-8128-ab7c7c438711@oracle.com> Vote: yes /Magnus On 2020-03-18 20:13, Philip Race wrote: > > I hereby nominate Alexey Semenyuk (alexey.semenyuk at oracle.com) to JDK > committer. > > Alexey is a member of the JDK software development team at Oracle and has > contributed 12 fixes [1] in the JDK project, first in the areas of > code coverage, build and installers, > and recently he was one of the principal contributors to the jpackage > tool implementation [2] > > Votes are due by 1pm PDT, April 1st, 2020. > Only current JDK Committers [3] 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 [4]. > > -phil > > [1] > http://hg.openjdk.java.net/jdk/jdk/search/?rev=%28keyword%28%22alexey.semenyuk%40oracle.com%22%29%20or%20author%28asemenyu%29%29&revcount=400 > > > 2 months ago???? asemenyuk???? 8236132: Add missing properties to msi > installers > 2 months ago???? asemenyuk???? 8232077: Investigate if default > behavior should allow downgrade scenario > 2 months ago???? asemenyuk???? 8233578: Document configurable > parameters of msi packages > 3 months ago???? asemenyuk???? 8236138: Add tests for jmod applications > 3 months ago???? asemenyuk???? 8236134: files missing in putback to > JDK-8233270 > 3 months ago???? asemenyuk???? 8233270: Add support to jtreg helpers > to unpack packages > 3 months ago???? asemenyuk???? 8235728: JDK-8212780 breaks builds with > a custom X11 include path > 3 months ago???? asemenyuk???? 8233270: Add support to jtreg helpers > to unpack packages? [*] > 3 months ago???? asemenyuk???? 8230933: Default icon is not set for > additional launchers [*] > 2017-03-30?????? asemenyuk???? 8177770: Need more precise control on > build system logging > 3 months ago?????? herrick???? 8212780: Packaging Tool Implementation > 2016-10-17?????? asemenyuk???? 8168093: Need a way for the launcher to > query the JRE location using Windows registry. > > [*] Not showing up in search, changeset is here :- > https://hg.openjdk.java.net/jdk/jdk/rev/1b1a7893c78a > > [2] jpackage:? http://hg.openjdk.java.net/jdk/jdk/rev/9f9e7c969f78 > (also listed above) > > [3] http://openjdk.java.net/census > > [4] http://openjdk.java.net/projects/#committer-vote From ivan.gerasimov at oracle.com Thu Mar 19 17:55:12 2020 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Thu, 19 Mar 2020 10:55:12 -0700 Subject: CFV: New JDK Committer: Alexey Semenyuk In-Reply-To: <5E7272F3.902@oracle.com> References: <5E7272F3.902@oracle.com> Message-ID: <4eee0b01-5dbf-30ca-56d1-6aef737b35e0@oracle.com> Vote: Yes On 3/18/20 12:13 PM, Philip Race wrote: > > I hereby nominate Alexey Semenyuk (alexey.semenyuk at oracle.com) to JDK > committer. > ... -- With kind regards, Ivan Gerasimov From mikhailo.seledtsov at oracle.com Thu Mar 19 19:03:04 2020 From: mikhailo.seledtsov at oracle.com (mikhailo.seledtsov at oracle.com) Date: Thu, 19 Mar 2020 12:03:04 -0700 Subject: CFV: New JDK Committer: Alexey Semenyuk In-Reply-To: <5E7272F3.902@oracle.com> References: <5E7272F3.902@oracle.com> Message-ID: <88e71b15-47ea-a2b8-fac2-1ab36e183204@oracle.com> Vote: yes On 3/18/20 12:13 PM, Philip Race wrote: > > I hereby nominate Alexey Semenyuk (alexey.semenyuk at oracle.com) to JDK > committer. > > Alexey is a member of the JDK software development team at Oracle and has > contributed 12 fixes [1] in the JDK project, first in the areas of > code coverage, build and installers, > and recently he was one of the principal contributors to the jpackage > tool implementation [2] > > Votes are due by 1pm PDT, April 1st, 2020. > Only current JDK Committers [3] 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 [4]. > > -phil > > [1] > http://hg.openjdk.java.net/jdk/jdk/search/?rev=%28keyword%28%22alexey.semenyuk%40oracle.com%22%29%20or%20author%28asemenyu%29%29&revcount=400 > > > 2 months ago???? asemenyuk???? 8236132: Add missing properties to msi > installers > 2 months ago???? asemenyuk???? 8232077: Investigate if default > behavior should allow downgrade scenario > 2 months ago???? asemenyuk???? 8233578: Document configurable > parameters of msi packages > 3 months ago???? asemenyuk???? 8236138: Add tests for jmod applications > 3 months ago???? asemenyuk???? 8236134: files missing in putback to > JDK-8233270 > 3 months ago???? asemenyuk???? 8233270: Add support to jtreg helpers > to unpack packages > 3 months ago???? asemenyuk???? 8235728: JDK-8212780 breaks builds with > a custom X11 include path > 3 months ago???? asemenyuk???? 8233270: Add support to jtreg helpers > to unpack packages? [*] > 3 months ago???? asemenyuk???? 8230933: Default icon is not set for > additional launchers [*] > 2017-03-30?????? asemenyuk???? 8177770: Need more precise control on > build system logging > 3 months ago?????? herrick???? 8212780: Packaging Tool Implementation > 2016-10-17?????? asemenyuk???? 8168093: Need a way for the launcher to > query the JRE location using Windows registry. > > [*] Not showing up in search, changeset is here :- > https://hg.openjdk.java.net/jdk/jdk/rev/1b1a7893c78a > > [2] jpackage:? http://hg.openjdk.java.net/jdk/jdk/rev/9f9e7c969f78 > (also listed above) > > [3] http://openjdk.java.net/census > > [4] http://openjdk.java.net/projects/#committer-vote From fw at deneb.enyo.de Thu Mar 19 19:39:33 2020 From: fw at deneb.enyo.de (Florian Weimer) Date: Thu, 19 Mar 2020 20:39:33 +0100 Subject: Anybody working on a solution to the mailing list problems (a.k.a JDK-8213225)? In-Reply-To: (Christoph Langer's message of "Thu, 19 Mar 2020 09:12:39 +0000") References: Message-ID: <871rpogmmi.fsf@mid.deneb.enyo.de> * Christoph Langer: > [1] https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-March/065046.html I can't prove it, but I think this message fails DKIM verification because Mailman stripped a text/html part which was present in the original. It's a conjecture based on this header: X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Obviously, that invalidates the signature on the message body. Other lists simply reject messages with text/html parts. > [2] https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2020-March/002642.html Looks similar. > [3] https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2020-March/002735.html I did not receive this message either, and I do not do any DKIM checking, so that could be something else. I looked for the message ID, <65c770e4-6f99-4c40-9f27-9a60d36c5085.maoliang.ml at alibaba-inc.com> in the logs of the outer mail relay, and I could not find a trace of it, either. From ningsheng.jian at arm.com Fri Mar 20 07:51:32 2020 From: ningsheng.jian at arm.com (Ningsheng Jian) Date: Fri, 20 Mar 2020 15:51:32 +0800 Subject: CFV: New JDK Committer: Nick Gasson Message-ID: <041546d5-fb08-602e-351a-b612395dc021@arm.com> I hereby nominate Nick Gasson (nick.gasson at arm.com) to JDK committer. Nick is a member of Arm JDK team and has contributed 29 changes to JDK project. [3] Votes are due by 10:00 GMT, April 3rd, 2020. 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, Ningsheng [1] http://openjdk.java.net/census [2] http://openjdk.java.net/projects/#committer-vote [3] http://hg.openjdk.java.net/jdk/jdk/log?revcount=100&rev=desc%28%22nick.gasson%40arm.com%22%29+or+author%28ngasson%29 8240353: AArch64: missing support for -XX:+ExtendedDTraceProbes in C1 8238705: [TESTBUG] jfr/event/gc/stacktrace/TestMetaspace* are stable with Xcomp on AArch64 8236634: Memory Access API tests fail on 32-bit 8237512: AArch64: aarch64TestHook leaks a BufferBlob 8236992: AArch64: remove redundant load_klass in itable stub 8237521: Memory Access API fixes for 32-bit 8236242: Arm32: build broken after 8234794 8234794: AArch64: runtime/memory/ReadFromNoaccessArea.java crashes 8235982: AArch64: Insufficient memory barriers in shadow region algorithm 8229912: [TESTBUG] java/net/Socks/SocksIPv6Test fails without IPv6 8229118: [TESTBUG] serviceability/sa/ClhsdbFindPC fails on AArch64 8224851: AArch64: fix warnings and errors with Clang and GCC 8.3 8224853: CDS address sanitizer errors 8221529: [TESTBUG] Docker tests use old/deprecated image on AArch64 8220707: [TESTBUG] serviceability/sa/TestHeapDumpForLargeArray.java fails with jtreg -vmoption:-Xmx < 8g 8220451: jdi/EventQueue/remove/remove004 failed due to "ERROR: thread2 is not alive" 8220456: jdi/EventQueue/remove_l/remove_l004 failed due to "TIMEOUT while waiting for event" 8219628: [TESTBUG] javadoc/doclet/InheritDocForUserTags fails with -othervm 8209413: AArch64: NPE in clhsdb jstack command 8217368: AArch64: C2 recursive stack locking optimisation not triggered 8217427: (dc) nio/channels/DatagramChannel/UseDGWithIPv6.java fails without IPv6 8216350: AArch64: monitor unlock fast path not called 8209414: AArch64: method handle invocation does not respect JVMTI interp_only mode 8215951: AArch64: jtreg test vmTestbase/nsk/jvmti/PopFrame/popframe005 segfaults 8215202: AArch64: jtreg test test/jdk/sun/nio/cs/FindEncoderBugs.java fails 8215100: AArch64: fix compareTo intrinsic with four-character Latin/Unicode 8214512: ARM32: Jtreg test compiler/c2/Test8062950.java fails on ARM 8209414: AArch64: method handle invocation does not respect JVMTI interp_only mode 8214077: test java/io/File/SetLastModified.java fails on ARM32 8214078: (fs) SecureDirectoryStream not supported on arm32 From ningsheng.jian at arm.com Fri Mar 20 07:54:45 2020 From: ningsheng.jian at arm.com (Ningsheng Jian) Date: Fri, 20 Mar 2020 15:54:45 +0800 Subject: CFV: New JDK Committer: Pengfei Li Message-ID: <55417a6f-f401-16ab-5dcc-0a93bba6cb03@arm.com> I hereby nominate Pengfei Li (pengfei.li at arm.com) to JDK committer. Pengfei is a member of Arm JDK team and has contributed 20 changes to JDK project. [3] Votes are due by 10:00 GMT, April 3rd, 2020. 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, Ningsheng [1] http://openjdk.java.net/census [2] http://openjdk.java.net/projects/#committer-vote [3] http://hg.openjdk.java.net/jdk/jdk/log?revcount=100&rev=desc%28%22pengfei.li%40arm.com%22%29+or+%28user%28%22pli%22%29+and+not+%28user%28%22pliden%22%29%29%29 8239549: AArch64: Backend support for MulAddVS2VI node 8237524: AArch64: String.compareTo() may return incorrect result 8232591: AArch64: Add missing match rules for smaddl, smsubl and smnegl 8233743: AArch64: Make r27 conditionally allocatable 8234791: Fix Client VM build for x86_64 and AArch64 8230591: AArch64: Missing intrinsics for Math.ceil, floor, rint 8228601: AArch64: Fix interpreter code at JVMCI deoptimization entry 8227512: [TESTBUG] Fix JTReg javac test failures with Graal 8226222: [JVMCI] Export AArch64 field VM_Version::_psr_info.dczid_el0 8223427: [TESTBUG] Disable JTReg Shenandoah tests when Graal is enabled 8223054: [TESTBUG] Put graalJarsCP before existing classpath in GraalUnitTestLauncher 8214922: Add vectorization support for fmin/fmax 8216259: AArch64: Vectorize Adler32 intrinsics 8218550: Add test omitted from JDK-8212043 8212043: Add floating-point Math.min/max intrinsics 8211333: AArch64: Fix another build failure after JDK-8211029 8210413: AArch64: Optimize div/rem by constant in C1 8210152: Optimize integer divisible by power-of-2 check 8209783: AArch64: Combine Multiply and Neg operations in C2 8208623: [TESTBUG] runtime/LoadClass/LongBCP.java fails in AUFS file system From jiefu at tencent.com Fri Mar 20 08:04:16 2020 From: jiefu at tencent.com (=?utf-8?B?amllZnUo5YKF5p2wKQ==?=) Date: Fri, 20 Mar 2020 08:04:16 +0000 Subject: New JDK Committer: Pengfei Li(Internet mail) In-Reply-To: <55417a6f-f401-16ab-5dcc-0a93bba6cb03@arm.com> References: <55417a6f-f401-16ab-5dcc-0a93bba6cb03@arm.com> Message-ID: <7423E3E3-70ED-48AC-9302-DBFC2A8E0C48@tencent.com> Vote: yes. Best regards, Jie ?On 2020/3/20, 3:56 PM, "jdk-dev on behalf of Ningsheng Jian" wrote: I hereby nominate Pengfei Li (pengfei.li at arm.com) to JDK committer. Pengfei is a member of Arm JDK team and has contributed 20 changes to JDK project. [3] Votes are due by 10:00 GMT, April 3rd, 2020. 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, Ningsheng [1] http://openjdk.java.net/census [2] http://openjdk.java.net/projects/#committer-vote [3] http://hg.openjdk.java.net/jdk/jdk/log?revcount=100&rev=desc%28%22pengfei.li%40arm.com%22%29+or+%28user%28%22pli%22%29+and+not+%28user%28%22pliden%22%29%29%29 8239549: AArch64: Backend support for MulAddVS2VI node 8237524: AArch64: String.compareTo() may return incorrect result 8232591: AArch64: Add missing match rules for smaddl, smsubl and smnegl 8233743: AArch64: Make r27 conditionally allocatable 8234791: Fix Client VM build for x86_64 and AArch64 8230591: AArch64: Missing intrinsics for Math.ceil, floor, rint 8228601: AArch64: Fix interpreter code at JVMCI deoptimization entry 8227512: [TESTBUG] Fix JTReg javac test failures with Graal 8226222: [JVMCI] Export AArch64 field VM_Version::_psr_info.dczid_el0 8223427: [TESTBUG] Disable JTReg Shenandoah tests when Graal is enabled 8223054: [TESTBUG] Put graalJarsCP before existing classpath in GraalUnitTestLauncher 8214922: Add vectorization support for fmin/fmax 8216259: AArch64: Vectorize Adler32 intrinsics 8218550: Add test omitted from JDK-8212043 8212043: Add floating-point Math.min/max intrinsics 8211333: AArch64: Fix another build failure after JDK-8211029 8210413: AArch64: Optimize div/rem by constant in C1 8210152: Optimize integer divisible by power-of-2 check 8209783: AArch64: Combine Multiply and Neg operations in C2 8208623: [TESTBUG] runtime/LoadClass/LongBCP.java fails in AUFS file system From jiefu at tencent.com Fri Mar 20 08:04:40 2020 From: jiefu at tencent.com (=?utf-8?B?amllZnUo5YKF5p2wKQ==?=) Date: Fri, 20 Mar 2020 08:04:40 +0000 Subject: New JDK Committer: Nick Gasson(Internet mail) In-Reply-To: <041546d5-fb08-602e-351a-b612395dc021@arm.com> References: <041546d5-fb08-602e-351a-b612395dc021@arm.com> Message-ID: Vote: yes. Best regards, Jie ?On 2020/3/20, 3:53 PM, "jdk-dev on behalf of Ningsheng Jian" wrote: I hereby nominate Nick Gasson (nick.gasson at arm.com) to JDK committer. Nick is a member of Arm JDK team and has contributed 29 changes to JDK project. [3] Votes are due by 10:00 GMT, April 3rd, 2020. 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, Ningsheng [1] http://openjdk.java.net/census [2] http://openjdk.java.net/projects/#committer-vote [3] http://hg.openjdk.java.net/jdk/jdk/log?revcount=100&rev=desc%28%22nick.gasson%40arm.com%22%29+or+author%28ngasson%29 8240353: AArch64: missing support for -XX:+ExtendedDTraceProbes in C1 8238705: [TESTBUG] jfr/event/gc/stacktrace/TestMetaspace* are stable with Xcomp on AArch64 8236634: Memory Access API tests fail on 32-bit 8237512: AArch64: aarch64TestHook leaks a BufferBlob 8236992: AArch64: remove redundant load_klass in itable stub 8237521: Memory Access API fixes for 32-bit 8236242: Arm32: build broken after 8234794 8234794: AArch64: runtime/memory/ReadFromNoaccessArea.java crashes 8235982: AArch64: Insufficient memory barriers in shadow region algorithm 8229912: [TESTBUG] java/net/Socks/SocksIPv6Test fails without IPv6 8229118: [TESTBUG] serviceability/sa/ClhsdbFindPC fails on AArch64 8224851: AArch64: fix warnings and errors with Clang and GCC 8.3 8224853: CDS address sanitizer errors 8221529: [TESTBUG] Docker tests use old/deprecated image on AArch64 8220707: [TESTBUG] serviceability/sa/TestHeapDumpForLargeArray.java fails with jtreg -vmoption:-Xmx < 8g 8220451: jdi/EventQueue/remove/remove004 failed due to "ERROR: thread2 is not alive" 8220456: jdi/EventQueue/remove_l/remove_l004 failed due to "TIMEOUT while waiting for event" 8219628: [TESTBUG] javadoc/doclet/InheritDocForUserTags fails with -othervm 8209413: AArch64: NPE in clhsdb jstack command 8217368: AArch64: C2 recursive stack locking optimisation not triggered 8217427: (dc) nio/channels/DatagramChannel/UseDGWithIPv6.java fails without IPv6 8216350: AArch64: monitor unlock fast path not called 8209414: AArch64: method handle invocation does not respect JVMTI interp_only mode 8215951: AArch64: jtreg test vmTestbase/nsk/jvmti/PopFrame/popframe005 segfaults 8215202: AArch64: jtreg test test/jdk/sun/nio/cs/FindEncoderBugs.java fails 8215100: AArch64: fix compareTo intrinsic with four-character Latin/Unicode 8214512: ARM32: Jtreg test compiler/c2/Test8062950.java fails on ARM 8209414: AArch64: method handle invocation does not respect JVMTI interp_only mode 8214077: test java/io/File/SetLastModified.java fails on ARM32 8214078: (fs) SecureDirectoryStream not supported on arm32 From volker.simonis at gmail.com Fri Mar 20 08:17:23 2020 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 20 Mar 2020 09:17:23 +0100 Subject: CFV: New JDK Committer: Pengfei Li In-Reply-To: <55417a6f-f401-16ab-5dcc-0a93bba6cb03@arm.com> References: <55417a6f-f401-16ab-5dcc-0a93bba6cb03@arm.com> Message-ID: Vote: yes Ningsheng Jian schrieb am Fr., 20. M?rz 2020, 08:55: > I hereby nominate Pengfei Li (pengfei.li at arm.com) to JDK committer. > > Pengfei is a member of Arm JDK team and has contributed 20 changes to > JDK project. [3] > > Votes are due by 10:00 GMT, April 3rd, 2020. > > 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, > Ningsheng > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] > > http://hg.openjdk.java.net/jdk/jdk/log?revcount=100&rev=desc%28%22pengfei.li%40arm.com%22%29+or+%28user%28%22pli%22%29+and+not+%28user%28%22pliden%22%29%29%29 > > 8239549: AArch64: Backend support for MulAddVS2VI node > 8237524: AArch64: String.compareTo() may return incorrect result > 8232591: AArch64: Add missing match rules for smaddl, smsubl and smnegl > 8233743: AArch64: Make r27 conditionally allocatable > 8234791: Fix Client VM build for x86_64 and AArch64 > 8230591: AArch64: Missing intrinsics for Math.ceil, floor, rint > 8228601: AArch64: Fix interpreter code at JVMCI deoptimization entry > 8227512: [TESTBUG] Fix JTReg javac test failures with Graal > 8226222: [JVMCI] Export AArch64 field VM_Version::_psr_info.dczid_el0 > 8223427: [TESTBUG] Disable JTReg Shenandoah tests when Graal is enabled > 8223054: [TESTBUG] Put graalJarsCP before existing classpath in > GraalUnitTestLauncher > 8214922: Add vectorization support for fmin/fmax > 8216259: AArch64: Vectorize Adler32 intrinsics > 8218550: Add test omitted from JDK-8212043 > 8212043: Add floating-point Math.min/max intrinsics > 8211333: AArch64: Fix another build failure after JDK-8211029 > 8210413: AArch64: Optimize div/rem by constant in C1 > 8210152: Optimize integer divisible by power-of-2 check > 8209783: AArch64: Combine Multiply and Neg operations in C2 > 8208623: [TESTBUG] runtime/LoadClass/LongBCP.java fails in AUFS file system > From volker.simonis at gmail.com Fri Mar 20 08:17:58 2020 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 20 Mar 2020 09:17:58 +0100 Subject: CFV: New JDK Committer: Nick Gasson In-Reply-To: <041546d5-fb08-602e-351a-b612395dc021@arm.com> References: <041546d5-fb08-602e-351a-b612395dc021@arm.com> Message-ID: Vote: yes Ningsheng Jian schrieb am Fr., 20. M?rz 2020, 08:51: > I hereby nominate Nick Gasson (nick.gasson at arm.com) to JDK committer. > > Nick is a member of Arm JDK team and has contributed 29 changes to JDK > project. [3] > > Votes are due by 10:00 GMT, April 3rd, 2020. > > 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, > Ningsheng > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] > > http://hg.openjdk.java.net/jdk/jdk/log?revcount=100&rev=desc%28%22nick.gasson%40arm.com%22%29+or+author%28ngasson%29 > > 8240353: AArch64: missing support for -XX:+ExtendedDTraceProbes in C1 > 8238705: [TESTBUG] jfr/event/gc/stacktrace/TestMetaspace* are stable > with Xcomp on AArch64 > 8236634: Memory Access API tests fail on 32-bit > 8237512: AArch64: aarch64TestHook leaks a BufferBlob > 8236992: AArch64: remove redundant load_klass in itable stub > 8237521: Memory Access API fixes for 32-bit > 8236242: Arm32: build broken after 8234794 > 8234794: AArch64: runtime/memory/ReadFromNoaccessArea.java crashes > 8235982: AArch64: Insufficient memory barriers in shadow region algorithm > 8229912: [TESTBUG] java/net/Socks/SocksIPv6Test fails without IPv6 > 8229118: [TESTBUG] serviceability/sa/ClhsdbFindPC fails on AArch64 > 8224851: AArch64: fix warnings and errors with Clang and GCC 8.3 > 8224853: CDS address sanitizer errors > 8221529: [TESTBUG] Docker tests use old/deprecated image on AArch64 > 8220707: [TESTBUG] serviceability/sa/TestHeapDumpForLargeArray.java > fails with jtreg -vmoption:-Xmx < 8g > 8220451: jdi/EventQueue/remove/remove004 failed due to "ERROR: thread2 > is not alive" 8220456: jdi/EventQueue/remove_l/remove_l004 failed due to > "TIMEOUT while waiting for event" > 8219628: [TESTBUG] javadoc/doclet/InheritDocForUserTags fails with -othervm > 8209413: AArch64: NPE in clhsdb jstack command > 8217368: AArch64: C2 recursive stack locking optimisation not triggered > 8217427: (dc) nio/channels/DatagramChannel/UseDGWithIPv6.java fails > without IPv6 > 8216350: AArch64: monitor unlock fast path not called > 8209414: AArch64: method handle invocation does not respect JVMTI > interp_only mode > 8215951: AArch64: jtreg test vmTestbase/nsk/jvmti/PopFrame/popframe005 > segfaults > 8215202: AArch64: jtreg test test/jdk/sun/nio/cs/FindEncoderBugs.java fails > 8215100: AArch64: fix compareTo intrinsic with four-character Latin/Unicode > 8214512: ARM32: Jtreg test compiler/c2/Test8062950.java fails on ARM > 8209414: AArch64: method handle invocation does not respect JVMTI > interp_only mode > 8214077: test java/io/File/SetLastModified.java fails on ARM32 > 8214078: (fs) SecureDirectoryStream not supported on arm32 > From david.holmes at oracle.com Fri Mar 20 08:18:58 2020 From: david.holmes at oracle.com (David Holmes) Date: Fri, 20 Mar 2020 18:18:58 +1000 Subject: CFV: New JDK Committer: Nick Gasson In-Reply-To: <041546d5-fb08-602e-351a-b612395dc021@arm.com> References: <041546d5-fb08-602e-351a-b612395dc021@arm.com> Message-ID: Vote: yes David On 20/03/2020 5:51 pm, Ningsheng Jian wrote: > I hereby nominate Nick Gasson (nick.gasson at arm.com) to JDK committer. > > Nick is a member of Arm JDK team and has contributed 29 changes to JDK > project. [3] > > Votes are due by 10:00 GMT, April 3rd, 2020. > > 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, > Ningsheng > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] > http://hg.openjdk.java.net/jdk/jdk/log?revcount=100&rev=desc%28%22nick.gasson%40arm.com%22%29+or+author%28ngasson%29 > > > 8240353: AArch64: missing support for -XX:+ExtendedDTraceProbes in C1 > 8238705: [TESTBUG] jfr/event/gc/stacktrace/TestMetaspace* are stable > with Xcomp on AArch64 > 8236634: Memory Access API tests fail on 32-bit > 8237512: AArch64: aarch64TestHook leaks a BufferBlob > 8236992: AArch64: remove redundant load_klass in itable stub > 8237521: Memory Access API fixes for 32-bit > 8236242: Arm32: build broken after 8234794 > 8234794: AArch64: runtime/memory/ReadFromNoaccessArea.java crashes > 8235982: AArch64: Insufficient memory barriers in shadow region algorithm > 8229912: [TESTBUG] java/net/Socks/SocksIPv6Test fails without IPv6 > 8229118: [TESTBUG] serviceability/sa/ClhsdbFindPC fails on AArch64 > 8224851: AArch64: fix warnings and errors with Clang and GCC 8.3 > 8224853: CDS address sanitizer errors > 8221529: [TESTBUG] Docker tests use old/deprecated image on AArch64 > 8220707: [TESTBUG] serviceability/sa/TestHeapDumpForLargeArray.java > fails with jtreg -vmoption:-Xmx < 8g > 8220451: jdi/EventQueue/remove/remove004 failed due to "ERROR: thread2 > is not alive" 8220456: jdi/EventQueue/remove_l/remove_l004 failed due to > "TIMEOUT while waiting for event" > 8219628: [TESTBUG] javadoc/doclet/InheritDocForUserTags fails with -othervm > 8209413: AArch64: NPE in clhsdb jstack command > 8217368: AArch64: C2 recursive stack locking optimisation not triggered > 8217427: (dc) nio/channels/DatagramChannel/UseDGWithIPv6.java fails > without IPv6 > 8216350: AArch64: monitor unlock fast path not called > 8209414: AArch64: method handle invocation does not respect JVMTI > interp_only mode > 8215951: AArch64: jtreg test vmTestbase/nsk/jvmti/PopFrame/popframe005 > segfaults > 8215202: AArch64: jtreg test test/jdk/sun/nio/cs/FindEncoderBugs.java fails > 8215100: AArch64: fix compareTo intrinsic with four-character Latin/Unicode > 8214512: ARM32: Jtreg test compiler/c2/Test8062950.java fails on ARM > 8209414: AArch64: method handle invocation does not respect JVMTI > interp_only mode > 8214077: test java/io/File/SetLastModified.java fails on ARM32 > 8214078: (fs) SecureDirectoryStream not supported on arm32 From david.holmes at oracle.com Fri Mar 20 08:19:24 2020 From: david.holmes at oracle.com (David Holmes) Date: Fri, 20 Mar 2020 18:19:24 +1000 Subject: CFV: New JDK Committer: Pengfei Li In-Reply-To: <55417a6f-f401-16ab-5dcc-0a93bba6cb03@arm.com> References: <55417a6f-f401-16ab-5dcc-0a93bba6cb03@arm.com> Message-ID: <431f595e-0d77-972c-8c72-c492814d946d@oracle.com> Vote: yes David On 20/03/2020 5:54 pm, Ningsheng Jian wrote: > I hereby nominate Pengfei Li (pengfei.li at arm.com) to JDK committer. > > Pengfei is a member of Arm JDK team and has contributed 20 changes to > JDK project. [3] > > Votes are due by 10:00 GMT, April 3rd, 2020. > > 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, > Ningsheng > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] > http://hg.openjdk.java.net/jdk/jdk/log?revcount=100&rev=desc%28%22pengfei.li%40arm.com%22%29+or+%28user%28%22pli%22%29+and+not+%28user%28%22pliden%22%29%29%29 > > > 8239549: AArch64: Backend support for MulAddVS2VI node > 8237524: AArch64: String.compareTo() may return incorrect result > 8232591: AArch64: Add missing match rules for smaddl, smsubl and smnegl > 8233743: AArch64: Make r27 conditionally allocatable > 8234791: Fix Client VM build for x86_64 and AArch64 > 8230591: AArch64: Missing intrinsics for Math.ceil, floor, rint > 8228601: AArch64: Fix interpreter code at JVMCI deoptimization entry > 8227512: [TESTBUG] Fix JTReg javac test failures with Graal > 8226222: [JVMCI] Export AArch64 field VM_Version::_psr_info.dczid_el0 > 8223427: [TESTBUG] Disable JTReg Shenandoah tests when Graal is enabled > 8223054: [TESTBUG] Put graalJarsCP before existing classpath in > GraalUnitTestLauncher > 8214922: Add vectorization support for fmin/fmax > 8216259: AArch64: Vectorize Adler32 intrinsics > 8218550: Add test omitted from JDK-8212043 > 8212043: Add floating-point Math.min/max intrinsics > 8211333: AArch64: Fix another build failure after JDK-8211029 > 8210413: AArch64: Optimize div/rem by constant in C1 > 8210152: Optimize integer divisible by power-of-2 check > 8209783: AArch64: Combine Multiply and Neg operations in C2 > 8208623: [TESTBUG] runtime/LoadClass/LongBCP.java fails in AUFS file system From tobias.hartmann at oracle.com Fri Mar 20 09:20:16 2020 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Fri, 20 Mar 2020 10:20:16 +0100 Subject: CFV: New JDK Committer: Pengfei Li In-Reply-To: <55417a6f-f401-16ab-5dcc-0a93bba6cb03@arm.com> References: <55417a6f-f401-16ab-5dcc-0a93bba6cb03@arm.com> Message-ID: Vote: yes Best regards, Tobias On 20.03.20 08:54, Ningsheng Jian wrote: > I hereby nominate Pengfei Li (pengfei.li at arm.com) to JDK committer. > > Pengfei is a member of Arm JDK team and has contributed 20 changes to JDK project. [3] > > Votes are due by 10:00 GMT, April 3rd, 2020. > > 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, > Ningsheng > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] > http://hg.openjdk.java.net/jdk/jdk/log?revcount=100&rev=desc%28%22pengfei.li%40arm.com%22%29+or+%28user%28%22pli%22%29+and+not+%28user%28%22pliden%22%29%29%29 > > > 8239549: AArch64: Backend support for MulAddVS2VI node > 8237524: AArch64: String.compareTo() may return incorrect result > 8232591: AArch64: Add missing match rules for smaddl, smsubl and smnegl > 8233743: AArch64: Make r27 conditionally allocatable > 8234791: Fix Client VM build for x86_64 and AArch64 > 8230591: AArch64: Missing intrinsics for Math.ceil, floor, rint > 8228601: AArch64: Fix interpreter code at JVMCI deoptimization entry > 8227512: [TESTBUG] Fix JTReg javac test failures with Graal > 8226222: [JVMCI] Export AArch64 field VM_Version::_psr_info.dczid_el0 > 8223427: [TESTBUG] Disable JTReg Shenandoah tests when Graal is enabled > 8223054: [TESTBUG] Put graalJarsCP before existing classpath in GraalUnitTestLauncher > 8214922: Add vectorization support for fmin/fmax > 8216259: AArch64: Vectorize Adler32 intrinsics > 8218550: Add test omitted from JDK-8212043 > 8212043: Add floating-point Math.min/max intrinsics > 8211333: AArch64: Fix another build failure after JDK-8211029 > 8210413: AArch64: Optimize div/rem by constant in C1 > 8210152: Optimize integer divisible by power-of-2 check > 8209783: AArch64: Combine Multiply and Neg operations in C2 > 8208623: [TESTBUG] runtime/LoadClass/LongBCP.java fails in AUFS file system From tobias.hartmann at oracle.com Fri Mar 20 09:20:32 2020 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Fri, 20 Mar 2020 10:20:32 +0100 Subject: CFV: New JDK Committer: Nick Gasson In-Reply-To: <041546d5-fb08-602e-351a-b612395dc021@arm.com> References: <041546d5-fb08-602e-351a-b612395dc021@arm.com> Message-ID: Vote: yes Best regards, Tobias On 20.03.20 08:51, Ningsheng Jian wrote: > I hereby nominate Nick Gasson (nick.gasson at arm.com) to JDK committer. > > Nick is a member of Arm JDK team and has contributed 29 changes to JDK project. [3] > > Votes are due by 10:00 GMT, April 3rd, 2020. > > 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, > Ningsheng > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] > http://hg.openjdk.java.net/jdk/jdk/log?revcount=100&rev=desc%28%22nick.gasson%40arm.com%22%29+or+author%28ngasson%29 > > > 8240353: AArch64: missing support for -XX:+ExtendedDTraceProbes in C1 > 8238705: [TESTBUG] jfr/event/gc/stacktrace/TestMetaspace* are stable with Xcomp on AArch64 > 8236634: Memory Access API tests fail on 32-bit > 8237512: AArch64: aarch64TestHook leaks a BufferBlob > 8236992: AArch64: remove redundant load_klass in itable stub > 8237521: Memory Access API fixes for 32-bit > 8236242: Arm32: build broken after 8234794 > 8234794: AArch64: runtime/memory/ReadFromNoaccessArea.java crashes > 8235982: AArch64: Insufficient memory barriers in shadow region algorithm > 8229912: [TESTBUG] java/net/Socks/SocksIPv6Test fails without IPv6 > 8229118: [TESTBUG] serviceability/sa/ClhsdbFindPC fails on AArch64 > 8224851: AArch64: fix warnings and errors with Clang and GCC 8.3 > 8224853: CDS address sanitizer errors > 8221529: [TESTBUG] Docker tests use old/deprecated image on AArch64 > 8220707: [TESTBUG] serviceability/sa/TestHeapDumpForLargeArray.java fails with jtreg -vmoption:-Xmx > < 8g > 8220451: jdi/EventQueue/remove/remove004 failed due to "ERROR: thread2 is not alive" 8220456: > jdi/EventQueue/remove_l/remove_l004 failed due to "TIMEOUT while waiting for event" > 8219628: [TESTBUG] javadoc/doclet/InheritDocForUserTags fails with -othervm > 8209413: AArch64: NPE in clhsdb jstack command > 8217368: AArch64: C2 recursive stack locking optimisation not triggered > 8217427: (dc) nio/channels/DatagramChannel/UseDGWithIPv6.java fails without IPv6 > 8216350: AArch64: monitor unlock fast path not called > 8209414: AArch64: method handle invocation does not respect JVMTI interp_only mode > 8215951: AArch64: jtreg test vmTestbase/nsk/jvmti/PopFrame/popframe005 segfaults > 8215202: AArch64: jtreg test test/jdk/sun/nio/cs/FindEncoderBugs.java fails > 8215100: AArch64: fix compareTo intrinsic with four-character Latin/Unicode > 8214512: ARM32: Jtreg test compiler/c2/Test8062950.java fails on ARM > 8209414: AArch64: method handle invocation does not respect JVMTI interp_only mode > 8214077: test java/io/File/SetLastModified.java fails on ARM32 > 8214078: (fs) SecureDirectoryStream not supported on arm32 From vladimir.x.ivanov at oracle.com Fri Mar 20 09:24:23 2020 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Fri, 20 Mar 2020 12:24:23 +0300 Subject: CFV: New JDK Committer: Nick Gasson In-Reply-To: <041546d5-fb08-602e-351a-b612395dc021@arm.com> References: <041546d5-fb08-602e-351a-b612395dc021@arm.com> Message-ID: Vote: yes Best regards, Vladimir Ivanov On 20.03.2020 10:51, Ningsheng Jian wrote: > I hereby nominate Nick Gasson (nick.gasson at arm.com) to JDK committer. From vladimir.x.ivanov at oracle.com Fri Mar 20 09:24:42 2020 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Fri, 20 Mar 2020 12:24:42 +0300 Subject: CFV: New JDK Committer: Pengfei Li In-Reply-To: <55417a6f-f401-16ab-5dcc-0a93bba6cb03@arm.com> References: <55417a6f-f401-16ab-5dcc-0a93bba6cb03@arm.com> Message-ID: Vote: yes Best regards, Vladimir Ivanov On 20.03.2020 10:54, Ningsheng Jian wrote: > I hereby nominate Pengfei Li (pengfei.li at arm.com) to JDK committer. From felix.yang at huawei.com Fri Mar 20 09:34:48 2020 From: felix.yang at huawei.com (Yangfei (Felix)) Date: Fri, 20 Mar 2020 09:34:48 +0000 Subject: New JDK Committer: Nick Gasson In-Reply-To: <041546d5-fb08-602e-351a-b612395dc021@arm.com> References: <041546d5-fb08-602e-351a-b612395dc021@arm.com> Message-ID: Vote: yes > -----Original Message----- > From: jdk-dev [mailto:jdk-dev-bounces at openjdk.java.net] On Behalf Of > Ningsheng Jian > Sent: Friday, March 20, 2020 3:52 PM > To: jdk-dev at openjdk.java.net > Subject: CFV: New JDK Committer: Nick Gasson > > I hereby nominate Nick Gasson (nick.gasson at arm.com) to JDK committer. > From felix.yang at huawei.com Fri Mar 20 09:34:57 2020 From: felix.yang at huawei.com (Yangfei (Felix)) Date: Fri, 20 Mar 2020 09:34:57 +0000 Subject: New JDK Committer: Pengfei Li In-Reply-To: <55417a6f-f401-16ab-5dcc-0a93bba6cb03@arm.com> References: <55417a6f-f401-16ab-5dcc-0a93bba6cb03@arm.com> Message-ID: Vote: yes > -----Original Message----- > From: jdk-dev [mailto:jdk-dev-bounces at openjdk.java.net] On Behalf Of > Ningsheng Jian > Sent: Friday, March 20, 2020 3:55 PM > To: jdk-dev at openjdk.java.net > Subject: CFV: New JDK Committer: Pengfei Li > > I hereby nominate Pengfei Li (pengfei.li at arm.com) to JDK committer. From dean.long at oracle.com Fri Mar 20 09:45:30 2020 From: dean.long at oracle.com (Dean Long) Date: Fri, 20 Mar 2020 02:45:30 -0700 Subject: CFV: New JDK Committer: Nick Gasson In-Reply-To: <041546d5-fb08-602e-351a-b612395dc021@arm.com> References: <041546d5-fb08-602e-351a-b612395dc021@arm.com> Message-ID: <56e0c52c-04c1-a62d-e578-2879e5ac2cf6@oracle.com> Vote: yes On 3/20/20 12:51 AM, Ningsheng Jian wrote: > I hereby nominate Nick Gasson (nick.gasson at arm.com) to JDK committer. > > Nick is a member of Arm JDK team and has contributed 29 changes to JDK > project. [3] > > Votes are due by 10:00 GMT, April 3rd, 2020. > > 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, > Ningsheng > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] > http://hg.openjdk.java.net/jdk/jdk/log?revcount=100&rev=desc%28%22nick.gasson%40arm.com%22%29+or+author%28ngasson%29 > > 8240353: AArch64: missing support for -XX:+ExtendedDTraceProbes in C1 > 8238705: [TESTBUG] jfr/event/gc/stacktrace/TestMetaspace* are stable > with Xcomp on AArch64 > 8236634: Memory Access API tests fail on 32-bit > 8237512: AArch64: aarch64TestHook leaks a BufferBlob > 8236992: AArch64: remove redundant load_klass in itable stub > 8237521: Memory Access API fixes for 32-bit > 8236242: Arm32: build broken after 8234794 > 8234794: AArch64: runtime/memory/ReadFromNoaccessArea.java crashes > 8235982: AArch64: Insufficient memory barriers in shadow region algorithm > 8229912: [TESTBUG] java/net/Socks/SocksIPv6Test fails without IPv6 > 8229118: [TESTBUG] serviceability/sa/ClhsdbFindPC fails on AArch64 > 8224851: AArch64: fix warnings and errors with Clang and GCC 8.3 > 8224853: CDS address sanitizer errors > 8221529: [TESTBUG] Docker tests use old/deprecated image on AArch64 > 8220707: [TESTBUG] serviceability/sa/TestHeapDumpForLargeArray.java > fails with jtreg -vmoption:-Xmx < 8g > 8220451: jdi/EventQueue/remove/remove004 failed due to "ERROR: thread2 > is not alive" 8220456: jdi/EventQueue/remove_l/remove_l004 failed due > to "TIMEOUT while waiting for event" > 8219628: [TESTBUG] javadoc/doclet/InheritDocForUserTags fails with > -othervm > 8209413: AArch64: NPE in clhsdb jstack command > 8217368: AArch64: C2 recursive stack locking optimisation not triggered > 8217427: (dc) nio/channels/DatagramChannel/UseDGWithIPv6.java fails > without IPv6 > 8216350: AArch64: monitor unlock fast path not called > 8209414: AArch64: method handle invocation does not respect JVMTI > interp_only mode > 8215951: AArch64: jtreg test vmTestbase/nsk/jvmti/PopFrame/popframe005 > segfaults > 8215202: AArch64: jtreg test test/jdk/sun/nio/cs/FindEncoderBugs.java > fails > 8215100: AArch64: fix compareTo intrinsic with four-character > Latin/Unicode > 8214512: ARM32: Jtreg test compiler/c2/Test8062950.java fails on ARM > 8209414: AArch64: method handle invocation does not respect JVMTI > interp_only mode > 8214077: test java/io/File/SetLastModified.java fails on ARM32 > 8214078: (fs) SecureDirectoryStream not supported on arm32 From dean.long at oracle.com Fri Mar 20 09:46:18 2020 From: dean.long at oracle.com (Dean Long) Date: Fri, 20 Mar 2020 02:46:18 -0700 Subject: CFV: New JDK Committer: Pengfei Li In-Reply-To: <55417a6f-f401-16ab-5dcc-0a93bba6cb03@arm.com> References: <55417a6f-f401-16ab-5dcc-0a93bba6cb03@arm.com> Message-ID: <32d1c426-484c-6ed9-fe99-aec407eb757a@oracle.com> Vote: yes On 3/20/20 12:54 AM, Ningsheng Jian wrote: > I hereby nominate Pengfei Li (pengfei.li at arm.com) to JDK committer. > > Pengfei is a member of Arm JDK team and has contributed 20 changes to > JDK project. [3] > > Votes are due by 10:00 GMT, April 3rd, 2020. > > 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, > Ningsheng > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] > http://hg.openjdk.java.net/jdk/jdk/log?revcount=100&rev=desc%28%22pengfei.li%40arm.com%22%29+or+%28user%28%22pli%22%29+and+not+%28user%28%22pliden%22%29%29%29 > > 8239549: AArch64: Backend support for MulAddVS2VI node > 8237524: AArch64: String.compareTo() may return incorrect result > 8232591: AArch64: Add missing match rules for smaddl, smsubl and smnegl > 8233743: AArch64: Make r27 conditionally allocatable > 8234791: Fix Client VM build for x86_64 and AArch64 > 8230591: AArch64: Missing intrinsics for Math.ceil, floor, rint > 8228601: AArch64: Fix interpreter code at JVMCI deoptimization entry > 8227512: [TESTBUG] Fix JTReg javac test failures with Graal > 8226222: [JVMCI] Export AArch64 field VM_Version::_psr_info.dczid_el0 > 8223427: [TESTBUG] Disable JTReg Shenandoah tests when Graal is enabled > 8223054: [TESTBUG] Put graalJarsCP before existing classpath in > GraalUnitTestLauncher > 8214922: Add vectorization support for fmin/fmax > 8216259: AArch64: Vectorize Adler32 intrinsics > 8218550: Add test omitted from JDK-8212043 > 8212043: Add floating-point Math.min/max intrinsics > 8211333: AArch64: Fix another build failure after JDK-8211029 > 8210413: AArch64: Optimize div/rem by constant in C1 > 8210152: Optimize integer divisible by power-of-2 check > 8209783: AArch64: Combine Multiply and Neg operations in C2 > 8208623: [TESTBUG] runtime/LoadClass/LongBCP.java fails in AUFS file > system From Alan.Bateman at oracle.com Fri Mar 20 09:52:17 2020 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 20 Mar 2020 02:52:17 -0700 (PDT) Subject: CFV: New JDK Committer: Nick Gasson In-Reply-To: <041546d5-fb08-602e-351a-b612395dc021@arm.com> References: <041546d5-fb08-602e-351a-b612395dc021@arm.com> Message-ID: Vote: yes From magnus.ihse.bursie at oracle.com Fri Mar 20 10:12:26 2020 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 20 Mar 2020 11:12:26 +0100 Subject: CFV: New JDK Committer: Nick Gasson In-Reply-To: <041546d5-fb08-602e-351a-b612395dc021@arm.com> References: <041546d5-fb08-602e-351a-b612395dc021@arm.com> Message-ID: Vote: yes /Magnus On 2020-03-20 08:51, Ningsheng Jian wrote: > I hereby nominate Nick Gasson (nick.gasson at arm.com) to JDK committer. > > Nick is a member of Arm JDK team and has contributed 29 changes to JDK > project. [3] > > Votes are due by 10:00 GMT, April 3rd, 2020. > > 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, > Ningsheng > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] > http://hg.openjdk.java.net/jdk/jdk/log?revcount=100&rev=desc%28%22nick.gasson%40arm.com%22%29+or+author%28ngasson%29 > > 8240353: AArch64: missing support for -XX:+ExtendedDTraceProbes in C1 > 8238705: [TESTBUG] jfr/event/gc/stacktrace/TestMetaspace* are stable > with Xcomp on AArch64 > 8236634: Memory Access API tests fail on 32-bit > 8237512: AArch64: aarch64TestHook leaks a BufferBlob > 8236992: AArch64: remove redundant load_klass in itable stub > 8237521: Memory Access API fixes for 32-bit > 8236242: Arm32: build broken after 8234794 > 8234794: AArch64: runtime/memory/ReadFromNoaccessArea.java crashes > 8235982: AArch64: Insufficient memory barriers in shadow region algorithm > 8229912: [TESTBUG] java/net/Socks/SocksIPv6Test fails without IPv6 > 8229118: [TESTBUG] serviceability/sa/ClhsdbFindPC fails on AArch64 > 8224851: AArch64: fix warnings and errors with Clang and GCC 8.3 > 8224853: CDS address sanitizer errors > 8221529: [TESTBUG] Docker tests use old/deprecated image on AArch64 > 8220707: [TESTBUG] serviceability/sa/TestHeapDumpForLargeArray.java > fails with jtreg -vmoption:-Xmx < 8g > 8220451: jdi/EventQueue/remove/remove004 failed due to "ERROR: thread2 > is not alive" 8220456: jdi/EventQueue/remove_l/remove_l004 failed due > to "TIMEOUT while waiting for event" > 8219628: [TESTBUG] javadoc/doclet/InheritDocForUserTags fails with > -othervm > 8209413: AArch64: NPE in clhsdb jstack command > 8217368: AArch64: C2 recursive stack locking optimisation not triggered > 8217427: (dc) nio/channels/DatagramChannel/UseDGWithIPv6.java fails > without IPv6 > 8216350: AArch64: monitor unlock fast path not called > 8209414: AArch64: method handle invocation does not respect JVMTI > interp_only mode > 8215951: AArch64: jtreg test vmTestbase/nsk/jvmti/PopFrame/popframe005 > segfaults > 8215202: AArch64: jtreg test test/jdk/sun/nio/cs/FindEncoderBugs.java > fails > 8215100: AArch64: fix compareTo intrinsic with four-character > Latin/Unicode > 8214512: ARM32: Jtreg test compiler/c2/Test8062950.java fails on ARM > 8209414: AArch64: method handle invocation does not respect JVMTI > interp_only mode > 8214077: test java/io/File/SetLastModified.java fails on ARM32 > 8214078: (fs) SecureDirectoryStream not supported on arm32 From thomas.schatzl at oracle.com Fri Mar 20 10:20:24 2020 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Fri, 20 Mar 2020 11:20:24 +0100 Subject: CFV: New JDK Committer: Nick Gasson In-Reply-To: <041546d5-fb08-602e-351a-b612395dc021@arm.com> References: <041546d5-fb08-602e-351a-b612395dc021@arm.com> Message-ID: <44c6db57-5f44-d280-acd8-30e3b70d9c2d@oracle.com> Vote: yes From thomas.schatzl at oracle.com Fri Mar 20 10:20:48 2020 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Fri, 20 Mar 2020 11:20:48 +0100 Subject: CFV: New JDK Committer: Pengfei Li In-Reply-To: <55417a6f-f401-16ab-5dcc-0a93bba6cb03@arm.com> References: <55417a6f-f401-16ab-5dcc-0a93bba6cb03@arm.com> Message-ID: Vote: yes On 20.03.20 08:54, Ningsheng Jian wrote: > I hereby nominate Pengfei Li (pengfei.li at arm.com) to JDK committer. From zgu at redhat.com Fri Mar 20 12:32:43 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Fri, 20 Mar 2020 08:32:43 -0400 Subject: CFV: New JDK Committer: Nick Gasson In-Reply-To: <041546d5-fb08-602e-351a-b612395dc021@arm.com> References: <041546d5-fb08-602e-351a-b612395dc021@arm.com> Message-ID: Vote: yes -Zhengyu On 3/20/20 3:51 AM, Ningsheng Jian wrote: > I hereby nominate Nick Gasson (nick.gasson at arm.com) to JDK committer. > > Nick is a member of Arm JDK team and has contributed 29 changes to JDK > project. [3] > > Votes are due by 10:00 GMT, April 3rd, 2020. > > 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, > Ningsheng > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] > http://hg.openjdk.java.net/jdk/jdk/log?revcount=100&rev=desc%28%22nick.gasson%40arm.com%22%29+or+author%28ngasson%29 > > > 8240353: AArch64: missing support for -XX:+ExtendedDTraceProbes in C1 > 8238705: [TESTBUG] jfr/event/gc/stacktrace/TestMetaspace* are stable > with Xcomp on AArch64 > 8236634: Memory Access API tests fail on 32-bit > 8237512: AArch64: aarch64TestHook leaks a BufferBlob > 8236992: AArch64: remove redundant load_klass in itable stub > 8237521: Memory Access API fixes for 32-bit > 8236242: Arm32: build broken after 8234794 > 8234794: AArch64: runtime/memory/ReadFromNoaccessArea.java crashes > 8235982: AArch64: Insufficient memory barriers in shadow region algorithm > 8229912: [TESTBUG] java/net/Socks/SocksIPv6Test fails without IPv6 > 8229118: [TESTBUG] serviceability/sa/ClhsdbFindPC fails on AArch64 > 8224851: AArch64: fix warnings and errors with Clang and GCC 8.3 > 8224853: CDS address sanitizer errors > 8221529: [TESTBUG] Docker tests use old/deprecated image on AArch64 > 8220707: [TESTBUG] serviceability/sa/TestHeapDumpForLargeArray.java > fails with jtreg -vmoption:-Xmx < 8g > 8220451: jdi/EventQueue/remove/remove004 failed due to "ERROR: thread2 > is not alive" 8220456: jdi/EventQueue/remove_l/remove_l004 failed due to > "TIMEOUT while waiting for event" > 8219628: [TESTBUG] javadoc/doclet/InheritDocForUserTags fails with -othervm > 8209413: AArch64: NPE in clhsdb jstack command > 8217368: AArch64: C2 recursive stack locking optimisation not triggered > 8217427: (dc) nio/channels/DatagramChannel/UseDGWithIPv6.java fails > without IPv6 > 8216350: AArch64: monitor unlock fast path not called > 8209414: AArch64: method handle invocation does not respect JVMTI > interp_only mode > 8215951: AArch64: jtreg test vmTestbase/nsk/jvmti/PopFrame/popframe005 > segfaults > 8215202: AArch64: jtreg test test/jdk/sun/nio/cs/FindEncoderBugs.java fails > 8215100: AArch64: fix compareTo intrinsic with four-character Latin/Unicode > 8214512: ARM32: Jtreg test compiler/c2/Test8062950.java fails on ARM > 8209414: AArch64: method handle invocation does not respect JVMTI > interp_only mode > 8214077: test java/io/File/SetLastModified.java fails on ARM32 > 8214078: (fs) SecureDirectoryStream not supported on arm32 > From zgu at redhat.com Fri Mar 20 12:33:01 2020 From: zgu at redhat.com (Zhengyu Gu) Date: Fri, 20 Mar 2020 08:33:01 -0400 Subject: CFV: New JDK Committer: Pengfei Li In-Reply-To: <55417a6f-f401-16ab-5dcc-0a93bba6cb03@arm.com> References: <55417a6f-f401-16ab-5dcc-0a93bba6cb03@arm.com> Message-ID: Vote: yes -Zhengyu On 3/20/20 3:54 AM, Ningsheng Jian wrote: > I hereby nominate Pengfei Li (pengfei.li at arm.com) to JDK committer. > > Pengfei is a member of Arm JDK team and has contributed 20 changes to > JDK project. [3] > > Votes are due by 10:00 GMT, April 3rd, 2020. > > 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, > Ningsheng > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] > http://hg.openjdk.java.net/jdk/jdk/log?revcount=100&rev=desc%28%22pengfei.li%40arm.com%22%29+or+%28user%28%22pli%22%29+and+not+%28user%28%22pliden%22%29%29%29 > > > 8239549: AArch64: Backend support for MulAddVS2VI node > 8237524: AArch64: String.compareTo() may return incorrect result > 8232591: AArch64: Add missing match rules for smaddl, smsubl and smnegl > 8233743: AArch64: Make r27 conditionally allocatable > 8234791: Fix Client VM build for x86_64 and AArch64 > 8230591: AArch64: Missing intrinsics for Math.ceil, floor, rint > 8228601: AArch64: Fix interpreter code at JVMCI deoptimization entry > 8227512: [TESTBUG] Fix JTReg javac test failures with Graal > 8226222: [JVMCI] Export AArch64 field VM_Version::_psr_info.dczid_el0 > 8223427: [TESTBUG] Disable JTReg Shenandoah tests when Graal is enabled > 8223054: [TESTBUG] Put graalJarsCP before existing classpath in > GraalUnitTestLauncher > 8214922: Add vectorization support for fmin/fmax > 8216259: AArch64: Vectorize Adler32 intrinsics > 8218550: Add test omitted from JDK-8212043 > 8212043: Add floating-point Math.min/max intrinsics > 8211333: AArch64: Fix another build failure after JDK-8211029 > 8210413: AArch64: Optimize div/rem by constant in C1 > 8210152: Optimize integer divisible by power-of-2 check > 8209783: AArch64: Combine Multiply and Neg operations in C2 > 8208623: [TESTBUG] runtime/LoadClass/LongBCP.java fails in AUFS file system > From jamsheed.c.m at oracle.com Fri Mar 20 12:51:28 2020 From: jamsheed.c.m at oracle.com (Jamsheed C M) Date: Fri, 20 Mar 2020 18:21:28 +0530 Subject: CFV: New JDK Committer: Nick Gasson In-Reply-To: <041546d5-fb08-602e-351a-b612395dc021@arm.com> References: <041546d5-fb08-602e-351a-b612395dc021@arm.com> Message-ID: <5115df16-61a3-7fb3-2cc2-12544d4e25f1@oracle.com> Vote: Yes Best regards, Jamsheed On 20/03/2020 13:21, Ningsheng Jian wrote: > I hereby nominate Nick Gasson (nick.gasson at arm.com) to JDK committer. > > Nick is a member of Arm JDK team and has contributed 29 changes to JDK > project. [3] > > Votes are due by 10:00 GMT, April 3rd, 2020. > > 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, > Ningsheng > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] > http://hg.openjdk.java.net/jdk/jdk/log?revcount=100&rev=desc%28%22nick.gasson%40arm.com%22%29+or+author%28ngasson%29 > > 8240353: AArch64: missing support for -XX:+ExtendedDTraceProbes in C1 > 8238705: [TESTBUG] jfr/event/gc/stacktrace/TestMetaspace* are stable > with Xcomp on AArch64 > 8236634: Memory Access API tests fail on 32-bit > 8237512: AArch64: aarch64TestHook leaks a BufferBlob > 8236992: AArch64: remove redundant load_klass in itable stub > 8237521: Memory Access API fixes for 32-bit > 8236242: Arm32: build broken after 8234794 > 8234794: AArch64: runtime/memory/ReadFromNoaccessArea.java crashes > 8235982: AArch64: Insufficient memory barriers in shadow region algorithm > 8229912: [TESTBUG] java/net/Socks/SocksIPv6Test fails without IPv6 > 8229118: [TESTBUG] serviceability/sa/ClhsdbFindPC fails on AArch64 > 8224851: AArch64: fix warnings and errors with Clang and GCC 8.3 > 8224853: CDS address sanitizer errors > 8221529: [TESTBUG] Docker tests use old/deprecated image on AArch64 > 8220707: [TESTBUG] serviceability/sa/TestHeapDumpForLargeArray.java > fails with jtreg -vmoption:-Xmx < 8g > 8220451: jdi/EventQueue/remove/remove004 failed due to "ERROR: thread2 > is not alive" 8220456: jdi/EventQueue/remove_l/remove_l004 failed due > to "TIMEOUT while waiting for event" > 8219628: [TESTBUG] javadoc/doclet/InheritDocForUserTags fails with > -othervm > 8209413: AArch64: NPE in clhsdb jstack command > 8217368: AArch64: C2 recursive stack locking optimisation not triggered > 8217427: (dc) nio/channels/DatagramChannel/UseDGWithIPv6.java fails > without IPv6 > 8216350: AArch64: monitor unlock fast path not called > 8209414: AArch64: method handle invocation does not respect JVMTI > interp_only mode > 8215951: AArch64: jtreg test vmTestbase/nsk/jvmti/PopFrame/popframe005 > segfaults > 8215202: AArch64: jtreg test test/jdk/sun/nio/cs/FindEncoderBugs.java > fails > 8215100: AArch64: fix compareTo intrinsic with four-character > Latin/Unicode > 8214512: ARM32: Jtreg test compiler/c2/Test8062950.java fails on ARM > 8209414: AArch64: method handle invocation does not respect JVMTI > interp_only mode > 8214077: test java/io/File/SetLastModified.java fails on ARM32 > 8214078: (fs) SecureDirectoryStream not supported on arm32 From jamsheed.c.m at oracle.com Fri Mar 20 12:53:55 2020 From: jamsheed.c.m at oracle.com (Jamsheed C M) Date: Fri, 20 Mar 2020 18:23:55 +0530 Subject: CFV: New JDK Committer: Pengfei Li In-Reply-To: <55417a6f-f401-16ab-5dcc-0a93bba6cb03@arm.com> References: <55417a6f-f401-16ab-5dcc-0a93bba6cb03@arm.com> Message-ID: <98b64763-3289-22ea-e066-6dd08ea46921@oracle.com> Vote: Yes Best regards, Jamsheed On 20/03/2020 13:24, Ningsheng Jian wrote: > I hereby nominate Pengfei Li (pengfei.li at arm.com) to JDK committer. > > Pengfei is a member of Arm JDK team and has contributed 20 changes to > JDK project. [3] > > Votes are due by 10:00 GMT, April 3rd, 2020. > > 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, > Ningsheng > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] > http://hg.openjdk.java.net/jdk/jdk/log?revcount=100&rev=desc%28%22pengfei.li%40arm.com%22%29+or+%28user%28%22pli%22%29+and+not+%28user%28%22pliden%22%29%29%29 > > 8239549: AArch64: Backend support for MulAddVS2VI node > 8237524: AArch64: String.compareTo() may return incorrect result > 8232591: AArch64: Add missing match rules for smaddl, smsubl and smnegl > 8233743: AArch64: Make r27 conditionally allocatable > 8234791: Fix Client VM build for x86_64 and AArch64 > 8230591: AArch64: Missing intrinsics for Math.ceil, floor, rint > 8228601: AArch64: Fix interpreter code at JVMCI deoptimization entry > 8227512: [TESTBUG] Fix JTReg javac test failures with Graal > 8226222: [JVMCI] Export AArch64 field VM_Version::_psr_info.dczid_el0 > 8223427: [TESTBUG] Disable JTReg Shenandoah tests when Graal is enabled > 8223054: [TESTBUG] Put graalJarsCP before existing classpath in > GraalUnitTestLauncher > 8214922: Add vectorization support for fmin/fmax > 8216259: AArch64: Vectorize Adler32 intrinsics > 8218550: Add test omitted from JDK-8212043 > 8212043: Add floating-point Math.min/max intrinsics > 8211333: AArch64: Fix another build failure after JDK-8211029 > 8210413: AArch64: Optimize div/rem by constant in C1 > 8210152: Optimize integer divisible by power-of-2 check > 8209783: AArch64: Combine Multiply and Neg operations in C2 > 8208623: [TESTBUG] runtime/LoadClass/LongBCP.java fails in AUFS file > system From Roger.Riggs at oracle.com Fri Mar 20 13:48:45 2020 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Fri, 20 Mar 2020 09:48:45 -0400 Subject: CFV: New JDK Committer: Pengfei Li In-Reply-To: <55417a6f-f401-16ab-5dcc-0a93bba6cb03@arm.com> References: <55417a6f-f401-16ab-5dcc-0a93bba6cb03@arm.com> Message-ID: <59b60534-0890-44b4-6ff6-5c4f7138d9f0@oracle.com> Vote: Yes On 3/20/20 3:54 AM, Ningsheng Jian wrote: > I hereby nominate Pengfei Li (pengfei.li at arm.com) to JDK committer. From Roger.Riggs at oracle.com Fri Mar 20 13:49:15 2020 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Fri, 20 Mar 2020 09:49:15 -0400 Subject: CFV: New JDK Committer: Nick Gasson In-Reply-To: <041546d5-fb08-602e-351a-b612395dc021@arm.com> References: <041546d5-fb08-602e-351a-b612395dc021@arm.com> Message-ID: <10ef950a-c88e-c04c-1035-4751dd32c4b3@oracle.com> Vote: Yes On 3/20/20 3:51 AM, Ningsheng Jian wrote: > I hereby nominate Nick Gasson (nick.gasson at arm.com) to JDK committer. From magnus.ihse.bursie at oracle.com Fri Mar 20 13:57:49 2020 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 20 Mar 2020 14:57:49 +0100 Subject: CFV: New JDK Committer: Pengfei Li In-Reply-To: <55417a6f-f401-16ab-5dcc-0a93bba6cb03@arm.com> References: <55417a6f-f401-16ab-5dcc-0a93bba6cb03@arm.com> Message-ID: <99168d49-8fd3-b719-0bcb-2eae44829260@oracle.com> Vote: yes /Magnus On 2020-03-20 08:54, Ningsheng Jian wrote: > I hereby nominate Pengfei Li (pengfei.li at arm.com) to JDK committer. > > Pengfei is a member of Arm JDK team and has contributed 20 changes to > JDK project. [3] > > Votes are due by 10:00 GMT, April 3rd, 2020. > > 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, > Ningsheng > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] > http://hg.openjdk.java.net/jdk/jdk/log?revcount=100&rev=desc%28%22pengfei.li%40arm.com%22%29+or+%28user%28%22pli%22%29+and+not+%28user%28%22pliden%22%29%29%29 > > 8239549: AArch64: Backend support for MulAddVS2VI node > 8237524: AArch64: String.compareTo() may return incorrect result > 8232591: AArch64: Add missing match rules for smaddl, smsubl and smnegl > 8233743: AArch64: Make r27 conditionally allocatable > 8234791: Fix Client VM build for x86_64 and AArch64 > 8230591: AArch64: Missing intrinsics for Math.ceil, floor, rint > 8228601: AArch64: Fix interpreter code at JVMCI deoptimization entry > 8227512: [TESTBUG] Fix JTReg javac test failures with Graal > 8226222: [JVMCI] Export AArch64 field VM_Version::_psr_info.dczid_el0 > 8223427: [TESTBUG] Disable JTReg Shenandoah tests when Graal is enabled > 8223054: [TESTBUG] Put graalJarsCP before existing classpath in > GraalUnitTestLauncher > 8214922: Add vectorization support for fmin/fmax > 8216259: AArch64: Vectorize Adler32 intrinsics > 8218550: Add test omitted from JDK-8212043 > 8212043: Add floating-point Math.min/max intrinsics > 8211333: AArch64: Fix another build failure after JDK-8211029 > 8210413: AArch64: Optimize div/rem by constant in C1 > 8210152: Optimize integer divisible by power-of-2 check > 8209783: AArch64: Combine Multiply and Neg operations in C2 > 8208623: [TESTBUG] runtime/LoadClass/LongBCP.java fails in AUFS file > system From christoph.langer at sap.com Fri Mar 20 14:03:57 2020 From: christoph.langer at sap.com (Langer, Christoph) Date: Fri, 20 Mar 2020 14:03:57 +0000 Subject: CFV: New JDK Committer: Nick Gasson In-Reply-To: <041546d5-fb08-602e-351a-b612395dc021@arm.com> References: <041546d5-fb08-602e-351a-b612395dc021@arm.com> Message-ID: Vote:yes /Christoph > -----Original Message----- > From: jdk-dev On Behalf Of > Ningsheng Jian > Sent: Freitag, 20. M?rz 2020 08:52 > To: jdk-dev at openjdk.java.net > Subject: CFV: New JDK Committer: Nick Gasson > > I hereby nominate Nick Gasson (nick.gasson at arm.com) to JDK committer. > > Nick is a member of Arm JDK team and has contributed 29 changes to JDK > project. [3] > > Votes are due by 10:00 GMT, April 3rd, 2020. > > 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, > Ningsheng > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] > http://hg.openjdk.java.net/jdk/jdk/log?revcount=100&rev=desc%28%22nic > k.gasson%40arm.com%22%29+or+author%28ngasson%29 > > 8240353: AArch64: missing support for -XX:+ExtendedDTraceProbes in C1 > 8238705: [TESTBUG] jfr/event/gc/stacktrace/TestMetaspace* are stable > with Xcomp on AArch64 > 8236634: Memory Access API tests fail on 32-bit > 8237512: AArch64: aarch64TestHook leaks a BufferBlob > 8236992: AArch64: remove redundant load_klass in itable stub > 8237521: Memory Access API fixes for 32-bit > 8236242: Arm32: build broken after 8234794 > 8234794: AArch64: runtime/memory/ReadFromNoaccessArea.java crashes > 8235982: AArch64: Insufficient memory barriers in shadow region algorithm > 8229912: [TESTBUG] java/net/Socks/SocksIPv6Test fails without IPv6 > 8229118: [TESTBUG] serviceability/sa/ClhsdbFindPC fails on AArch64 > 8224851: AArch64: fix warnings and errors with Clang and GCC 8.3 > 8224853: CDS address sanitizer errors > 8221529: [TESTBUG] Docker tests use old/deprecated image on AArch64 > 8220707: [TESTBUG] serviceability/sa/TestHeapDumpForLargeArray.java > fails with jtreg -vmoption:-Xmx < 8g > 8220451: jdi/EventQueue/remove/remove004 failed due to "ERROR: thread2 > is not alive" 8220456: jdi/EventQueue/remove_l/remove_l004 failed due to > "TIMEOUT while waiting for event" > 8219628: [TESTBUG] javadoc/doclet/InheritDocForUserTags fails with - > othervm > 8209413: AArch64: NPE in clhsdb jstack command > 8217368: AArch64: C2 recursive stack locking optimisation not triggered > 8217427: (dc) nio/channels/DatagramChannel/UseDGWithIPv6.java fails > without IPv6 > 8216350: AArch64: monitor unlock fast path not called > 8209414: AArch64: method handle invocation does not respect JVMTI > interp_only mode > 8215951: AArch64: jtreg test vmTestbase/nsk/jvmti/PopFrame/popframe005 > segfaults > 8215202: AArch64: jtreg test test/jdk/sun/nio/cs/FindEncoderBugs.java fails > 8215100: AArch64: fix compareTo intrinsic with four-character Latin/Unicode > 8214512: ARM32: Jtreg test compiler/c2/Test8062950.java fails on ARM > 8209414: AArch64: method handle invocation does not respect JVMTI > interp_only mode > 8214077: test java/io/File/SetLastModified.java fails on ARM32 > 8214078: (fs) SecureDirectoryStream not supported on arm32 From christoph.langer at sap.com Fri Mar 20 14:04:10 2020 From: christoph.langer at sap.com (Langer, Christoph) Date: Fri, 20 Mar 2020 14:04:10 +0000 Subject: CFV: New JDK Committer: Pengfei Li In-Reply-To: <55417a6f-f401-16ab-5dcc-0a93bba6cb03@arm.com> References: <55417a6f-f401-16ab-5dcc-0a93bba6cb03@arm.com> Message-ID: Vote:yes /Christoph > -----Original Message----- > From: jdk-dev On Behalf Of > Ningsheng Jian > Sent: Freitag, 20. M?rz 2020 08:55 > To: jdk-dev at openjdk.java.net > Subject: CFV: New JDK Committer: Pengfei Li > > I hereby nominate Pengfei Li (pengfei.li at arm.com) to JDK committer. > > Pengfei is a member of Arm JDK team and has contributed 20 changes to > JDK project. [3] > > Votes are due by 10:00 GMT, April 3rd, 2020. > > 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, > Ningsheng > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] > http://hg.openjdk.java.net/jdk/jdk/log?revcount=100&rev=desc%28%22pe > ngfei.li%40arm.com%22%29+or+%28user%28%22pli%22%29+and+not+%28u > ser%28%22pliden%22%29%29%29 > > 8239549: AArch64: Backend support for MulAddVS2VI node > 8237524: AArch64: String.compareTo() may return incorrect result > 8232591: AArch64: Add missing match rules for smaddl, smsubl and smnegl > 8233743: AArch64: Make r27 conditionally allocatable > 8234791: Fix Client VM build for x86_64 and AArch64 > 8230591: AArch64: Missing intrinsics for Math.ceil, floor, rint > 8228601: AArch64: Fix interpreter code at JVMCI deoptimization entry > 8227512: [TESTBUG] Fix JTReg javac test failures with Graal > 8226222: [JVMCI] Export AArch64 field VM_Version::_psr_info.dczid_el0 > 8223427: [TESTBUG] Disable JTReg Shenandoah tests when Graal is enabled > 8223054: [TESTBUG] Put graalJarsCP before existing classpath in > GraalUnitTestLauncher > 8214922: Add vectorization support for fmin/fmax > 8216259: AArch64: Vectorize Adler32 intrinsics > 8218550: Add test omitted from JDK-8212043 > 8212043: Add floating-point Math.min/max intrinsics > 8211333: AArch64: Fix another build failure after JDK-8211029 > 8210413: AArch64: Optimize div/rem by constant in C1 > 8210152: Optimize integer divisible by power-of-2 check > 8209783: AArch64: Combine Multiply and Neg operations in C2 > 8208623: [TESTBUG] runtime/LoadClass/LongBCP.java fails in AUFS file > system From adinn at redhat.com Fri Mar 20 15:55:01 2020 From: adinn at redhat.com (Andrew Dinn) Date: Fri, 20 Mar 2020 15:55:01 +0000 Subject: CFV: New JDK Committer: Nick Gasson In-Reply-To: <041546d5-fb08-602e-351a-b612395dc021@arm.com> References: <041546d5-fb08-602e-351a-b612395dc021@arm.com> Message-ID: <8c338458-80c1-59b2-1289-2a6a1e695efa@redhat.com> vote: yes On 20/03/2020 07:51, Ningsheng Jian wrote: > I hereby nominate Nick Gasson (nick.gasson at arm.com) to JDK committer. > > Nick is a member of Arm JDK team and has contributed 29 changes to JDK > project. [3] > > Votes are due by 10:00 GMT, April 3rd, 2020. > > 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, > Ningsheng > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] > http://hg.openjdk.java.net/jdk/jdk/log?revcount=100&rev=desc%28%22nick.gasson%40arm.com%22%29+or+author%28ngasson%29 > > > 8240353: AArch64: missing support for -XX:+ExtendedDTraceProbes in C1 > 8238705: [TESTBUG] jfr/event/gc/stacktrace/TestMetaspace* are stable > with Xcomp on AArch64 > 8236634: Memory Access API tests fail on 32-bit > 8237512: AArch64: aarch64TestHook leaks a BufferBlob > 8236992: AArch64: remove redundant load_klass in itable stub > 8237521: Memory Access API fixes for 32-bit > 8236242: Arm32: build broken after 8234794 > 8234794: AArch64: runtime/memory/ReadFromNoaccessArea.java crashes > 8235982: AArch64: Insufficient memory barriers in shadow region algorithm > 8229912: [TESTBUG] java/net/Socks/SocksIPv6Test fails without IPv6 > 8229118: [TESTBUG] serviceability/sa/ClhsdbFindPC fails on AArch64 > 8224851: AArch64: fix warnings and errors with Clang and GCC 8.3 > 8224853: CDS address sanitizer errors > 8221529: [TESTBUG] Docker tests use old/deprecated image on AArch64 > 8220707: [TESTBUG] serviceability/sa/TestHeapDumpForLargeArray.java > fails with jtreg -vmoption:-Xmx < 8g > 8220451: jdi/EventQueue/remove/remove004 failed due to "ERROR: thread2 > is not alive" 8220456: jdi/EventQueue/remove_l/remove_l004 failed due to > "TIMEOUT while waiting for event" > 8219628: [TESTBUG] javadoc/doclet/InheritDocForUserTags fails with -othervm > 8209413: AArch64: NPE in clhsdb jstack command > 8217368: AArch64: C2 recursive stack locking optimisation not triggered > 8217427: (dc) nio/channels/DatagramChannel/UseDGWithIPv6.java fails > without IPv6 > 8216350: AArch64: monitor unlock fast path not called > 8209414: AArch64: method handle invocation does not respect JVMTI > interp_only mode > 8215951: AArch64: jtreg test vmTestbase/nsk/jvmti/PopFrame/popframe005 > segfaults > 8215202: AArch64: jtreg test test/jdk/sun/nio/cs/FindEncoderBugs.java fails > 8215100: AArch64: fix compareTo intrinsic with four-character Latin/Unicode > 8214512: ARM32: Jtreg test compiler/c2/Test8062950.java fails on ARM > 8209414: AArch64: method handle invocation does not respect JVMTI > interp_only mode > 8214077: test java/io/File/SetLastModified.java fails on ARM32 > 8214078: (fs) SecureDirectoryStream not supported on arm32 > -- 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 From adinn at redhat.com Fri Mar 20 15:55:30 2020 From: adinn at redhat.com (Andrew Dinn) Date: Fri, 20 Mar 2020 15:55:30 +0000 Subject: CFV: New JDK Committer: Pengfei Li In-Reply-To: <55417a6f-f401-16ab-5dcc-0a93bba6cb03@arm.com> References: <55417a6f-f401-16ab-5dcc-0a93bba6cb03@arm.com> Message-ID: <203d6fb3-05c7-b17a-ffe0-9aa6f680c96f@redhat.com> Vote: yes On 20/03/2020 07:54, Ningsheng Jian wrote: > I hereby nominate Pengfei Li (pengfei.li at arm.com) to JDK committer. > > Pengfei is a member of Arm JDK team and has contributed 20 changes to > JDK project. [3] > > Votes are due by 10:00 GMT, April 3rd, 2020. > > 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, > Ningsheng > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] > http://hg.openjdk.java.net/jdk/jdk/log?revcount=100&rev=desc%28%22pengfei.li%40arm.com%22%29+or+%28user%28%22pli%22%29+and+not+%28user%28%22pliden%22%29%29%29 > > > 8239549: AArch64: Backend support for MulAddVS2VI node > 8237524: AArch64: String.compareTo() may return incorrect result > 8232591: AArch64: Add missing match rules for smaddl, smsubl and smnegl > 8233743: AArch64: Make r27 conditionally allocatable > 8234791: Fix Client VM build for x86_64 and AArch64 > 8230591: AArch64: Missing intrinsics for Math.ceil, floor, rint > 8228601: AArch64: Fix interpreter code at JVMCI deoptimization entry > 8227512: [TESTBUG] Fix JTReg javac test failures with Graal > 8226222: [JVMCI] Export AArch64 field VM_Version::_psr_info.dczid_el0 > 8223427: [TESTBUG] Disable JTReg Shenandoah tests when Graal is enabled > 8223054: [TESTBUG] Put graalJarsCP before existing classpath in > GraalUnitTestLauncher > 8214922: Add vectorization support for fmin/fmax > 8216259: AArch64: Vectorize Adler32 intrinsics > 8218550: Add test omitted from JDK-8212043 > 8212043: Add floating-point Math.min/max intrinsics > 8211333: AArch64: Fix another build failure after JDK-8211029 > 8210413: AArch64: Optimize div/rem by constant in C1 > 8210152: Optimize integer divisible by power-of-2 check > 8209783: AArch64: Combine Multiply and Neg operations in C2 > 8208623: [TESTBUG] runtime/LoadClass/LongBCP.java fails in AUFS file system > -- 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 From jianglizhou at google.com Fri Mar 20 17:26:18 2020 From: jianglizhou at google.com (Jiangli Zhou) Date: Fri, 20 Mar 2020 10:26:18 -0700 Subject: New JDK Committer: Nick Gasson(Internet mail) In-Reply-To: References: <041546d5-fb08-602e-351a-b612395dc021@arm.com> Message-ID: Vote: yes Best Regards, Jiangli > > ?On 2020/3/20, 3:53 PM, "jdk-dev on behalf of Ningsheng Jian" wrote: > > I hereby nominate Nick Gasson (nick.gasson at arm.com) to JDK committer. > > Nick is a member of Arm JDK team and has contributed 29 changes to JDK > project. [3] > > Votes are due by 10:00 GMT, April 3rd, 2020. > > 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, > Ningsheng > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] > http://hg.openjdk.java.net/jdk/jdk/log?revcount=100&rev=desc%28%22nick.gasson%40arm.com%22%29+or+author%28ngasson%29 > > 8240353: AArch64: missing support for -XX:+ExtendedDTraceProbes in C1 > 8238705: [TESTBUG] jfr/event/gc/stacktrace/TestMetaspace* are stable > with Xcomp on AArch64 > 8236634: Memory Access API tests fail on 32-bit > 8237512: AArch64: aarch64TestHook leaks a BufferBlob > 8236992: AArch64: remove redundant load_klass in itable stub > 8237521: Memory Access API fixes for 32-bit > 8236242: Arm32: build broken after 8234794 > 8234794: AArch64: runtime/memory/ReadFromNoaccessArea.java crashes > 8235982: AArch64: Insufficient memory barriers in shadow region algorithm > 8229912: [TESTBUG] java/net/Socks/SocksIPv6Test fails without IPv6 > 8229118: [TESTBUG] serviceability/sa/ClhsdbFindPC fails on AArch64 > 8224851: AArch64: fix warnings and errors with Clang and GCC 8.3 > 8224853: CDS address sanitizer errors > 8221529: [TESTBUG] Docker tests use old/deprecated image on AArch64 > 8220707: [TESTBUG] serviceability/sa/TestHeapDumpForLargeArray.java > fails with jtreg -vmoption:-Xmx < 8g > 8220451: jdi/EventQueue/remove/remove004 failed due to "ERROR: thread2 > is not alive" 8220456: jdi/EventQueue/remove_l/remove_l004 failed due to > "TIMEOUT while waiting for event" > 8219628: [TESTBUG] javadoc/doclet/InheritDocForUserTags fails with -othervm > 8209413: AArch64: NPE in clhsdb jstack command > 8217368: AArch64: C2 recursive stack locking optimisation not triggered > 8217427: (dc) nio/channels/DatagramChannel/UseDGWithIPv6.java fails > without IPv6 > 8216350: AArch64: monitor unlock fast path not called > 8209414: AArch64: method handle invocation does not respect JVMTI > interp_only mode > 8215951: AArch64: jtreg test vmTestbase/nsk/jvmti/PopFrame/popframe005 > segfaults > 8215202: AArch64: jtreg test test/jdk/sun/nio/cs/FindEncoderBugs.java fails > 8215100: AArch64: fix compareTo intrinsic with four-character Latin/Unicode > 8214512: ARM32: Jtreg test compiler/c2/Test8062950.java fails on ARM > 8209414: AArch64: method handle invocation does not respect JVMTI > interp_only mode > 8214077: test java/io/File/SetLastModified.java fails on ARM32 > 8214078: (fs) SecureDirectoryStream not supported on arm32 > > > From jianglizhou at google.com Fri Mar 20 17:27:06 2020 From: jianglizhou at google.com (Jiangli Zhou) Date: Fri, 20 Mar 2020 10:27:06 -0700 Subject: New JDK Committer: Pengfei Li(Internet mail) In-Reply-To: <7423E3E3-70ED-48AC-9302-DBFC2A8E0C48@tencent.com> References: <55417a6f-f401-16ab-5dcc-0a93bba6cb03@arm.com> <7423E3E3-70ED-48AC-9302-DBFC2A8E0C48@tencent.com> Message-ID: Vote: yes Best Regards, Jiangli > > ?On 2020/3/20, 3:56 PM, "jdk-dev on behalf of Ningsheng Jian" wrote: > > I hereby nominate Pengfei Li (pengfei.li at arm.com) to JDK committer. > > Pengfei is a member of Arm JDK team and has contributed 20 changes to > JDK project. [3] > > Votes are due by 10:00 GMT, April 3rd, 2020. > > 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, > Ningsheng > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] > http://hg.openjdk.java.net/jdk/jdk/log?revcount=100&rev=desc%28%22pengfei.li%40arm.com%22%29+or+%28user%28%22pli%22%29+and+not+%28user%28%22pliden%22%29%29%29 > > 8239549: AArch64: Backend support for MulAddVS2VI node > 8237524: AArch64: String.compareTo() may return incorrect result > 8232591: AArch64: Add missing match rules for smaddl, smsubl and smnegl > 8233743: AArch64: Make r27 conditionally allocatable > 8234791: Fix Client VM build for x86_64 and AArch64 > 8230591: AArch64: Missing intrinsics for Math.ceil, floor, rint > 8228601: AArch64: Fix interpreter code at JVMCI deoptimization entry > 8227512: [TESTBUG] Fix JTReg javac test failures with Graal > 8226222: [JVMCI] Export AArch64 field VM_Version::_psr_info.dczid_el0 > 8223427: [TESTBUG] Disable JTReg Shenandoah tests when Graal is enabled > 8223054: [TESTBUG] Put graalJarsCP before existing classpath in > GraalUnitTestLauncher > 8214922: Add vectorization support for fmin/fmax > 8216259: AArch64: Vectorize Adler32 intrinsics > 8218550: Add test omitted from JDK-8212043 > 8212043: Add floating-point Math.min/max intrinsics > 8211333: AArch64: Fix another build failure after JDK-8211029 > 8210413: AArch64: Optimize div/rem by constant in C1 > 8210152: Optimize integer divisible by power-of-2 check > 8209783: AArch64: Combine Multiply and Neg operations in C2 > 8208623: [TESTBUG] runtime/LoadClass/LongBCP.java fails in AUFS file system > > > From vladimir.kozlov at oracle.com Fri Mar 20 17:29:45 2020 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 20 Mar 2020 10:29:45 -0700 Subject: CFV: New JDK Committer: Pengfei Li In-Reply-To: <55417a6f-f401-16ab-5dcc-0a93bba6cb03@arm.com> References: <55417a6f-f401-16ab-5dcc-0a93bba6cb03@arm.com> Message-ID: Vote: yes On 3/20/20 12:54 AM, Ningsheng Jian wrote: > I hereby nominate Pengfei Li (pengfei.li at arm.com) to JDK committer. > > Pengfei is a member of Arm JDK team and has contributed 20 changes to JDK project. [3] > > Votes are due by 10:00 GMT, April 3rd, 2020. > > 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, > Ningsheng > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] > http://hg.openjdk.java.net/jdk/jdk/log?revcount=100&rev=desc%28%22pengfei.li%40arm.com%22%29+or+%28user%28%22pli%22%29+and+not+%28user%28%22pliden%22%29%29%29 > > > 8239549: AArch64: Backend support for MulAddVS2VI node > 8237524: AArch64: String.compareTo() may return incorrect result > 8232591: AArch64: Add missing match rules for smaddl, smsubl and smnegl > 8233743: AArch64: Make r27 conditionally allocatable > 8234791: Fix Client VM build for x86_64 and AArch64 > 8230591: AArch64: Missing intrinsics for Math.ceil, floor, rint > 8228601: AArch64: Fix interpreter code at JVMCI deoptimization entry > 8227512: [TESTBUG] Fix JTReg javac test failures with Graal > 8226222: [JVMCI] Export AArch64 field VM_Version::_psr_info.dczid_el0 > 8223427: [TESTBUG] Disable JTReg Shenandoah tests when Graal is enabled > 8223054: [TESTBUG] Put graalJarsCP before existing classpath in GraalUnitTestLauncher > 8214922: Add vectorization support for fmin/fmax > 8216259: AArch64: Vectorize Adler32 intrinsics > 8218550: Add test omitted from JDK-8212043 > 8212043: Add floating-point Math.min/max intrinsics > 8211333: AArch64: Fix another build failure after JDK-8211029 > 8210413: AArch64: Optimize div/rem by constant in C1 > 8210152: Optimize integer divisible by power-of-2 check > 8209783: AArch64: Combine Multiply and Neg operations in C2 > 8208623: [TESTBUG] runtime/LoadClass/LongBCP.java fails in AUFS file system From vladimir.kozlov at oracle.com Fri Mar 20 17:30:25 2020 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 20 Mar 2020 10:30:25 -0700 Subject: CFV: New JDK Committer: Nick Gasson In-Reply-To: <041546d5-fb08-602e-351a-b612395dc021@arm.com> References: <041546d5-fb08-602e-351a-b612395dc021@arm.com> Message-ID: Vote: yes On 3/20/20 12:51 AM, Ningsheng Jian wrote: > I hereby nominate Nick Gasson (nick.gasson at arm.com) to JDK committer. > > Nick is a member of Arm JDK team and has contributed 29 changes to JDK project. [3] > > Votes are due by 10:00 GMT, April 3rd, 2020. > > 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, > Ningsheng > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] http://hg.openjdk.java.net/jdk/jdk/log?revcount=100&rev=desc%28%22nick.gasson%40arm.com%22%29+or+author%28ngasson%29 > > 8240353: AArch64: missing support for -XX:+ExtendedDTraceProbes in C1 > 8238705: [TESTBUG] jfr/event/gc/stacktrace/TestMetaspace* are stable with Xcomp on AArch64 > 8236634: Memory Access API tests fail on 32-bit > 8237512: AArch64: aarch64TestHook leaks a BufferBlob > 8236992: AArch64: remove redundant load_klass in itable stub > 8237521: Memory Access API fixes for 32-bit > 8236242: Arm32: build broken after 8234794 > 8234794: AArch64: runtime/memory/ReadFromNoaccessArea.java crashes > 8235982: AArch64: Insufficient memory barriers in shadow region algorithm > 8229912: [TESTBUG] java/net/Socks/SocksIPv6Test fails without IPv6 > 8229118: [TESTBUG] serviceability/sa/ClhsdbFindPC fails on AArch64 > 8224851: AArch64: fix warnings and errors with Clang and GCC 8.3 > 8224853: CDS address sanitizer errors > 8221529: [TESTBUG] Docker tests use old/deprecated image on AArch64 > 8220707: [TESTBUG] serviceability/sa/TestHeapDumpForLargeArray.java fails with jtreg -vmoption:-Xmx < 8g > 8220451: jdi/EventQueue/remove/remove004 failed due to "ERROR: thread2 is not alive" 8220456: > jdi/EventQueue/remove_l/remove_l004 failed due to "TIMEOUT while waiting for event" > 8219628: [TESTBUG] javadoc/doclet/InheritDocForUserTags fails with -othervm > 8209413: AArch64: NPE in clhsdb jstack command > 8217368: AArch64: C2 recursive stack locking optimisation not triggered > 8217427: (dc) nio/channels/DatagramChannel/UseDGWithIPv6.java fails without IPv6 > 8216350: AArch64: monitor unlock fast path not called > 8209414: AArch64: method handle invocation does not respect JVMTI interp_only mode > 8215951: AArch64: jtreg test vmTestbase/nsk/jvmti/PopFrame/popframe005 segfaults > 8215202: AArch64: jtreg test test/jdk/sun/nio/cs/FindEncoderBugs.java fails > 8215100: AArch64: fix compareTo intrinsic with four-character Latin/Unicode > 8214512: ARM32: Jtreg test compiler/c2/Test8062950.java fails on ARM > 8209414: AArch64: method handle invocation does not respect JVMTI interp_only mode > 8214077: test java/io/File/SetLastModified.java fails on ARM32 > 8214078: (fs) SecureDirectoryStream not supported on arm32 From bsrbnd at gmail.com Fri Mar 20 18:29:22 2020 From: bsrbnd at gmail.com (B. Blaser) Date: Fri, 20 Mar 2020 19:29:22 +0100 Subject: CFV: New JDK Committer: Pengfei Li In-Reply-To: <55417a6f-f401-16ab-5dcc-0a93bba6cb03@arm.com> References: <55417a6f-f401-16ab-5dcc-0a93bba6cb03@arm.com> Message-ID: Vote: yes Regards, Bernard On Fri, 20 Mar 2020 at 08:58, Ningsheng Jian wrote: > > I hereby nominate Pengfei Li (pengfei.li at arm.com) to JDK committer. > [...] From luke.hutch at gmail.com Sat Mar 21 17:40:41 2020 From: luke.hutch at gmail.com (Luke Hutchison) Date: Sat, 21 Mar 2020 11:40:41 -0600 Subject: JDK 14 record type representation in classfile format? Message-ID: How are JDK 14 record types encoded in the classfile format? There is an 8-byte class attribute named "Record", but the format of this attribute is not documented in the JDK 14 classfile format specification (presumably because this feature is still in preview). Also, records have an "InnerClasses" class attribute, with an inner class name of "java.lang.invoke.MethodHandles$Lookup" and an outer class name of "java.lang.invoke.MethodHandles". Normally the outer class name matches the class whose classfile the attribute is contained in. Why is this inner class attribute there, and why does the outer class name not match the name of the record? From forax at univ-mlv.fr Sat Mar 21 18:00:04 2020 From: forax at univ-mlv.fr (Remi Forax) Date: Sat, 21 Mar 2020 19:00:04 +0100 (CET) Subject: JDK 14 record type representation in classfile format? In-Reply-To: References: Message-ID: <210577329.1731587.1584813604436.JavaMail.zimbra@u-pem.fr> Hi Luke, wrong mailing list, record being a preview feature, the right mailing list is amber-dev at openjdk.java.net. (please remove jdk-dev if you reply) ----- Mail original ----- > De: "Luke Hutchison" > ?: "jdk-dev" > Envoy?: Samedi 21 Mars 2020 18:40:41 > Objet: JDK 14 record type representation in classfile format? > How are JDK 14 record types encoded in the classfile format? There is an > 8-byte class attribute named "Record", but the format of this attribute is > not documented in the JDK 14 classfile format specification (presumably > because this feature is still in preview). if you to go at https://docs.oracle.com/javase/specs/ there is a link just below the JVM spec about record because as you said, it's a preview feature https://docs.oracle.com/javase/specs/jvms/se14/preview/specs/records-jvms.html and yes, there is a Record attribute see section 4.7.30. > > Also, records have an "InnerClasses" class attribute, with an inner class > name of "java.lang.invoke.MethodHandles$Lookup" and an outer class name of > "java.lang.invoke.MethodHandles". Normally the outer class name matches the > class whose classfile the attribute is contained in. Why is this inner > class attribute there, and why does the outer class name not match the name > of the record? This look like a bug to me. regards, R?mi From goetz.lindenmaier at sap.com Mon Mar 23 08:05:36 2020 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 23 Mar 2020 08:05:36 +0000 Subject: CFV: New JDK Reviewer: Hamlin Li In-Reply-To: References: Message-ID: Vote: yes Best regards, Goety. > -----Original Message----- > From: jdk-dev On Behalf Of Roger > Riggs > Sent: Monday, March 16, 2020 8:42 PM > To: jdk-dev at openjdk.java.net > Subject: CFV: New JDK Reviewer: Hamlin Li > > I hereby nominate Hamlin Li to JDK Reviewer. > > Hamlin is currently a JDK Committer and a member of the software quality > team at Oracle. > Hamlin has more than 130 contributions [3]. > > Hamlin has improved test quality, expanded code coverage, and tracked > down > intermittent failures in Core Library subsystems including Compact > Strings, Stack Walking, > Platform Logging, NIO, and RMI. > > Votes are due by March 31st, 2020. > > 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]. > > Roger Riggs > > [1] http://openjdk.java.net/census#jdk > [2] http://openjdk.java.net/projects/#reviewer-vote > [3] > http://hg.openjdk.java.net/jdk/jdk/search/?rev=%28keyword%28%22huami > ng.li%40oracle.com%22%29%20or%20author%28mli%29%29&revcount=400 From erik.joelsson at oracle.com Mon Mar 23 13:44:41 2020 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 23 Mar 2020 06:44:41 -0700 Subject: CFV: New JDK Committer: Alexey Semenyuk In-Reply-To: <5E7272F3.902@oracle.com> References: <5E7272F3.902@oracle.com> Message-ID: Vote: yes /Erik From sgehwolf at redhat.com Mon Mar 23 14:15:08 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Mon, 23 Mar 2020 15:15:08 +0100 Subject: CFV: New JDK Committer: Nick Gasson In-Reply-To: <041546d5-fb08-602e-351a-b612395dc021@arm.com> References: <041546d5-fb08-602e-351a-b612395dc021@arm.com> Message-ID: <75199f7a2f1d9bca1b8423a8b7875308532220c1.camel@redhat.com> Vote: yes. On Fri, 2020-03-20 at 15:51 +0800, Ningsheng Jian wrote: > I hereby nominate Nick Gasson (nick.gasson at arm.com) to JDK committer. > > Nick is a member of Arm JDK team and has contributed 29 changes to JDK > project. [3] > > Votes are due by 10:00 GMT, April 3rd, 2020. > > 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, > Ningsheng > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] > http://hg.openjdk.java.net/jdk/jdk/log?revcount=100&rev=desc%28%22nick.gasson%40arm.com%22%29+or+author%28ngasson%29 > > 8240353: AArch64: missing support for -XX:+ExtendedDTraceProbes in C1 > 8238705: [TESTBUG] jfr/event/gc/stacktrace/TestMetaspace* are stable > with Xcomp on AArch64 > 8236634: Memory Access API tests fail on 32-bit > 8237512: AArch64: aarch64TestHook leaks a BufferBlob > 8236992: AArch64: remove redundant load_klass in itable stub > 8237521: Memory Access API fixes for 32-bit > 8236242: Arm32: build broken after 8234794 > 8234794: AArch64: runtime/memory/ReadFromNoaccessArea.java crashes > 8235982: AArch64: Insufficient memory barriers in shadow region algorithm > 8229912: [TESTBUG] java/net/Socks/SocksIPv6Test fails without IPv6 > 8229118: [TESTBUG] serviceability/sa/ClhsdbFindPC fails on AArch64 > 8224851: AArch64: fix warnings and errors with Clang and GCC 8.3 > 8224853: CDS address sanitizer errors > 8221529: [TESTBUG] Docker tests use old/deprecated image on AArch64 > 8220707: [TESTBUG] serviceability/sa/TestHeapDumpForLargeArray.java > fails with jtreg -vmoption:-Xmx < 8g > 8220451: jdi/EventQueue/remove/remove004 failed due to "ERROR: thread2 > is not alive" 8220456: jdi/EventQueue/remove_l/remove_l004 failed due to > "TIMEOUT while waiting for event" > 8219628: [TESTBUG] javadoc/doclet/InheritDocForUserTags fails with -othervm > 8209413: AArch64: NPE in clhsdb jstack command > 8217368: AArch64: C2 recursive stack locking optimisation not triggered > 8217427: (dc) nio/channels/DatagramChannel/UseDGWithIPv6.java fails > without IPv6 > 8216350: AArch64: monitor unlock fast path not called > 8209414: AArch64: method handle invocation does not respect JVMTI > interp_only mode > 8215951: AArch64: jtreg test vmTestbase/nsk/jvmti/PopFrame/popframe005 > segfaults > 8215202: AArch64: jtreg test test/jdk/sun/nio/cs/FindEncoderBugs.java fails > 8215100: AArch64: fix compareTo intrinsic with four-character Latin/Unicode > 8214512: ARM32: Jtreg test compiler/c2/Test8062950.java fails on ARM > 8209414: AArch64: method handle invocation does not respect JVMTI > interp_only mode > 8214077: test java/io/File/SetLastModified.java fails on ARM32 > 8214078: (fs) SecureDirectoryStream not supported on arm32 > From dmitry.chuyko at bell-sw.com Tue Mar 24 09:51:02 2020 From: dmitry.chuyko at bell-sw.com (Dmitry Chuyko) Date: Tue, 24 Mar 2020 12:51:02 +0300 Subject: CFV: New JDK Committer: Nick Gasson In-Reply-To: <041546d5-fb08-602e-351a-b612395dc021@arm.com> References: <041546d5-fb08-602e-351a-b612395dc021@arm.com> Message-ID: Vote: yes On 3/20/20 10:51 AM, Ningsheng Jian wrote: > I hereby nominate Nick Gasson (nick.gasson at arm.com) to JDK committer. > > ............... From dmitry.chuyko at bell-sw.com Tue Mar 24 09:51:53 2020 From: dmitry.chuyko at bell-sw.com (Dmitry Chuyko) Date: Tue, 24 Mar 2020 12:51:53 +0300 Subject: CFV: New JDK Committer: Pengfei Li In-Reply-To: <55417a6f-f401-16ab-5dcc-0a93bba6cb03@arm.com> References: <55417a6f-f401-16ab-5dcc-0a93bba6cb03@arm.com> Message-ID: Vote: yes On 3/20/20 10:54 AM, Ningsheng Jian wrote: > I hereby nominate Pengfei Li (pengfei.li at arm.com) to JDK committer. > > .......... From thomas.stuefe at gmail.com Tue Mar 24 10:02:37 2020 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Tue, 24 Mar 2020 11:02:37 +0100 Subject: hg.openjdk.java.net down Message-ID: Hi, hg.openjdk.java.net gives us a HTTP 502 "bad gateway". Is it only us in Germany? Could someone from Oracle please look at it? Thank you! ..Thomas From forax at univ-mlv.fr Tue Mar 24 10:06:50 2020 From: forax at univ-mlv.fr (Remi Forax) Date: Tue, 24 Mar 2020 11:06:50 +0100 (CET) Subject: hg.openjdk.java.net down In-Reply-To: References: Message-ID: <2105997650.1014601.1585044410890.JavaMail.zimbra@u-pem.fr> Same issue from France :( R?mi ----- Mail original ----- > De: "Thomas St?fe" > ?: "jdk-dev" > Envoy?: Mardi 24 Mars 2020 11:02:37 > Objet: hg.openjdk.java.net down > Hi, > > hg.openjdk.java.net gives us a HTTP 502 "bad gateway". Is it only us in > Germany? Could someone from Oracle please look at it? > > Thank you! > > ..Thomas From Alan.Bateman at oracle.com Tue Mar 24 10:11:11 2020 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 24 Mar 2020 10:11:11 +0000 Subject: hg.openjdk.java.net down In-Reply-To: References: Message-ID: <9b54f656-d4d8-4377-c82a-06b53b04a9bd@oracle.com> On 24/03/2020 10:02, Thomas St?fe wrote: > Hi, > > hg.openjdk.java.net gives us a HTTP 502 "bad gateway". Is it only us in > Germany? There does seem to be a problem right now with both http and https. ssh seems to be working. -Alan From thomas.stuefe at gmail.com Tue Mar 24 10:49:37 2020 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Tue, 24 Mar 2020 11:49:37 +0100 Subject: CFV: New JDK Committer: Nick Gasson In-Reply-To: <041546d5-fb08-602e-351a-b612395dc021@arm.com> References: <041546d5-fb08-602e-351a-b612395dc021@arm.com> Message-ID: Vote: yes On Fri, Mar 20, 2020, 08:52 Ningsheng Jian wrote: > I hereby nominate Nick Gasson (nick.gasson at arm.com) to JDK committer. > > Nick is a member of Arm JDK team and has contributed 29 changes to JDK > project. [3] > > Votes are due by 10:00 GMT, April 3rd, 2020. > > 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, > Ningsheng > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] > > http://hg.openjdk.java.net/jdk/jdk/log?revcount=100&rev=desc%28%22nick.gasson%40arm.com%22%29+or+author%28ngasson%29 > > 8240353: AArch64: missing support for -XX:+ExtendedDTraceProbes in C1 > 8238705: [TESTBUG] jfr/event/gc/stacktrace/TestMetaspace* are stable > with Xcomp on AArch64 > 8236634: Memory Access API tests fail on 32-bit > 8237512: AArch64: aarch64TestHook leaks a BufferBlob > 8236992: AArch64: remove redundant load_klass in itable stub > 8237521: Memory Access API fixes for 32-bit > 8236242: Arm32: build broken after 8234794 > 8234794: AArch64: runtime/memory/ReadFromNoaccessArea.java crashes > 8235982: AArch64: Insufficient memory barriers in shadow region algorithm > 8229912: [TESTBUG] java/net/Socks/SocksIPv6Test fails without IPv6 > 8229118: [TESTBUG] serviceability/sa/ClhsdbFindPC fails on AArch64 > 8224851: AArch64: fix warnings and errors with Clang and GCC 8.3 > 8224853: CDS address sanitizer errors > 8221529: [TESTBUG] Docker tests use old/deprecated image on AArch64 > 8220707: [TESTBUG] serviceability/sa/TestHeapDumpForLargeArray.java > fails with jtreg -vmoption:-Xmx < 8g > 8220451: jdi/EventQueue/remove/remove004 failed due to "ERROR: thread2 > is not alive" 8220456: jdi/EventQueue/remove_l/remove_l004 failed due to > "TIMEOUT while waiting for event" > 8219628: [TESTBUG] javadoc/doclet/InheritDocForUserTags fails with -othervm > 8209413: AArch64: NPE in clhsdb jstack command > 8217368: AArch64: C2 recursive stack locking optimisation not triggered > 8217427: (dc) nio/channels/DatagramChannel/UseDGWithIPv6.java fails > without IPv6 > 8216350: AArch64: monitor unlock fast path not called > 8209414: AArch64: method handle invocation does not respect JVMTI > interp_only mode > 8215951: AArch64: jtreg test vmTestbase/nsk/jvmti/PopFrame/popframe005 > segfaults > 8215202: AArch64: jtreg test test/jdk/sun/nio/cs/FindEncoderBugs.java fails > 8215100: AArch64: fix compareTo intrinsic with four-character Latin/Unicode > 8214512: ARM32: Jtreg test compiler/c2/Test8062950.java fails on ARM > 8209414: AArch64: method handle invocation does not respect JVMTI > interp_only mode > 8214077: test java/io/File/SetLastModified.java fails on ARM32 > 8214078: (fs) SecureDirectoryStream not supported on arm32 > From thomas.stuefe at gmail.com Tue Mar 24 11:02:53 2020 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Tue, 24 Mar 2020 12:02:53 +0100 Subject: hg.openjdk.java.net down In-Reply-To: <9b54f656-d4d8-4377-c82a-06b53b04a9bd@oracle.com> References: <9b54f656-d4d8-4377-c82a-06b53b04a9bd@oracle.com> Message-ID: Thank you Alan, I switched to ssh for pull and it works. Cheers, Thomas On Tue, Mar 24, 2020 at 11:11 AM Alan Bateman wrote: > > > On 24/03/2020 10:02, Thomas St?fe wrote: > > Hi, > > > > hg.openjdk.java.net gives us a HTTP 502 "bad gateway". Is it only us in > > Germany? > There does seem to be a problem right now with both http and https. ssh > seems to be working. > > -Alan > From tim.bell at oracle.com Tue Mar 24 14:32:38 2020 From: tim.bell at oracle.com (Tim Bell) Date: Tue, 24 Mar 2020 07:32:38 -0700 Subject: hg.openjdk.java.net down In-Reply-To: References: <9b54f656-d4d8-4377-c82a-06b53b04a9bd@oracle.com> Message-ID: The web server side of https://hg.openjdk.java.net/ is back up. hgweb.fcgi dumped core and went into maintenance mode. Tim On 2020-03-24 04:02, Thomas St?fe wrote: > Thank you Alan, I switched to ssh for pull and it works. > > Cheers, Thomas > > On Tue, Mar 24, 2020 at 11:11 AM Alan Bateman > wrote: > >> >> >> On 24/03/2020 10:02, Thomas St?fe wrote: >>> Hi, >>> >>> hg.openjdk.java.net gives us a HTTP 502 "bad gateway". Is it only us in >>> Germany? >> There does seem to be a problem right now with both http and https. ssh >> seems to be working. >> >> -Alan >> From tim.bell at oracle.com Tue Mar 24 14:33:53 2020 From: tim.bell at oracle.com (Tim Bell) Date: Tue, 24 Mar 2020 07:33:53 -0700 Subject: hg.openjdk.java.net down In-Reply-To: <2105997650.1014601.1585044410890.JavaMail.zimbra@u-pem.fr> References: <2105997650.1014601.1585044410890.JavaMail.zimbra@u-pem.fr> Message-ID: All- The web server side of https://hg.openjdk.java.net/ is back up. hgweb.fcgi dumped core and went into maintenance mode. Tim On 2020-03-24 03:06, Remi Forax wrote: > Same issue from France :( > > R?mi > > ----- Mail original ----- >> De: "Thomas St?fe" >> ?: "jdk-dev" >> Envoy?: Mardi 24 Mars 2020 11:02:37 >> Objet: hg.openjdk.java.net down > >> Hi, >> >> hg.openjdk.java.net gives us a HTTP 502 "bad gateway". Is it only us in >> Germany? Could someone from Oracle please look at it? >> >> Thank you! >> >> ..Thomas From thomas.stuefe at gmail.com Tue Mar 24 14:35:54 2020 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Tue, 24 Mar 2020 15:35:54 +0100 Subject: hg.openjdk.java.net down In-Reply-To: References: <9b54f656-d4d8-4377-c82a-06b53b04a9bd@oracle.com> Message-ID: Thank you Tim. On Tue, Mar 24, 2020 at 3:32 PM Tim Bell wrote: > The web server side of https://hg.openjdk.java.net/ is back up. > > hgweb.fcgi dumped core and went into maintenance mode. > > Tim > > On 2020-03-24 04:02, Thomas St?fe wrote: > > Thank you Alan, I switched to ssh for pull and it works. > > > > Cheers, Thomas > > > > On Tue, Mar 24, 2020 at 11:11 AM Alan Bateman > > wrote: > > > >> > >> > >> On 24/03/2020 10:02, Thomas St?fe wrote: > >>> Hi, > >>> > >>> hg.openjdk.java.net gives us a HTTP 502 "bad gateway". Is it only us > in > >>> Germany? > >> There does seem to be a problem right now with both http and https. ssh > >> seems to be working. > >> > >> -Alan > >> > > From mark.reinhold at oracle.com Tue Mar 24 17:26:41 2020 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Tue, 24 Mar 2020 10:26:41 -0700 (PDT) Subject: JEP proposed to target JDK 15: 372: Remove the Nashorn JavaScript Engine Message-ID: <20200324172641.BE19E31B0EB@eggemoggin.niobe.net> The following JEP is proposed to target JDK 15: 372: Remove the Nashorn JavaScript Engine https://openjdk.java.net/jeps/372 Feedback on this proposal from JDK Project Committers and Reviewers [1] is more than welcome, as are reasoned objections. If no such objections are raised by 23:59 UTC on Tuesday, 31 March, or if they?re raised and then satisfactorily answered, then per the JEP 2.0 process proposal [2] I?ll target this JEP to JDK 15. - Mark [1] https://openjdk.java.net/census#jdk [2] https://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html From mark.reinhold at oracle.com Tue Mar 24 18:58:10 2020 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Tue, 24 Mar 2020 11:58:10 -0700 (PDT) Subject: New candidate JEP: 378: Text Blocks (Standard) Message-ID: <20200324185810.CA07231B11C@eggemoggin.niobe.net> https://openjdk.java.net/jeps/378 - Mark From mark.reinhold at oracle.com Wed Mar 25 21:19:36 2020 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Wed, 25 Mar 2020 14:19:36 -0700 (PDT) Subject: JEP proposed to target JDK 15: 378: Text Blocks (Standard) Message-ID: <20200325211936.5932D31B363@eggemoggin.niobe.net> The following JEP is proposed to target JDK 15: 378: Text Blocks (Standard) https://openjdk.java.net/jeps/378 Feedback on this proposal from JDK Project Committers and Reviewers [1] is more than welcome, as are reasoned objections. If no such objections are raised by 23:59 UTC on Wednesday, 1 April, or if they?re raised and then satisfactorily answered, then per the JEP 2.0 process proposal [2] I?ll target this JEP to JDK 15. - Mark [1] https://openjdk.java.net/census#jdk [2] https://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html From mark.reinhold at oracle.com Thu Mar 26 19:45:14 2020 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Thu, 26 Mar 2020 12:45:14 -0700 (PDT) Subject: Proposed schedule for JDK 15 Message-ID: <20200326194514.A429931B577@eggemoggin.niobe.net> With JDK 14 done and dusted, here?s a proposed schedule for JDK 15: 2020/06/11 Rampdown Phase One 2020/07/16 Rampdown Phase Two 2020/08/06 Initial Release Candidate 2020/08/20 Final Release Candidate 2020/09/15 General Availability The phases are defined in JEP 3 [1]. Comments on this proposal from JDK Committers and Reviewers [2] are welcome, as are reasoned objections. If no such objections are raised by 23:00 UTC next Thursday, 2 April, or if they?re raised and satisfactorily answered, then per the JEP 2.0 process proposal [3] this will be the schedule for JDK 15. - Mark [1] https://openjdk.java.net/jeps/3 [2] https://openjdk.java.net/census#jdk [3] https://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html From mark.reinhold at oracle.com Thu Mar 26 22:00:53 2020 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Thu, 26 Mar 2020 15:00:53 -0700 (PDT) Subject: JEP proposed to target JDK 15: 377: ZGC: A Scalable Low-Latency Garbage Collector (Production) Message-ID: <20200326220053.A76CC31B5A5@eggemoggin.niobe.net> The following JEP is proposed to target JDK 15: 377: ZGC: A Scalable Low-Latency Garbage Collector (Production) https://openjdk.java.net/jeps/377 Feedback on this proposal from JDK Project Committers and Reviewers [1] is more than welcome, as are reasoned objections. If no such objections are raised by 23:59 UTC on Thursday, 2 April, or if they?re raised and then satisfactorily answered, then per the JEP 2.0 process proposal [2] I?ll target this JEP to JDK 15. - Mark [1] https://openjdk.java.net/census#jdk [2] https://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html From eduard.filipas at telemach.net Mon Mar 30 07:07:00 2020 From: eduard.filipas at telemach.net (=?utf-8?B?ZWR1YXJkLmZpbGlwYXNAdGVsZW1hY2gubmV0?=) Date: Mon, 30 Mar 2020 07:07:00 GMT Subject: Javaw cmd Message-ID: <000f4244.486b6e6019783fba@telemach.net> Hi everybodyI have a issue that javaw starts cmd on win7 and win 10.. I have made project with latest intelij and javafx11 openjdk11. Now i dont have java installed i just copied java.zip to folder.. If i start with bat full command path cmd is activated even if i specify javawHope?You can helpRegards From forax at univ-mlv.fr Mon Mar 30 07:51:59 2020 From: forax at univ-mlv.fr (Remi Forax) Date: Mon, 30 Mar 2020 09:51:59 +0200 (CEST) Subject: Javaw cmd In-Reply-To: <000f4244.486b6e6019783fba@telemach.net> References: <000f4244.486b6e6019783fba@telemach.net> Message-ID: <1247374342.337023.1585554719944.JavaMail.zimbra@u-pem.fr> Hi, wrong mailing list :) it's for people interested in developing Java, not how to use it in a peculiar environment. Usually the website StackOverflow is better when you are asking why something is not working. Also because you are using JavaFX, i'm pretty sure there is a specific mailing list on the website dedicated to JavaFX [1]. regards, R?mi [1] https://openjfx.io/ ----- Mail original ----- > De: "eduard filipas" > ?: "jdk-dev" > Envoy?: Lundi 30 Mars 2020 09:07:00 > Objet: Javaw cmd > Hi everybodyI have a issue that javaw starts cmd on win7 and win 10.. I have > made project with latest intelij and javafx11 openjdk11. Now i dont have java > installed i just copied java.zip to folder.. If i start with bat full command > path cmd is activated even if i specify javawHope?You can helpRegards From derekw at marvell.com Mon Mar 30 16:29:24 2020 From: derekw at marvell.com (Derek White) Date: Mon, 30 Mar 2020 16:29:24 +0000 Subject: [EXT] CFV: New JDK Committer: Pengfei Li In-Reply-To: <55417a6f-f401-16ab-5dcc-0a93bba6cb03@arm.com> References: <55417a6f-f401-16ab-5dcc-0a93bba6cb03@arm.com> Message-ID: Vote: Yes ________________________________ From: jdk-dev on behalf of Ningsheng Jian Sent: Friday, March 20, 2020 3:54 AM To: jdk-dev at openjdk.java.net Subject: [EXT] CFV: New JDK Committer: Pengfei Li External Email ---------------------------------------------------------------------- I hereby nominate Pengfei Li (pengfei.li at arm.com) to JDK committer. Pengfei is a member of Arm JDK team and has contributed 20 changes to JDK project. [3] Votes are due by 10:00 GMT, April 3rd, 2020. 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, Ningsheng [1] https://urldefense.proofpoint.com/v2/url?u=http-3A__openjdk.java.net_census&d=DwICaQ&c=nKjWec2b6R0mOyPaz7xtfQ&r=2klNslw4FgBYHOF4bScoy9pTL_wQyMjGbUJaBRIS6OM&m=58IU6fvL8_16iMri1uRVIuubO09JbjD2fG0bsnR6zdU&s=QZXqOE6wxYhEo0aR9P1K3oM6Nhg8rz0-mz8AA54EEHE&e= [2] https://urldefense.proofpoint.com/v2/url?u=http-3A__openjdk.java.net_projects_-23committer-2Dvote&d=DwICaQ&c=nKjWec2b6R0mOyPaz7xtfQ&r=2klNslw4FgBYHOF4bScoy9pTL_wQyMjGbUJaBRIS6OM&m=58IU6fvL8_16iMri1uRVIuubO09JbjD2fG0bsnR6zdU&s=Zz9lExnTjGiLXDZQVy-QKRNWev8dMzZ0V9zv_ms89sk&e= [3] https://urldefense.proofpoint.com/v2/url?u=http-3A__hg.openjdk.java.net_jdk_jdk_log-3Frevcount-3D100-26rev-3Ddesc-2528-2522pengfei.li-2540arm.com-2522-2529-2Bor-2B-2528user-2528-2522pli-2522-2529-2Band-2Bnot-2B-2528user-2528-2522pliden-2522-2529-2529-2529&d=DwICaQ&c=nKjWec2b6R0mOyPaz7xtfQ&r=2klNslw4FgBYHOF4bScoy9pTL_wQyMjGbUJaBRIS6OM&m=58IU6fvL8_16iMri1uRVIuubO09JbjD2fG0bsnR6zdU&s=R8Of0T0gn90vrgFnI3y_p-pmkafXkxHhCvpE96qcJx0&e= 8239549: AArch64: Backend support for MulAddVS2VI node 8237524: AArch64: String.compareTo() may return incorrect result 8232591: AArch64: Add missing match rules for smaddl, smsubl and smnegl 8233743: AArch64: Make r27 conditionally allocatable 8234791: Fix Client VM build for x86_64 and AArch64 8230591: AArch64: Missing intrinsics for Math.ceil, floor, rint 8228601: AArch64: Fix interpreter code at JVMCI deoptimization entry 8227512: [TESTBUG] Fix JTReg javac test failures with Graal 8226222: [JVMCI] Export AArch64 field VM_Version::_psr_info.dczid_el0 8223427: [TESTBUG] Disable JTReg Shenandoah tests when Graal is enabled 8223054: [TESTBUG] Put graalJarsCP before existing classpath in GraalUnitTestLauncher 8214922: Add vectorization support for fmin/fmax 8216259: AArch64: Vectorize Adler32 intrinsics 8218550: Add test omitted from JDK-8212043 8212043: Add floating-point Math.min/max intrinsics 8211333: AArch64: Fix another build failure after JDK-8211029 8210413: AArch64: Optimize div/rem by constant in C1 8210152: Optimize integer divisible by power-of-2 check 8209783: AArch64: Combine Multiply and Neg operations in C2 8208623: [TESTBUG] runtime/LoadClass/LongBCP.java fails in AUFS file system From dmitrij.pochepko at bell-sw.com Mon Mar 30 16:38:42 2020 From: dmitrij.pochepko at bell-sw.com (Dmitrij Pochepko) Date: Mon, 30 Mar 2020 19:38:42 +0300 Subject: CFV: New JDK Committer: Pengfei Li In-Reply-To: <55417a6f-f401-16ab-5dcc-0a93bba6cb03@arm.com> References: <55417a6f-f401-16ab-5dcc-0a93bba6cb03@arm.com> Message-ID: <00b1fbd0-acdc-0545-4bba-4a4bb01e8502@bell-sw.com> Vote: yes On 20.03.2020 10:54, Ningsheng Jian wrote: > I hereby nominate Pengfei Li (pengfei.li at arm.com) to JDK committer. > > Pengfei is a member of Arm JDK team and has contributed 20 changes to > JDK project. [3] > > Votes are due by 10:00 GMT, April 3rd, 2020. > > 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, > Ningsheng > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] > http://hg.openjdk.java.net/jdk/jdk/log?revcount=100&rev=desc%28%22pengfei.li%40arm.com%22%29+or+%28user%28%22pli%22%29+and+not+%28user%28%22pliden%22%29%29%29 > > 8239549: AArch64: Backend support for MulAddVS2VI node > 8237524: AArch64: String.compareTo() may return incorrect result > 8232591: AArch64: Add missing match rules for smaddl, smsubl and smnegl > 8233743: AArch64: Make r27 conditionally allocatable > 8234791: Fix Client VM build for x86_64 and AArch64 > 8230591: AArch64: Missing intrinsics for Math.ceil, floor, rint > 8228601: AArch64: Fix interpreter code at JVMCI deoptimization entry > 8227512: [TESTBUG] Fix JTReg javac test failures with Graal > 8226222: [JVMCI] Export AArch64 field VM_Version::_psr_info.dczid_el0 > 8223427: [TESTBUG] Disable JTReg Shenandoah tests when Graal is enabled > 8223054: [TESTBUG] Put graalJarsCP before existing classpath in > GraalUnitTestLauncher > 8214922: Add vectorization support for fmin/fmax > 8216259: AArch64: Vectorize Adler32 intrinsics > 8218550: Add test omitted from JDK-8212043 > 8212043: Add floating-point Math.min/max intrinsics > 8211333: AArch64: Fix another build failure after JDK-8211029 > 8210413: AArch64: Optimize div/rem by constant in C1 > 8210152: Optimize integer divisible by power-of-2 check > 8209783: AArch64: Combine Multiply and Neg operations in C2 > 8208623: [TESTBUG] runtime/LoadClass/LongBCP.java fails in AUFS file > system From dmitrij.pochepko at bell-sw.com Mon Mar 30 16:39:14 2020 From: dmitrij.pochepko at bell-sw.com (Dmitrij Pochepko) Date: Mon, 30 Mar 2020 19:39:14 +0300 Subject: CFV: New JDK Committer: Nick Gasson In-Reply-To: <041546d5-fb08-602e-351a-b612395dc021@arm.com> References: <041546d5-fb08-602e-351a-b612395dc021@arm.com> Message-ID: <55e9f3d2-2265-aea6-2123-6c4a7bfa001b@bell-sw.com> Vote: yes On 20.03.2020 10:51, Ningsheng Jian wrote: > I hereby nominate Nick Gasson (nick.gasson at arm.com) to JDK committer. > > Nick is a member of Arm JDK team and has contributed 29 changes to JDK > project. [3] > > Votes are due by 10:00 GMT, April 3rd, 2020. > > 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, > Ningsheng > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] > http://hg.openjdk.java.net/jdk/jdk/log?revcount=100&rev=desc%28%22nick.gasson%40arm.com%22%29+or+author%28ngasson%29 > > 8240353: AArch64: missing support for -XX:+ExtendedDTraceProbes in C1 > 8238705: [TESTBUG] jfr/event/gc/stacktrace/TestMetaspace* are stable > with Xcomp on AArch64 > 8236634: Memory Access API tests fail on 32-bit > 8237512: AArch64: aarch64TestHook leaks a BufferBlob > 8236992: AArch64: remove redundant load_klass in itable stub > 8237521: Memory Access API fixes for 32-bit > 8236242: Arm32: build broken after 8234794 > 8234794: AArch64: runtime/memory/ReadFromNoaccessArea.java crashes > 8235982: AArch64: Insufficient memory barriers in shadow region algorithm > 8229912: [TESTBUG] java/net/Socks/SocksIPv6Test fails without IPv6 > 8229118: [TESTBUG] serviceability/sa/ClhsdbFindPC fails on AArch64 > 8224851: AArch64: fix warnings and errors with Clang and GCC 8.3 > 8224853: CDS address sanitizer errors > 8221529: [TESTBUG] Docker tests use old/deprecated image on AArch64 > 8220707: [TESTBUG] serviceability/sa/TestHeapDumpForLargeArray.java > fails with jtreg -vmoption:-Xmx < 8g > 8220451: jdi/EventQueue/remove/remove004 failed due to "ERROR: thread2 > is not alive" 8220456: jdi/EventQueue/remove_l/remove_l004 failed due > to "TIMEOUT while waiting for event" > 8219628: [TESTBUG] javadoc/doclet/InheritDocForUserTags fails with > -othervm > 8209413: AArch64: NPE in clhsdb jstack command > 8217368: AArch64: C2 recursive stack locking optimisation not triggered > 8217427: (dc) nio/channels/DatagramChannel/UseDGWithIPv6.java fails > without IPv6 > 8216350: AArch64: monitor unlock fast path not called > 8209414: AArch64: method handle invocation does not respect JVMTI > interp_only mode > 8215951: AArch64: jtreg test vmTestbase/nsk/jvmti/PopFrame/popframe005 > segfaults > 8215202: AArch64: jtreg test test/jdk/sun/nio/cs/FindEncoderBugs.java > fails > 8215100: AArch64: fix compareTo intrinsic with four-character > Latin/Unicode > 8214512: ARM32: Jtreg test compiler/c2/Test8062950.java fails on ARM > 8209414: AArch64: method handle invocation does not respect JVMTI > interp_only mode > 8214077: test java/io/File/SetLastModified.java fails on ARM32 > 8214078: (fs) SecureDirectoryStream not supported on arm32 From alexey.ivanov at oracle.com Mon Mar 30 16:49:47 2020 From: alexey.ivanov at oracle.com (Alexey Ivanov) Date: Mon, 30 Mar 2020 17:49:47 +0100 Subject: CFV: New JDK Committer: Alexey Semenyuk In-Reply-To: <5E7272F3.902@oracle.com> References: <5E7272F3.902@oracle.com> Message-ID: Vote: yes On 18/03/2020 19:13, Philip Race wrote: > I hereby nominate Alexey Semenyuk (alexey.semenyuk at oracle.com) to JDK > committer. -- Regards, Alexey From mark.reinhold at oracle.com Mon Mar 30 17:45:27 2020 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Mon, 30 Mar 2020 10:45:27 -0700 (PDT) Subject: JEP proposed to target JDK 15: 379: Shenandoah: A Low-Pause-Time Garbage Collector (Production) Message-ID: <20200330174527.A642131BADC@eggemoggin.niobe.net> The following JEP is proposed to target JDK 15: 379: Shenandoah: A Low-Pause-Time Garbage Collector (Production) https://openjdk.java.net/jeps/379 Feedback on this proposal from JDK Project Committers and Reviewers [1] is more than welcome, as are reasoned objections. If no such objections are raised by 23:59 UTC on Monday, 6 April, or if they?re raised and then satisfactorily answered, then per the JEP 2.0 process proposal [2] I?ll target this JEP to JDK 15. - Mark [1] https://openjdk.java.net/census#jdk [2] https://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html From Sergey.Bylokhov at oracle.com Tue Mar 31 00:31:04 2020 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 30 Mar 2020 17:31:04 -0700 Subject: CFV: New JDK Committer: Alexey Semenyuk In-Reply-To: <5E7272F3.902@oracle.com> References: <5E7272F3.902@oracle.com> Message-ID: <27100743-92e3-b960-4a33-ab3bace9e828@oracle.com> Vote: yes On 3/18/20 12:13 pm, Philip Race wrote: > > I hereby nominate Alexey Semenyuk (alexey.semenyuk at oracle.com) to JDK committer. > > Alexey is a member of the JDK software development team at Oracle and has > contributed 12 fixes [1] in the JDK project, first in the areas of code coverage, build and installers, > and recently he was one of the principal contributors to the jpackage tool implementation [2] > > Votes are due by 1pm PDT, April 1st, 2020. > Only current JDK Committers [3] 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 [4]. > > -phil > > [1] > http://hg.openjdk.java.net/jdk/jdk/search/?rev=%28keyword%28%22alexey.semenyuk%40oracle.com%22%29%20or%20author%28asemenyu%29%29&revcount=400 > > 2 months ago???? asemenyuk???? 8236132: Add missing properties to msi installers > 2 months ago???? asemenyuk???? 8232077: Investigate if default behavior should allow downgrade scenario > 2 months ago???? asemenyuk???? 8233578: Document configurable parameters of msi packages > 3 months ago???? asemenyuk???? 8236138: Add tests for jmod applications > 3 months ago???? asemenyuk???? 8236134: files missing in putback to JDK-8233270 > 3 months ago???? asemenyuk???? 8233270: Add support to jtreg helpers to unpack packages > 3 months ago???? asemenyuk???? 8235728: JDK-8212780 breaks builds with a custom X11 include path > 3 months ago???? asemenyuk???? 8233270: Add support to jtreg helpers to unpack packages? [*] > 3 months ago???? asemenyuk???? 8230933: Default icon is not set for additional launchers [*] > 2017-03-30?????? asemenyuk???? 8177770: Need more precise control on build system logging > 3 months ago?????? herrick???? 8212780: Packaging Tool Implementation > 2016-10-17?????? asemenyuk???? 8168093: Need a way for the launcher to query the JRE location using Windows registry. > > [*] Not showing up in search, changeset is here :- > https://hg.openjdk.java.net/jdk/jdk/rev/1b1a7893c78a > > [2] jpackage:? http://hg.openjdk.java.net/jdk/jdk/rev/9f9e7c969f78 (also listed above) > > [3] http://openjdk.java.net/census > > [4] http://openjdk.java.net/projects/#committer-vote -- Best regards, Sergey. From aph at redhat.com Tue Mar 31 09:16:36 2020 From: aph at redhat.com (Andrew Haley) Date: Tue, 31 Mar 2020 10:16:36 +0100 Subject: Result: New JDK Committer: Chihiro Ito Message-ID: <73010250-c0ba-108c-4cb9-42a4b44e93fe@redhat.com> Voting for Chihiro Ito [1] is now closed. Yes: 15 Veto: 0 Abstain: 0 According to the Bylaws definition of Lazy Consensus, this is sufficient to approve the nomination. [1] https://mail.openjdk.java.net/pipermail/jdk-dev/2020-March/004044.html -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671