From kusrinivasan at vmware.com Wed Apr 1 01:11:14 2020 From: kusrinivasan at vmware.com (Kumar Srinivasan) Date: Wed, 1 Apr 2020 01:11:14 +0000 Subject: CFV: New JDK Committer: Alexey Semenyuk In-Reply-To: <5E7272F3.902@oracle.com> References: <5E7272F3.902@oracle.com> Message-ID: Vote: yes > On Mar 18, 2020, at 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] > https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fhg.openjdk.java.net%2Fjdk%2Fjdk%2Fsearch%2F%3Frev%3D%2528keyword%2528%2522alexey.semenyuk%2540oracle.com%2522%2529%2520or%2520author%2528asemenyu%2529%2529%26revcount%3D400&data=02%7C01%7Ckusrinivasan%40vmware.com%7C4f774b5fbb3b439d8cf908d7cb70cf02%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637201557686624542&sdata=FKefrMejysxZl0hkJlsTjR8eMzI6Ke8WaUxc9Ng%2FdRE%3D&reserved=0 > > 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://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fhg.openjdk.java.net%2Fjdk%2Fjdk%2Frev%2F1b1a7893c78a&data=02%7C01%7Ckusrinivasan%40vmware.com%7C4f774b5fbb3b439d8cf908d7cb70cf02%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637201557686624542&sdata=CsZ3rWmKecAr9%2FPW%2B8HY3LrQxqJIrAMOu7NnJt7en50%3D&reserved=0 > > [2] jpackage: https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fhg.openjdk.java.net%2Fjdk%2Fjdk%2Frev%2F9f9e7c969f78&data=02%7C01%7Ckusrinivasan%40vmware.com%7C4f774b5fbb3b439d8cf908d7cb70cf02%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637201557686624542&sdata=lgJZOgvns3BJuAppKbY8bFjwik8PtXqOa8QidL0hNuw%3D&reserved=0 (also listed above) > > [3] https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fopenjdk.java.net%2Fcensus&data=02%7C01%7Ckusrinivasan%40vmware.com%7C4f774b5fbb3b439d8cf908d7cb70cf02%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637201557686624542&sdata=9Lw9D1ef%2FipQuuEkQVfTiVYS9O%2FeEUM30dsai%2BQGrzA%3D&reserved=0 > > [4] https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fopenjdk.java.net%2Fprojects%2F%23committer-vote&data=02%7C01%7Ckusrinivasan%40vmware.com%7C4f774b5fbb3b439d8cf908d7cb70cf02%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637201557686634530&sdata=2C%2BWI9WkOp1Rdw3mw%2B6S2lPjGfDuMEUGD8%2BSJbx6yBU%3D&reserved=0 From Sergey.Bylokhov at oracle.com Wed Apr 1 05:24:30 2020 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 31 Mar 2020 22:24:30 -0700 Subject: Result: New JDK Reviewer: Pankaj Bansal Message-ID: Voting for Pankaj Bansal [1] is now closed. Yes: 9 Veto: 0 Abstain: 0 According to the Bylaws definition of Three-Vote Consensus, this is sufficient to approve the nomination. Sergey Bylokhov [1] https://mail.openjdk.java.net/pipermail/jdk-dev/2020-March/004058.html From Roger.Riggs at oracle.com Wed Apr 1 16:25:51 2020 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Wed, 1 Apr 2020 12:25:51 -0400 Subject: Result: New JDK Reviewer: Hamlin Li Message-ID: Voting for Hamlin Li [1] is now closed. Yes: 15 Veto: 0 Abstain: 0 According to the Bylaws definition of Three-Vote Consensus, this is sufficient to approve the nomination. Roger Riggs https://mail.openjdk.java.net/pipermail/jdk-dev/2020-March/004069.html From mark.reinhold at oracle.com Wed Apr 1 16:44:25 2020 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Wed, 01 Apr 2020 09:44:25 -0700 Subject: JEP proposed to target JDK 15: 372: Remove the Nashorn JavaScript Engine In-Reply-To: <20200324172641.BE19E31B0EB@eggemoggin.niobe.net> References: <20200324172641.BE19E31B0EB@eggemoggin.niobe.net> Message-ID: <20200401094425.728709127@eggemoggin.niobe.net> 2020/3/24 10:26:41 -0700, mark.reinhold at oracle.com: > 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 Hearing no objections, I?ve targeted this JEP to JDK 15. - Mark From mark.reinhold at oracle.com Wed Apr 1 23:26:16 2020 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Wed, 1 Apr 2020 16:26:16 -0700 (PDT) Subject: JEP proposed to target JDK 15: 371: Hidden Classes Message-ID: <20200401232616.E1D2E31C141@eggemoggin.niobe.net> The following JEP is proposed to target JDK 15: 371: Hidden Classes https://openjdk.java.net/jeps/371 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, 8 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 hufeng1987 at gmail.com Thu Apr 2 04:19:07 2020 From: hufeng1987 at gmail.com (Netroby) Date: Thu, 2 Apr 2020 12:19:07 +0800 Subject: JEP proposed to target JDK 15: 371: Hidden Classes In-Reply-To: <20200401232616.E1D2E31C141@eggemoggin.niobe.net> References: <20200401232616.E1D2E31C141@eggemoggin.niobe.net> Message-ID: This may be dangerous. For virus creator and attacker. If they replace the origin Jar, the hidden class may cause we can not easy to see what's inside it . For company , If company choose to using hide class protect the important framework. It's valuable , but for who working deal with the framework, not good news. We often tired to find out whats happening. while there is exception, what's inside the exceptions. The JEP may cause us coders hard to work. Not just easy to read code, easy to understand. Like there will have many walls , block us . close our eyes. any way, Hidden class may useful, but not to Java coder like me. Appreciate your time. ---------------------------- Netroby ?2020?4?2??? ??7:26??? > > The following JEP is proposed to target JDK 15: > > 371: Hidden Classes > https://openjdk.java.net/jeps/371 > > 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, 8 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 david.holmes at oracle.com Thu Apr 2 04:30:04 2020 From: david.holmes at oracle.com (David Holmes) Date: Thu, 2 Apr 2020 14:30:04 +1000 Subject: JEP proposed to target JDK 15: 371: Hidden Classes In-Reply-To: References: <20200401232616.E1D2E31C141@eggemoggin.niobe.net> Message-ID: <8b321f61-b668-36b3-f70e-4e4414949cfa@oracle.com> On 2/04/2020 2:19 pm, Netroby wrote: > This may be dangerous. For virus creator and attacker. If they replace > the origin Jar, the hidden class may cause we can not easy to see > what's inside it . I don't think you are understanding the sense in which these classes are "hidden". This isn't about invisible classes in jar files. The ability to call Lookup.defineHiddenClass replaces (in part) the private/internal API Unsafe.defineAnonymousClass API so that framework writers now have a supported API to use for injecting classes. You must have appropriate permissions/capabilities to define a hidden class. David ----- > For company , If company choose to using hide class protect the > important framework. It's valuable , but for who working deal with the > framework, not good news. > > We often tired to find out whats happening. while there is exception, > what's inside the exceptions. > > The JEP may cause us coders hard to work. Not just easy to read code, > easy to understand. > > Like there will have many walls , block us . close our eyes. > > any way, Hidden class may useful, but not to Java coder like me. > > > Appreciate your time. > ---------------------------- > Netroby > > ?2020?4?2??? ??7:26??? >> >> The following JEP is proposed to target JDK 15: >> >> 371: Hidden Classes >> https://openjdk.java.net/jeps/371 >> >> 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, 8 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 mandy.chung at oracle.com Thu Apr 2 05:25:54 2020 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 1 Apr 2020 22:25:54 -0700 Subject: JEP proposed to target JDK 15: 371: Hidden Classes In-Reply-To: References: <20200401232616.E1D2E31C141@eggemoggin.niobe.net> Message-ID: Hi Netroby, Like David said, I think you misunderstand what this JEP proposes. A hidden class is like a normal class that you can inspect and reflect on.? One main characteristics of a hidden class is that it cannot be symbolically referenced by other classes and hence a hidden class cannot be named as a supertype, cannot be a declaring field type, and cannot be the parameter type or the return type. It cannot be found by class loader via `Class::forName`, `ClassLoader::loadClass`, `Lookup::findClass` etc.? This is what the hidden-ness is about. The class bytes of a hidden class is passed to the `Lookup::defineHiddenClass` as the argument.? Typically it is generated dynamically.? It is not a class file on the classpath (which I suspect JAR file you are referring to). Mandy On 4/1/20 9:19 PM, Netroby wrote: > This may be dangerous. For virus creator and attacker. If they replace > the origin Jar, the hidden class may cause we can not easy to see > what's inside it . > > For company , If company choose to using hide class protect the > important framework. It's valuable , but for who working deal with the > framework, not good news. > > We often tired to find out whats happening. while there is exception, > what's inside the exceptions. > > The JEP may cause us coders hard to work. Not just easy to read code, > easy to understand. > > Like there will have many walls , block us . close our eyes. > > any way, Hidden class may useful, but not to Java coder like me. > > > Appreciate your time. > ---------------------------- > Netroby > > ?2020?4?2??? ??7:26??? >> The following JEP is proposed to target JDK 15: >> >> 371: Hidden Classes >> https://openjdk.java.net/jeps/371 >> >> 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, 8 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 philip.race at oracle.com Thu Apr 2 15:23:15 2020 From: philip.race at oracle.com (Philip Race) Date: Thu, 02 Apr 2020 08:23:15 -0700 Subject: Result: New JDK Committer: Alexey Semenyuk Message-ID: <5E860363.2020305@oracle.com> Voting for Alexey Semenyuk [1] is now closed. Yes: 16 Veto: 0 Abstain: 0 According to the Bylaws definition of Lazy Consensus [2], this is sufficient to approve the nomination. -phil. [1] https://mail.openjdk.java.net/pipermail/jdk-dev/2020-March/004092.html [2] http://openjdk.java.net/bylaws#lazy-consensus From mark.reinhold at oracle.com Thu Apr 2 17:20:11 2020 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Thu, 02 Apr 2020 10:20:11 -0700 Subject: JEP proposed to target JDK 15: 378: Text Blocks (Standard) In-Reply-To: <20200325211936.5932D31B363@eggemoggin.niobe.net> References: <20200325211936.5932D31B363@eggemoggin.niobe.net> Message-ID: <20200402102011.100194573@eggemoggin.niobe.net> 2020/3/25 14:19:36 -0700, mark.reinhold at oracle.com: > 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. Hearing no objections, I?ve targeted this JEP to JDK 15. - Mark From ningsheng.jian at arm.com Fri Apr 3 10:20:39 2020 From: ningsheng.jian at arm.com (Ningsheng Jian) Date: Fri, 3 Apr 2020 18:20:39 +0800 Subject: Result: New JDK Committer: Nick Gasson Message-ID: <71f8ff6e-a3b3-d172-5103-ccc4184940f8@arm.com> Voting for Nick Gasson [1] is now closed. Yes: 21 Veto: 0 Abstain: 0 According to the Bylaws definition of Lazy Consensus, this is sufficient to approve the nomination. Thanks, Ningsheng [1] https://mail.openjdk.java.net/pipermail/jdk-dev/2020-March/004111.html From ningsheng.jian at arm.com Fri Apr 3 10:24:20 2020 From: ningsheng.jian at arm.com (Ningsheng Jian) Date: Fri, 3 Apr 2020 18:24:20 +0800 Subject: Result: New JDK Committer: Pengfei Li Message-ID: Voting for Pengfei Li [1] is now closed. Yes: 20 Veto: 0 Abstain: 0 According to the Bylaws definition of Lazy Consensus, this is sufficient to approve the nomination. Thanks, Ningsheng [1] https://mail.openjdk.java.net/pipermail/jdk-dev/2020-March/004112.html From philip.race at oracle.com Mon Apr 6 15:52:00 2020 From: philip.race at oracle.com (Philip Race) Date: Mon, 06 Apr 2020 08:52:00 -0700 Subject: RFC: Draft JEP : A Java 2D Metal API based rendering pipeline for macOS Message-ID: <5E8B5020.8010306@oracle.com> Hello all, I am sending notification to this mailing list to get wider visibility and provide opportunity for comments on the draft JEP [1] to "Implement a Java 2D internal rendering pipeline for macOS using the Apple Metal APIs as an alternative to the deprecated Apple OpenGL APIs". We expect to move it to the submitted state very soon, so please add any comments you may have to the JEP - or send them to the Project Lanai [2] mailing list [3]. Please see the JEP for more details. -phil. [1] https://bugs.openjdk.java.net/browse/JDK-8238361 [2] http://openjdk.java.net/projects/lanai/ [3] http://mail.openjdk.java.net/mailman/listinfo/lanai-dev From mark.reinhold at oracle.com Mon Apr 6 22:20:55 2020 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Mon, 6 Apr 2020 15:20:55 -0700 (PDT) Subject: New candidate JEP: 381: Remove the Solaris and SPARC Ports Message-ID: <20200406222055.4928531CA4B@eggemoggin.niobe.net> https://openjdk.java.net/jeps/381 - Mark From peter.tribble at gmail.com Tue Apr 7 08:45:48 2020 From: peter.tribble at gmail.com (Peter Tribble) Date: Tue, 7 Apr 2020 09:45:48 +0100 Subject: New candidate JEP: 381: Remove the Solaris and SPARC Ports In-Reply-To: <20200406222055.4928531CA4B@eggemoggin.niobe.net> References: <20200406222055.4928531CA4B@eggemoggin.niobe.net> Message-ID: On Mon, Apr 6, 2020 at 11:23 PM wrote: > https://openjdk.java.net/jeps/381 I have no role in the OpenJDK community, so cannot formally offer feedback. However, a comment: Under 'Risks and assumptions', it says "Removing support for Solaris or SPARC could affect other ports in the very unlikely case that they rely on Solaris or SPARC source code." It's not actually that unlikely - an illumos port is absolutely certain to rely on the existing Solaris code. (We would use essentially all the code, the port is largely a toolchain swap.) Thanks, -- -Peter Tribble http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/ From mark.reinhold at oracle.com Tue Apr 7 16:23:58 2020 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Tue, 07 Apr 2020 09:23:58 -0700 Subject: JEP proposed to target JDK 15: 377: ZGC: A Scalable Low-Latency Garbage Collector (Production) In-Reply-To: <20200326220053.A76CC31B5A5@eggemoggin.niobe.net> References: <20200326220053.A76CC31B5A5@eggemoggin.niobe.net> Message-ID: <20200407092358.158171631@eggemoggin.niobe.net> 2020/3/26 15:00:53 -0700, mark.reinhold at oracle.com: > 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. Hearing no objections, I?ve targeted this JEP to JDK 15. (I did this last Friday, actually, but forgot to send this message.) - Mark From mark.reinhold at oracle.com Tue Apr 7 16:28:33 2020 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Tue, 07 Apr 2020 09:28:33 -0700 Subject: JEP proposed to target JDK 15: 379: Shenandoah: A Low-Pause-Time Garbage Collector (Production) In-Reply-To: <20200330174527.A642131BADC@eggemoggin.niobe.net> References: <20200330174527.A642131BADC@eggemoggin.niobe.net> Message-ID: <20200407092833.493341796@eggemoggin.niobe.net> 2020/3/30 10:45:27 -0700, mark.reinhold at oracle.com: > 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. Hearing no objections, I?ve targeted this JEP to JDK 15. - Mark From mikael.vidstedt at oracle.com Tue Apr 7 19:49:02 2020 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Tue, 7 Apr 2020 12:49:02 -0700 Subject: New candidate JEP: 381: Remove the Solaris and SPARC Ports In-Reply-To: References: <20200406222055.4928531CA4B@eggemoggin.niobe.net> Message-ID: <62BBA455-D3DC-4E0D-A0A5-6E227F3D892C@oracle.com> > On Apr 7, 2020, at 1:45 AM, Peter Tribble wrote: > > On Mon, Apr 6, 2020 at 11:23 PM > wrote: > https://openjdk.java.net/jeps/381 > > I have no role in the OpenJDK community, so cannot formally offer feedback. Still appreciated, formal or not! > However, a comment: Under 'Risks and assumptions', it says > "Removing support for Solaris or SPARC could affect other ports in the > very unlikely case that they rely on Solaris or SPARC source code." > > It's not actually that unlikely - an illumos port is absolutely certain to rely on > the existing Solaris code. (We would use essentially all the code, the port > is largely a toolchain swap.) Undertstood - external/downstream ports like the Illumos one are of course ?implicitly? affected by a change like this. The specific statement in the Risks/assumptions section was only meant to reflect in-tree ports (in OpenJDK), I realize that wasn?t clear. I added ?in-tree? to the JEP to hopefully make it more clear. Cheers, Mikael From alex.buckley at oracle.com Tue Apr 7 23:26:24 2020 From: alex.buckley at oracle.com (Alex Buckley) Date: Tue, 7 Apr 2020 16:26:24 -0700 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: A few follow-up points: On 3/3/2020 1:15 PM, Alex Buckley wrote: > 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. To clarify: The JLS will list only those preview APIs which are essential to preview language features, and will not list preview APIs which are orthogonal to the Java language. The Java SE Platform Specification will need to list the latter group of preview APIs -- straightforward, since the Platform Spec already lists preview JEPs -- and say "These APIs exist only when preview features are enabled." We already do something like this in the Platform Spec for 14, to make record serialization/deserialization exist only when preview features are enabled at run time -- see http://cr.openjdk.java.net/~iris/se/14/latestSpec/java-se-14-annex-4.html Switching gears slightly: If some future version of Java SE has a preview feature called Virtual Threads, then the feature would include significant extensions to JVM TI and JNI. These are C-language APIs, so we can't mark the new API points as "preview" and have them be disabled by default at compile time. Still, feedback is important, so we would plan to include new C-language API points in the most direct way possible (e.g., no names mangled with `__preview` prefixes) and then heavily document their non-final status. > 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. I want to emphasize that previewing is meaningful not only in the Java language, JVM, and SE API, but also in "supported" JDK APIs and tools: 1. Supported JDK APIs are APIs outside `java.*` that we export, recommend, and steward as carefully as if they were inside. Examples: JDI (`com.sun.jdi` in `jdk.jdi`) and the Compiler Tree API (`com.sun.source.tree` in `jdk.compiler`). If some future version of Java SE has a preview feature called Virtual Threads, then the feature would include significant extensions to JDI as well as JVM TI and JNI; we would plan to identify the Java-language API points in JDI as preview APIs. 2. Supported JDK tools means the majority of JDK tools. They're not mentioned in the Platform Spec, but they have a long life and we maintain them in the usual careful, compatible way. (We even regard them as having "specifications" -- see https://docs.oracle.com/en/java/javase/14/docs/specs/man/index.html) For example, consider `jpackage`: it gathered initial feedback with a dedicated EA build on jdk.java.net, so a plausible next step would have been to preview in `jdk.jpackage` rather than to incubate in `jdk.incubator.jpackage`. When a tool is previewed, I don't believe the --enable-preview flag is worthwhile; what's important is a loud start-up message that the tool is in preview, and may change if/when it becomes permanent. Alex From mark.reinhold at oracle.com Wed Apr 8 17:36:46 2020 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Wed, 08 Apr 2020 10:36:46 -0700 Subject: Proposed schedule for JDK 15 In-Reply-To: <20200326194514.A429931B577@eggemoggin.niobe.net> References: <20200326194514.A429931B577@eggemoggin.niobe.net> Message-ID: <20200408103646.280550358@eggemoggin.niobe.net> 2020/3/26 12:45:14 -0700, mark.reinhold at oracle.com: > 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. Hearing no objections, this is now the schedule for JDK 15: https://openjdk.java.net/projects/jdk/15/ - Mark From christoph.langer at sap.com Thu Apr 9 06:37:24 2020 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 9 Apr 2020 06:37:24 +0000 Subject: Anybody working on a solution to the mailing list problems (a.k.a JDK-8213225)? In-Reply-To: <871rpogmmi.fsf@mid.deneb.enyo.de> References: <871rpogmmi.fsf@mid.deneb.enyo.de> Message-ID: Hi all, thanks for your replies, kind of confirming THE problem or at least confirming that there IS a problem. It would be good if somebody from the Oracle infrastructure team could come forward, sharing their current status/view of the issue. Or if somebody could get into direct contact with me to help debugging the problem. I feel a bit ignored and left alone from that side, actually, although I think that's an important problem for the OpenJDK community to solve... Best regards Christoph > -----Original Message----- > From: Florian Weimer > Sent: Donnerstag, 19. M?rz 2020 20:40 > To: Langer, Christoph > Cc: jdk-dev at openjdk.java.net; ops at openjdk.java.net > Subject: Re: Anybody working on a solution to the mailing list problems (a.k.a > JDK-8213225)? > > * 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 martinrb at google.com Thu Apr 9 07:07:36 2020 From: martinrb at google.com (Martin Buchholz) Date: Thu, 9 Apr 2020 00:07:36 -0700 Subject: Anybody working on a solution to the mailing list problems (a.k.a JDK-8213225)? In-Reply-To: References: Message-ID: This continues to be the biggest single problem for the OpenJDK project. The solution "should" be simple - upgrade the ancient mailing list infrastructure. On Thu, Mar 19, 2020 at 3:13 AM Martijn Verburg wrote: > 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 ). > Well, I work at Google and I couldn't get Google to change either. See JDK-8213225 From christoph.langer at sap.com Thu Apr 9 07:26:49 2020 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 9 Apr 2020 07:26:49 +0000 Subject: Anybody working on a solution to the mailing list problems (a.k.a JDK-8213225)? In-Reply-To: References: Message-ID: Hi Martin, > This continues to be the biggest single problem for the OpenJDK project. > The solution "should" be simple - upgrade the ancient mailing list > infrastructure. Yes, probably. It would be very much appreciated if somebody from Oracle could comment on this endeavor... @GB members: I think that's something to address in the Governing Board, if we continue to see no progress. Cheers Christoph From aph at redhat.com Thu Apr 9 09:06:19 2020 From: aph at redhat.com (Andrew Haley) Date: Thu, 9 Apr 2020 10:06:19 +0100 Subject: Anybody working on a solution to the mailing list problems (a.k.a JDK-8213225)? In-Reply-To: References: <871rpogmmi.fsf@mid.deneb.enyo.de> Message-ID: <309dad5e-689e-a161-79f8-0e109b48b500@redhat.com> On 4/9/20 7:37 AM, Langer, Christoph wrote: > thanks for your replies, kind of confirming THE problem or at least confirming that there IS a problem. > > It would be good if somebody from the Oracle infrastructure team could come forward, sharing their current status/view of the issue. Or if somebody could get into direct contact with me to help debugging the problem. It would help if we had some kind of idea about the actual problem. Presumably gmail is using some kind of heuristic; I don't know because I don't use gmail. So, please send a couple of false positives my way and we'll try to figure out what the problem is. I'm not a great believer in "Let's upgrade to something modern" as an obvious cure because modern solutions have their own problems. -- 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 Thu Apr 9 12:32:50 2020 From: aph at redhat.com (Andrew Haley) Date: Thu, 9 Apr 2020 13:32:50 +0100 Subject: Anybody working on a solution to the mailing list problems (a.k.a JDK-8213225)? In-Reply-To: <309dad5e-689e-a161-79f8-0e109b48b500@redhat.com> References: <871rpogmmi.fsf@mid.deneb.enyo.de> <309dad5e-689e-a161-79f8-0e109b48b500@redhat.com> Message-ID: On 4/9/20 10:06 AM, Andrew Haley wrote: > It would help if we had some kind of idea about the actual problem. NM, I scanned this thread and I see it now. "Upgrade to Mailman 3" might be an answer, but we'll see. -- 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 mark.reinhold at oracle.com Thu Apr 9 23:37:37 2020 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Thu, 09 Apr 2020 16:37:37 -0700 Subject: Anybody working on a solution to the mailing list problems (a.k.a JDK-8213225)? In-Reply-To: References: Message-ID: <20200409163737.191346016@eggemoggin.niobe.net> Tim Bell is actively working on this issue, starting with an upgrade of our Mailman instance. Once that?s done, we?ll consider the various options to address the DMARC problem. Unfortunately, none of them is both simple and unobtrusive. Stay tuned ... - Mark From mark.reinhold at oracle.com Fri Apr 10 16:32:55 2020 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Fri, 10 Apr 2020 09:32:55 -0700 Subject: JEP proposed to target JDK 15: 371: Hidden Classes In-Reply-To: <20200401232616.E1D2E31C141@eggemoggin.niobe.net> References: <20200401232616.E1D2E31C141@eggemoggin.niobe.net> Message-ID: <20200410093255.795678185@eggemoggin.niobe.net> 2020/4/1 16:26:16 -0700, mark.reinhold at oracle.com: > The following JEP is proposed to target JDK 15: > > 371: Hidden Classes > https://openjdk.java.net/jeps/371 > > 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, 8 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. Hearing no objections, I?ve targeted this JEP to JDK 15. - Mark From christoph.langer at sap.com Tue Apr 14 13:17:22 2020 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 14 Apr 2020 13:17:22 +0000 Subject: Anybody working on a solution to the mailing list problems (a.k.a JDK-8213225)? In-Reply-To: <20200409163737.191346016@eggemoggin.niobe.net> References: <20200409163737.191346016@eggemoggin.niobe.net> Message-ID: Hi Mark, thanks for your update on this. That was actually one of the statements I was hoping to hear ?? Looking forward to any progress being made. Thanks & Best regards Christoph > -----Original Message----- > From: mark.reinhold at oracle.com > Sent: Freitag, 10. April 2020 01:38 > To: Langer, Christoph > Cc: jdk-dev at openjdk.java.net; ops at openjdk.java.net > Subject: Re: Anybody working on a solution to the mailing list problems (a.k.a > JDK-8213225)? > > Tim Bell is actively working on this issue, starting with an > upgrade of our Mailman instance. > > Once that?s done, we?ll consider the various options to address > the DMARC problem. Unfortunately, none of them is both simple > and unobtrusive. > > Stay tuned ... > > - Mark From mark.reinhold at oracle.com Tue Apr 14 23:53:11 2020 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Tue, 14 Apr 2020 16:53:11 -0700 (PDT) Subject: New candidate JEP: 382: New macOS Rendering Pipeline Message-ID: <20200414235311.AD3EB31E403@eggemoggin.niobe.net> https://openjdk.java.net/jeps/382 - Mark From chris.hegarty at oracle.com Wed Apr 15 15:13:15 2020 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 15 Apr 2020 16:13:15 +0100 Subject: CFV: New JDK Reviewer: Mark Sheppard Message-ID: I hereby nominate Mark Sheppard [4] to JDK Reviewer. Mark is currently a JDK Committer and a member of the Java Platform Group at Oracle. Mark has more than 87 contributions [3]. Mark's contrubutions span a wide variet of areas; bug fixes, enhancements and spec clarifications in the Netwokring area, security improvements to CORBA, as well as changes and improvements in core libraries. Votes are due by 29th April 2020, 16:00 UTC. 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]. -Chris. [1] https://openjdk.java.net/census#jdk [2] https://openjdk.java.net/projects/#reviewer-vote [3] https://hg.openjdk.java.net/jdk/jdk/search/?rev=%28keyword%28%22mark.sheppard%40oracle.com%22%29%20or%20author%28msheppar%29%29&revcount=400 [4] https://openjdk.java.net/census#msheppar From pavel.rappo at oracle.com Wed Apr 15 15:22:48 2020 From: pavel.rappo at oracle.com (Pavel Rappo) Date: Wed, 15 Apr 2020 16:22:48 +0100 Subject: CFV: New JDK Reviewer: Mark Sheppard In-Reply-To: References: Message-ID: <4F806A9B-BF67-4A89-85AF-F87844204F83@oracle.com> Vote: yes > On 15 Apr 2020, at 16:13, Chris Hegarty wrote: > > I hereby nominate Mark Sheppard [4] to JDK Reviewer. > > Mark is currently a JDK Committer and a member of the Java Platform > Group at Oracle. Mark has more than 87 contributions [3]. > > Mark's contrubutions span a wide variet of areas; bug fixes, > enhancements and spec clarifications in the Netwokring area, security > improvements to CORBA, as well as changes and improvements in core > libraries. > > Votes are due by 29th April 2020, 16:00 UTC. > > 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]. > > -Chris. > > [1] https://openjdk.java.net/census#jdk > [2] https://openjdk.java.net/projects/#reviewer-vote > [3] https://hg.openjdk.java.net/jdk/jdk/search/?rev=%28keyword%28%22mark.sheppard%40oracle.com%22%29%20or%20author%28msheppar%29%29&revcount=400 > [4] https://openjdk.java.net/census#msheppar > From james.laskey at oracle.com Wed Apr 15 15:26:38 2020 From: james.laskey at oracle.com (Jim Laskey) Date: Wed, 15 Apr 2020 12:26:38 -0300 Subject: CFV: New JDK Reviewer: Mark Sheppard In-Reply-To: References: Message-ID: <2D3A3AB6-9395-4B57-9F22-66B915A8C563@oracle.com> Vote: Yes > On Apr 15, 2020, at 12:13 PM, Chris Hegarty wrote: > > I hereby nominate Mark Sheppard [4] to JDK Reviewer. > > Mark is currently a JDK Committer and a member of the Java Platform > Group at Oracle. Mark has more than 87 contributions [3]. > > Mark's contrubutions span a wide variet of areas; bug fixes, > enhancements and spec clarifications in the Netwokring area, security > improvements to CORBA, as well as changes and improvements in core > libraries. > > Votes are due by 29th April 2020, 16:00 UTC. > > 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]. > > -Chris. > > [1] https://openjdk.java.net/census#jdk > [2] https://openjdk.java.net/projects/#reviewer-vote > [3] https://hg.openjdk.java.net/jdk/jdk/search/?rev=%28keyword%28%22mark.sheppard%40oracle.com%22%29%20or%20author%28msheppar%29%29&revcount=400 > [4] https://openjdk.java.net/census#msheppar > From sean.coffey at oracle.com Wed Apr 15 15:31:44 2020 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Wed, 15 Apr 2020 16:31:44 +0100 Subject: CFV: New JDK Reviewer: Mark Sheppard In-Reply-To: References: Message-ID: Vote: Yes regards, Sean. On 15/04/2020 16:13, Chris Hegarty wrote: > I hereby nominate Mark Sheppard [4] to JDK Reviewer. > > Mark is currently a JDK Committer and a member of the Java Platform > Group at Oracle. Mark has more than 87 contributions [3]. > > Mark's contrubutions span a wide variet of areas; bug fixes, > enhancements and spec clarifications in the Netwokring area, security > improvements to CORBA, as well as changes and improvements in core > libraries. > > Votes are due by 29th April 2020, 16:00 UTC. > > 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]. > > -Chris. > > [1] https://openjdk.java.net/census#jdk > [2] https://openjdk.java.net/projects/#reviewer-vote > [3] https://hg.openjdk.java.net/jdk/jdk/search/?rev=%28keyword%28%22mark.sheppard%40oracle.com%22%29%20or%20author%28msheppar%29%29&revcount=400 > [4] https://openjdk.java.net/census#msheppar > From sha.jiang at oracle.com Wed Apr 15 15:41:51 2020 From: sha.jiang at oracle.com (sha.jiang at oracle.com) Date: Wed, 15 Apr 2020 23:41:51 +0800 Subject: CFV: New JDK Reviewer: Mark Sheppard In-Reply-To: References: Message-ID: Vote: yes Best regards, John Jiang On 2020/4/15 23:13, Chris Hegarty wrote: > I hereby nominate Mark Sheppard [4] to JDK Reviewer. > > Mark is currently a JDK Committer and a member of the Java Platform > Group at Oracle. Mark has more than 87 contributions [3]. > > Mark's contrubutions span a wide variet of areas; bug fixes, > enhancements and spec clarifications in the Netwokring area, security > improvements to CORBA, as well as changes and improvements in core > libraries. > > Votes are due by 29th April 2020, 16:00 UTC. > > 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]. > > -Chris. > > [1] https://openjdk.java.net/census#jdk > [2] https://openjdk.java.net/projects/#reviewer-vote > [3] https://hg.openjdk.java.net/jdk/jdk/search/?rev=%28keyword%28%22mark.sheppard%40oracle.com%22%29%20or%20author%28msheppar%29%29&revcount=400 > [4] https://openjdk.java.net/census#msheppar > From vincent.x.ryan at oracle.com Wed Apr 15 15:43:04 2020 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Wed, 15 Apr 2020 16:43:04 +0100 Subject: CFV: New JDK Reviewer: Mark Sheppard In-Reply-To: References: Message-ID: <08961851-E4CF-43BB-9019-9A0C31C1FC97@oracle.com> Vote: yes > On 15 Apr 2020, at 16:13, Chris Hegarty wrote: > > I hereby nominate Mark Sheppard [4] to JDK Reviewer. > > Mark is currently a JDK Committer and a member of the Java Platform > Group at Oracle. Mark has more than 87 contributions [3]. > > Mark's contrubutions span a wide variet of areas; bug fixes, > enhancements and spec clarifications in the Netwokring area, security > improvements to CORBA, as well as changes and improvements in core > libraries. > > Votes are due by 29th April 2020, 16:00 UTC. > > 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]. > > -Chris. > > [1] https://openjdk.java.net/census#jdk > [2] https://openjdk.java.net/projects/#reviewer-vote > [3] https://hg.openjdk.java.net/jdk/jdk/search/?rev=%28keyword%28%22mark.sheppard%40oracle.com%22%29%20or%20author%28msheppar%29%29&revcount=400 > [4] https://openjdk.java.net/census#msheppar > From Roger.Riggs at oracle.com Wed Apr 15 15:56:04 2020 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Wed, 15 Apr 2020 11:56:04 -0400 Subject: CFV: New JDK Reviewer: Mark Sheppard In-Reply-To: References: Message-ID: Vote: Yes On 4/15/20 11:13 AM, Chris Hegarty wrote: > I hereby nominate Mark Sheppard [4] to JDK Reviewer. From daniel.fuchs at oracle.com Wed Apr 15 16:16:36 2020 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Wed, 15 Apr 2020 17:16:36 +0100 Subject: CFV: New JDK Reviewer: Mark Sheppard In-Reply-To: References: Message-ID: <80c182be-f12d-763f-a96b-8aad0257079b@oracle.com> Vote: yes best regards, -- daniel On 15/04/2020 16:13, Chris Hegarty wrote: > I hereby nominate Mark Sheppard [4] to JDK Reviewer. From naoto.sato at oracle.com Wed Apr 15 16:22:54 2020 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Wed, 15 Apr 2020 09:22:54 -0700 Subject: CFV: New JDK Reviewer: Mark Sheppard In-Reply-To: References: Message-ID: <12e1171d-caab-eb4a-5147-4629c0dd3f55@oracle.com> Vote: yes Naoto On 4/15/20 8:13 AM, Chris Hegarty wrote: > I hereby nominate Mark Sheppard [4] to JDK Reviewer. > > Mark is currently a JDK Committer and a member of the Java Platform > Group at Oracle. Mark has more than 87 contributions [3]. > > Mark's contrubutions span a wide variet of areas; bug fixes, > enhancements and spec clarifications in the Netwokring area, security > improvements to CORBA, as well as changes and improvements in core > libraries. > > Votes are due by 29th April 2020, 16:00 UTC. > > 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]. > > -Chris. > > [1] https://openjdk.java.net/census#jdk > [2] https://openjdk.java.net/projects/#reviewer-vote > [3] https://hg.openjdk.java.net/jdk/jdk/search/?rev=%28keyword%28%22mark.sheppard%40oracle.com%22%29%20or%20author%28msheppar%29%29&revcount=400 > [4] https://openjdk.java.net/census#msheppar > From joe.darcy at oracle.com Wed Apr 15 16:45:31 2020 From: joe.darcy at oracle.com (Joe Darcy) Date: Wed, 15 Apr 2020 09:45:31 -0700 Subject: CFV: New JDK Reviewer: Mark Sheppard In-Reply-To: References: Message-ID: Vote: yes -Joe On 4/15/2020 8:13 AM, Chris Hegarty wrote: > I hereby nominate Mark Sheppard [4] to JDK Reviewer. > > Mark is currently a JDK Committer and a member of the Java Platform > Group at Oracle. Mark has more than 87 contributions [3]. > > Mark's contrubutions span a wide variet of areas; bug fixes, > enhancements and spec clarifications in the Netwokring area, security > improvements to CORBA, as well as changes and improvements in core > libraries. > > Votes are due by 29th April 2020, 16:00 UTC. > > 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]. > > -Chris. > > [1] https://openjdk.java.net/census#jdk > [2] https://openjdk.java.net/projects/#reviewer-vote > [3] https://hg.openjdk.java.net/jdk/jdk/search/?rev=%28keyword%28%22mark.sheppard%40oracle.com%22%29%20or%20author%28msheppar%29%29&revcount=400 > [4] https://openjdk.java.net/census#msheppar > From volker.simonis at gmail.com Wed Apr 15 16:59:17 2020 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 15 Apr 2020 18:59:17 +0200 Subject: CFV: New JDK Reviewer: Mark Sheppard In-Reply-To: References: Message-ID: Vote: yes On Wed, Apr 15, 2020 at 5:13 PM Chris Hegarty wrote: > > I hereby nominate Mark Sheppard [4] to JDK Reviewer. > > Mark is currently a JDK Committer and a member of the Java Platform > Group at Oracle. Mark has more than 87 contributions [3]. > > Mark's contrubutions span a wide variet of areas; bug fixes, > enhancements and spec clarifications in the Netwokring area, security > improvements to CORBA, as well as changes and improvements in core > libraries. > > Votes are due by 29th April 2020, 16:00 UTC. > > 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]. > > -Chris. > > [1] https://openjdk.java.net/census#jdk > [2] https://openjdk.java.net/projects/#reviewer-vote > [3] https://hg.openjdk.java.net/jdk/jdk/search/?rev=%28keyword%28%22mark.sheppard%40oracle.com%22%29%20or%20author%28msheppar%29%29&revcount=400 > [4] https://openjdk.java.net/census#msheppar > From jianglizhou at google.com Wed Apr 15 17:29:27 2020 From: jianglizhou at google.com (Jiangli Zhou) Date: Wed, 15 Apr 2020 10:29:27 -0700 Subject: CFV: New JDK Reviewer: Mark Sheppard In-Reply-To: References: Message-ID: Vote: Yes Best, Jiangli On Wed, Apr 15, 2020 at 8:13 AM Chris Hegarty wrote: > > I hereby nominate Mark Sheppard [4] to JDK Reviewer. > > Mark is currently a JDK Committer and a member of the Java Platform > Group at Oracle. Mark has more than 87 contributions [3]. > > Mark's contrubutions span a wide variet of areas; bug fixes, > enhancements and spec clarifications in the Netwokring area, security > improvements to CORBA, as well as changes and improvements in core > libraries. > > Votes are due by 29th April 2020, 16:00 UTC. > > 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]. > > -Chris. > > [1] https://openjdk.java.net/census#jdk > [2] https://openjdk.java.net/projects/#reviewer-vote > [3] https://hg.openjdk.java.net/jdk/jdk/search/?rev=%28keyword%28%22mark.sheppard%40oracle.com%22%29%20or%20author%28msheppar%29%29&revcount=400 > [4] https://openjdk.java.net/census#msheppar > From vicente.romero at oracle.com Wed Apr 15 17:51:41 2020 From: vicente.romero at oracle.com (Vicente Romero) Date: Wed, 15 Apr 2020 13:51:41 -0400 Subject: CFV: New JDK Reviewer: Mark Sheppard In-Reply-To: References: Message-ID: vote: yes Vicente On 4/15/20 11:13 AM, Chris Hegarty wrote: > I hereby nominate Mark Sheppard [4] to JDK Reviewer. > > Mark is currently a JDK Committer and a member of the Java Platform > Group at Oracle. Mark has more than 87 contributions [3]. > > Mark's contrubutions span a wide variet of areas; bug fixes, > enhancements and spec clarifications in the Netwokring area, security > improvements to CORBA, as well as changes and improvements in core > libraries. > > Votes are due by 29th April 2020, 16:00 UTC. > > 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]. > > -Chris. > > [1] https://openjdk.java.net/census#jdk > [2] https://openjdk.java.net/projects/#reviewer-vote > [3] https://hg.openjdk.java.net/jdk/jdk/search/?rev=%28keyword%28%22mark.sheppard%40oracle.com%22%29%20or%20author%28msheppar%29%29&revcount=400 > [4] https://openjdk.java.net/census#msheppar > From harold.seigel at oracle.com Wed Apr 15 18:02:01 2020 From: harold.seigel at oracle.com (Harold Seigel) Date: Wed, 15 Apr 2020 14:02:01 -0400 Subject: CFV: New JDK Reviewer: Mark Sheppard In-Reply-To: References: Message-ID: <6ad4128f-8ea3-cbfa-5d75-1350acdb4615@oracle.com> Vote: yes Thanks, Harold On 4/15/2020 11:13 AM, Chris Hegarty wrote: > I hereby nominate Mark Sheppard [4] to JDK Reviewer. > > Mark is currently a JDK Committer and a member of the Java Platform > Group at Oracle. Mark has more than 87 contributions [3]. > > Mark's contrubutions span a wide variet of areas; bug fixes, > enhancements and spec clarifications in the Netwokring area, security > improvements to CORBA, as well as changes and improvements in core > libraries. > > Votes are due by 29th April 2020, 16:00 UTC. > > 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]. > > -Chris. > > [1] https://openjdk.java.net/census#jdk > [2] https://openjdk.java.net/projects/#reviewer-vote > [3] https://hg.openjdk.java.net/jdk/jdk/search/?rev=%28keyword%28%22mark.sheppard%40oracle.com%22%29%20or%20author%28msheppar%29%29&revcount=400 > [4] https://openjdk.java.net/census#msheppar > From michael.x.mcmahon at oracle.com Thu Apr 16 06:57:12 2020 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Thu, 16 Apr 2020 07:57:12 +0100 Subject: CFV: New JDK Reviewer: Mark Sheppard In-Reply-To: References: Message-ID: <7ac7bfd6-00c5-6a9c-281e-12baa13cd955@oracle.com> Vote: Yes On 15/04/2020 16:13, Chris Hegarty wrote: > I hereby nominate Mark Sheppard [4] to JDK Reviewer. > > Mark is currently a JDK Committer and a member of the Java Platform > Group at Oracle. Mark has more than 87 contributions [3]. > > Mark's contrubutions span a wide variet of areas; bug fixes, > enhancements and spec clarifications in the Netwokring area, security > improvements to CORBA, as well as changes and improvements in core > libraries. > > Votes are due by 29th April 2020, 16:00 UTC. > > 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]. > > -Chris. > > [1] https://openjdk.java.net/census#jdk > [2] https://openjdk.java.net/projects/#reviewer-vote > [3] https://hg.openjdk.java.net/jdk/jdk/search/?rev=%28keyword%28%22mark.sheppard%40oracle.com%22%29%20or%20author%28msheppar%29%29&revcount=400 > [4] https://openjdk.java.net/census#msheppar > From adinn at redhat.com Thu Apr 16 08:30:24 2020 From: adinn at redhat.com (Andrew Dinn) Date: Thu, 16 Apr 2020 09:30:24 +0100 Subject: CFV: New JDK Reviewer: Mark Sheppard In-Reply-To: References: Message-ID: <5888e800-099c-903a-78fc-696949b72a72@redhat.com> Vote: yes On 15/04/2020 16:13, Chris Hegarty wrote: > I hereby nominate Mark Sheppard [4] to JDK Reviewer. > > Mark is currently a JDK Committer and a member of the Java Platform > Group at Oracle. Mark has more than 87 contributions [3]. > > Mark's contrubutions span a wide variet of areas; bug fixes, > enhancements and spec clarifications in the Netwokring area, security > improvements to CORBA, as well as changes and improvements in core > libraries. > > Votes are due by 29th April 2020, 16:00 UTC. > > 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]. > > -Chris. > > [1] https://openjdk.java.net/census#jdk > [2] https://openjdk.java.net/projects/#reviewer-vote > [3] https://hg.openjdk.java.net/jdk/jdk/search/?rev=%28keyword%28%22mark.sheppard%40oracle.com%22%29%20or%20author%28msheppar%29%29&revcount=400 > [4] https://openjdk.java.net/census#msheppar > -- 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 magnus.ihse.bursie at oracle.com Thu Apr 16 10:45:27 2020 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 16 Apr 2020 12:45:27 +0200 Subject: CFV: New JDK Reviewer: Mark Sheppard In-Reply-To: References: Message-ID: Vote: yes /Magnus On 2020-04-15 17:13, Chris Hegarty wrote: > I hereby nominate Mark Sheppard [4] to JDK Reviewer. > > Mark is currently a JDK Committer and a member of the Java Platform > Group at Oracle. Mark has more than 87 contributions [3]. > > Mark's contrubutions span a wide variet of areas; bug fixes, > enhancements and spec clarifications in the Netwokring area, security > improvements to CORBA, as well as changes and improvements in core > libraries. > > Votes are due by 29th April 2020, 16:00 UTC. > > 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]. > > -Chris. > > [1] https://openjdk.java.net/census#jdk > [2] https://openjdk.java.net/projects/#reviewer-vote > [3] https://hg.openjdk.java.net/jdk/jdk/search/?rev=%28keyword%28%22mark.sheppard%40oracle.com%22%29%20or%20author%28msheppar%29%29&revcount=400 > [4] https://openjdk.java.net/census#msheppar > From Roger.Riggs at oracle.com Thu Apr 16 15:11:57 2020 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Thu, 16 Apr 2020 11:11:57 -0400 Subject: CFV: New JDK Reviewer: Amy Lu Message-ID: <7ef71ca0-fcd1-1230-13ea-4b00cf307d48@oracle.com> I hereby nominate Amy Lu [4] to JDK Reviewer. Amy is currently a JDK Committer and a member of the software quality team at Oracle, and has more than 150 contributions [3]. Amy has improved test stability, maintainability and coverage across areas of java.nio, java.util, java.lang, etc. Votes are due by 1st May, 2020, 16:00 UTC. Only current JDK Reviewers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Three Vote Consensus voting instructions, see [2]. Regards, Roger [1] https://openjdk.java.net/census#jdk [2] https://openjdk.java.net/projects/#reviewer-vote [3] http://hg.openjdk.java.net/jdk/jdk/log?revcount=400&rev=%28keyword%28%22amy.lu%40oracle.com%22%29+or+author%28amlu%29%29 [4] https://openjdk.java.net/census#almu From chris.hegarty at oracle.com Thu Apr 16 15:36:24 2020 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 16 Apr 2020 16:36:24 +0100 Subject: CFV: New JDK Reviewer: Amy Lu In-Reply-To: <7ef71ca0-fcd1-1230-13ea-4b00cf307d48@oracle.com> References: <7ef71ca0-fcd1-1230-13ea-4b00cf307d48@oracle.com> Message-ID: <1E0C7BAF-3AD8-4D45-A11F-27B4F836BE30@oracle.com> > On 16 Apr 2020, at 16:11, Roger Riggs wrote: > > I hereby nominate Amy Lu [4] to JDK Reviewer. Vote: YES -Chris From xuelei.fan at oracle.com Thu Apr 16 15:57:55 2020 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 16 Apr 2020 08:57:55 -0700 Subject: CFV: New JDK Reviewer: Amy Lu In-Reply-To: <7ef71ca0-fcd1-1230-13ea-4b00cf307d48@oracle.com> References: <7ef71ca0-fcd1-1230-13ea-4b00cf307d48@oracle.com> Message-ID: <16db73ed-b97f-4048-5b64-1e41e0273f98@oracle.com> Vote: Yes. Xuelei On 4/16/2020 8:11 AM, Roger Riggs wrote: > I hereby nominate Amy Lu [4] to JDK Reviewer. > > Amy is currently a JDK Committer and a member of the software quality > team at Oracle, and has more than 150 contributions [3]. > > Amy has improved test stability, maintainability and coverage across > areas of java.nio, java.util, java.lang, etc. > > Votes are due by 1st May, 2020, 16:00 UTC. > Only current JDK Reviewers [1] are eligible to vote on this nomination. > > Votes must be cast in the open by replying to this mailing list. > For Three Vote Consensus voting instructions, see [2]. > > Regards, Roger > > [1] https://openjdk.java.net/census#jdk > [2] https://openjdk.java.net/projects/#reviewer-vote > [3] > http://hg.openjdk.java.net/jdk/jdk/log?revcount=400&rev=%28keyword%28%22amy.lu%40oracle.com%22%29+or+author%28amlu%29%29 > > [4] https://openjdk.java.net/census#almu From Roger.Riggs at oracle.com Thu Apr 16 15:59:05 2020 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Thu, 16 Apr 2020 11:59:05 -0400 Subject: CFV: New JDK Reviewer: Amy Lu In-Reply-To: <7ef71ca0-fcd1-1230-13ea-4b00cf307d48@oracle.com> References: <7ef71ca0-fcd1-1230-13ea-4b00cf307d48@oracle.com> Message-ID: <3df1b135-9aa7-bab4-963f-d151dad17d7b@oracle.com> Vote: Yes On 4/16/20 11:11 AM, Roger Riggs wrote: > I hereby nominate Amy Lu [4] to JDK Reviewer. From andy.herrick at oracle.com Thu Apr 16 16:04:00 2020 From: andy.herrick at oracle.com (Andy Herrick) Date: Thu, 16 Apr 2020 12:04:00 -0400 Subject: CFV: New JDK Reviewer: Amy Lu In-Reply-To: <7ef71ca0-fcd1-1230-13ea-4b00cf307d48@oracle.com> References: <7ef71ca0-fcd1-1230-13ea-4b00cf307d48@oracle.com> Message-ID: <9098820f-c0a6-ea3f-d9de-966e020f970f@oracle.com> vote: yes /Andy On 4/16/2020 11:11 AM, Roger Riggs wrote: > I hereby nominate Amy Lu [4] to JDK Reviewer. > > Amy is currently a JDK Committer and a member of the software quality > team at Oracle, and has more than 150 contributions [3]. > > Amy has improved test stability, maintainability and coverage across > areas of java.nio, java.util, java.lang, etc. > > Votes are due by 1st May, 2020, 16:00 UTC. > Only current JDK Reviewers [1] are eligible to vote on this nomination. > > Votes must be cast in the open by replying to this mailing list. > For Three Vote Consensus voting instructions, see [2]. > > Regards, Roger > > [1] https://openjdk.java.net/census#jdk > [2] https://openjdk.java.net/projects/#reviewer-vote > [3] > http://hg.openjdk.java.net/jdk/jdk/log?revcount=400&rev=%28keyword%28%22amy.lu%40oracle.com%22%29+or+author%28amlu%29%29 > > [4] https://openjdk.java.net/census#almu From joe.darcy at oracle.com Thu Apr 16 16:08:21 2020 From: joe.darcy at oracle.com (Joe Darcy) Date: Thu, 16 Apr 2020 09:08:21 -0700 Subject: CFV: New JDK Reviewer: Amy Lu In-Reply-To: <7ef71ca0-fcd1-1230-13ea-4b00cf307d48@oracle.com> References: <7ef71ca0-fcd1-1230-13ea-4b00cf307d48@oracle.com> Message-ID: <40ba93cd-1681-97e8-7ff7-e6c1c86dd1bb@oracle.com> Vote: yes -Joe On 4/16/2020 8:11 AM, Roger Riggs wrote: > I hereby nominate Amy Lu [4] to JDK Reviewer. > > Amy is currently a JDK Committer and a member of the software quality > team at Oracle, and has more than 150 contributions [3]. > > Amy has improved test stability, maintainability and coverage across > areas of java.nio, java.util, java.lang, etc. > > Votes are due by 1st May, 2020, 16:00 UTC. > Only current JDK Reviewers [1] are eligible to vote on this nomination. > > Votes must be cast in the open by replying to this mailing list. > For Three Vote Consensus voting instructions, see [2]. > > Regards, Roger > > [1] https://openjdk.java.net/census#jdk > [2] https://openjdk.java.net/projects/#reviewer-vote > [3] > http://hg.openjdk.java.net/jdk/jdk/log?revcount=400&rev=%28keyword%28%22amy.lu%40oracle.com%22%29+or+author%28amlu%29%29 > > [4] https://openjdk.java.net/census#almu From james.laskey at oracle.com Thu Apr 16 16:10:16 2020 From: james.laskey at oracle.com (Jim Laskey) Date: Thu, 16 Apr 2020 13:10:16 -0300 Subject: CFV: New JDK Reviewer: Amy Lu In-Reply-To: <7ef71ca0-fcd1-1230-13ea-4b00cf307d48@oracle.com> References: <7ef71ca0-fcd1-1230-13ea-4b00cf307d48@oracle.com> Message-ID: <65A13724-BA6C-4B08-A0AB-3A96C47186F2@oracle.com> Vote: Yes > On Apr 16, 2020, at 12:11 PM, Roger Riggs wrote: > > I hereby nominate Amy Lu [4] to JDK Reviewer. > > Amy is currently a JDK Committer and a member of the software quality team at Oracle, and has more than 150 contributions [3]. > > Amy has improved test stability, maintainability and coverage across areas of java.nio, java.util, java.lang, etc. > > Votes are due by 1st May, 2020, 16:00 UTC. > Only current JDK Reviewers [1] are eligible to vote on this nomination. > > Votes must be cast in the open by replying to this mailing list. > For Three Vote Consensus voting instructions, see [2]. > > Regards, Roger > > [1] https://openjdk.java.net/census#jdk > [2] https://openjdk.java.net/projects/#reviewer-vote > [3] http://hg.openjdk.java.net/jdk/jdk/log?revcount=400&rev=%28keyword%28%22amy.lu%40oracle.com%22%29+or+author%28amlu%29%29 > [4] https://openjdk.java.net/census#almu From huizhe.wang at oracle.com Thu Apr 16 16:22:43 2020 From: huizhe.wang at oracle.com (Joe Wang) Date: Thu, 16 Apr 2020 09:22:43 -0700 Subject: CFV: New JDK Reviewer: Amy Lu In-Reply-To: <7ef71ca0-fcd1-1230-13ea-4b00cf307d48@oracle.com> References: <7ef71ca0-fcd1-1230-13ea-4b00cf307d48@oracle.com> Message-ID: <2fb6876b-1c14-ecdd-d29f-1d08f89842af@oracle.com> Vote: YES -Joe On 4/16/20 8:11 AM, Roger Riggs wrote: > I hereby nominate Amy Lu [4] to JDK Reviewer. From huizhe.wang at oracle.com Thu Apr 16 16:23:15 2020 From: huizhe.wang at oracle.com (Joe Wang) Date: Thu, 16 Apr 2020 09:23:15 -0700 Subject: CFV: New JDK Reviewer: Mark Sheppard In-Reply-To: References: Message-ID: <5ca01f1b-00aa-a97d-a6bf-b782c2da126c@oracle.com> Vote: YES -Joe On 4/15/20 8:13 AM, Chris Hegarty wrote: > I hereby nominate Mark Sheppard [4] to JDK Reviewer. From mandy.chung at oracle.com Thu Apr 16 16:33:51 2020 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 16 Apr 2020 09:33:51 -0700 Subject: CFV: New JDK Reviewer: Amy Lu In-Reply-To: <7ef71ca0-fcd1-1230-13ea-4b00cf307d48@oracle.com> References: <7ef71ca0-fcd1-1230-13ea-4b00cf307d48@oracle.com> Message-ID: <22c97a6a-e5c1-a908-f8fb-fbaa4ebbf893@oracle.com> Vote: yes Mandy On 4/16/20 8:11 AM, Roger Riggs wrote: > I hereby nominate Amy Lu [4] to JDK Reviewer. > > Amy is currently a JDK Committer and a member of the software quality > team at Oracle, and has more than 150 contributions [3]. > > Amy has improved test stability, maintainability and coverage across > areas of java.nio, java.util, java.lang, etc. > > Votes are due by 1st May, 2020, 16:00 UTC. > Only current JDK Reviewers [1] are eligible to vote on this nomination. > > Votes must be cast in the open by replying to this mailing list. > For Three Vote Consensus voting instructions, see [2]. > > Regards, Roger > > [1] https://openjdk.java.net/census#jdk > [2] https://openjdk.java.net/projects/#reviewer-vote > [3] > http://hg.openjdk.java.net/jdk/jdk/log?revcount=400&rev=%28keyword%28%22amy.lu%40oracle.com%22%29+or+author%28amlu%29%29 > > [4] https://openjdk.java.net/census#almu From mandy.chung at oracle.com Thu Apr 16 16:46:21 2020 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 16 Apr 2020 09:46:21 -0700 Subject: CFV: New JDK Reviewer: Mark Sheppard In-Reply-To: References: Message-ID: Vote: yes Mandy On 4/15/20 8:13 AM, Chris Hegarty wrote: > I hereby nominate Mark Sheppard [4] to JDK Reviewer. > > Mark is currently a JDK Committer and a member of the Java Platform > Group at Oracle. Mark has more than 87 contributions [3]. > > Mark's contrubutions span a wide variet of areas; bug fixes, > enhancements and spec clarifications in the Netwokring area, security > improvements to CORBA, as well as changes and improvements in core > libraries. > > Votes are due by 29th April 2020, 16:00 UTC. > > 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]. > > -Chris. > > [1] https://openjdk.java.net/census#jdk > [2] https://openjdk.java.net/projects/#reviewer-vote > [3] https://hg.openjdk.java.net/jdk/jdk/search/?rev=%28keyword%28%22mark.sheppard%40oracle.com%22%29%20or%20author%28msheppar%29%29&revcount=400 > [4] https://openjdk.java.net/census#msheppar > From daniel.fuchs at oracle.com Thu Apr 16 17:20:28 2020 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Thu, 16 Apr 2020 18:20:28 +0100 Subject: CFV: New JDK Reviewer: Amy Lu In-Reply-To: <7ef71ca0-fcd1-1230-13ea-4b00cf307d48@oracle.com> References: <7ef71ca0-fcd1-1230-13ea-4b00cf307d48@oracle.com> Message-ID: <33555266-4969-9097-c350-62f5f41a3427@oracle.com> Vote: yes best regards, -- daniel On 16/04/2020 16:11, Roger Riggs wrote: > I hereby nominate Amy Lu [4] to JDK Reviewer. From brent.christian at oracle.com Thu Apr 16 17:44:44 2020 From: brent.christian at oracle.com (Brent Christian) Date: Thu, 16 Apr 2020 10:44:44 -0700 Subject: CFV: New JDK Reviewer: Amy Lu In-Reply-To: <7ef71ca0-fcd1-1230-13ea-4b00cf307d48@oracle.com> References: <7ef71ca0-fcd1-1230-13ea-4b00cf307d48@oracle.com> Message-ID: <0be4a103-b573-0c6d-4e2a-d805635c84a9@oracle.com> Vote: Yes -Brent On 4/16/20 8:11 AM, Roger Riggs wrote: > I hereby nominate Amy Lu [4] to JDK Reviewer. > From brent.christian at oracle.com Thu Apr 16 17:45:37 2020 From: brent.christian at oracle.com (Brent Christian) Date: Thu, 16 Apr 2020 10:45:37 -0700 Subject: CFV: New JDK Reviewer: Mark Sheppard In-Reply-To: References: Message-ID: Vote: Yes -Brent On 4/15/20 8:13 AM, Chris Hegarty wrote: > I hereby nominate Mark Sheppard [4] to JDK Reviewer. > From harold.seigel at oracle.com Thu Apr 16 17:46:57 2020 From: harold.seigel at oracle.com (Harold Seigel) Date: Thu, 16 Apr 2020 13:46:57 -0400 Subject: CFV: New JDK Reviewer: Amy Lu In-Reply-To: <7ef71ca0-fcd1-1230-13ea-4b00cf307d48@oracle.com> References: <7ef71ca0-fcd1-1230-13ea-4b00cf307d48@oracle.com> Message-ID: Vote: yes Thanks, Harold On 4/16/2020 11:11 AM, Roger Riggs wrote: > I hereby nominate Amy Lu [4] to JDK Reviewer. > > Amy is currently a JDK Committer and a member of the software quality > team at Oracle, and has more than 150 contributions [3]. > > Amy has improved test stability, maintainability and coverage across > areas of java.nio, java.util, java.lang, etc. > > Votes are due by 1st May, 2020, 16:00 UTC. > Only current JDK Reviewers [1] are eligible to vote on this nomination. > > Votes must be cast in the open by replying to this mailing list. > For Three Vote Consensus voting instructions, see [2]. > > Regards, Roger > > [1] https://openjdk.java.net/census#jdk > [2] https://openjdk.java.net/projects/#reviewer-vote > [3] > http://hg.openjdk.java.net/jdk/jdk/log?revcount=400&rev=%28keyword%28%22amy.lu%40oracle.com%22%29+or+author%28amlu%29%29 > > [4] https://openjdk.java.net/census#almu From paul.sandoz at oracle.com Thu Apr 16 17:59:29 2020 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 16 Apr 2020 10:59:29 -0700 Subject: CFV: New JDK Reviewer: Mark Sheppard In-Reply-To: References: Message-ID: <27292765-29A8-405E-B634-53AAD535C403@oracle.com> Vote: yes Paul. From hohensee at amazon.com Thu Apr 16 18:10:50 2020 From: hohensee at amazon.com (Hohensee, Paul) Date: Thu, 16 Apr 2020 18:10:50 +0000 Subject: CFV: New JDK Reviewer: Amy Lu Message-ID: <58BF467B-C638-4E28-93C7-070DFDC4D9BC@amazon.com> Vote: yes ?On 4/16/20, 8:14 AM, "jdk-dev on behalf of Roger Riggs" wrote: I hereby nominate Amy Lu [4] to JDK Reviewer. Amy is currently a JDK Committer and a member of the software quality team at Oracle, and has more than 150 contributions [3]. Amy has improved test stability, maintainability and coverage across areas of java.nio, java.util, java.lang, etc. Votes are due by 1st May, 2020, 16:00 UTC. Only current JDK Reviewers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Three Vote Consensus voting instructions, see [2]. Regards, Roger [1] https://openjdk.java.net/census#jdk [2] https://openjdk.java.net/projects/#reviewer-vote [3] http://hg.openjdk.java.net/jdk/jdk/log?revcount=400&rev=%28keyword%28%22amy.lu%40oracle.com%22%29+or+author%28amlu%29%29 [4] https://openjdk.java.net/census#almu From thomas.stuefe at gmail.com Thu Apr 16 18:24:35 2020 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 16 Apr 2020 20:24:35 +0200 Subject: CFV: New JDK Reviewer: Amy Lu In-Reply-To: <7ef71ca0-fcd1-1230-13ea-4b00cf307d48@oracle.com> References: <7ef71ca0-fcd1-1230-13ea-4b00cf307d48@oracle.com> Message-ID: Vote: yes. On Thu, Apr 16, 2020 at 5:14 PM Roger Riggs wrote: > I hereby nominate Amy Lu [4] to JDK Reviewer. > > Amy is currently a JDK Committer and a member of the software quality > team at Oracle, and has more than 150 contributions [3]. > > Amy has improved test stability, maintainability and coverage across > areas of java.nio, java.util, java.lang, etc. > > Votes are due by 1st May, 2020, 16:00 UTC. > Only current JDK Reviewers [1] are eligible to vote on this nomination. > > Votes must be cast in the open by replying to this mailing list. > For Three Vote Consensus voting instructions, see [2]. > > Regards, Roger > > [1] https://openjdk.java.net/census#jdk > [2] https://openjdk.java.net/projects/#reviewer-vote > [3] > > http://hg.openjdk.java.net/jdk/jdk/log?revcount=400&rev=%28keyword%28%22amy.lu%40oracle.com%22%29+or+author%28amlu%29%29 > > [4] https://openjdk.java.net/census#almu > From netbeans at post.cz Thu Apr 16 13:18:29 2020 From: netbeans at post.cz (netbeans at post.cz) Date: Thu, 16 Apr 2020 15:18:29 +0200 (CEST) Subject: Java API Improvements Message-ID: <21s.3VYJN.5YmxoWlM95o.1Uc5ib@seznam.cz> Improvement Stream: public default Stream unless(Predicate predicate) { //predicate.negate () public default Stream nonNull() { //So instead of filter((o) -> o != null) public > Stream cast(Z cl) // instead of filter( (o)->o == null || o instanceof Class).map(Class::cast) //Maybe more readable for non-native-English-speakers public default Stream andIf(Predicate predicate) //alias for filter public default Stream andIfNot(Predicate predicate) //alias to unless Improvement Optional: implements Serializable //if T instanceof Serializable public void ifEmpty(Runnable action) public > Optional cast(Z cl) //filter((o)->o instanceof Class).map(Class::cast) public Optional unless(Predicate predicate) //Maybe more readable for non-native-English-speakers public Optional andIf(Predicate predicate) public Optional andIfNot(Predicate predicate) Improvement Predicate: implements Serializable //if T instanceof Serializable public default Predicate andNot(Predicate predicate) //less lambdas public static Predicate allMatch(Z... what) public static Predicate noneMatch(Z... what) public static Predicate anyMatch(Z... what) public static Predicate isNull() public static Predicate nonNull() Improvement String: public static boolean isNotNullAndBlank(String value) public static boolean isNotNullAndEmpty(String value) Improving "var": SomeClass z; ... ofNullable(z).filter(var::isSomething) // instead of filter(SomeClass:: isSomething) From adinn at redhat.com Thu Apr 16 19:52:59 2020 From: adinn at redhat.com (Andrew Dinn) Date: Thu, 16 Apr 2020 20:52:59 +0100 Subject: CFV: New JDK Reviewer: Amy Lu In-Reply-To: <7ef71ca0-fcd1-1230-13ea-4b00cf307d48@oracle.com> References: <7ef71ca0-fcd1-1230-13ea-4b00cf307d48@oracle.com> Message-ID: Vote: yes On 16/04/2020 16:11, Roger Riggs wrote: > I hereby nominate Amy Lu [4] to JDK Reviewer. > > Amy is currently a JDK Committer and a member of the software quality > team at Oracle, and has more than 150 contributions [3]. > > Amy has improved test stability, maintainability and coverage across > areas of java.nio, java.util, java.lang, etc. > > Votes are due by 1st May, 2020, 16:00 UTC. > Only current JDK Reviewers [1] are eligible to vote on this nomination. > > Votes must be cast in the open by replying to this mailing list. > For Three Vote Consensus voting instructions, see [2]. > > Regards, Roger > > [1] https://openjdk.java.net/census#jdk > [2] https://openjdk.java.net/projects/#reviewer-vote > [3] > http://hg.openjdk.java.net/jdk/jdk/log?revcount=400&rev=%28keyword%28%22amy.lu%40oracle.com%22%29+or+author%28amlu%29%29 > > [4] https://openjdk.java.net/census#almu > -- 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 sha.jiang at oracle.com Thu Apr 16 22:29:09 2020 From: sha.jiang at oracle.com (sha.jiang at oracle.com) Date: Fri, 17 Apr 2020 06:29:09 +0800 Subject: CFV: New JDK Reviewer: Amy Lu In-Reply-To: <7ef71ca0-fcd1-1230-13ea-4b00cf307d48@oracle.com> References: <7ef71ca0-fcd1-1230-13ea-4b00cf307d48@oracle.com> Message-ID: Vote: Yes Best regards, John Jiang On 2020/4/16 23:11, Roger Riggs wrote: > I hereby nominate Amy Lu [4] to JDK Reviewer. > > Amy is currently a JDK Committer and a member of the software quality > team at Oracle, and has more than 150 contributions [3]. > > Amy has improved test stability, maintainability and coverage across > areas of java.nio, java.util, java.lang, etc. > > Votes are due by 1st May, 2020, 16:00 UTC. > Only current JDK Reviewers [1] are eligible to vote on this nomination. > > Votes must be cast in the open by replying to this mailing list. > For Three Vote Consensus voting instructions, see [2]. > > Regards, Roger > > [1] https://openjdk.java.net/census#jdk > [2] https://openjdk.java.net/projects/#reviewer-vote > [3] > http://hg.openjdk.java.net/jdk/jdk/log?revcount=400&rev=%28keyword%28%22amy.lu%40oracle.com%22%29+or+author%28amlu%29%29 > > [4] https://openjdk.java.net/census#almu From brian.burkhalter at oracle.com Thu Apr 16 22:56:15 2020 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Thu, 16 Apr 2020 15:56:15 -0700 Subject: CFV: New JDK Reviewer: Mark Sheppard Message-ID: <5C796C9E-0A67-43EC-B361-7976DA18E39B@oracle.com> Vote: yes Brian On 4/15/20 8:13 AM, Chris Hegarty wrote: > I hereby nominate Mark Sheppard [4] to JDK Reviewer. From igor.ignatyev at oracle.com Thu Apr 16 23:19:28 2020 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Thu, 16 Apr 2020 16:19:28 -0700 Subject: CFV: New JDK Reviewer: Amy Lu In-Reply-To: <7ef71ca0-fcd1-1230-13ea-4b00cf307d48@oracle.com> References: <7ef71ca0-fcd1-1230-13ea-4b00cf307d48@oracle.com> Message-ID: Vote: yes -- Igor > On Apr 16, 2020, at 8:11 AM, Roger Riggs wrote: > > I hereby nominate Amy Lu [4] to JDK Reviewer. From weijun.wang at oracle.com Fri Apr 17 05:54:15 2020 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 17 Apr 2020 13:54:15 +0800 Subject: CFV: New JDK Reviewer: Amy Lu In-Reply-To: <7ef71ca0-fcd1-1230-13ea-4b00cf307d48@oracle.com> References: <7ef71ca0-fcd1-1230-13ea-4b00cf307d48@oracle.com> Message-ID: <4872F487-4836-41BB-A2DA-8FFCB27F2933@oracle.com> Vote: YES -weijun > On Apr 16, 2020, at 11:11 PM, Roger Riggs wrote: > > I hereby nominate Amy Lu [4] to JDK Reviewer. From JAYATHIRTH.D.V at ORACLE.COM Fri Apr 17 06:25:38 2020 From: JAYATHIRTH.D.V at ORACLE.COM (Jayathirth D v) Date: Fri, 17 Apr 2020 11:55:38 +0530 Subject: CFV: New JDK Reviewer: Amy Lu In-Reply-To: <7ef71ca0-fcd1-1230-13ea-4b00cf307d48@oracle.com> References: <7ef71ca0-fcd1-1230-13ea-4b00cf307d48@oracle.com> Message-ID: <266DE5A7-D4F3-4749-8B2C-0ACAA9C0C54B@ORACLE.COM> Vote : Yes Thanks, Jay > On 16-Apr-2020, at 8:41 PM, Roger Riggs wrote: > > I hereby nominate Amy Lu [4] to JDK Reviewer. > > Amy is currently a JDK Committer and a member of the software quality team at Oracle, and has more than 150 contributions [3]. > > Amy has improved test stability, maintainability and coverage across areas of java.nio, java.util, java.lang, etc. > > Votes are due by 1st May, 2020, 16:00 UTC. > Only current JDK Reviewers [1] are eligible to vote on this nomination. > > Votes must be cast in the open by replying to this mailing list. > For Three Vote Consensus voting instructions, see [2]. > > Regards, Roger > > [1] https://openjdk.java.net/census#jdk > [2] https://openjdk.java.net/projects/#reviewer-vote > [3] http://hg.openjdk.java.net/jdk/jdk/log?revcount=400&rev=%28keyword%28%22amy.lu%40oracle.com%22%29+or+author%28amlu%29%29 > [4] https://openjdk.java.net/census#almu From huaming.li at oracle.com Fri Apr 17 06:33:03 2020 From: huaming.li at oracle.com (Hamlin Li) Date: Fri, 17 Apr 2020 14:33:03 +0800 Subject: CFV: New JDK Reviewer: Amy Lu In-Reply-To: <266DE5A7-D4F3-4749-8B2C-0ACAA9C0C54B@ORACLE.COM> References: <7ef71ca0-fcd1-1230-13ea-4b00cf307d48@oracle.com> <266DE5A7-D4F3-4749-8B2C-0ACAA9C0C54B@ORACLE.COM> Message-ID: Vote: yes On 2020/4/17 2:25 PM, Jayathirth D v wrote: > Vote : Yes > > Thanks, > Jay > >> On 16-Apr-2020, at 8:41 PM, Roger Riggs wrote: >> >> I hereby nominate Amy Lu [4] to JDK Reviewer. >> >> Amy is currently a JDK Committer and a member of the software quality team at Oracle, and has more than 150 contributions [3]. >> >> Amy has improved test stability, maintainability and coverage across areas of java.nio, java.util, java.lang, etc. >> >> Votes are due by 1st May, 2020, 16:00 UTC. >> Only current JDK Reviewers [1] are eligible to vote on this nomination. >> >> Votes must be cast in the open by replying to this mailing list. >> For Three Vote Consensus voting instructions, see [2]. >> >> Regards, Roger >> >> [1] https://openjdk.java.net/census#jdk >> [2] https://openjdk.java.net/projects/#reviewer-vote >> [3] http://hg.openjdk.java.net/jdk/jdk/log?revcount=400&rev=%28keyword%28%22amy.lu%40oracle.com%22%29+or+author%28amlu%29%29 >> [4] https://openjdk.java.net/census#almu From dmitry.markov at oracle.com Fri Apr 17 06:34:40 2020 From: dmitry.markov at oracle.com (Dmitry Markov) Date: Fri, 17 Apr 2020 07:34:40 +0100 Subject: CFV: New JDK Reviewer: Amy Lu In-Reply-To: <7ef71ca0-fcd1-1230-13ea-4b00cf307d48@oracle.com> References: <7ef71ca0-fcd1-1230-13ea-4b00cf307d48@oracle.com> Message-ID: <879FF912-411B-4084-97F8-D61E07B740C7@oracle.com> Vote: Yes Regards, Dmitry > On 16 Apr 2020, at 16:11, Roger Riggs wrote: > > I hereby nominate Amy Lu [4] to JDK Reviewer. > > Amy is currently a JDK Committer and a member of the software quality team at Oracle, and has more than 150 contributions [3]. > > Amy has improved test stability, maintainability and coverage across areas of java.nio, java.util, java.lang, etc. > > Votes are due by 1st May, 2020, 16:00 UTC. > Only current JDK Reviewers [1] are eligible to vote on this nomination. > > Votes must be cast in the open by replying to this mailing list. > For Three Vote Consensus voting instructions, see [2]. > > Regards, Roger > > [1] https://openjdk.java.net/census#jdk > [2] https://openjdk.java.net/projects/#reviewer-vote > [3] http://hg.openjdk.java.net/jdk/jdk/log?revcount=400&rev=%28keyword%28%22amy.lu%40oracle.com%22%29+or+author%28amlu%29%29 > [4] https://openjdk.java.net/census#almu From dmitry.markov at oracle.com Fri Apr 17 06:36:13 2020 From: dmitry.markov at oracle.com (Dmitry Markov) Date: Fri, 17 Apr 2020 07:36:13 +0100 Subject: CFV: New JDK Reviewer: Mark Sheppard In-Reply-To: References: Message-ID: <125C2F61-F972-4AD0-85A1-9CBCCB9743C2@oracle.com> Vote: Yes Regards, Dmitry > On 15 Apr 2020, at 16:13, Chris Hegarty wrote: > > I hereby nominate Mark Sheppard [4] to JDK Reviewer. > > Mark is currently a JDK Committer and a member of the Java Platform > Group at Oracle. Mark has more than 87 contributions [3]. > > Mark's contrubutions span a wide variet of areas; bug fixes, > enhancements and spec clarifications in the Netwokring area, security > improvements to CORBA, as well as changes and improvements in core > libraries. > > Votes are due by 29th April 2020, 16:00 UTC. > > 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]. > > -Chris. > > [1] https://openjdk.java.net/census#jdk > [2] https://openjdk.java.net/projects/#reviewer-vote > [3] https://hg.openjdk.java.net/jdk/jdk/search/?rev=%28keyword%28%22mark.sheppard%40oracle.com%22%29%20or%20author%28msheppar%29%29&revcount=400 > [4] https://openjdk.java.net/census#msheppar > From huaming.li at oracle.com Fri Apr 17 06:40:40 2020 From: huaming.li at oracle.com (Hamlin Li) Date: Fri, 17 Apr 2020 14:40:40 +0800 Subject: CFV: New JDK Reviewer: Mark Sheppard In-Reply-To: References: Message-ID: Vote: yes On 2020/4/15 11:13 PM, Chris Hegarty wrote: > I hereby nominate Mark Sheppard [4] to JDK Reviewer. > > Mark is currently a JDK Committer and a member of the Java Platform > Group at Oracle. Mark has more than 87 contributions [3]. > > Mark's contrubutions span a wide variet of areas; bug fixes, > enhancements and spec clarifications in the Netwokring area, security > improvements to CORBA, as well as changes and improvements in core > libraries. > > Votes are due by 29th April 2020, 16:00 UTC. > > 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]. > > -Chris. > > [1] https://openjdk.java.net/census#jdk > [2] https://openjdk.java.net/projects/#reviewer-vote > [3] https://hg.openjdk.java.net/jdk/jdk/search/?rev=%28keyword%28%22mark.sheppard%40oracle.com%22%29%20or%20author%28msheppar%29%29&revcount=400 > [4] https://openjdk.java.net/census#msheppar > From netbeans at post.cz Fri Apr 17 06:24:23 2020 From: netbeans at post.cz (netbeans at post.cz) Date: Fri, 17 Apr 2020 08:24:23 +0200 (CEST) Subject: Java API Improvements Message-ID: <2kx.3VYJV.2jWSPrF4rvk.1UcKkN@seznam.cz> In context: https://mail.openjdk.java.net/pipermail/jdk-dev/2020-April/004240.html Improvement String: Instead of: public static boolean isNotNullAndBlank(String value) public static boolean isNotNullAndEmpty(String value) in case of adding "unless" (Stream; see link above): public static boolean isNullOrBlank(String value) public static boolean isNullOrEmpty(String value) Improvement CharSequence: //if below ones are added then isNullOrBlank and isNullOrEmpty could goes there public default isEmpty(); public default isBlank(); From Alan.Bateman at oracle.com Fri Apr 17 07:55:43 2020 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 17 Apr 2020 08:55:43 +0100 Subject: CFV: New JDK Reviewer: Amy Lu In-Reply-To: <7ef71ca0-fcd1-1230-13ea-4b00cf307d48@oracle.com> References: <7ef71ca0-fcd1-1230-13ea-4b00cf307d48@oracle.com> Message-ID: <61483ce7-fc49-329f-8d0a-19e4ee42790b@oracle.com> Vote: yes From naoto.sato at oracle.com Fri Apr 17 15:53:38 2020 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Fri, 17 Apr 2020 08:53:38 -0700 Subject: CFV: New JDK Reviewer: Amy Lu In-Reply-To: <7ef71ca0-fcd1-1230-13ea-4b00cf307d48@oracle.com> References: <7ef71ca0-fcd1-1230-13ea-4b00cf307d48@oracle.com> Message-ID: Vote: yes Naoto On 4/16/20 8:11 AM, Roger Riggs wrote: > I hereby nominate Amy Lu [4] to JDK Reviewer. > > Amy is currently a JDK Committer and a member of the software quality > team at Oracle, and has more than 150 contributions [3]. > > Amy has improved test stability, maintainability and coverage across > areas of java.nio, java.util, java.lang, etc. > > Votes are due by 1st May, 2020, 16:00 UTC. > Only current JDK Reviewers [1] are eligible to vote on this nomination. > > Votes must be cast in the open by replying to this mailing list. > For Three Vote Consensus voting instructions, see [2]. > > Regards, Roger > > [1] https://openjdk.java.net/census#jdk > [2] https://openjdk.java.net/projects/#reviewer-vote > [3] > http://hg.openjdk.java.net/jdk/jdk/log?revcount=400&rev=%28keyword%28%22amy.lu%40oracle.com%22%29+or+author%28amlu%29%29 > > [4] https://openjdk.java.net/census#almu From pavel.rappo at oracle.com Fri Apr 17 15:58:28 2020 From: pavel.rappo at oracle.com (Pavel Rappo) Date: Fri, 17 Apr 2020 16:58:28 +0100 Subject: CFV: New JDK Reviewer: Amy Lu In-Reply-To: <7ef71ca0-fcd1-1230-13ea-4b00cf307d48@oracle.com> References: <7ef71ca0-fcd1-1230-13ea-4b00cf307d48@oracle.com> Message-ID: <16FCF245-2B0C-4B28-BA03-1B324CDE10EC@oracle.com> Vote: yes > On 16 Apr 2020, at 16:11, Roger Riggs wrote: > > I hereby nominate Amy Lu [4] to JDK Reviewer. > > Amy is currently a JDK Committer and a member of the software quality team at Oracle, and has more than 150 contributions [3]. > > Amy has improved test stability, maintainability and coverage across areas of java.nio, java.util, java.lang, etc. > > Votes are due by 1st May, 2020, 16:00 UTC. > Only current JDK Reviewers [1] are eligible to vote on this nomination. > > Votes must be cast in the open by replying to this mailing list. > For Three Vote Consensus voting instructions, see [2]. > > Regards, Roger > > [1] https://openjdk.java.net/census#jdk > [2] https://openjdk.java.net/projects/#reviewer-vote > [3] http://hg.openjdk.java.net/jdk/jdk/log?revcount=400&rev=%28keyword%28%22amy.lu%40oracle.com%22%29+or+author%28amlu%29%29 > [4] https://openjdk.java.net/census#almu From volker.simonis at gmail.com Fri Apr 17 16:03:06 2020 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 17 Apr 2020 18:03:06 +0200 Subject: CFV: New JDK Reviewer: Amy Lu In-Reply-To: <7ef71ca0-fcd1-1230-13ea-4b00cf307d48@oracle.com> References: <7ef71ca0-fcd1-1230-13ea-4b00cf307d48@oracle.com> Message-ID: Vote: yes On Thu, Apr 16, 2020 at 5:13 PM Roger Riggs wrote: > > I hereby nominate Amy Lu [4] to JDK Reviewer. > > Amy is currently a JDK Committer and a member of the software quality > team at Oracle, and has more than 150 contributions [3]. > > Amy has improved test stability, maintainability and coverage across > areas of java.nio, java.util, java.lang, etc. > > Votes are due by 1st May, 2020, 16:00 UTC. > Only current JDK Reviewers [1] are eligible to vote on this nomination. > > Votes must be cast in the open by replying to this mailing list. > For Three Vote Consensus voting instructions, see [2]. > > Regards, Roger > > [1] https://openjdk.java.net/census#jdk > [2] https://openjdk.java.net/projects/#reviewer-vote > [3] > http://hg.openjdk.java.net/jdk/jdk/log?revcount=400&rev=%28keyword%28%22amy.lu%40oracle.com%22%29+or+author%28amlu%29%29 > > [4] https://openjdk.java.net/census#almu From calvin.cheung at oracle.com Fri Apr 17 16:11:00 2020 From: calvin.cheung at oracle.com (Calvin Cheung) Date: Fri, 17 Apr 2020 09:11:00 -0700 Subject: CFV: New JDK Reviewer: Amy Lu In-Reply-To: <7ef71ca0-fcd1-1230-13ea-4b00cf307d48@oracle.com> References: <7ef71ca0-fcd1-1230-13ea-4b00cf307d48@oracle.com> Message-ID: Vote: yes On 4/16/20 8:11 AM, Roger Riggs wrote: > I hereby nominate Amy Lu [4] to JDK Reviewer. > > Amy is currently a JDK Committer and a member of the software quality > team at Oracle, and has more than 150 contributions [3]. > > Amy has improved test stability, maintainability and coverage across > areas of java.nio, java.util, java.lang, etc. > > Votes are due by 1st May, 2020, 16:00 UTC. > Only current JDK Reviewers [1] are eligible to vote on this nomination. > > Votes must be cast in the open by replying to this mailing list. > For Three Vote Consensus voting instructions, see [2]. > > Regards, Roger > > [1] https://openjdk.java.net/census#jdk > [2] https://openjdk.java.net/projects/#reviewer-vote > [3] > http://hg.openjdk.java.net/jdk/jdk/log?revcount=400&rev=%28keyword%28%22amy.lu%40oracle.com%22%29+or+author%28amlu%29%29 > > [4] https://openjdk.java.net/census#almu From sean.coffey at oracle.com Fri Apr 17 16:15:50 2020 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Fri, 17 Apr 2020 17:15:50 +0100 Subject: CFV: New JDK Reviewer: Amy Lu In-Reply-To: <7ef71ca0-fcd1-1230-13ea-4b00cf307d48@oracle.com> References: <7ef71ca0-fcd1-1230-13ea-4b00cf307d48@oracle.com> Message-ID: <04e0369b-f0eb-8096-9194-b4343f619e44@oracle.com> vote: yes regards, Sean. On 16/04/2020 16:11, Roger Riggs wrote: > I hereby nominate Amy Lu [4] to JDK Reviewer. > > Amy is currently a JDK Committer and a member of the software quality > team at Oracle, and has more than 150 contributions [3]. > > Amy has improved test stability, maintainability and coverage across > areas of java.nio, java.util, java.lang, etc. > > Votes are due by 1st May, 2020, 16:00 UTC. > Only current JDK Reviewers [1] are eligible to vote on this nomination. > > Votes must be cast in the open by replying to this mailing list. > For Three Vote Consensus voting instructions, see [2]. > > Regards, Roger > > [1] https://openjdk.java.net/census#jdk > [2] https://openjdk.java.net/projects/#reviewer-vote > [3] > http://hg.openjdk.java.net/jdk/jdk/log?revcount=400&rev=%28keyword%28%22amy.lu%40oracle.com%22%29+or+author%28amlu%29%29 > > [4] https://openjdk.java.net/census#almu From christoph.langer at sap.com Sun Apr 19 06:24:10 2020 From: christoph.langer at sap.com (Langer, Christoph) Date: Sun, 19 Apr 2020 06:24:10 +0000 Subject: CFV: New JDK Reviewer: Mark Sheppard In-Reply-To: References: Message-ID: Vote:yes /Christoph > -----Original Message----- > From: jdk-dev On Behalf Of Chris > Hegarty > Sent: Mittwoch, 15. April 2020 17:13 > To: jdk-dev > Subject: CFV: New JDK Reviewer: Mark Sheppard > > I hereby nominate Mark Sheppard [4] to JDK Reviewer. > > Mark is currently a JDK Committer and a member of the Java Platform > Group at Oracle. Mark has more than 87 contributions [3]. > > Mark's contrubutions span a wide variet of areas; bug fixes, > enhancements and spec clarifications in the Netwokring area, security > improvements to CORBA, as well as changes and improvements in core > libraries. > > Votes are due by 29th April 2020, 16:00 UTC. > > 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]. > > -Chris. > > [1] https://openjdk.java.net/census#jdk > [2] https://openjdk.java.net/projects/#reviewer-vote > [3] > https://hg.openjdk.java.net/jdk/jdk/search/?rev=%28keyword%28%22mark > .sheppard%40oracle.com%22%29%20or%20author%28msheppar%29%29&re > vcount=400 > [4] https://openjdk.java.net/census#msheppar From christoph.langer at sap.com Sun Apr 19 06:24:52 2020 From: christoph.langer at sap.com (Langer, Christoph) Date: Sun, 19 Apr 2020 06:24:52 +0000 Subject: CFV: New JDK Reviewer: Amy Lu In-Reply-To: <7ef71ca0-fcd1-1230-13ea-4b00cf307d48@oracle.com> References: <7ef71ca0-fcd1-1230-13ea-4b00cf307d48@oracle.com> Message-ID: Vote:yes /Christoph > -----Original Message----- > From: jdk-dev On Behalf Of Roger > Riggs > Sent: Donnerstag, 16. April 2020 17:12 > To: jdk-dev > Subject: CFV: New JDK Reviewer: Amy Lu > > I hereby nominate Amy Lu [4] to JDK Reviewer. > > Amy is currently a JDK Committer and a member of the software quality > team at Oracle, and has more than 150 contributions [3]. > > Amy has improved test stability, maintainability and coverage across > areas of java.nio, java.util, java.lang, etc. > > Votes are due by 1st May, 2020, 16:00 UTC. > Only current JDK Reviewers [1] are eligible to vote on this nomination. > > Votes must be cast in the open by replying to this mailing list. > For Three Vote Consensus voting instructions, see [2]. > > Regards, Roger > > [1] https://openjdk.java.net/census#jdk > [2] https://openjdk.java.net/projects/#reviewer-vote > [3] > http://hg.openjdk.java.net/jdk/jdk/log?revcount=400&rev=%28keyword%2 > 8%22amy.lu%40oracle.com%22%29+or+author%28amlu%29%29 > > [4] https://openjdk.java.net/census#almu From jianglizhou at google.com Mon Apr 20 03:19:57 2020 From: jianglizhou at google.com (Jiangli Zhou) Date: Sun, 19 Apr 2020 20:19:57 -0700 Subject: CFV: New JDK Reviewer: Amy Lu In-Reply-To: <7ef71ca0-fcd1-1230-13ea-4b00cf307d48@oracle.com> References: <7ef71ca0-fcd1-1230-13ea-4b00cf307d48@oracle.com> Message-ID: Vote:yes Best, Jiangli On Thu, Apr 16, 2020 at 8:13 AM Roger Riggs wrote: > > I hereby nominate Amy Lu [4] to JDK Reviewer. > > Amy is currently a JDK Committer and a member of the software quality > team at Oracle, and has more than 150 contributions [3]. > > Amy has improved test stability, maintainability and coverage across > areas of java.nio, java.util, java.lang, etc. > > Votes are due by 1st May, 2020, 16:00 UTC. > Only current JDK Reviewers [1] are eligible to vote on this nomination. > > Votes must be cast in the open by replying to this mailing list. > For Three Vote Consensus voting instructions, see [2]. > > Regards, Roger > > [1] https://openjdk.java.net/census#jdk > [2] https://openjdk.java.net/projects/#reviewer-vote > [3] > http://hg.openjdk.java.net/jdk/jdk/log?revcount=400&rev=%28keyword%28%22amy.lu%40oracle.com%22%29+or+author%28amlu%29%29 > > [4] https://openjdk.java.net/census#almu From alexey.ivanov at oracle.com Mon Apr 20 10:09:53 2020 From: alexey.ivanov at oracle.com (Alexey Ivanov) Date: Mon, 20 Apr 2020 11:09:53 +0100 Subject: CFV: New JDK Reviewer: Mark Sheppard In-Reply-To: References: Message-ID: <04b805a5-63f5-483c-1ff2-4cb15513592d@oracle.com> Vote: yes On 15/04/2020 16:13, Chris Hegarty wrote: > I hereby nominate Mark Sheppard [4] to JDK Reviewer. > > Mark is currently a JDK Committer and a member of the Java Platform > Group at Oracle. Mark has more than 87 contributions [3]. > > [3]https://hg.openjdk.java.net/jdk/jdk/search/?rev=%28keyword%28%22mark.sheppard%40oracle.com%22%29%20or%20author%28msheppar%29%29&revcount=400 > [4]https://openjdk.java.net/census#msheppar -- Regards, Alexey From lists at selckin.be Mon Apr 20 14:18:44 2020 From: lists at selckin.be (Thomas Matthijs) Date: Mon, 20 Apr 2020 16:18:44 +0200 Subject: Anybody working on a solution to the mailing list problems (a.k.a JDK-8213225)? In-Reply-To: <309dad5e-689e-a161-79f8-0e109b48b500@redhat.com> References: <871rpogmmi.fsf@mid.deneb.enyo.de> <309dad5e-689e-a161-79f8-0e109b48b500@redhat.com> Message-ID: Still interested in examples? marked as spam: http://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-April/011583.html SPF:PASS with IP 141.146.126.78 DKIM:'FAIL' with domain datadoghq.com DMARC:'FAIL' Received: by 2002:a92:6e01:0:0:0:0:0 with SMTP id j1csp3862954ilc; Mon, 20 Apr 2020 07:04:22 -0700 (PDT) X-Google-Smtp-Source: APiQypIIg1b2qDud68GCJ1D/cVyiL/42sbXZ3q00Pjh63LTvbCgklSZ+tuconluYnBMxeJUVvIS4 X-Received: by 2002:a02:3351:: with SMTP id k17mr15806701jak.31.1587391462061; Mon, 20 Apr 2020 07:04:22 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1587391462; cv=none; d=google.com; s=arc-20160816; b=QIGytMHel4ywjCupiCvBVTUd08Su+ti/2KJstpZXTcbdatmmALCJQVeCs/IRY5wvcA Jq36AOlNsf9dXhS+KnuzU26fABcbNEBSRg2wil1da4t8E3NRhPGjAiyKT+FNhHucnTdD e6dZN6XtXNARXDbXG/1s8rgdwA8CHQfinztFYuU0aG3Qci0bxzX6cmi91rP+/msWqRqe nIeqlLVVzlOnUhnH6PJ6srHNJ0sZqIjezAbyh14lkT+4rsXJb7EK/8S9auZY0l4dJj+d 9Le1wBYehXVE+/8r73br+inc6ldtzx1CFUY54GHL2h6ihDkrbuGiczB6Zc4LrQoSqJxi xjMw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=sender:errors-to:list-subscribe:list-help:list-post:list-archive :list-unsubscribe:list-id:precedence:to:subject:message-id:date:from :mime-version:dkim-signature:delivered-to; bh=Gk30/mnMrJmCupYnETd2D4uamD3Cf6A4J3rHDY13UWk=; b=dCl/RlUwd+3jTHCw9w7XMbVqWZc4GruElJeZQTKFWJQjv67AdIruo5qJqblZx712MM tk+ZWtXMD7eh21YhYdaHa2wDzfrBk2Br+kwZO7aPpdCwO8Q5rM6fbZq4g8l/Usx3XKCt ZQaFKPb5omhJrsa9L2YSMZGyfxMo7LMk9pz6ykv0bciq5qcaAr9xkaQumBJM1bmIA4iV WY9GAUclNYDvd7N2wn5M/rCPBQvmYTEGRJRj3f5ipjJnInxDOlF8f+tMMU23q6wYZEzP 0/vFIp9TZVYN92frJ2AuDR+5UCkolp50i5e1UiOT3EGnFwqrSdCbUawfp7dtRePYhGSa S7Gg== ARC-Authentication-Results: i=1; mx.google.com; dkim=neutral (body hash did not verify) header.i=@datadoghq.com header.s=google header.b=YVkCqAu0; spf=pass (google.com: domain of jdk8u-dev-bounces at openjdk.java.net designates 141.146.126.78 as permitted sender) smtp.mailfrom=jdk8u-dev-bounces at openjdk.java.net; dmarc=fail (p=REJECT sp=REJECT dis=QUARANTINE) header.from=datadoghq.com Return-Path: Received: from aserp2120.oracle.com (aserp2120.oracle.com. [141.146.126.78]) by mx.google.com with ESMTPS id j66si870607ilg.17.2020.04.20.07.04.21 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 20 Apr 2020 07:04:22 -0700 (PDT) Received-SPF: pass (google.com: domain of jdk8u-dev-bounces at openjdk.java.net designates 141.146.126.78 as permitted sender) client-ip=141.146.126.78; Authentication-Results: mx.google.com; dkim=neutral (body hash did not verify) header.i=@datadoghq.com header.s=google header.b=YVkCqAu0; spf=pass (google.com: domain of jdk8u-dev-bounces at openjdk.java.net designates 141.146.126.78 as permitted sender) smtp.mailfrom=jdk8u-dev-bounces at openjdk.java.net; dmarc=fail (p=REJECT sp=REJECT dis=QUARANTINE) header.from=datadoghq.com Received: from pps.filterd (aserp2120.oracle.com [127.0.0.1]) by aserp2120.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 03KDwM2q020311; Mon, 20 Apr 2020 14:03:15 GMT Received: from aserp3030.oracle.com (aserp3030.oracle.com [141.146.126.71]) by aserp2120.oracle.com with ESMTP id 30fsgkqdnh-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 20 Apr 2020 14:03:13 +0000 Received: from pps.filterd (aserp3030.oracle.com [127.0.0.1]) by aserp3030.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 03KDvWbt161095; Mon, 20 Apr 2020 14:03:13 GMT Received: from aojmv0009 (aojmv0009.oracle.com [137.254.59.6]) by aserp3030.oracle.com with ESMTP id 30gb3qg6xj-1; Mon, 20 Apr 2020 14:03:13 +0000 Received: from aojmv0009.oracle.com (localhost [127.0.0.1]) by aojmv0009 (Postfix) with ESMTP id 7C3C532592E; Mon, 20 Apr 2020 14:03:10 +0000 (UTC) X-Original-To: jdk8u-dev at openjdk.java.net Delivered-To: jdk8u-dev at openjdk.java.net Received: from userp3020.oracle.com (userp3020.oracle.com [156.151.31.79]) by aojmv0009 (Postfix) with ESMTP id 8F9D9325922 for ; Mon, 20 Apr 2020 14:02:55 +0000 (UTC) Received: from pps.filterd (userp3020.oracle.com [127.0.0.1]) by userp3020.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 03KDvNvW032066 for ; Mon, 20 Apr 2020 14:02:54 GMT Received: from userp2060.oracle.com (userp2060.oracle.com [156.151.31.92]) by userp3020.oracle.com with ESMTP id 30gb8whc8p-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Mon, 20 Apr 2020 14:02:54 +0000 Received: from pps.filterd (userp2060.oracle.com [127.0.0.1]) by userp2060.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 03KDxaEu070065 for ; Mon, 20 Apr 2020 14:02:54 GMT Received: from mail-wm1-f51.google.com (mail-wm1-f51.google.com [209.85.128.51]) by userp2060.oracle.com with ESMTP id 30fqbt2e6b-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=OK) for ; Mon, 20 Apr 2020 14:02:51 +0000 Received: by mail-wm1-f51.google.com with SMTP id h2so11170879wmb.4 for ; Mon, 20 Apr 2020 07:02:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=datadoghq.com; s=google; h=mime-version:from:date:message-id:subject:to; bh=FQGVpE0jxL+O4jaaDslirZFkbwPENeBuKf9/h4RqcU0=; b=YVkCqAu05TiKlj95N+CPQ8nIpHCgDalPQdEtt+CVHBT8MMdeziIdIo2Drp74U4tpo1 swLc+uzcN5wcR/wumUtj5Qw0dv0e2Z/wP0lxf1TqS0bc6oT2tjB9QWFWtiOkmkhnUglH Fo2EDLy9l3ZQdjH1H32mEWDKH/1VpOgGViKdQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=FQGVpE0jxL+O4jaaDslirZFkbwPENeBuKf9/h4RqcU0=; b=MT9NO8GZrMpXrIC1+yeAbnp3YU2pdgKMJHZVczorIS4Iz/R9ChSytS3z+bGjmr95C1 63RRa3At5F8Y6UBvJ4vQx3/reow+QYa3o/BnB/XhjPR5NTQpa2Cd5mU1ZcwymH9yfdu/ 5pNBw/mDmAR/vyDoA4TtCdUllGipsPeRL9vn4eByKA21ebrgWFTsL8/fCKX39NEOks2W iKFu4LhwoJdKiW1nXZIQFBRMbJrqGqwTF4mcX5wJ8ShtLj/TP1td62Nuc8CdCbh5U2h9 182mJequaCnXuW7UawrRNuNdPrnvhGkezaCIT6RhUhrTzhuVQKR1sJxaUJHFfE0US3rK oRJA== X-Gm-Message-State: AGi0PuYVNh/sUl7P8hTlm7NzOFPHutoCBiD9jmMR2MQcfKEi96UAnshD rW0j4ewtRFyY+xt/V0+u9VQ9b8lFN13kK8Ibf2DWcoOdNuhXuQ== X-Received: by 2002:a1c:2d14:: with SMTP id t20mr18008608wmt.28.1587391368948; Mon, 20 Apr 2020 07:02:48 -0700 (PDT) MIME-Version: 1.0 On Thu, 9 Apr 2020 at 11:09, Andrew Haley wrote: > > On 4/9/20 7:37 AM, Langer, Christoph wrote: > > thanks for your replies, kind of confirming THE problem or at least confirming that there IS a problem. > > > > It would be good if somebody from the Oracle infrastructure team could come forward, sharing their current status/view of the issue. Or if somebody could get into direct contact with me to help debugging the problem. > > It would help if we had some kind of idea about the actual problem. > Presumably gmail is using some kind of heuristic; I don't know because > I don't use gmail. So, please send a couple of false positives my way > and we'll try to figure out what the problem is. > > I'm not a great believer in "Let's upgrade to something modern" as an > obvious cure because modern solutions have their own problems. > > -- > 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 kusrinivasan at vmware.com Mon Apr 20 19:13:29 2020 From: kusrinivasan at vmware.com (Kumar Srinivasan) Date: Mon, 20 Apr 2020 19:13:29 +0000 Subject: CFV: New JDK Reviewer: Amy Lu In-Reply-To: <7ef71ca0-fcd1-1230-13ea-4b00cf307d48@oracle.com> References: <7ef71ca0-fcd1-1230-13ea-4b00cf307d48@oracle.com> Message-ID: <89482060-BDCC-41F6-80EB-D1828906D453@vmware.com> Vote: yes > On Apr 16, 2020, at 8:11 AM, Roger Riggs wrote: > > I hereby nominate Amy Lu [4] to JDK Reviewer. > > Amy is currently a JDK Committer and a member of the software quality team at Oracle, and has more than 150 contributions [3]. > > Amy has improved test stability, maintainability and coverage across areas of java.nio, java.util, java.lang, etc. > > Votes are due by 1st May, 2020, 16:00 UTC. > Only current JDK Reviewers [1] are eligible to vote on this nomination. > > Votes must be cast in the open by replying to this mailing list. > For Three Vote Consensus voting instructions, see [2]. > > Regards, Roger > > [1] https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fopenjdk.java.net%2Fcensus%23jdk&data=02%7C01%7Ckusrinivasan%40vmware.com%7Cce38e9490f0e4d2c0df308d7e218f6fd%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637226469171988693&sdata=ji1MUBh0M4w7gTaq23LnP4m%2FbRdlK5gFmX6CQG0KCrA%3D&reserved=0 > [2] https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fopenjdk.java.net%2Fprojects%2F%23reviewer-vote&data=02%7C01%7Ckusrinivasan%40vmware.com%7Cce38e9490f0e4d2c0df308d7e218f6fd%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637226469171988693&sdata=nc1kPn%2FA7SsdxDL8%2BgCZYpjvdTu0hH%2BXCohtYf%2Fcj7g%3D&reserved=0 > [3] https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fhg.openjdk.java.net%2Fjdk%2Fjdk%2Flog%3Frevcount%3D400%26rev%3D%2528keyword%2528%2522amy.lu%2540oracle.com%2522%2529%2Bor%2Bauthor%2528amlu%2529%2529&data=02%7C01%7Ckusrinivasan%40vmware.com%7Cce38e9490f0e4d2c0df308d7e218f6fd%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637226469171998700&sdata=s1cwP0dOmWZIqkrLvWyuhUNEzHWieq8%2BDXVBuOjrX1Q%3D&reserved=0 > [4] https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fopenjdk.java.net%2Fcensus%23almu&data=02%7C01%7Ckusrinivasan%40vmware.com%7Cce38e9490f0e4d2c0df308d7e218f6fd%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637226469171998700&sdata=zZ4umhKM2PTUYFq9h1dIkGkbNaZX87lAZdJnG0piv3c%3D&reserved=0 From paul.sandoz at oracle.com Mon Apr 20 19:19:18 2020 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 20 Apr 2020 12:19:18 -0700 Subject: CFV: New JDK Reviewer: Amy Lu In-Reply-To: <7ef71ca0-fcd1-1230-13ea-4b00cf307d48@oracle.com> References: <7ef71ca0-fcd1-1230-13ea-4b00cf307d48@oracle.com> Message-ID: <4760168C-2706-4BF1-867F-B2B763984A7A@oracle.com> Vote: yes Paul. From mark.reinhold at oracle.com Mon Apr 20 23:34:26 2020 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Mon, 20 Apr 2020 16:34:26 -0700 (PDT) Subject: New candidate JEP: 383: Foreign-Memory Access API (Second Incubator) Message-ID: <20200420233426.067AD322767@eggemoggin.niobe.net> https://openjdk.java.net/jeps/383 - Mark From fw at deneb.enyo.de Tue Apr 21 09:14:55 2020 From: fw at deneb.enyo.de (Florian Weimer) Date: Tue, 21 Apr 2020 11:14:55 +0200 Subject: Anybody working on a solution to the mailing list problems (a.k.a JDK-8213225)? In-Reply-To: (Thomas Matthijs's message of "Mon, 20 Apr 2020 16:18:44 +0200") References: <871rpogmmi.fsf@mid.deneb.enyo.de> <309dad5e-689e-a161-79f8-0e109b48b500@redhat.com> Message-ID: <87r1whurn4.fsf@mid.deneb.enyo.de> * Thomas Matthijs: > Still interested in examples? > marked as spam: > http://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-April/011583.html The header has: X-Content-Filtered-By: Mailman/MimeDel 2.1.17 I suspect it's the same issue I already mentioned: The text/html part was stripped by the mailing list software. Of course that changes the message body, and so the DKIM signature no longer verifies. The workaround is not send text/html multipart messages to the mailing lists. From stuart.marks at oracle.com Tue Apr 21 16:38:48 2020 From: stuart.marks at oracle.com (Stuart Marks) Date: Tue, 21 Apr 2020 09:38:48 -0700 Subject: CFV: New JDK Reviewer: Amy Lu In-Reply-To: <7ef71ca0-fcd1-1230-13ea-4b00cf307d48@oracle.com> References: <7ef71ca0-fcd1-1230-13ea-4b00cf307d48@oracle.com> Message-ID: <3eff2cdd-11e3-5477-4734-cab36ac9bb94@oracle.com> Vote: yes On 4/16/20 8:11 AM, Roger Riggs wrote: > I hereby nominate Amy Lu [4] to JDK Reviewer. > > Amy is currently a JDK Committer and a member of the software quality team at > Oracle, and has more than 150 contributions [3]. > > Amy has improved test stability, maintainability and coverage across areas of > java.nio, java.util, java.lang, etc. > > Votes are due by 1st May, 2020, 16:00 UTC. > Only current JDK Reviewers [1] are eligible to vote on this nomination. > > Votes must be cast in the open by replying to this mailing list. > For Three Vote Consensus voting instructions, see [2]. > > Regards, Roger > > [1] https://openjdk.java.net/census#jdk > [2] https://openjdk.java.net/projects/#reviewer-vote > [3] > http://hg.openjdk.java.net/jdk/jdk/log?revcount=400&rev=%28keyword%28%22amy.lu%40oracle.com%22%29+or+author%28amlu%29%29 > > [4] https://openjdk.java.net/census#almu From stuart.marks at oracle.com Tue Apr 21 16:38:08 2020 From: stuart.marks at oracle.com (Stuart Marks) Date: Tue, 21 Apr 2020 09:38:08 -0700 Subject: CFV: New JDK Reviewer: Mark Sheppard In-Reply-To: References: Message-ID: <22b6dbdc-a364-eaae-6164-2df589b35ea5@oracle.com> Vote: yes On 4/15/20 8:13 AM, Chris Hegarty wrote: > I hereby nominate Mark Sheppard [4] to JDK Reviewer. > > Mark is currently a JDK Committer and a member of the Java Platform > Group at Oracle. Mark has more than 87 contributions [3]. > > Mark's contrubutions span a wide variet of areas; bug fixes, > enhancements and spec clarifications in the Netwokring area, security > improvements to CORBA, as well as changes and improvements in core > libraries. > > Votes are due by 29th April 2020, 16:00 UTC. > > 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]. > > -Chris. > > [1] https://openjdk.java.net/census#jdk > [2] https://openjdk.java.net/projects/#reviewer-vote > [3] https://hg.openjdk.java.net/jdk/jdk/search/?rev=%28keyword%28%22mark.sheppard%40oracle.com%22%29%20or%20author%28msheppar%29%29&revcount=400 > [4] https://openjdk.java.net/census#msheppar > From joe.darcy at oracle.com Wed Apr 22 18:35:09 2020 From: joe.darcy at oracle.com (Joe Darcy) Date: Wed, 22 Apr 2020 11:35:09 -0700 Subject: FYI, planned update of floating-point terminology in JLS and JVMS to IEEE 754-2019 Message-ID: <8628e9d4-17b1-3dc0-af04-556472467990@oracle.com> Hello, The Java Language Specification (JLS) and Java Virtual Machine Specification (JVMS) use terminology from and make reference to the 1985 release of the IEEE 754 floating-point standard. The IEEE 754 standard from 1985 has been superseded, most recently by a release from 2019. The new release has changed the terminology used for various floating-point concepts referred to by JLS and JVMS. To accommodate this, we're planning to update the floating-point terminology used in the Java SE 15 editions of JLS and JVMS: ??? JDK-7074799: Adopt IEEE 754-2019 terminology in JLS ??? https://bugs.openjdk.java.net/browse/JDK-7074799 http://cr.openjdk.java.net/~darcy/Ieee754TerminologyUpdate/2020-04-21/specs/float-terminology-jls.html ??? JDK-8240327: Adopt IEEE 754-2019 terminology in JVMS ??? https://bugs.openjdk.java.net/browse/JDK-8240327 http://cr.openjdk.java.net/~darcy/Ieee754TerminologyUpdate/2020-04-21/specs/float-terminology-jvms.html The operational semantics of floating-point in JLS and JVMS is *not* altered by this spec update. The floating-point operations, +, -, *, /, etc. are specified to produce the same results for the same inputs as before and the sets of possible inputs are unchanged. The terminology updates in IEEE 754 include: * "IEEE 754 Standard for Binary Floating-Point Arithmetic" to ??? "IEEE 754 Standard for Floating-Point Arithmetic" (2019 standard covers binary and decimal arithmetic) * single format -> binary32 format * double format -> binary64 format * denormalized value -> subnormal value * round to nearest rounding mode -> roundTiesToEven rounding-direction attribute * round towards zero rounding mode -> roundTowardZero rounding-direction attribute Informative notes about the changes to rounding mode / rounding-direction attribution naming in IEEE 754 have been added to the java.math.RoundingMode enum in JDK 15: ??? JDK-8240624: Note mapping of RoundingMode constants to equivalent IEEE 754-2019 attribute ??? https://hg.openjdk.java.net/jdk/jdk/rev/5a58d0939974 Updates to java.lang.{Math, StrictMath} are possible too under ??? ??? JDK-8240632: Note differences between IEEE 754-2019 math lib special cases and java.lang.Math Few, if any, behavior changes are expected as part of JDK-8240632. Thanks to Alex for detailed reviews of earlier iterations of the JLS and JVMS spec changes. Cheers, -Joe From fw at deneb.enyo.de Wed Apr 22 18:44:40 2020 From: fw at deneb.enyo.de (Florian Weimer) Date: Wed, 22 Apr 2020 20:44:40 +0200 Subject: FYI, planned update of floating-point terminology in JLS and JVMS to IEEE 754-2019 In-Reply-To: <8628e9d4-17b1-3dc0-af04-556472467990@oracle.com> (Joe Darcy's message of "Wed, 22 Apr 2020 11:35:09 -0700") References: <8628e9d4-17b1-3dc0-af04-556472467990@oracle.com> Message-ID: <878singy1z.fsf@mid.deneb.enyo.de> * Joe Darcy: > The Java Language Specification (JLS) and Java Virtual Machine > Specification (JVMS) use terminology from and make reference to the 1985 > release of the IEEE 754 floating-point standard. The IEEE 754 standard > from 1985 has been superseded, most recently by a release from 2019. I don't have access to the IEEE standard (yeah, I know ?), but there are rumors that the Math::min and Math::max implementations for floating point arguments now match some IEEE 754 operation. If this indeed ttrue, it would make sense to update the Javadoc accordingly. (This goes in the opposite direction of what JDK-8240632 is about.) From joe.darcy at oracle.com Wed Apr 22 19:17:11 2020 From: joe.darcy at oracle.com (Joe Darcy) Date: Wed, 22 Apr 2020 12:17:11 -0700 Subject: FYI, planned update of floating-point terminology in JLS and JVMS to IEEE 754-2019 In-Reply-To: <878singy1z.fsf@mid.deneb.enyo.de> References: <8628e9d4-17b1-3dc0-af04-556472467990@oracle.com> <878singy1z.fsf@mid.deneb.enyo.de> Message-ID: <2934fdf1-a1eb-e38b-4c59-5c1df64933e0@oracle.com> Hi Florian, On 4/22/2020 11:44 AM, Florian Weimer wrote: > * Joe Darcy: > >> The Java Language Specification (JLS) and Java Virtual Machine >> Specification (JVMS) use terminology from and make reference to the 1985 >> release of the IEEE 754 floating-point standard. The IEEE 754 standard >> from 1985 has been superseded, most recently by a release from 2019. > I don't have access to the IEEE standard (yeah, I know ?), but there > are rumors that the Math::min and Math::max implementations for > floating point arguments now match some IEEE 754 operation. If this > indeed ttrue, it would make sense to update the Javadoc accordingly. > > (This goes in the opposite direction of what JDK-8240632 is about.) One part of JDK-8240632 I'm considering is a table mapping between IEEE 754-2019 operation/recommended operation and the Java math library equivalent. Many of them would be obvious, (sin -> sin, cos -> cos, etc.), but there are some that differ in their details. Java Math.{min, max} have always specified the fine detail that -0.0 is treated as strictly less than +0.0 and that if either argument to min/max is a NaN, the result is also a NaN. IEEE 754-2008 added minNum/maxNum operations. These did *not* require -0.0 to be treated as less than +0.0 and do not propagate a NaN value in case one argument is non-NaN. IEEE 754-2019 added minimum/maximum operations that do correspond to the Java library definitions of min/max and updated minNum/maxNum to distinguish between signed zeros. HTH, -Joe From doko at ubuntu.com Thu Apr 23 12:51:30 2020 From: doko at ubuntu.com (Matthias Klose) Date: Thu, 23 Apr 2020 14:51:30 +0200 Subject: mistriggered "error: warnings found and -Werror specified" for java warnings Message-ID: <959c6dd6-36d7-95d2-5ddd-1e52d90e39e8@ubuntu.com> jdk-15+20 fails to build with * For target support_test_failure_handler_classes__the.BUILD_FAILURE_HANDLER_batch: /packages/openjdk/15/openjdk-15-15~20/test/failure_handler/src/share/classes/jdk/test/failurehandler/jtreg/GatherDiagnosticInfoObserver.java:136: warning: [deprecation] finishedTesting() in Observer has been deprecated public void finishedTesting() { ^ error: warnings found and -Werror specified 1 error 1 warning Apparently --disable-warnings-as-errors only has an effect on C/C++ files, however the build diagnostics trigger on java warnings as well, and apparently -Werror is hard-coded in various places for java options. Should the documentation for this configure option be clarified, or should it trigger for java warnings as well? Matthias From erik.joelsson at oracle.com Thu Apr 23 13:12:28 2020 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 23 Apr 2020 06:12:28 -0700 Subject: mistriggered "error: warnings found and -Werror specified" for java warnings In-Reply-To: <959c6dd6-36d7-95d2-5ddd-1e52d90e39e8@ubuntu.com> References: <959c6dd6-36d7-95d2-5ddd-1e52d90e39e8@ubuntu.com> Message-ID: Hello Matthias, On 2020-04-23 05:51, Matthias Klose wrote: > jdk-15+20 fails to build with > > * For target support_test_failure_handler_classes__the.BUILD_FAILURE_HANDLER_batch: > /packages/openjdk/15/openjdk-15-15~20/test/failure_handler/src/share/classes/jdk/test/failurehandler/jtreg/GatherDiagnosticInfoObserver.java:136: > warning: [deprecation] finishedTesting() in Observer has been deprecated > public void finishedTesting() { > ^ > error: warnings found and -Werror specified > 1 error > 1 warning That's strange. I assume this tool is built with the boot JDK, so that makes me wonder what boot JDK you are using as we have not seen this warning/error? > > Apparently --disable-warnings-as-errors only has an effect on C/C++ files, > however the build diagnostics trigger on java warnings as well, and apparently > -Werror is hard-coded in various places for java options. Should the > documentation for this configure option be clarified, or should it trigger for > java warnings as well? Correct. The reasoning is that OpenJDK is built on a wide variety of environments with different compiler versions, so keeping the build warning free on all of them isn't feasible. This option makes it possible to build with all those different compiler versions while still maintaining a warning free source for a core set of compiler versions. In contrast, the Java code should only be compiled with a very small set of javac versions, which should be easily controlled. The majority of the code is even compiled with the Javac we are building. We have contemplated a similar option for Java code, but concluded that it doesn't serve any purpose. The Java source should just always be warning free. /Erik From igor.ignatyev at oracle.com Thu Apr 23 13:50:09 2020 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Thu, 23 Apr 2020 06:50:09 -0700 Subject: mistriggered "error: warnings found and -Werror specified" for java warnings In-Reply-To: References: <959c6dd6-36d7-95d2-5ddd-1e52d90e39e8@ubuntu.com> Message-ID: <22A2ACB8-C78E-464D-989C-C1BEEB6DA92C@oracle.com> > On Apr 23, 2020, at 6:12 AM, Erik Joelsson wrote: > > Hello Matthias, > > On 2020-04-23 05:51, Matthias Klose wrote: >> jdk-15+20 fails to build with >> >> * For target support_test_failure_handler_classes__the.BUILD_FAILURE_HANDLER_batch: >> /packages/openjdk/15/openjdk-15-15~20/test/failure_handler/src/share/classes/jdk/test/failurehandler/jtreg/GatherDiagnosticInfoObserver.java:136: >> warning: [deprecation] finishedTesting() in Observer has been deprecated >> public void finishedTesting() { >> ^ >> error: warnings found and -Werror specified >> 1 error >> 1 warning > That's strange. I assume this tool is built with the boot JDK, so that makes me wonder what boot JDK you are using as we have not seen this warning/error? I guess version of jtreg/jt-harness is more relevant here as deprecated finishedTesting is from com.sun.javatest.Harness.Observer. --Igor >> >> Apparently --disable-warnings-as-errors only has an effect on C/C++ files, >> however the build diagnostics trigger on java warnings as well, and apparently >> -Werror is hard-coded in various places for java options. Should the >> documentation for this configure option be clarified, or should it trigger for >> java warnings as well? > > Correct. The reasoning is that OpenJDK is built on a wide variety of environments with different compiler versions, so keeping the build warning free on all of them isn't feasible. This option makes it possible to build with all those different compiler versions while still maintaining a warning free source for a core set of compiler versions. In contrast, the Java code should only be compiled with a very small set of javac versions, which should be easily controlled. The majority of the code is even compiled with the Javac we are building. We have contemplated a similar option for Java code, but concluded that it doesn't serve any purpose. The Java source should just always be warning free. > > /Erik > From magnus.ihse.bursie at oracle.com Thu Apr 23 14:05:11 2020 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 23 Apr 2020 16:05:11 +0200 Subject: mistriggered "error: warnings found and -Werror specified" for java warnings In-Reply-To: <22A2ACB8-C78E-464D-989C-C1BEEB6DA92C@oracle.com> References: <959c6dd6-36d7-95d2-5ddd-1e52d90e39e8@ubuntu.com> <22A2ACB8-C78E-464D-989C-C1BEEB6DA92C@oracle.com> Message-ID: <36059D8D-EDC8-45EA-AECE-2DFA77C26349@oracle.com> > 23 apr. 2020 kl. 15:50 skrev Igor Ignatyev : > > > >> On Apr 23, 2020, at 6:12 AM, Erik Joelsson wrote: >> >> Hello Matthias, >> >>> On 2020-04-23 05:51, Matthias Klose wrote: >>> jdk-15+20 fails to build with >>> >>> * For target support_test_failure_handler_classes__the.BUILD_FAILURE_HANDLER_batch: >>> /packages/openjdk/15/openjdk-15-15~20/test/failure_handler/src/share/classes/jdk/test/failurehandler/jtreg/GatherDiagnosticInfoObserver.java:136: >>> warning: [deprecation] finishedTesting() in Observer has been deprecated >>> public void finishedTesting() { >>> ^ >>> error: warnings found and -Werror specified >>> 1 error >>> 1 warning >> That's strange. I assume this tool is built with the boot JDK, so that makes me wonder what boot JDK you are using as we have not seen this warning/error? > I guess version of jtreg/jt-harness is more relevant here as deprecated finishedTesting is from com.sun.javatest.Harness.Observer. Aha, that?s probably the explanation. I recently removed deprecation as a disabled warning for the failure handler. If it depends on jtreg, and it has changed deprecation status, that might trigger a compilation warning. I?m on mobile now and can?t check how this should be resolved. If a newer version of jtreg introduced the depreciation, we should fix our sources. If this is something only present in older sources (?) we might need to raise the minimum jtreg version. /Magnus > > --Igor > >>> >>> Apparently --disable-warnings-as-errors only has an effect on C/C++ files, >>> however the build diagnostics trigger on java warnings as well, and apparently >>> -Werror is hard-coded in various places for java options. Should the >>> documentation for this configure option be clarified, or should it trigger for >>> java warnings as well? >> >> Correct. The reasoning is that OpenJDK is built on a wide variety of environments with different compiler versions, so keeping the build warning free on all of them isn't feasible. This option makes it possible to build with all those different compiler versions while still maintaining a warning free source for a core set of compiler versions. In contrast, the Java code should only be compiled with a very small set of javac versions, which should be easily controlled. The majority of the code is even compiled with the Javac we are building. We have contemplated a similar option for Java code, but concluded that it doesn't serve any purpose. The Java source should just always be warning free. >> >> /Erik >> > From doko at ubuntu.com Thu Apr 23 14:48:52 2020 From: doko at ubuntu.com (Matthias Klose) Date: Thu, 23 Apr 2020 16:48:52 +0200 Subject: mistriggered "error: warnings found and -Werror specified" for java warnings In-Reply-To: <36059D8D-EDC8-45EA-AECE-2DFA77C26349@oracle.com> References: <959c6dd6-36d7-95d2-5ddd-1e52d90e39e8@ubuntu.com> <22A2ACB8-C78E-464D-989C-C1BEEB6DA92C@oracle.com> <36059D8D-EDC8-45EA-AECE-2DFA77C26349@oracle.com> Message-ID: <17b7a4ab-8846-5377-4c99-808e12bb23a5@ubuntu.com> On 4/23/20 4:05 PM, Magnus Ihse Bursie wrote: > >> 23 apr. 2020 kl. 15:50 skrev Igor Ignatyev : >> >> >> >>> On Apr 23, 2020, at 6:12 AM, Erik Joelsson wrote: >>> >>> Hello Matthias, >>> >>>> On 2020-04-23 05:51, Matthias Klose wrote: >>>> jdk-15+20 fails to build with >>>> >>>> * For target support_test_failure_handler_classes__the.BUILD_FAILURE_HANDLER_batch: >>>> /packages/openjdk/15/openjdk-15-15~20/test/failure_handler/src/share/classes/jdk/test/failurehandler/jtreg/GatherDiagnosticInfoObserver.java:136: >>>> warning: [deprecation] finishedTesting() in Observer has been deprecated >>>> public void finishedTesting() { >>>> ^ >>>> error: warnings found and -Werror specified >>>> 1 error >>>> 1 warning >>> That's strange. I assume this tool is built with the boot JDK, so that makes me wonder what boot JDK you are using as we have not seen this warning/error? that's with 14.0.1+7. >> I guess version of jtreg/jt-harness is more relevant here as deprecated finishedTesting is from com.sun.javatest.Harness.Observer. > > Aha, that?s probably the explanation. I recently removed deprecation as a disabled warning for the failure handler. If it depends on jtreg, and it has changed deprecation status, that might trigger a compilation warning. > > I?m on mobile now and can?t check how this should be resolved. > > If a newer version of jtreg introduced the depreciation, we should fix our sources. If this is something only present in older sources (?) we might need to raise the minimum jtreg version. jtharness 6.0-b10 and jtreg 5.0-b1. > > /Magnus > >> >> --Igor >> >>>> >>>> Apparently --disable-warnings-as-errors only has an effect on C/C++ files, >>>> however the build diagnostics trigger on java warnings as well, and apparently >>>> -Werror is hard-coded in various places for java options. Should the >>>> documentation for this configure option be clarified, or should it trigger for >>>> java warnings as well? >>> >>> Correct. The reasoning is that OpenJDK is built on a wide variety of environments with different compiler versions, so keeping the build warning free on all of them isn't feasible. This option makes it possible to build with all those different compiler versions while still maintaining a warning free source for a core set of compiler versions. In contrast, the Java code should only be compiled with a very small set of javac versions, which should be easily controlled. The majority of the code is even compiled with the Javac we are building. We have contemplated a similar option for Java code, but concluded that it doesn't serve any purpose. The Java source should just always be warning free. >>> >>> /Erik >>> >> > From igor.ignatyev at oracle.com Thu Apr 23 15:17:25 2020 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Thu, 23 Apr 2020 08:17:25 -0700 Subject: mistriggered "error: warnings found and -Werror specified" for java warnings In-Reply-To: <17b7a4ab-8846-5377-4c99-808e12bb23a5@ubuntu.com> References: <959c6dd6-36d7-95d2-5ddd-1e52d90e39e8@ubuntu.com> <22A2ACB8-C78E-464D-989C-C1BEEB6DA92C@oracle.com> <36059D8D-EDC8-45EA-AECE-2DFA77C26349@oracle.com> <17b7a4ab-8846-5377-4c99-808e12bb23a5@ubuntu.com> Message-ID: <46622B21-7B98-4B71-902F-CF4B6344C6E8@oracle.com> Hi Matthias, > jtharness 6.0-b10 and jtreg 5.0-b1. jtreg 5.0-b1 "officially" depends on jt6.0-b08, and the bundle which we use internally has jt6.0-b08 within it, and AFAICT jt6.0-b08 hasn't deprecated c.s.j.H.Observer::finishedTesting yet. so as a temp. solution to allow configurations like yours, we need to suppress deprecation warning in failure handler, that's if we decide that such configurations are "supported", which isn't that obvious as you might encounter some deviations in jtreg behavior b/c another version of its dependency is used, so I'd encourage you to use the exact same version as used by jtreg build script[1]. a proper solution would include switching jtreg to newer version of jt-harness (which implies adjustment of jtreg and subsequently testing), promotion/tagging of newer jtreg build, switching to newer jtreg in jdk and updating in failurehandler. Thanks, -- Igor [1] http://hg.openjdk.java.net/code-tools/jtreg/file/fc37a1d7f0ea/make/build-all.sh#l129 > On Apr 23, 2020, at 7:48 AM, Matthias Klose wrote: > > On 4/23/20 4:05 PM, Magnus Ihse Bursie wrote: >> >>> 23 apr. 2020 kl. 15:50 skrev Igor Ignatyev : >>> >>> >>> >>>> On Apr 23, 2020, at 6:12 AM, Erik Joelsson wrote: >>>> >>>> Hello Matthias, >>>> >>>>> On 2020-04-23 05:51, Matthias Klose wrote: >>>>> jdk-15+20 fails to build with >>>>> >>>>> * For target support_test_failure_handler_classes__the.BUILD_FAILURE_HANDLER_batch: >>>>> /packages/openjdk/15/openjdk-15-15~20/test/failure_handler/src/share/classes/jdk/test/failurehandler/jtreg/GatherDiagnosticInfoObserver.java:136: >>>>> warning: [deprecation] finishedTesting() in Observer has been deprecated >>>>> public void finishedTesting() { >>>>> ^ >>>>> error: warnings found and -Werror specified >>>>> 1 error >>>>> 1 warning >>>> That's strange. I assume this tool is built with the boot JDK, so that makes me wonder what boot JDK you are using as we have not seen this warning/error? > > that's with 14.0.1+7. > >>> I guess version of jtreg/jt-harness is more relevant here as deprecated finishedTesting is from com.sun.javatest.Harness.Observer. >> >> Aha, that?s probably the explanation. I recently removed deprecation as a disabled warning for the failure handler. If it depends on jtreg, and it has changed deprecation status, that might trigger a compilation warning. >> >> I?m on mobile now and can?t check how this should be resolved. >> >> If a newer version of jtreg introduced the depreciation, we should fix our sources. If this is something only present in older sources (?) we might need to raise the minimum jtreg version. > > jtharness 6.0-b10 and jtreg 5.0-b1. > >> >> /Magnus >> >>> >>> --Igor >>> >>>>> >>>>> Apparently --disable-warnings-as-errors only has an effect on C/C++ files, >>>>> however the build diagnostics trigger on java warnings as well, and apparently >>>>> -Werror is hard-coded in various places for java options. Should the >>>>> documentation for this configure option be clarified, or should it trigger for >>>>> java warnings as well? >>>> >>>> Correct. The reasoning is that OpenJDK is built on a wide variety of environments with different compiler versions, so keeping the build warning free on all of them isn't feasible. This option makes it possible to build with all those different compiler versions while still maintaining a warning free source for a core set of compiler versions. In contrast, the Java code should only be compiled with a very small set of javac versions, which should be easily controlled. The majority of the code is even compiled with the Javac we are building. We have contemplated a similar option for Java code, but concluded that it doesn't serve any purpose. The Java source should just always be warning free. >>>> >>>> /Erik From nikolay.martynov at datadoghq.com Thu Apr 23 15:41:01 2020 From: nikolay.martynov at datadoghq.com (Nikolay Martynov) Date: Thu, 23 Apr 2020 11:41:01 -0400 Subject: Patch for JDK-8243489 Thread CPU Load event may contain wrong data for CPU time under certain conditions Message-ID: Hi It looks like per thread CPU time sent with the CPU load event may be inadvertently reset under certain conditions (JDK-8243489). This should address the problem: http://cr.openjdk.java.net/~jbachorik/8243489/webrev.00/. Please let me know if any more information is needed. Thanks! Nikolay. From magnus.ihse.bursie at oracle.com Thu Apr 23 16:59:11 2020 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 23 Apr 2020 18:59:11 +0200 Subject: mistriggered "error: warnings found and -Werror specified" for java warnings In-Reply-To: <46622B21-7B98-4B71-902F-CF4B6344C6E8@oracle.com> References: <959c6dd6-36d7-95d2-5ddd-1e52d90e39e8@ubuntu.com> <22A2ACB8-C78E-464D-989C-C1BEEB6DA92C@oracle.com> <36059D8D-EDC8-45EA-AECE-2DFA77C26349@oracle.com> <17b7a4ab-8846-5377-4c99-808e12bb23a5@ubuntu.com> <46622B21-7B98-4B71-902F-CF4B6344C6E8@oracle.com> Message-ID: <2c4b666b-86d8-c5bb-43e2-1f2816c979ee@oracle.com> On 2020-04-23 17:17, Igor Ignatyev wrote: > Hi Matthias, > >> jtharness 6.0-b10 and jtreg 5.0-b1. > > jtreg 5.0-b1 "officially" depends on?jt6.0-b08, and the bundle which > we use internally has?jt6.0-b08 within it, and AFAICT?jt6.0-b08 hasn't > deprecated c.s.j.H.Observer::finishedTesting yet. so as a temp. > solution to allow configurations like yours, we need to suppress > deprecation warning in failure handler, that's if we decide that such > configurations are "supported", which isn't that obvious as you might > encounter some deviations in jtreg behavior ? b/c another version of > its dependency is used, so I'd encourage you to use the exact same > version as used by jtreg build script[1]. From my point of view, I think we should have a very narrow range of supported jtreg versions. It's not like when building with the system zlib; this is a framework solely used for testing the JDK, and I think we can (and should) be quite strict as to which versions the current code base is designed to work with. Things get a little bit muddier if the version of jtreg matches, but not an upstream dependency for jtreg. I still tend to lean towards Igor's suggestion here, that a properly setup jtreg environment is the one officially built by jtreg. /Magnus > > a proper solution would include switching jtreg to newer version of > jt-harness (which implies adjustment of jtreg and subsequently > testing), promotion/tagging of newer jtreg build, switching to newer > jtreg in jdk and updating in failurehandler. > > Thanks, > -- Igor > > [1] > http://hg.openjdk.java.net/code-tools/jtreg/file/fc37a1d7f0ea/make/build-all.sh#l129 > >> On Apr 23, 2020, at 7:48 AM, Matthias Klose > > wrote: >> >> On 4/23/20 4:05 PM, Magnus Ihse Bursie wrote: >>> >>>> 23 apr. 2020 kl. 15:50 skrev Igor Ignatyev >>>> >: >>>> >>>> >>>> >>>>> On Apr 23, 2020, at 6:12 AM, Erik Joelsson >>>>> > wrote: >>>>> >>>>> Hello Matthias, >>>>> >>>>>> On 2020-04-23 05:51, Matthias Klose wrote: >>>>>> jdk-15+20 fails to build with >>>>>> >>>>>> * For target >>>>>> support_test_failure_handler_classes__the.BUILD_FAILURE_HANDLER_batch: >>>>>> /packages/openjdk/15/openjdk-15-15~20/test/failure_handler/src/share/classes/jdk/test/failurehandler/jtreg/GatherDiagnosticInfoObserver.java:136: >>>>>> warning: [deprecation] finishedTesting() in Observer has been >>>>>> deprecated >>>>>> ??public void finishedTesting() { >>>>>> ??????????????^ >>>>>> error: warnings found and -Werror specified >>>>>> 1 error >>>>>> 1 warning >>>>> That's strange. I assume this tool is built with the boot JDK, so >>>>> that makes me wonder what boot JDK you are using as we have not >>>>> seen this warning/error? >> >> that's with 14.0.1+7. >> >>>> I guess version of jtreg/jt-harness is more relevant here as >>>> deprecated finishedTesting is from com.sun.javatest.Harness.Observer. >>> >>> Aha, that?s probably the explanation. I recently removed deprecation >>> as a disabled warning for the failure handler. If it depends on >>> jtreg, and it has changed deprecation status, that might trigger a >>> compilation warning. >>> >>> I?m on mobile now and can?t check how this should be resolved. >>> >>> If a newer version of jtreg introduced the depreciation, we should >>> fix our sources. If this is something only present in older sources >>> (?) we might need to raise the minimum jtreg version. >> >> jtharness 6.0-b10 and jtreg 5.0-b1. >> >>> >>> /Magnus >>> >>>> >>>> --Igor >>>> >>>>>> >>>>>> Apparently --disable-warnings-as-errors only has an effect on >>>>>> C/C++ files, >>>>>> however the build diagnostics trigger on java warnings as well, >>>>>> and apparently >>>>>> -Werror is hard-coded in various places for java options. Should the >>>>>> documentation for this configure option be clarified, or should >>>>>> it trigger for >>>>>> java warnings as well? >>>>> >>>>> Correct. The reasoning is that OpenJDK is built on a wide variety >>>>> of environments with different compiler versions, so keeping the >>>>> build warning free on all of them isn't feasible. This option >>>>> makes it possible to build with all those different compiler >>>>> versions while still maintaining a warning free source for a core >>>>> set of compiler versions. In contrast, the Java code should only >>>>> be compiled with a very small set of javac versions, which should >>>>> be easily controlled. The majority of the code is even compiled >>>>> with the Javac we are building. We have contemplated a similar >>>>> option for Java code, but concluded that it doesn't serve any >>>>> purpose. The Java source should just always be warning free. >>>>> >>>>> /Erik > From david.holmes at oracle.com Thu Apr 23 23:58:46 2020 From: david.holmes at oracle.com (David Holmes) Date: Fri, 24 Apr 2020 09:58:46 +1000 Subject: Patch for JDK-8243489 Thread CPU Load event may contain wrong data for CPU time under certain conditions In-Reply-To: References: Message-ID: <89b4f266-1c5d-886a-56c6-f3b392b0efc1@oracle.com> Hi Nikolay, Please take this to hotspot-jfr-dev at openjdk.java.net for review. Thanks, David On 24/04/2020 1:41 am, Nikolay Martynov wrote: > Hi > > It looks like per thread CPU time sent with the CPU load event may be > inadvertently reset under certain conditions (JDK-8243489). This should > address the problem: > http://cr.openjdk.java.net/~jbachorik/8243489/webrev.00/. > > Please let me know if any more information is needed. > Thanks! > > Nikolay. > From doko at ubuntu.com Fri Apr 24 08:29:59 2020 From: doko at ubuntu.com (Matthias Klose) Date: Fri, 24 Apr 2020 10:29:59 +0200 Subject: mistriggered "error: warnings found and -Werror specified" for java warnings In-Reply-To: <2c4b666b-86d8-c5bb-43e2-1f2816c979ee@oracle.com> References: <959c6dd6-36d7-95d2-5ddd-1e52d90e39e8@ubuntu.com> <22A2ACB8-C78E-464D-989C-C1BEEB6DA92C@oracle.com> <36059D8D-EDC8-45EA-AECE-2DFA77C26349@oracle.com> <17b7a4ab-8846-5377-4c99-808e12bb23a5@ubuntu.com> <46622B21-7B98-4B71-902F-CF4B6344C6E8@oracle.com> <2c4b666b-86d8-c5bb-43e2-1f2816c979ee@oracle.com> Message-ID: On 4/23/20 6:59 PM, Magnus Ihse Bursie wrote: > > > On 2020-04-23 17:17, Igor Ignatyev wrote: >> Hi Matthias, >> >>> jtharness 6.0-b10 and jtreg 5.0-b1. >> >> jtreg 5.0-b1 "officially" depends on?jt6.0-b08, and the bundle which we use >> internally has?jt6.0-b08 within it, and AFAICT?jt6.0-b08 hasn't deprecated >> c.s.j.H.Observer::finishedTesting yet. so as a temp. solution to allow >> configurations like yours, we need to suppress deprecation warning in failure >> handler, that's if we decide that such configurations are "supported", which >> isn't that obvious as you might encounter some deviations in jtreg behavior ? >> b/c another version of its dependency is used, so I'd encourage you to use the >> exact same version as used by jtreg build script[1]. > From my point of view, I think we should have a very narrow range of supported > jtreg versions. It's not like when building with the system zlib; this is a > framework solely used for testing the JDK, and I think we can (and should) be > quite strict as to which versions the current code base is designed to work with. well, you are not that strict when it comes to the compiler used, and try to support a wide range of compilers. You bundle some third party libraries where you have stricter version requirements. > Things get a little bit muddier if the version of jtreg matches, but not an > upstream dependency for jtreg. I still tend to lean towards Igor's suggestion > here, that a properly setup jtreg environment is the one officially built by jtreg. I am trying to run the tests as part of the package builds in Debian/Ubuntu. Now you can argue that packaging jtreg 5.0-b1 depending on jtharness 6.0-b10 is a packaging mistake, otoh there is no upper dependency on the jtharness version. Going forward with the suggestion would mean to track all dependencies of jtreg, package those, hoping that unrelated packages in the distro archives can work with these versions, and do this for every jtreg version that is required by any openjdk version you want to build in a distro context. Not very appealing. The alternative would be to disable testing. Not appealing either. I'll see to revert that deprecation in jtharness 6.0-b10 for now, or patching the openjdk build process to ignore that warning. Matthias > /Magnus > > >> >> a proper solution would include switching jtreg to newer version of jt-harness >> (which implies adjustment of jtreg and subsequently testing), >> promotion/tagging of newer jtreg build, switching to newer jtreg in jdk and >> updating in failurehandler. >> >> Thanks, >> -- Igor >> >> [1] >> http://hg.openjdk.java.net/code-tools/jtreg/file/fc37a1d7f0ea/make/build-all.sh#l129 >> >> >>> On Apr 23, 2020, at 7:48 AM, Matthias Klose >> > wrote: >>> >>> On 4/23/20 4:05 PM, Magnus Ihse Bursie wrote: >>>> >>>>> 23 apr. 2020 kl. 15:50 skrev Igor Ignatyev >>>> >: >>>>> >>>>> >>>>> >>>>>> On Apr 23, 2020, at 6:12 AM, Erik Joelsson >>>>> > wrote: >>>>>> >>>>>> Hello Matthias, >>>>>> >>>>>>> On 2020-04-23 05:51, Matthias Klose wrote: >>>>>>> jdk-15+20 fails to build with >>>>>>> >>>>>>> * For target >>>>>>> support_test_failure_handler_classes__the.BUILD_FAILURE_HANDLER_batch: >>>>>>> /packages/openjdk/15/openjdk-15-15~20/test/failure_handler/src/share/classes/jdk/test/failurehandler/jtreg/GatherDiagnosticInfoObserver.java:136: >>>>>>> >>>>>>> warning: [deprecation] finishedTesting() in Observer has been deprecated >>>>>>> ??public void finishedTesting() { >>>>>>> ??????????????^ >>>>>>> error: warnings found and -Werror specified >>>>>>> 1 error >>>>>>> 1 warning >>>>>> That's strange. I assume this tool is built with the boot JDK, so that >>>>>> makes me wonder what boot JDK you are using as we have not seen this >>>>>> warning/error? >>> >>> that's with 14.0.1+7. >>> >>>>> I guess version of jtreg/jt-harness is more relevant here as deprecated >>>>> finishedTesting is from com.sun.javatest.Harness.Observer. >>>> >>>> Aha, that?s probably the explanation. I recently removed deprecation as a >>>> disabled warning for the failure handler. If it depends on jtreg, and it has >>>> changed deprecation status, that might trigger a compilation warning. >>>> >>>> I?m on mobile now and can?t check how this should be resolved. >>>> >>>> If a newer version of jtreg introduced the depreciation, we should fix our >>>> sources. If this is something only present in older sources (?) we might >>>> need to raise the minimum jtreg version. >>> >>> jtharness 6.0-b10 and jtreg 5.0-b1. >>> >>>> >>>> /Magnus >>>> >>>>> >>>>> --Igor >>>>> >>>>>>> >>>>>>> Apparently --disable-warnings-as-errors only has an effect on C/C++ files, >>>>>>> however the build diagnostics trigger on java warnings as well, and >>>>>>> apparently >>>>>>> -Werror is hard-coded in various places for java options. Should the >>>>>>> documentation for this configure option be clarified, or should it >>>>>>> trigger for >>>>>>> java warnings as well? >>>>>> >>>>>> Correct. The reasoning is that OpenJDK is built on a wide variety of >>>>>> environments with different compiler versions, so keeping the build >>>>>> warning free on all of them isn't feasible. This option makes it possible >>>>>> to build with all those different compiler versions while still >>>>>> maintaining a warning free source for a core set of compiler versions. In >>>>>> contrast, the Java code should only be compiled with a very small set of >>>>>> javac versions, which should be easily controlled. The majority of the >>>>>> code is even compiled with the Javac we are building. We have contemplated >>>>>> a similar option for Java code, but concluded that it doesn't serve any >>>>>> purpose. The Java source should just always be warning free. >>>>>> >>>>>> /Erik >> > > From magnus.ihse.bursie at oracle.com Fri Apr 24 08:51:43 2020 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 24 Apr 2020 10:51:43 +0200 Subject: mistriggered "error: warnings found and -Werror specified" for java warnings In-Reply-To: References: <959c6dd6-36d7-95d2-5ddd-1e52d90e39e8@ubuntu.com> <22A2ACB8-C78E-464D-989C-C1BEEB6DA92C@oracle.com> <36059D8D-EDC8-45EA-AECE-2DFA77C26349@oracle.com> <17b7a4ab-8846-5377-4c99-808e12bb23a5@ubuntu.com> <46622B21-7B98-4B71-902F-CF4B6344C6E8@oracle.com> <2c4b666b-86d8-c5bb-43e2-1f2816c979ee@oracle.com> Message-ID: <91720e85-f49f-2ab5-420a-ec489191a02d@oracle.com> On 2020-04-24 10:29, Matthias Klose wrote: > On 4/23/20 6:59 PM, Magnus Ihse Bursie wrote: >> >> On 2020-04-23 17:17, Igor Ignatyev wrote: >>> Hi Matthias, >>> >>>> jtharness 6.0-b10 and jtreg 5.0-b1. >>> jtreg 5.0-b1 "officially" depends on?jt6.0-b08, and the bundle which we use >>> internally has?jt6.0-b08 within it, and AFAICT?jt6.0-b08 hasn't deprecated >>> c.s.j.H.Observer::finishedTesting yet. so as a temp. solution to allow >>> configurations like yours, we need to suppress deprecation warning in failure >>> handler, that's if we decide that such configurations are "supported", which >>> isn't that obvious as you might encounter some deviations in jtreg behavior >>> b/c another version of its dependency is used, so I'd encourage you to use the >>> exact same version as used by jtreg build script[1]. >> From my point of view, I think we should have a very narrow range of supported >> jtreg versions. It's not like when building with the system zlib; this is a >> framework solely used for testing the JDK, and I think we can (and should) be >> quite strict as to which versions the current code base is designed to work with. > well, you are not that strict when it comes to the compiler used, and try to > support a wide range of compilers. You bundle some third party libraries where > you have stricter version requirements. You are absolutely correct. My point here is that jtreg is a specialized tool, created solely for running tests in the JDK. This is not the case with compilers and external libraries. I think the main reason that jtreg is not part of the JDK repo is ... well... maybe not to "pollute" it with things that might strictly speaking not be needed, and could be placed elsewhere. Or just legacy reasons. > >> Things get a little bit muddier if the version of jtreg matches, but not an >> upstream dependency for jtreg. I still tend to lean towards Igor's suggestion >> here, that a properly setup jtreg environment is the one officially built by jtreg. > I am trying to run the tests as part of the package builds in Debian/Ubuntu. > Now you can argue that packaging jtreg 5.0-b1 depending on jtharness 6.0-b10 is > a packaging mistake, otoh there is no upper dependency on the jtharness version. > > Going forward with the suggestion would mean to track all dependencies of jtreg, > package those, hoping that unrelated packages in the distro archives can work > with these versions, and do this for every jtreg version that is required by any > openjdk version you want to build in a distro context. Not very appealing. The > alternative would be to disable testing. Not appealing either. > > I'll see to revert that deprecation in jtharness 6.0-b10 for now, or patching > the openjdk build process to ignore that warning. I think you missed the third option: updating the failure handler code so it does not use deprecated, or soon-to-be-deprecated, methods. Even if builds of jtreg using jtharness 6.0-b08 works fine, there will apparently come a time when the current code will trigger a warning. If there exists non-deprecated replacement methods in 6.0-b08, then we should perhaps switch to using these right now? (And also, what kind of madman versioning scheme is used if you introduce deprecations between "6.0-b08" and "6.0-b10"?!? :-o I would have assumed API changes would have caused a version bumb to something like 6.1 at the very least.) But if this approach is not feasible, I'm going to accept to re-disable the deprecation warning for the failure handler. I'm just noting that if we do that, it will basically have to stay there forever. If an engineer ever wanted to clear up the remaining warnings for the failure handler, how would they go ahead to make sure they don't break anything? A build with the recommended libraries will produce no warnings, so how can he know that he needs to keep it? Download and try a wide range of combination of libraries and their dependencies? /Magnus > > Matthias > >> /Magnus >> >> >>> a proper solution would include switching jtreg to newer version of jt-harness >>> (which implies adjustment of jtreg and subsequently testing), >>> promotion/tagging of newer jtreg build, switching to newer jtreg in jdk and >>> updating in failurehandler. >>> >>> Thanks, >>> -- Igor >>> >>> [1] >>> http://hg.openjdk.java.net/code-tools/jtreg/file/fc37a1d7f0ea/make/build-all.sh#l129 >>> >>> >>>> On Apr 23, 2020, at 7:48 AM, Matthias Klose >>> > wrote: >>>> >>>> On 4/23/20 4:05 PM, Magnus Ihse Bursie wrote: >>>>>> 23 apr. 2020 kl. 15:50 skrev Igor Ignatyev >>>>> >: >>>>>> >>>>>> >>>>>> >>>>>>> On Apr 23, 2020, at 6:12 AM, Erik Joelsson >>>>>> > wrote: >>>>>>> >>>>>>> Hello Matthias, >>>>>>> >>>>>>>> On 2020-04-23 05:51, Matthias Klose wrote: >>>>>>>> jdk-15+20 fails to build with >>>>>>>> >>>>>>>> * For target >>>>>>>> support_test_failure_handler_classes__the.BUILD_FAILURE_HANDLER_batch: >>>>>>>> /packages/openjdk/15/openjdk-15-15~20/test/failure_handler/src/share/classes/jdk/test/failurehandler/jtreg/GatherDiagnosticInfoObserver.java:136: >>>>>>>> >>>>>>>> warning: [deprecation] finishedTesting() in Observer has been deprecated >>>>>>>> ??public void finishedTesting() { >>>>>>>> ??????????????^ >>>>>>>> error: warnings found and -Werror specified >>>>>>>> 1 error >>>>>>>> 1 warning >>>>>>> That's strange. I assume this tool is built with the boot JDK, so that >>>>>>> makes me wonder what boot JDK you are using as we have not seen this >>>>>>> warning/error? >>>> that's with 14.0.1+7. >>>> >>>>>> I guess version of jtreg/jt-harness is more relevant here as deprecated >>>>>> finishedTesting is from com.sun.javatest.Harness.Observer. >>>>> Aha, that?s probably the explanation. I recently removed deprecation as a >>>>> disabled warning for the failure handler. If it depends on jtreg, and it has >>>>> changed deprecation status, that might trigger a compilation warning. >>>>> >>>>> I?m on mobile now and can?t check how this should be resolved. >>>>> >>>>> If a newer version of jtreg introduced the depreciation, we should fix our >>>>> sources. If this is something only present in older sources (?) we might >>>>> need to raise the minimum jtreg version. >>>> jtharness 6.0-b10 and jtreg 5.0-b1. >>>> >>>>> /Magnus >>>>> >>>>>> --Igor >>>>>> >>>>>>>> Apparently --disable-warnings-as-errors only has an effect on C/C++ files, >>>>>>>> however the build diagnostics trigger on java warnings as well, and >>>>>>>> apparently >>>>>>>> -Werror is hard-coded in various places for java options. Should the >>>>>>>> documentation for this configure option be clarified, or should it >>>>>>>> trigger for >>>>>>>> java warnings as well? >>>>>>> Correct. The reasoning is that OpenJDK is built on a wide variety of >>>>>>> environments with different compiler versions, so keeping the build >>>>>>> warning free on all of them isn't feasible. This option makes it possible >>>>>>> to build with all those different compiler versions while still >>>>>>> maintaining a warning free source for a core set of compiler versions. In >>>>>>> contrast, the Java code should only be compiled with a very small set of >>>>>>> javac versions, which should be easily controlled. The majority of the >>>>>>> code is even compiled with the Javac we are building. We have contemplated >>>>>>> a similar option for Java code, but concluded that it doesn't serve any >>>>>>> purpose. The Java source should just always be warning free. >>>>>>> >>>>>>> /Erik >> From joe.darcy at oracle.com Mon Apr 27 22:43:38 2020 From: joe.darcy at oracle.com (Joe Darcy) Date: Mon, 27 Apr 2020 15:43:38 -0700 Subject: Reminder: submit CSRs for JDK 15 changes ahead of rampdown 1 milestone of June 11, 2020 Message-ID: <8f47f1fd-dbe8-a974-093a-a08a60c02660@oracle.com> Hello, Per the JDK 15 schedule (http://openjdk.java.net/projects/jdk/15/), rampdown phase one is coming up on June 11, 2020. If you have outstanding changes intended to go into JDK 15, please file any CSRs with sufficient lead time to accommodate both the review and responses to possible review feedback. More detail about the CSR process is written up on its wiki: ???? https://wiki.openjdk.java.net/display/csr/Main Happy coding, -Joe From simone.bordet at gmail.com Tue Apr 28 09:05:36 2020 From: simone.bordet at gmail.com (Simone Bordet) Date: Tue, 28 Apr 2020 11:05:36 +0200 Subject: Java 11 vs 14 MethodHandle behavior change Message-ID: Hi, at the Jetty Project we have found an incompatible behavior change between Java 11 and 14 related to MethodHandles. Where is the best place to discuss the details? core-libs-dev? Thanks! -- Simone Bordet --- Finally, no matter how good the architecture and design are, to deliver bug-free software with optimal performance and reliability, the implementation technique must be flawless. Victoria Livschitz From forax at univ-mlv.fr Tue Apr 28 09:24:54 2020 From: forax at univ-mlv.fr (Remi Forax) Date: Tue, 28 Apr 2020 11:24:54 +0200 (CEST) Subject: Java 11 vs 14 MethodHandle behavior change In-Reply-To: References: Message-ID: <1550103530.1081077.1588065894993.JavaMail.zimbra@u-pem.fr> Hi Simone, I would say yes :) R?mi ----- Mail original ----- > De: "Simone Bordet" > ?: "jdk-dev" > Envoy?: Mardi 28 Avril 2020 11:05:36 > Objet: Java 11 vs 14 MethodHandle behavior change > Hi, > > at the Jetty Project we have found an incompatible behavior change > between Java 11 and 14 related to MethodHandles. > > Where is the best place to discuss the details? > core-libs-dev? > > Thanks! > > -- > Simone Bordet > --- > Finally, no matter how good the architecture and design are, > to deliver bug-free software with optimal performance and reliability, > the implementation technique must be flawless. Victoria Livschitz From Alan.Bateman at oracle.com Tue Apr 28 09:26:37 2020 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 28 Apr 2020 10:26:37 +0100 Subject: Java 11 vs 14 MethodHandle behavior change In-Reply-To: References: Message-ID: <8e5f4734-bf1e-db36-761c-47beeae9540d@oracle.com> On 28/04/2020 10:05, Simone Bordet wrote: > Hi, > > at the Jetty Project we have found an incompatible behavior change > between Java 11 and 14 related to MethodHandles. > > Where is the best place to discuss the details? > core-libs-dev? > Yes, core-lib-dev. Make sure to go through the release notes [1] first as there are a number of changes to the specification, esp. with privateLookupIn and teleporting. -Alan [1] http://jdk.java.net/14/release-notes From chris.hegarty at oracle.com Thu Apr 30 15:22:26 2020 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 30 Apr 2020 16:22:26 +0100 Subject: Result: New JDK Project Reviewer: Mark Sheppard Message-ID: Voting for Mark Sheppard (msheppar) [1] is now closed. Yes: 26 Abstain: 0 Invalid: 0 According to the Bylaws definition of Three-Vote Consensus [1], this is sufficient to approve the nomination. -Chris. [1] https://mail.openjdk.java.net/pipermail/jdk-dev/2020-April/004205.html [2] http://openjdk.java.net/bylaws#three-vote-consensus From mark.reinhold at oracle.com Thu Apr 30 22:06:21 2020 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Thu, 30 Apr 2020 15:06:21 -0700 (PDT) Subject: JEP proposed to target JDK 15: 373: Reimplement the Legacy DatagramSocket API Message-ID: <20200430220621.D4C3D331A94@eggemoggin.niobe.net> The following JEP is proposed to target JDK 15: 373: Reimplement the Legacy DatagramSocket API https://openjdk.java.net/jeps/373 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, 7 May, 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 Apr 30 22:07:32 2020 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Thu, 30 Apr 2020 15:07:32 -0700 (PDT) Subject: JEP proposed to target JDK 15: 375: Pattern Matching for instanceof (Second Preview) Message-ID: <20200430220732.CAD77331A9A@eggemoggin.niobe.net> The following JEP is proposed to target JDK 15: 375: Pattern Matching for instanceof (Second Preview) https://openjdk.java.net/jeps/375 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, 7 May, 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