From ivan.gerasimov at oracle.com Wed Aug 1 06:06:51 2018 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Tue, 31 Jul 2018 23:06:51 -0700 Subject: CFV: New JDK Reviewer: Adam Petcher In-Reply-To: <8f94f30f-04c1-7b0f-a9d0-d9f55385dcb9@oracle.com> References: <8f94f30f-04c1-7b0f-a9d0-d9f55385dcb9@oracle.com> Message-ID: Vote: Yes On 7/31/18 7:05 AM, Sean Mullan wrote: > I hereby nominate Adam Petcher to JDK Reviewer. > -- With kind regards, Ivan Gerasimov From dmitry.markov at oracle.com Wed Aug 1 08:52:44 2018 From: dmitry.markov at oracle.com (Dmitry Markov) Date: Wed, 1 Aug 2018 09:52:44 +0100 Subject: CFV: New JDK Reviewer: Adam Petcher In-Reply-To: <8f94f30f-04c1-7b0f-a9d0-d9f55385dcb9@oracle.com> References: <8f94f30f-04c1-7b0f-a9d0-d9f55385dcb9@oracle.com> Message-ID: <76B88BEE-5FDE-4EBB-B986-2DE5609E6FF9@oracle.com> Vote: Yes Thanks, Dmitry > On 31 Jul 2018, at 15:05, Sean Mullan wrote: > > I hereby nominate Adam Petcher to JDK Reviewer. > > Adam is a member of the Security Libraries Team at Oracle. He has been working on security for the JDK since December 2016 and has made 28 official contributions [3]. Adam is also the lead of 2 significant crypto related JEPs, one which will be delivered in JDK 11, and the other which is currently a Candidate: > > - JEP 324: Key Agreement with Curve25519 and Curve448 (http://openjdk.java.net/jeps/324) > - JEP 339: Edwards-Curve Digital Signature Algorithm (EdDSA) (http://openjdk.java.net/jeps/339) > > In addition, he was a contributor to the TLS 1.3 implementation and wrote code for the session resumption and signature schemes which will be delivered in JDK 11: > > http://hg.openjdk.java.net/jdk/jdk/rev/68fa3d4026ea > > Based on Adam's work on JEPs and the many significant contributions he has made to the JDK, I believe he is fully ready for the Reviewer role. > > Votes are due by 15:00 GMT Tuesday August 14, 2018. > > 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]. > > Sean Mullan > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#reviewer-vote > [3] http://hg.openjdk.java.net/jdk/jdk/search/?rev=%28keyword%28adam.petcher%29%20or%20author%28apetcher%29%29&revcount=200 From dmitry.markov at oracle.com Wed Aug 1 08:55:43 2018 From: dmitry.markov at oracle.com (Dmitry Markov) Date: Wed, 1 Aug 2018 09:55:43 +0100 Subject: CFV: New JDK Committer: Leonid Mesnik In-Reply-To: References: Message-ID: <8B9AF4AC-C5E2-4E8F-AE10-D3FC23E68263@oracle.com> Vote: Yes Thanks, Dmitry > On 26 Jul 2018, at 22:26, Igor Ignatyev wrote: > > I hereby nominate Leonid Mesnik (lmesnik) to JDK Committer. > > Leonid works for the Oracle SQE team and has contributed more than 30 changes. > His contributions can be found here [3] and are also listed below. > > Votes are due by 2:30 pm PT, August 9, 2018. > > Only current JDK Committers [1] are eligible to vote > on this nomination. Votes must be cast in the open by replying > to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Igor Ignatyev > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] http://hg.openjdk.java.net/jdk/jdk/log?revcount=1000&rev=(keyword(%22leonid.mesnik%40oracle.com%22)+or+author(lmesnik))+and+not+desc(%22Merge%22) > > 8204974: Quarantine serviceability/sa/TestInstanceKlassSize* tests for CDS enabled mode > 8204103: Mark test serviceability/dcmd/compiler/CompilerQueueTest.java as intermittent and exclude it from tier1 > 8203491: [TESTBUG] Port heapdump tests into java > 8202748: jtreg :hotspot_misc group shouldn't include vmTestbase tests > 8200187: Exclude 3 long-running tests from tier1 > 8200091: [TESTBUG] Update jittester for jdk11 > 8199271: [TESTBUG] open source VM testbase stress tests > 8199064: Test applications/jcstress/other/Test.java#id1108 fails on Sparc > 8197901: Crash during GC when logging level is debug > 8197455: There is some runthese related unused code in bytecodeInterpreter.cpp > 8184775: tools/launcher/modules/illegalaccess/IllegalAccessTest.java times out on some platforms when xcomp is used. > 8166898: G1SATBCardTableLoggingModRefBS::invalidate() incorrect with whole_heap == true > 8166761: Compiler testing in tier2 should be optimized to finish in 20 minutes. > 8166724: gc/g1/TestHumongousShrinkHeap.java fails with OOME > 8162852: Mark stress compiler and gc tests with stress keyword > 8158581: ciReplay can not be run w/ JFR enabled > 8157831: JVMCI tests should not be executed on linux-arm32 > 8156777: [TESTBUG] test/testlibrary_tests/SimpleClassFileLoadHookTest.java requires non minimal VM > 8156032: Clean up parallel GC specific code from vm/gc/shared/preservedMarks.cpp > 8155950: Add minimal VM in JIB profile on linux-x86 > 8155946: Minimal VM fails to built after 8154153: PS: Restore preserved marks in parallel > 8155570: serviceability/tmtools/jstat/GcTest02.java fails with parallel GC > 8154209: Remove client VM from default JIB profile on windows-x86 and linux-x86 > 8143966: JEP 233: Generate Run-Time Compiler Tests Automatically > 8139876: Exclude hanging nsk/stress/stack from execution with deoptimization enabled > 8079134: [TESTBUG] Remove applicable_*gc and needs_*gc groups from TEST.groups > 8065579: WB method to start G1 concurrent mark cycle should be introduced > 8055953: [TESTBUG] Fix for 8055098 does not contain unit test > 8055098: WB API should be extended to provide information about size and age of object. > 8009808: TEST-BUG : test case is using bash style tests. Default shell for jtreg is bourne. thus failure > 8009763: Add WB test for String.intern() From rajan.halade at oracle.com Wed Aug 1 17:44:21 2018 From: rajan.halade at oracle.com (Rajan Halade) Date: Wed, 1 Aug 2018 10:44:21 -0700 Subject: CFV: New JDK Committer: Leonid Mesnik In-Reply-To: References: Message-ID: <1e9b55d2-63f9-6ad6-2305-94233e5d1bca@oracle.com> Vote: yes - Rajan On 7/26/18 2:26 PM, Igor Ignatyev wrote: > I hereby nominate Leonid Mesnik (lmesnik) to JDK Committer. From rajan.halade at oracle.com Wed Aug 1 17:45:31 2018 From: rajan.halade at oracle.com (Rajan Halade) Date: Wed, 1 Aug 2018 10:45:31 -0700 Subject: CFV: New JDK Reviewer: Adam Petcher In-Reply-To: <8f94f30f-04c1-7b0f-a9d0-d9f55385dcb9@oracle.com> References: <8f94f30f-04c1-7b0f-a9d0-d9f55385dcb9@oracle.com> Message-ID: Vote: yes - Rajan On 7/31/18 7:05 AM, Sean Mullan wrote: > I hereby nominate Adam Petcher to JDK Reviewer. From Sergey.Bylokhov at oracle.com Wed Aug 1 18:36:12 2018 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 1 Aug 2018 11:36:12 -0700 Subject: CFV: New JDK Committer: Ekaterina Pavlova In-Reply-To: <7aec8105-8d0e-6778-c064-1ab4f2fd8208@oracle.com> References: <7aec8105-8d0e-6778-c064-1ab4f2fd8208@oracle.com> Message-ID: <6efd99d2-e3fe-6cd2-0566-f3991860c1fc@oracle.com> Vote: yes -- Best regards, Sergey. From valerie.peng at oracle.com Wed Aug 1 20:10:13 2018 From: valerie.peng at oracle.com (Valerie Peng) Date: Wed, 1 Aug 2018 13:10:13 -0700 Subject: CFV: New JDK Reviewer: Adam Petcher In-Reply-To: <8f94f30f-04c1-7b0f-a9d0-d9f55385dcb9@oracle.com> References: <8f94f30f-04c1-7b0f-a9d0-d9f55385dcb9@oracle.com> Message-ID: <0dff0112-01cb-bc9f-548b-065358a8618e@oracle.com> Vote: Yes Valerie On 7/31/2018 7:05 AM, Sean Mullan wrote: > I hereby nominate Adam Petcher to JDK Reviewer. > > Adam is a member of the Security Libraries Team at Oracle. He has been > working on security for the JDK since December 2016 and has made 28 > official contributions [3]. Adam is also the lead of 2 significant > crypto related JEPs, one which will be delivered in JDK 11, and the > other which is currently a Candidate: > > ?? - JEP 324: Key Agreement with Curve25519 and Curve448 > (http://openjdk.java.net/jeps/324) > ?? - JEP 339: Edwards-Curve Digital Signature Algorithm (EdDSA) > (http://openjdk.java.net/jeps/339) > > In addition, he was a contributor to the TLS 1.3 implementation and > wrote code for the session resumption and signature schemes which will > be delivered in JDK 11: > > ?? http://hg.openjdk.java.net/jdk/jdk/rev/68fa3d4026ea > > Based on Adam's work on JEPs and the many significant contributions he > has made to the JDK, I believe he is fully ready for the Reviewer role. > > Votes are due by 15:00 GMT Tuesday August 14, 2018. > > 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]. > > Sean Mullan > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#reviewer-vote > [3] > http://hg.openjdk.java.net/jdk/jdk/search/?rev=%28keyword%28adam.petcher%29%20or%20author%28apetcher%29%29&revcount=200 From vladimir.x.ivanov at oracle.com Wed Aug 1 20:35:32 2018 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Wed, 1 Aug 2018 13:35:32 -0700 Subject: CFV: New JDK Reviewer: Adam Petcher In-Reply-To: <8f94f30f-04c1-7b0f-a9d0-d9f55385dcb9@oracle.com> References: <8f94f30f-04c1-7b0f-a9d0-d9f55385dcb9@oracle.com> Message-ID: <35e923df-d1fe-8a70-64f3-9f74001c0e96@oracle.com> Vote: yes Best regards, Vladimir Ivanov On 31/07/2018 07:05, Sean Mullan wrote: > I hereby nominate Adam Petcher to JDK Reviewer. > From vladimir.x.ivanov at oracle.com Wed Aug 1 20:36:10 2018 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Wed, 1 Aug 2018 13:36:10 -0700 Subject: CFV: New JDK Committer: Ekaterina Pavlova In-Reply-To: References: Message-ID: Vote: yes Best regards, Vladimir Ivanov On 20/07/2018 11:52, Igor Ignatyev wrote: > I hereby nominate Ekaterina Pavlova (epavlova) to JDK Committer. From vladimir.x.ivanov at oracle.com Wed Aug 1 20:36:30 2018 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Wed, 1 Aug 2018 13:36:30 -0700 Subject: CFV: New JDK Committer: Leonid Mesnik In-Reply-To: References: Message-ID: Vote: yes Best regards, Vladimir Ivanov On 26/07/2018 14:26, Igor Ignatyev wrote: > I hereby nominate Leonid Mesnik (lmesnik) to JDK Committer. From dmitry.markov at oracle.com Thu Aug 2 06:46:55 2018 From: dmitry.markov at oracle.com (Dmitry Markov) Date: Thu, 2 Aug 2018 07:46:55 +0100 Subject: CFV: New JDK Committer: Ekaterina Pavlova In-Reply-To: References: Message-ID: <6243C2C9-06E3-4C22-A48B-5CE2C84D5866@oracle.com> Vote: Yes Thanks, Dmitry > On 20 Jul 2018, at 19:52, Igor Ignatyev wrote: > > I hereby nominate Ekaterina Pavlova (epavlova) to JDK Committer. > > Ekaterina works for the Oracle SQE team and has contributed more than 20 changes. > Her contributions can be found here [3] and are also listed below. > > Votes are due by 12:00 pm PT, August 3, 2018. > > Only current JDK Committers [1] are eligible to vote > on this nomination. Votes must be cast in the open by replying > to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Igor Ignatyev > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] http://hg.openjdk.java.net/jdk/jdk/log?revcount=100&rev=(author(epavlova)+or+desc(%22ekaterina.pavlova%40oracle.com%22))+and+not+merge() > > 8207761: Split compiler/graalunit/JttReflectFTest.java > 8207380: compiler/graalunit/JttLangMTest.java timeout > 8206951: [Graal] org.graalvm.compiler.hotspot.test.GraalOSRTest to ProblemList-graal.txt > 8195630: [Graal] vmTestbase/nsk/jvmti/AttachOnDemand/attach024/TestDescription.java fails with Graal > 8205207: Port Graal unit tests under jtreg > 8205074: [Graal] Add rest of compiler/stable tests into ProblemList-graal.txt > 8204978: [Graal] Disable Epsilon GC tests from running with Graal > 8204694: Add failed compiler/stable tests into ProblemList-graal.txt > 8200266: [Graal] Update ProblemList-graal.txt files > 8203318: compiler/stable/TestStableShort.java is broken > 8202276: Update test/hotspot/jtreg/ProblemList-graal.txt > 8200071: Fix test/hotspot/jtreg/ProblemList-graal.txt > 8198924: [Graal] java/lang/StackWalker/LocalsAndOperands.java timeouts with Graal > 8197453: Add support of extra problem list > 8190975: [Graal] Tests which run with --limit-modules java.base could fail when Graal is used as JIT > 8185134: [Graal] Introduce vm.graal predicate and tag tests which are not applicable for Graal > 8181124: Get rid of compiler.testlibrary.rtm.predicate > 8145728: compiler/cpuflags/TestAESIntrinsicsOnSupportedConfig.java Expected message not found > 8180324: [JVMCI][TESTBUG] failed JVMCI junit test NativeCallTest.java > 8181124: Get rid of compiler.testlibrary.rtm.predicate > 8181820: jdk/test/lib/Platform should not depend on jdk/test/lib/Utils > 8178118: Arguments::create_numbered_property allocates wrong buffer in case count > 99 > 8178731: compiler/ciReplay/SABase.java does not compile From karen.kinnear at oracle.com Thu Aug 2 13:32:05 2018 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Thu, 2 Aug 2018 06:32:05 -0700 Subject: CFV: New JDK Committer: Ekaterina Pavlova In-Reply-To: References: Message-ID: <2CBA8971-DF4E-4FB3-B12C-7F8818609DBD@oracle.com> Vote: yes Thanks, Karen > On Jul 23, 2018, at 5:17 AM, Mario Torre wrote: > > Vote: yes, > > Cheers, > Mario > >> On Fri, Jul 20, 2018 at 8:52 PM, Igor Ignatyev wrote: >> I hereby nominate Ekaterina Pavlova (epavlova) to JDK Committer. >> >> Ekaterina works for the Oracle SQE team and has contributed more than 20 changes. >> Her contributions can be found here [3] and are also listed below. >> >> Votes are due by 12:00 pm PT, August 3, 2018. >> >> Only current JDK Committers [1] are eligible to vote >> on this nomination. Votes must be cast in the open by replying >> to this mailing list. >> >> For Lazy Consensus voting instructions, see [2]. >> >> Igor Ignatyev >> >> [1] http://openjdk.java.net/census >> [2] http://openjdk.java.net/projects/#committer-vote >> [3] http://hg.openjdk.java.net/jdk/jdk/log?revcount=100&rev=(author(epavlova)+or+desc(%22ekaterina.pavlova%40oracle.com%22))+and+not+merge() >> >> 8207761: Split compiler/graalunit/JttReflectFTest.java >> 8207380: compiler/graalunit/JttLangMTest.java timeout >> 8206951: [Graal] org.graalvm.compiler.hotspot.test.GraalOSRTest to ProblemList-graal.txt >> 8195630: [Graal] vmTestbase/nsk/jvmti/AttachOnDemand/attach024/TestDescription.java fails with Graal >> 8205207: Port Graal unit tests under jtreg >> 8205074: [Graal] Add rest of compiler/stable tests into ProblemList-graal.txt >> 8204978: [Graal] Disable Epsilon GC tests from running with Graal >> 8204694: Add failed compiler/stable tests into ProblemList-graal.txt >> 8200266: [Graal] Update ProblemList-graal.txt files >> 8203318: compiler/stable/TestStableShort.java is broken >> 8202276: Update test/hotspot/jtreg/ProblemList-graal.txt >> 8200071: Fix test/hotspot/jtreg/ProblemList-graal.txt >> 8198924: [Graal] java/lang/StackWalker/LocalsAndOperands.java timeouts with Graal >> 8197453: Add support of extra problem list >> 8190975: [Graal] Tests which run with --limit-modules java.base could fail when Graal is used as JIT >> 8185134: [Graal] Introduce vm.graal predicate and tag tests which are not applicable for Graal >> 8181124: Get rid of compiler.testlibrary.rtm.predicate >> 8145728: compiler/cpuflags/TestAESIntrinsicsOnSupportedConfig.java Expected message not found >> 8180324: [JVMCI][TESTBUG] failed JVMCI junit test NativeCallTest.java >> 8181124: Get rid of compiler.testlibrary.rtm.predicate >> 8181820: jdk/test/lib/Platform should not depend on jdk/test/lib/Utils >> 8178118: Arguments::create_numbered_property allocates wrong buffer in case count > 99 >> 8178731: compiler/ciReplay/SABase.java does not compile > > > > -- > Mario Torre > Associate Manager, Software Engineering > Red Hat GmbH > 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From serguei.spitsyn at oracle.com Thu Aug 2 17:47:37 2018 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 2 Aug 2018 10:47:37 -0700 Subject: CFV: New JDK Reviewer: Adam Petcher In-Reply-To: <8f94f30f-04c1-7b0f-a9d0-d9f55385dcb9@oracle.com> References: <8f94f30f-04c1-7b0f-a9d0-d9f55385dcb9@oracle.com> Message-ID: Vote: yes From serguei.spitsyn at oracle.com Thu Aug 2 18:08:36 2018 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 2 Aug 2018 11:08:36 -0700 Subject: CFV: New JDK Committer: Daniil Titov In-Reply-To: References: Message-ID: I hereby nominate Daniil Titov (dtitov) to JDK Committer. Daniil works for the Oracle Serviceability team and has contributed more than 20 changes. His contributions can be found here [3]. Votes are due by 12:00 pm PT, August 16, 2018. Only current JDK Committers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [2]. Serguei Spitsyn [1] http://openjdk.java.net/census [2] http://openjdk.java.net/projects/#committer-vote [3] http://hg.openjdk.java.net/jdk/jdk/log?revcount=1000&rev=(keyword(%22daniil.titov%40oracle.com%22)+or+author(dtitov))+and+not+desc(%22Merge%22) From vladimir.kozlov at oracle.com Thu Aug 2 18:10:15 2018 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 2 Aug 2018 11:10:15 -0700 Subject: CFV: New JDK Committer: Daniil Titov In-Reply-To: References: Message-ID: Vote: yes On 8/2/18 11:08 AM, serguei.spitsyn at oracle.com wrote: > I hereby nominate Daniil Titov (dtitov) to JDK Committer. > > Daniil works for the Oracle Serviceability team and has contributed more > than 20 changes. > His contributions can be found here [3]. > > Votes are due by 12:00 pm PT, August 16, 2018. > > Only current JDK Committers [1] are eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Serguei Spitsyn > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] > http://hg.openjdk.java.net/jdk/jdk/log?revcount=1000&rev=(keyword(%22daniil.titov%40oracle.com%22)+or+author(dtitov))+and+not+desc(%22Merge%22) > > > From serguei.spitsyn at oracle.com Thu Aug 2 18:21:58 2018 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 2 Aug 2018 11:21:58 -0700 Subject: CFV: New JDK Committer: Jc Beyler Message-ID: <5dccf119-c59a-3bb2-76c2-9bc7b309ec2d@oracle.com> I hereby nominate Jean Christophe Beyler (jcbeyler) to JDK Committer. Jean Christophe works for "Java Performance and Garbage Collection" and "Java Runtime" teams at Google and has contributed more than 20 changes. His contributions can be found here [3]. Votes are due by 12:00 pm PT, August 16, 2018. Only current JDK Committers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [2]. Serguei Spitsyn [1] http://openjdk.java.net/census [2] http://openjdk.java.net/projects/#committer-vote [3] http://hg.openjdk.java.net/jdk/jdk/log?revcount=1000&rev=(keyword(%22jcbeyler%40google.com%22)+or+author(jcbeyler))+and+not+desc(%22Merge%22) From Sergey.Bylokhov at oracle.com Thu Aug 2 18:22:53 2018 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 2 Aug 2018 11:22:53 -0700 Subject: CFV: New JDK Committer: Daniil Titov In-Reply-To: References: Message-ID: <792969b5-18a0-c559-12cb-0521452c125b@oracle.com> Vote: yes -- Best regards, Sergey. From philip.race at oracle.com Thu Aug 2 18:25:29 2018 From: philip.race at oracle.com (Philip Race) Date: Thu, 02 Aug 2018 11:25:29 -0700 Subject: CFV: New JDK Committer: Jc Beyler In-Reply-To: <5dccf119-c59a-3bb2-76c2-9bc7b309ec2d@oracle.com> References: <5dccf119-c59a-3bb2-76c2-9bc7b309ec2d@oracle.com> Message-ID: <5B634C99.5000308@oracle.com> Vote: yes -phil. From mikhailo.seledtsov at oracle.com Thu Aug 2 18:28:42 2018 From: mikhailo.seledtsov at oracle.com (mikhailo) Date: Thu, 2 Aug 2018 11:28:42 -0700 Subject: CFV: New JDK Committer: Jc Beyler In-Reply-To: <5dccf119-c59a-3bb2-76c2-9bc7b309ec2d@oracle.com> References: <5dccf119-c59a-3bb2-76c2-9bc7b309ec2d@oracle.com> Message-ID: Vote: yes Misha On 08/02/2018 11:21 AM, serguei.spitsyn at oracle.com wrote: > I hereby nominate Jean Christophe Beyler (jcbeyler) to JDK Committer. > > Jean Christophe works for "Java Performance and Garbage Collection" and > "Java Runtime" teams at Google and has contributed more than 20 changes. > His contributions can be found here [3]. > > Votes are due by 12:00 pm PT, August 16, 2018. > > Only current JDK Committers [1] are eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Serguei Spitsyn > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] > http://hg.openjdk.java.net/jdk/jdk/log?revcount=1000&rev=(keyword(%22jcbeyler%40google.com%22)+or+author(jcbeyler))+and+not+desc(%22Merge%22) > > > From chris.plummer at oracle.com Thu Aug 2 18:33:19 2018 From: chris.plummer at oracle.com (Chris Plummer) Date: Thu, 2 Aug 2018 11:33:19 -0700 Subject: CFV: New JDK Committer: Daniil Titov In-Reply-To: References: Message-ID: Vote: yes On 8/2/18 11:08 AM, serguei.spitsyn at oracle.com wrote: > I hereby nominate Daniil Titov (dtitov) to JDK Committer. > > Daniil works for the Oracle Serviceability team and has contributed > more than 20 changes. > His contributions can be found here [3]. > > Votes are due by 12:00 pm PT, August 16, 2018. > > Only current JDK Committers [1] are eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Serguei Spitsyn > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] > http://hg.openjdk.java.net/jdk/jdk/log?revcount=1000&rev=(keyword(%22daniil.titov%40oracle.com%22)+or+author(dtitov))+and+not+desc(%22Merge%22) > > From igor.ignatyev at oracle.com Thu Aug 2 18:34:01 2018 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Thu, 2 Aug 2018 11:34:01 -0700 Subject: CFV: New JDK Committer: Jc Beyler In-Reply-To: <5dccf119-c59a-3bb2-76c2-9bc7b309ec2d@oracle.com> References: <5dccf119-c59a-3bb2-76c2-9bc7b309ec2d@oracle.com> Message-ID: <7094AC8B-2C1C-47BF-B869-3A6DA8FA9442@oracle.com> Vote: yes -- Igor > On Aug 2, 2018, at 11:21 AM, serguei.spitsyn at oracle.com wrote: > > I hereby nominate Jean Christophe Beyler (jcbeyler) to JDK Committer. From chris.plummer at oracle.com Thu Aug 2 18:34:07 2018 From: chris.plummer at oracle.com (Chris Plummer) Date: Thu, 2 Aug 2018 11:34:07 -0700 Subject: CFV: New JDK Committer: Jc Beyler In-Reply-To: <5dccf119-c59a-3bb2-76c2-9bc7b309ec2d@oracle.com> References: <5dccf119-c59a-3bb2-76c2-9bc7b309ec2d@oracle.com> Message-ID: Vote: yes On 8/2/18 11:21 AM, serguei.spitsyn at oracle.com wrote: > I hereby nominate Jean Christophe Beyler (jcbeyler) to JDK Committer. > > Jean Christophe works for "Java Performance and Garbage Collection" and > "Java Runtime" teams at Google and has contributed more than 20 changes. > His contributions can be found here [3]. > > Votes are due by 12:00 pm PT, August 16, 2018. > > Only current JDK Committers [1] are eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Serguei Spitsyn > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] > http://hg.openjdk.java.net/jdk/jdk/log?revcount=1000&rev=(keyword(%22jcbeyler%40google.com%22)+or+author(jcbeyler))+and+not+desc(%22Merge%22) > > > From igor.ignatyev at oracle.com Thu Aug 2 18:35:35 2018 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Thu, 2 Aug 2018 11:35:35 -0700 Subject: CFV: New JDK Committer: Daniil Titov In-Reply-To: References: Message-ID: Vote: yes -- Igor > On Aug 2, 2018, at 11:08 AM, serguei.spitsyn at oracle.com wrote: > > I hereby nominate Daniil Titov (dtitov) to JDK Committer. From coleen.phillimore at oracle.com Thu Aug 2 18:37:06 2018 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Thu, 2 Aug 2018 14:37:06 -0400 Subject: CFV: New JDK Committer: Jc Beyler In-Reply-To: <5dccf119-c59a-3bb2-76c2-9bc7b309ec2d@oracle.com> References: <5dccf119-c59a-3bb2-76c2-9bc7b309ec2d@oracle.com> Message-ID: Vote: yes On 8/2/18 2:21 PM, serguei.spitsyn at oracle.com wrote: > I hereby nominate Jean Christophe Beyler (jcbeyler) to JDK Committer. > > Jean Christophe works for "Java Performance and Garbage Collection" and > "Java Runtime" teams at Google and has contributed more than 20 changes. > His contributions can be found here [3]. > > Votes are due by 12:00 pm PT, August 16, 2018. > > Only current JDK Committers [1] are eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Serguei Spitsyn > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] > http://hg.openjdk.java.net/jdk/jdk/log?revcount=1000&rev=(keyword(%22jcbeyler%40google.com%22)+or+author(jcbeyler))+and+not+desc(%22Merge%22) > > > From daniel.daugherty at oracle.com Thu Aug 2 18:38:18 2018 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 2 Aug 2018 14:38:18 -0400 Subject: CFV: New JDK Committer: Jc Beyler In-Reply-To: <5dccf119-c59a-3bb2-76c2-9bc7b309ec2d@oracle.com> References: <5dccf119-c59a-3bb2-76c2-9bc7b309ec2d@oracle.com> Message-ID: <18f79240-b15d-099f-f935-cdd7fe9064c3@oracle.com> Vote: yes Dan On 8/2/18 2:21 PM, serguei.spitsyn at oracle.com wrote: > I hereby nominate Jean Christophe Beyler (jcbeyler) to JDK Committer. > > Jean Christophe works for "Java Performance and Garbage Collection" and > "Java Runtime" teams at Google and has contributed more than 20 changes. > His contributions can be found here [3]. > > Votes are due by 12:00 pm PT, August 16, 2018. > > Only current JDK Committers [1] are eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Serguei Spitsyn > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] > http://hg.openjdk.java.net/jdk/jdk/log?revcount=1000&rev=(keyword(%22jcbeyler%40google.com%22)+or+author(jcbeyler))+and+not+desc(%22Merge%22) > > > > From hohensee at amazon.com Thu Aug 2 18:42:34 2018 From: hohensee at amazon.com (Hohensee, Paul) Date: Thu, 2 Aug 2018 18:42:34 +0000 Subject: New JDK Committer: Jc Beyler In-Reply-To: <5dccf119-c59a-3bb2-76c2-9bc7b309ec2d@oracle.com> References: <5dccf119-c59a-3bb2-76c2-9bc7b309ec2d@oracle.com> Message-ID: <4982D2C4-E229-4C8F-A795-029FB239950B@amazon.com> Vote: yes. ?On 8/2/18, 11:23 AM, "jdk-dev on behalf of serguei.spitsyn at oracle.com" wrote: I hereby nominate Jean Christophe Beyler (jcbeyler) to JDK Committer. Jean Christophe works for "Java Performance and Garbage Collection" and "Java Runtime" teams at Google and has contributed more than 20 changes. His contributions can be found here [3]. Votes are due by 12:00 pm PT, August 16, 2018. Only current JDK Committers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [2]. Serguei Spitsyn [1] http://openjdk.java.net/census [2] http://openjdk.java.net/projects/#committer-vote [3] http://hg.openjdk.java.net/jdk/jdk/log?revcount=1000&rev=(keyword(%22jcbeyler%40google.com%22)+or+author(jcbeyler))+and+not+desc(%22Merge%22) From calvin.cheung at oracle.com Thu Aug 2 18:51:29 2018 From: calvin.cheung at oracle.com (Calvin Cheung) Date: Thu, 02 Aug 2018 11:51:29 -0700 Subject: CFV: New JDK Reviewer: Adam Petcher In-Reply-To: <8f94f30f-04c1-7b0f-a9d0-d9f55385dcb9@oracle.com> References: <8f94f30f-04c1-7b0f-a9d0-d9f55385dcb9@oracle.com> Message-ID: <5B6352B1.9000609@oracle.com> Vote: yes On 7/31/18, 7:05 AM, Sean Mullan wrote: > I hereby nominate Adam Petcher to JDK Reviewer. > > Adam is a member of the Security Libraries Team at Oracle. He has been > working on security for the JDK since December 2016 and has made 28 > official contributions [3]. Adam is also the lead of 2 significant > crypto related JEPs, one which will be delivered in JDK 11, and the > other which is currently a Candidate: > > - JEP 324: Key Agreement with Curve25519 and Curve448 > (http://openjdk.java.net/jeps/324) > - JEP 339: Edwards-Curve Digital Signature Algorithm (EdDSA) > (http://openjdk.java.net/jeps/339) > > In addition, he was a contributor to the TLS 1.3 implementation and > wrote code for the session resumption and signature schemes which will > be delivered in JDK 11: > > http://hg.openjdk.java.net/jdk/jdk/rev/68fa3d4026ea > > Based on Adam's work on JEPs and the many significant contributions he > has made to the JDK, I believe he is fully ready for the Reviewer role. > > Votes are due by 15:00 GMT Tuesday August 14, 2018. > > 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]. > > Sean Mullan > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#reviewer-vote > [3] > http://hg.openjdk.java.net/jdk/jdk/search/?rev=%28keyword%28adam.petcher%29%20or%20author%28apetcher%29%29&revcount=200 From calvin.cheung at oracle.com Thu Aug 2 18:52:17 2018 From: calvin.cheung at oracle.com (Calvin Cheung) Date: Thu, 02 Aug 2018 11:52:17 -0700 Subject: CFV: New JDK Committer: Daniil Titov In-Reply-To: References: Message-ID: <5B6352E1.2090700@oracle.com> Vote: yes On 8/2/18, 11:08 AM, serguei.spitsyn at oracle.com wrote: > I hereby nominate Daniil Titov (dtitov) to JDK Committer. > > Daniil works for the Oracle Serviceability team and has contributed > more than 20 changes. > His contributions can be found here [3]. > > Votes are due by 12:00 pm PT, August 16, 2018. > > Only current JDK Committers [1] are eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Serguei Spitsyn > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] > http://hg.openjdk.java.net/jdk/jdk/log?revcount=1000&rev=(keyword(%22daniil.titov%40oracle.com%22)+or+author(dtitov))+and+not+desc(%22Merge%22) > > From calvin.cheung at oracle.com Thu Aug 2 18:53:08 2018 From: calvin.cheung at oracle.com (Calvin Cheung) Date: Thu, 02 Aug 2018 11:53:08 -0700 Subject: CFV: New JDK Committer: Jc Beyler In-Reply-To: <5dccf119-c59a-3bb2-76c2-9bc7b309ec2d@oracle.com> References: <5dccf119-c59a-3bb2-76c2-9bc7b309ec2d@oracle.com> Message-ID: <5B635314.8050806@oracle.com> Vote: yes On 8/2/18, 11:21 AM, serguei.spitsyn at oracle.com wrote: > I hereby nominate Jean Christophe Beyler (jcbeyler) to JDK Committer. > > Jean Christophe works for "Java Performance and Garbage Collection" and > "Java Runtime" teams at Google and has contributed more than 20 changes. > His contributions can be found here [3]. > > Votes are due by 12:00 pm PT, August 16, 2018. > > Only current JDK Committers [1] are eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Serguei Spitsyn > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] > http://hg.openjdk.java.net/jdk/jdk/log?revcount=1000&rev=(keyword(%22jcbeyler%40google.com%22)+or+author(jcbeyler))+and+not+desc(%22Merge%22) > > > From vladimir.x.ivanov at oracle.com Thu Aug 2 18:57:45 2018 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Thu, 2 Aug 2018 11:57:45 -0700 Subject: CFV: New JDK Committer: Jc Beyler In-Reply-To: <5dccf119-c59a-3bb2-76c2-9bc7b309ec2d@oracle.com> References: <5dccf119-c59a-3bb2-76c2-9bc7b309ec2d@oracle.com> Message-ID: <87d40144-1319-ee97-0b13-3e36327c819e@oracle.com> Vote: yes Best regards, Vladimir Ivanov On 02/08/2018 11:21, serguei.spitsyn at oracle.com wrote: > I hereby nominate Jean Christophe Beyler (jcbeyler) to JDK Committer. From vladimir.kozlov at oracle.com Thu Aug 2 18:59:13 2018 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 2 Aug 2018 11:59:13 -0700 Subject: CFV: New JDK Committer: Jc Beyler In-Reply-To: <5dccf119-c59a-3bb2-76c2-9bc7b309ec2d@oracle.com> References: <5dccf119-c59a-3bb2-76c2-9bc7b309ec2d@oracle.com> Message-ID: Vote: yes On 8/2/18 11:21 AM, serguei.spitsyn at oracle.com wrote: > I hereby nominate Jean Christophe Beyler (jcbeyler) to JDK Committer. > > Jean Christophe works for "Java Performance and Garbage Collection" and > "Java Runtime" teams at Google and has contributed more than 20 changes. > His contributions can be found here [3]. > > Votes are due by 12:00 pm PT, August 16, 2018. > > Only current JDK Committers [1] are eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Serguei Spitsyn > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] > http://hg.openjdk.java.net/jdk/jdk/log?revcount=1000&rev=(keyword(%22jcbeyler%40google.com%22)+or+author(jcbeyler))+and+not+desc(%22Merge%22) > > > > From gromero at linux.vnet.ibm.com Thu Aug 2 19:09:28 2018 From: gromero at linux.vnet.ibm.com (Gustavo Romero) Date: Thu, 2 Aug 2018 16:09:28 -0300 Subject: CFV: New JDK Committer: Jc Beyler In-Reply-To: <5dccf119-c59a-3bb2-76c2-9bc7b309ec2d@oracle.com> References: <5dccf119-c59a-3bb2-76c2-9bc7b309ec2d@oracle.com> Message-ID: <4ddf983b-56e5-3c80-adeb-15ac55d3848b@linux.vnet.ibm.com> Vote: yes On 08/02/2018 03:21 PM, serguei.spitsyn at oracle.com wrote: > I hereby nominate Jean Christophe Beyler (jcbeyler) to JDK Committer. > > Jean Christophe works for "Java Performance and Garbage Collection" and > "Java Runtime" teams at Google and has contributed more than 20 changes. > His contributions can be found here [3]. > > Votes are due by 12:00 pm PT, August 16, 2018. > > Only current JDK Committers [1] are eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Serguei Spitsyn > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] http://hg.openjdk.java.net/jdk/jdk/log?revcount=1000&rev=(keyword(%22jcbeyler%40google.com%22)+or+author(jcbeyler))+and+not+desc(%22Merge%22) From andy.herrick at oracle.com Thu Aug 2 19:14:18 2018 From: andy.herrick at oracle.com (Andy Herrick) Date: Thu, 2 Aug 2018 15:14:18 -0400 Subject: CFV: New JDK Committer: Daniil Titov In-Reply-To: References: Message-ID: <296e3c46-b277-709b-68bb-f5a227d13e1c@oracle.com> vote: yes /Andy On 8/2/2018 2:08 PM, serguei.spitsyn at oracle.com wrote: > I hereby nominate Daniil Titov (dtitov) to JDK Committer. > > Daniil works for the Oracle Serviceability team and has contributed > more than 20 changes. > His contributions can be found here [3]. > > Votes are due by 12:00 pm PT, August 16, 2018. > > Only current JDK Committers [1] are eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Serguei Spitsyn > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] > http://hg.openjdk.java.net/jdk/jdk/log?revcount=1000&rev=(keyword(%22daniil.titov%40oracle.com%22)+or+author(dtitov))+and+not+desc(%22Merge%22) > > From Alan.Bateman at oracle.com Thu Aug 2 19:19:50 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 2 Aug 2018 12:19:50 -0700 Subject: CFV: New JDK Committer: Jc Beyler In-Reply-To: <5dccf119-c59a-3bb2-76c2-9bc7b309ec2d@oracle.com> References: <5dccf119-c59a-3bb2-76c2-9bc7b309ec2d@oracle.com> Message-ID: Vote: yes From thomas.stuefe at gmail.com Thu Aug 2 19:22:15 2018 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 2 Aug 2018 21:22:15 +0200 Subject: CFV: New JDK Committer: Jc Beyler In-Reply-To: <5dccf119-c59a-3bb2-76c2-9bc7b309ec2d@oracle.com> References: <5dccf119-c59a-3bb2-76c2-9bc7b309ec2d@oracle.com> Message-ID: Vote: yes On Thu, Aug 2, 2018 at 8:21 PM, serguei.spitsyn at oracle.com wrote: > I hereby nominate Jean Christophe Beyler (jcbeyler) to JDK Committer. > > Jean Christophe works for "Java Performance and Garbage Collection" and > "Java Runtime" teams at Google and has contributed more than 20 changes. > His contributions can be found here [3]. > > Votes are due by 12:00 pm PT, August 16, 2018. > > Only current JDK Committers [1] are eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Serguei Spitsyn > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] > http://hg.openjdk.java.net/jdk/jdk/log?revcount=1000&rev=(keyword(%22jcbeyler%40google.com%22)+or+author(jcbeyler))+and+not+desc(%22Merge%22) > > > From thomas.stuefe at gmail.com Thu Aug 2 19:22:27 2018 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 2 Aug 2018 21:22:27 +0200 Subject: CFV: New JDK Committer: Daniil Titov In-Reply-To: References: Message-ID: Vote: yes On Thu, Aug 2, 2018 at 8:08 PM, serguei.spitsyn at oracle.com wrote: > I hereby nominate Daniil Titov (dtitov) to JDK Committer. > > Daniil works for the Oracle Serviceability team and has contributed more > than 20 changes. > His contributions can be found here [3]. > > Votes are due by 12:00 pm PT, August 16, 2018. > > Only current JDK Committers [1] are eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Serguei Spitsyn > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] > http://hg.openjdk.java.net/jdk/jdk/log?revcount=1000&rev=(keyword(%22daniil.titov%40oracle.com%22)+or+author(dtitov))+and+not+desc(%22Merge%22) > > From zgu at redhat.com Thu Aug 2 19:29:22 2018 From: zgu at redhat.com (Zhengyu Gu) Date: Thu, 2 Aug 2018 15:29:22 -0400 Subject: CFV: New JDK Committer: Jc Beyler In-Reply-To: <5dccf119-c59a-3bb2-76c2-9bc7b309ec2d@oracle.com> References: <5dccf119-c59a-3bb2-76c2-9bc7b309ec2d@oracle.com> Message-ID: <0ce6735e-0cc2-d228-a58b-60f1393f7eb1@redhat.com> Vote: yes -Zhengyu On 08/02/2018 02:21 PM, serguei.spitsyn at oracle.com wrote: > I hereby nominate Jean Christophe Beyler (jcbeyler) to JDK Committer. > > Jean Christophe works for "Java Performance and Garbage Collection" and > "Java Runtime" teams at Google and has contributed more than 20 changes. > His contributions can be found here [3]. > > Votes are due by 12:00 pm PT, August 16, 2018. > > Only current JDK Committers [1] are eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Serguei Spitsyn > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] > http://hg.openjdk.java.net/jdk/jdk/log?revcount=1000&rev=(keyword(%22jcbeyler%40google.com%22)+or+author(jcbeyler))+and+not+desc(%22Merge%22) > > > > From rasbold at google.com Thu Aug 2 19:46:38 2018 From: rasbold at google.com (Chuck Rasbold) Date: Thu, 2 Aug 2018 12:46:38 -0700 Subject: CFV: New JDK Committer: Jc Beyler In-Reply-To: <5dccf119-c59a-3bb2-76c2-9bc7b309ec2d@oracle.com> References: <5dccf119-c59a-3bb2-76c2-9bc7b309ec2d@oracle.com> Message-ID: Vote: yes On Thu, Aug 2, 2018 at 11:21 AM, serguei.spitsyn at oracle.com < serguei.spitsyn at oracle.com> wrote: > I hereby nominate Jean Christophe Beyler (jcbeyler) to JDK Committer. > > Jean Christophe works for "Java Performance and Garbage Collection" and > "Java Runtime" teams at Google and has contributed more than 20 changes. > His contributions can be found here [3]. > > Votes are due by 12:00 pm PT, August 16, 2018. > > Only current JDK Committers [1] are eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Serguei Spitsyn > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] http://hg.openjdk.java.net/jdk/jdk/log?revcount=1000&rev=( > keyword(%22jcbeyler%40google.com%22)+or+author(jcbeyler))+an > d+not+desc(%22Merge%22) > > > > From cushon at google.com Thu Aug 2 19:49:26 2018 From: cushon at google.com (Liam Miller-Cushon) Date: Thu, 2 Aug 2018 12:49:26 -0700 Subject: CFV: New JDK Committer: Jc Beyler In-Reply-To: References: <5dccf119-c59a-3bb2-76c2-9bc7b309ec2d@oracle.com> Message-ID: Vote: yes On Thu, Aug 2, 2018 at 12:46 PM Chuck Rasbold wrote: > Vote: yes > > On Thu, Aug 2, 2018 at 11:21 AM, serguei.spitsyn at oracle.com < > serguei.spitsyn at oracle.com> wrote: > > > I hereby nominate Jean Christophe Beyler (jcbeyler) to JDK Committer. > > > > Jean Christophe works for "Java Performance and Garbage Collection" and > > "Java Runtime" teams at Google and has contributed more than 20 changes. > > His contributions can be found here [3]. > > > > Votes are due by 12:00 pm PT, August 16, 2018. > > > > Only current JDK Committers [1] are eligible to vote on this nomination. > > Votes must be cast in the open by replying to this mailing list. > > > > For Lazy Consensus voting instructions, see [2]. > > > > Serguei Spitsyn > > > > [1] http://openjdk.java.net/census > > [2] http://openjdk.java.net/projects/#committer-vote > > [3] http://hg.openjdk.java.net/jdk/jdk/log?revcount=1000&rev=( > > keyword(%22jcbeyler%40google.com%22)+or+author(jcbeyler))+an > > d+not+desc(%22Merge%22) > > > > > > > > > From roger.riggs at oracle.com Thu Aug 2 20:04:56 2018 From: roger.riggs at oracle.com (Roger Riggs) Date: Thu, 2 Aug 2018 13:04:56 -0700 Subject: CFV: New JDK Committer: Jc Beyler In-Reply-To: <5dccf119-c59a-3bb2-76c2-9bc7b309ec2d@oracle.com> References: <5dccf119-c59a-3bb2-76c2-9bc7b309ec2d@oracle.com> Message-ID: <4e02e912-c54b-5d3f-0dd2-b0094b7f412a@oracle.com> Vote: Yes On 8/2/18 11:21 AM, serguei.spitsyn at oracle.com wrote: > I hereby nominate Jean Christophe Beyler (jcbeyler) to JDK Committer. From john.r.rose at oracle.com Thu Aug 2 20:39:24 2018 From: john.r.rose at oracle.com (John Rose) Date: Thu, 2 Aug 2018 13:39:24 -0700 Subject: CFV: New JDK Committer: Jc Beyler In-Reply-To: <5dccf119-c59a-3bb2-76c2-9bc7b309ec2d@oracle.com> References: <5dccf119-c59a-3bb2-76c2-9bc7b309ec2d@oracle.com> Message-ID: <3F877BEF-F39D-40B8-9C41-1E35E37EAA87@oracle.com> Vote: yes From james.laskey at oracle.com Thu Aug 2 21:16:00 2018 From: james.laskey at oracle.com (James Laskey) Date: Thu, 2 Aug 2018 14:16:00 -0700 Subject: CFV: New JDK Committer: Jc Beyler In-Reply-To: <5dccf119-c59a-3bb2-76c2-9bc7b309ec2d@oracle.com> References: <5dccf119-c59a-3bb2-76c2-9bc7b309ec2d@oracle.com> Message-ID: Vote: yes Sent from my iPhone > On Aug 2, 2018, at 11:21 AM, "serguei.spitsyn at oracle.com" wrote: > > I hereby nominate Jean Christophe Beyler (jcbeyler) to JDK Committer. > > Jean Christophe works for "Java Performance and Garbage Collection" and > "Java Runtime" teams at Google and has contributed more than 20 changes. > His contributions can be found here [3]. > > Votes are due by 12:00 pm PT, August 16, 2018. > > Only current JDK Committers [1] are eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Serguei Spitsyn > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] http://hg.openjdk.java.net/jdk/jdk/log?revcount=1000&rev=(keyword(%22jcbeyler%40google.com%22)+or+author(jcbeyler))+and+not+desc(%22Merge%22) > > > From martinrb at google.com Fri Aug 3 01:40:25 2018 From: martinrb at google.com (Martin Buchholz) Date: Thu, 2 Aug 2018 18:40:25 -0700 Subject: CFV: New JDK Committer: Jc Beyler In-Reply-To: <5dccf119-c59a-3bb2-76c2-9bc7b309ec2d@oracle.com> References: <5dccf119-c59a-3bb2-76c2-9bc7b309ec2d@oracle.com> Message-ID: Vote: yes From claes.redestad at oracle.com Fri Aug 3 04:49:24 2018 From: claes.redestad at oracle.com (Claes Redestad) Date: Thu, 02 Aug 2018 21:49:24 -0700 Subject: CFV: New JDK Committer: Jc Beyler In-Reply-To: <5dccf119-c59a-3bb2-76c2-9bc7b309ec2d@oracle.com> References: <5dccf119-c59a-3bb2-76c2-9bc7b309ec2d@oracle.com> Message-ID: Vote: yes "serguei.spitsyn at oracle.com" skrev: (2 augusti 2018 11:21:58 GMT-07:00) >I hereby nominate Jean Christophe Beyler (jcbeyler) to JDK Committer. > >Jean Christophe works for "Java Performance and Garbage Collection" and >"Java Runtime" teams at Google and has contributed more than 20 >changes. >His contributions can be found here [3]. > >Votes are due by 12:00 pm PT, August 16, 2018. > >Only current JDK Committers [1] are eligible to vote on this >nomination. >Votes must be cast in the open by replying to this mailing list. > >For Lazy Consensus voting instructions, see [2]. > >Serguei Spitsyn > >[1] http://openjdk.java.net/census >[2] http://openjdk.java.net/projects/#committer-vote >[3] >http://hg.openjdk.java.net/jdk/jdk/log?revcount=1000&rev=(keyword(%22jcbeyler%40google.com%22)+or+author(jcbeyler))+and+not+desc(%22Merge%22) -- Skickat fr?n min Android-enhet med K-9 Mail. Urs?kta min f?ordighet. From dmitry.markov at oracle.com Fri Aug 3 06:19:22 2018 From: dmitry.markov at oracle.com (Dmitry Markov) Date: Fri, 3 Aug 2018 07:19:22 +0100 Subject: CFV: New JDK Committer: Jc Beyler In-Reply-To: <5dccf119-c59a-3bb2-76c2-9bc7b309ec2d@oracle.com> References: <5dccf119-c59a-3bb2-76c2-9bc7b309ec2d@oracle.com> Message-ID: <73694CA7-37CA-4373-B1E6-8E75E2BC83F5@oracle.com> Vote: Yes Thanks, Dmitry > On 2 Aug 2018, at 19:21, serguei.spitsyn at oracle.com wrote: > > I hereby nominate Jean Christophe Beyler (jcbeyler) to JDK Committer. > > Jean Christophe works for "Java Performance and Garbage Collection" and > "Java Runtime" teams at Google and has contributed more than 20 changes. > His contributions can be found here [3]. > > Votes are due by 12:00 pm PT, August 16, 2018. > > Only current JDK Committers [1] are eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Serguei Spitsyn > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] http://hg.openjdk.java.net/jdk/jdk/log?revcount=1000&rev=(keyword(%22jcbeyler%40google.com%22)+or+author(jcbeyler))+and+not+desc(%22Merge%22) > > > From dmitry.markov at oracle.com Fri Aug 3 06:22:32 2018 From: dmitry.markov at oracle.com (Dmitry Markov) Date: Fri, 3 Aug 2018 07:22:32 +0100 Subject: CFV: New JDK Committer: Daniil Titov In-Reply-To: References: Message-ID: <7703BBC0-76CD-4264-8C4E-ECDE692837A8@oracle.com> Vote: Yes Thanks, Dmitry > On 2 Aug 2018, at 19:08, serguei.spitsyn at oracle.com wrote: > > I hereby nominate Daniil Titov (dtitov) to JDK Committer. > > Daniil works for the Oracle Serviceability team and has contributed more than 20 changes. > His contributions can be found here [3]. > > Votes are due by 12:00 pm PT, August 16, 2018. > > Only current JDK Committers [1] are eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Serguei Spitsyn > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] http://hg.openjdk.java.net/jdk/jdk/log?revcount=1000&rev=(keyword(%22daniil.titov%40oracle.com%22)+or+author(dtitov))+and+not+desc(%22Merge%22) > > From li.jiang at oracle.com Fri Aug 3 07:20:44 2018 From: li.jiang at oracle.com (li.jiang at oracle.com) Date: Fri, 3 Aug 2018 15:20:44 +0800 Subject: RFR: 8208663: JDK 11 L10n resource file update - msg drop 20 Message-ID: Hi, Please review the changes for JDK 11 L10n resource file update msg drop 20. Webrev: http://cr.openjdk.java.net/~ljiang/8208663/webrev/read/open/ Bug: https://bugs.openjdk.java.net/browse/JDK-8208663 The new strings in src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/standard_*.properties got translation. Thanks, Leo From sgehwolf at redhat.com Fri Aug 3 07:29:38 2018 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Fri, 03 Aug 2018 09:29:38 +0200 Subject: CFV: New JDK Committer: Jc Beyler In-Reply-To: <5dccf119-c59a-3bb2-76c2-9bc7b309ec2d@oracle.com> References: <5dccf119-c59a-3bb2-76c2-9bc7b309ec2d@oracle.com> Message-ID: <809f08ee32a97bf203beefe1e498adcaa41c0dd5.camel@redhat.com> Vote: yes On Thu, 2018-08-02 at 11:21 -0700, serguei.spitsyn at oracle.com wrote: > I hereby nominate Jean Christophe Beyler (jcbeyler) to JDK Committer. > > Jean Christophe works for "Java Performance and Garbage Collection" and > "Java Runtime" teams at Google and has contributed more than 20 changes. > His contributions can be found here [3]. > > Votes are due by 12:00 pm PT, August 16, 2018. > > Only current JDK Committers [1] are eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Serguei Spitsyn > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] http://hg.openjdk.java.net/jdk/jdk/log?revcount=1000&rev=(keyword(%22jcbeyler%40google.com%22)+or+author(jcbeyler))+and+not+desc(%22Merge%22) > > > From adinn at redhat.com Fri Aug 3 07:54:25 2018 From: adinn at redhat.com (Andrew Dinn) Date: Fri, 3 Aug 2018 08:54:25 +0100 Subject: CFV: New JDK Committer: Jc Beyler In-Reply-To: <5dccf119-c59a-3bb2-76c2-9bc7b309ec2d@oracle.com> References: <5dccf119-c59a-3bb2-76c2-9bc7b309ec2d@oracle.com> Message-ID: Vote: yes On 02/08/18 19:21, serguei.spitsyn at oracle.com wrote: > I hereby nominate Jean Christophe Beyler (jcbeyler) to JDK Committer. > > Jean Christophe works for "Java Performance and Garbage Collection" and > "Java Runtime" teams at Google and has contributed more than 20 changes. > His contributions can be found here [3]. > > Votes are due by 12:00 pm PT, August 16, 2018. > > Only current JDK Committers [1] are eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Serguei Spitsyn > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] > http://hg.openjdk.java.net/jdk/jdk/log?revcount=1000&rev=(keyword(%22jcbeyler%40google.com%22)+or+author(jcbeyler))+and+not+desc(%22Merge%22) > > > > > -- regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From thomas.schatzl at oracle.com Fri Aug 3 08:28:38 2018 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Fri, 03 Aug 2018 10:28:38 +0200 Subject: CFV: New JDK Committer: Jc Beyler In-Reply-To: <5dccf119-c59a-3bb2-76c2-9bc7b309ec2d@oracle.com> References: <5dccf119-c59a-3bb2-76c2-9bc7b309ec2d@oracle.com> Message-ID: <064cfa4246da392f5a1894203a00033c439a3c30.camel@oracle.com> Vote: yes On Thu, 2018-08-02 at 11:21 -0700, serguei.spitsyn at oracle.com wrote: > I hereby nominate Jean Christophe Beyler (jcbeyler) to JDK Committer. > > Jean Christophe works for "Java Performance and Garbage Collection" > and > "Java Runtime" teams at Google and has contributed more than 20 > changes. > His contributions can be found here [3]. > > Votes are due by 12:00 pm PT, August 16, 2018. > > Only current JDK Committers [1] are eligible to vote on this > nomination. > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Serguei Spitsyn > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] http://hg.openjdk.java.net/jdk/jdk/log?revcount=1000&rev=(keyword > (%22jcbeyler%40google.com%22)+or+author(jcbeyler))+and+not+desc(%22Me > rge%22) > > > From alexey.ivanov at oracle.com Fri Aug 3 10:29:16 2018 From: alexey.ivanov at oracle.com (Alexey Ivanov) Date: Fri, 3 Aug 2018 13:29:16 +0300 Subject: CFV: New JDK Committer: Daniil Titov In-Reply-To: References: Message-ID: Vote: yes Regards, Alexey On 02/08/2018 21:08, serguei.spitsyn at oracle.com wrote: > I hereby nominate Daniil Titov (dtitov) to JDK Committer. > > Daniil works for the Oracle Serviceability team and has contributed > more than 20 changes. > His contributions can be found here [3]. > > Votes are due by 12:00 pm PT, August 16, 2018. > > Only current JDK Committers [1] are eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Serguei Spitsyn > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] > http://hg.openjdk.java.net/jdk/jdk/log?revcount=1000&rev=(keyword(%22daniil.titov%40oracle.com%22)+or+author(dtitov))+and+not+desc(%22Merge%22) > > From christoph.langer at sap.com Fri Aug 3 12:30:21 2018 From: christoph.langer at sap.com (Langer, Christoph) Date: Fri, 3 Aug 2018 12:30:21 +0000 Subject: New JDK Committer: Jc Beyler In-Reply-To: <5dccf119-c59a-3bb2-76c2-9bc7b309ec2d@oracle.com> References: <5dccf119-c59a-3bb2-76c2-9bc7b309ec2d@oracle.com> Message-ID: <6c45721f5a2a4c0c8e00a9710731088d@sap.com> Vote:yes Best regards Christoph > -----Original Message----- > From: jdk-dev On Behalf Of > serguei.spitsyn at oracle.com > Sent: Donnerstag, 2. August 2018 20:22 > To: jdk-dev > Subject: CFV: New JDK Committer: Jc Beyler > > I hereby nominate Jean Christophe Beyler (jcbeyler) to JDK Committer. > > Jean Christophe works for "Java Performance and Garbage Collection" and > "Java Runtime" teams at Google and has contributed more than 20 changes. > His contributions can be found here [3]. > > Votes are due by 12:00 pm PT, August 16, 2018. > > Only current JDK Committers [1] are eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Serguei Spitsyn > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] > http://hg.openjdk.java.net/jdk/jdk/log?revcount=1000&rev=(keyword(%22j > cbeyler%40google.com%22)+or+author(jcbeyler))+and+not+desc(%22Merg > e%22) > > From christoph.langer at sap.com Fri Aug 3 12:30:33 2018 From: christoph.langer at sap.com (Langer, Christoph) Date: Fri, 3 Aug 2018 12:30:33 +0000 Subject: New JDK Committer: Daniil Titov In-Reply-To: References: Message-ID: Vote:yes Best regards Christoph > -----Original Message----- > From: jdk-dev On Behalf Of > serguei.spitsyn at oracle.com > Sent: Donnerstag, 2. August 2018 20:09 > To: jdk-dev > Subject: CFV: New JDK Committer: Daniil Titov > > I hereby nominate Daniil Titov (dtitov) to JDK Committer. > > Daniil works for the Oracle Serviceability team and has contributed more than > 20 changes. > His contributions can be found here [3]. > > Votes are due by 12:00 pm PT, August 16, 2018. > > Only current JDK Committers [1] are eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Serguei Spitsyn > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] > http://hg.openjdk.java.net/jdk/jdk/log?revcount=1000&rev=(keyword(%22 > daniil.titov%40oracle.com%22)+or+author(dtitov))+and+not+desc(%22Merg > e%22) > From anton.litvinov at oracle.com Fri Aug 3 12:40:41 2018 From: anton.litvinov at oracle.com (Anton Litvinov) Date: Fri, 3 Aug 2018 13:40:41 +0100 Subject: CFV: New JDK Committer: Daniil Titov In-Reply-To: References: Message-ID: <444da553-138e-b404-d0f3-5030ccc8c6b1@oracle.com> Vote: yes Thank you, Anton On 02/08/2018 19:08, serguei.spitsyn at oracle.com wrote: > I hereby nominate Daniil Titov (dtitov) to JDK Committer. > > Daniil works for the Oracle Serviceability team and has contributed > more than 20 changes. > His contributions can be found here [3]. > > Votes are due by 12:00 pm PT, August 16, 2018. > > Only current JDK Committers [1] are eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Serguei Spitsyn > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] > http://hg.openjdk.java.net/jdk/jdk/log?revcount=1000&rev=(keyword(%22daniil.titov%40oracle.com%22)+or+author(dtitov))+and+not+desc(%22Merge%22) > > From naoto.sato at oracle.com Fri Aug 3 17:46:20 2018 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Fri, 3 Aug 2018 10:46:20 -0700 Subject: RFR: 8208663: JDK 11 L10n resource file update - msg drop 20 In-Reply-To: References: Message-ID: Looks good. The bug needs "noreg-l10n" label. Naoto On 8/3/18 12:20 AM, li.jiang at oracle.com wrote: > Hi, > > Please review the changes for JDK 11 L10n resource file update msg drop 20. > > Webrev: > http://cr.openjdk.java.net/~ljiang/8208663/webrev/read/open/ > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8208663 > > The new strings in > src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/standard_*.properties > got translation. > > Thanks, > Leo From igor.ignatyev at oracle.com Fri Aug 3 19:38:29 2018 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Fri, 3 Aug 2018 12:38:29 -0700 Subject: Result: New JDK Committer: Ekaterina Pavlova Message-ID: Voting for Ekaterina Pavlova[1] is now closed. Yes: 33 Veto: 0 Abstain: 0 According to the Bylaws definition of Lazy Consensus, this is sufficient to approve the nomination. Igor Ignatyev [1] http://mail.openjdk.java.net/pipermail/jdk-dev/2018-July/001635.html From vladimir.x.ivanov at oracle.com Fri Aug 3 19:40:49 2018 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Fri, 3 Aug 2018 12:40:49 -0700 Subject: CFV: New JDK Committer: Daniil Titov In-Reply-To: References: Message-ID: Vote: yes Best regards, Vladimir Ivanov On 02/08/2018 11:08, serguei.spitsyn at oracle.com wrote: > I hereby nominate Daniil Titov (dtitov) to JDK Committer. From li.jiang at oracle.com Fri Aug 3 23:19:26 2018 From: li.jiang at oracle.com (li.jiang at oracle.com) Date: Sat, 4 Aug 2018 07:19:26 +0800 Subject: RFR: 8208663: JDK 11 L10n resource file update - msg drop 20 In-Reply-To: References: Message-ID: Thank you Naoto, added the label. -Leo On 04/08/2018 1:46 AM, naoto.sato at oracle.com wrote: > Looks good. The bug needs "noreg-l10n" label. > > Naoto > > On 8/3/18 12:20 AM, li.jiang at oracle.com wrote: >> Hi, >> >> Please review the changes for JDK 11 L10n resource file update msg >> drop 20. >> >> Webrev: >> http://cr.openjdk.java.net/~ljiang/8208663/webrev/read/open/ >> >> Bug: >> https://bugs.openjdk.java.net/browse/JDK-8208663 >> >> The new strings in >> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/standard_*.properties >> got translation. >> >> Thanks, >> Leo From yumin.qi at gmail.com Sat Aug 4 16:49:44 2018 From: yumin.qi at gmail.com (yumin qi) Date: Sat, 4 Aug 2018 09:49:44 -0700 Subject: CFV: New JDK Committer: Daniil Titov In-Reply-To: References: Message-ID: vote:Yes On Thu, Aug 2, 2018 at 11:09 AM serguei.spitsyn at oracle.com < serguei.spitsyn at oracle.com> wrote: > I hereby nominate Daniil Titov (dtitov) to JDK Committer. > > Daniil works for the Oracle Serviceability team and has contributed more > than 20 changes. > His contributions can be found here [3]. > > Votes are due by 12:00 pm PT, August 16, 2018. > > Only current JDK Committers [1] are eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Serguei Spitsyn > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] > http://hg.openjdk.java.net/jdk/jdk/log?revcount=1000&rev=(keyword(%22daniil.titov%40oracle.com%22)+or+author(dtitov))+and+not+desc(%22Merge%22) > > > From yumin.qi at gmail.com Sat Aug 4 17:13:07 2018 From: yumin.qi at gmail.com (yumin qi) Date: Sat, 4 Aug 2018 10:13:07 -0700 Subject: CFV: New JDK Committer: Jc Beyler In-Reply-To: <5dccf119-c59a-3bb2-76c2-9bc7b309ec2d@oracle.com> References: <5dccf119-c59a-3bb2-76c2-9bc7b309ec2d@oracle.com> Message-ID: vote: Yes On Thu, Aug 2, 2018 at 11:22 AM serguei.spitsyn at oracle.com < serguei.spitsyn at oracle.com> wrote: > I hereby nominate Jean Christophe Beyler (jcbeyler) to JDK Committer. > > Jean Christophe works for "Java Performance and Garbage Collection" and > "Java Runtime" teams at Google and has contributed more than 20 changes. > His contributions can be found here [3]. > > Votes are due by 12:00 pm PT, August 16, 2018. > > Only current JDK Committers [1] are eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Serguei Spitsyn > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] > http://hg.openjdk.java.net/jdk/jdk/log?revcount=1000&rev=(keyword(%22jcbeyler%40google.com%22)+or+author(jcbeyler))+and+not+desc(%22Merge%22) > > > > From Roger.Riggs at Oracle.com Mon Aug 6 15:38:04 2018 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Mon, 6 Aug 2018 11:38:04 -0400 Subject: CFV: New JDK Committer: Daniil Titov In-Reply-To: References: Message-ID: <19f632ca-587f-7e01-c38a-839ac1d5fb98@Oracle.com> Vote: Yes On 8/2/2018 2:08 PM, serguei.spitsyn at oracle.com wrote: > I hereby nominate Daniil Titov (dtitov) to JDK Committer. From jiangli.zhou at oracle.com Mon Aug 6 16:51:08 2018 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Mon, 6 Aug 2018 09:51:08 -0700 Subject: CFV: New JDK Committer: Daniil Titov In-Reply-To: References: Message-ID: <22fdc10d-80cf-666d-33ec-55e81a0d57c7@oracle.com> Vote: yes Thanks, Jiangli On 8/2/18 11:08 AM, serguei.spitsyn at oracle.com wrote: > I hereby nominate Daniil Titov (dtitov) to JDK Committer. > > Daniil works for the Oracle Serviceability team and has contributed > more than 20 changes. > His contributions can be found here [3]. > > Votes are due by 12:00 pm PT, August 16, 2018. > > Only current JDK Committers [1] are eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Serguei Spitsyn > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] > http://hg.openjdk.java.net/jdk/jdk/log?revcount=1000&rev=(keyword(%22daniil.titov%40oracle.com%22)+or+author(dtitov))+and+not+desc(%22Merge%22) > > From jiangli.zhou at oracle.com Mon Aug 6 17:04:57 2018 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Mon, 6 Aug 2018 10:04:57 -0700 Subject: CFV: New JDK Committer: Jc Beyler In-Reply-To: <5dccf119-c59a-3bb2-76c2-9bc7b309ec2d@oracle.com> References: <5dccf119-c59a-3bb2-76c2-9bc7b309ec2d@oracle.com> Message-ID: Vote: yes Thanks, Jiangli On 8/2/18 11:21 AM, serguei.spitsyn at oracle.com wrote: > I hereby nominate Jean Christophe Beyler (jcbeyler) to JDK Committer. > > Jean Christophe works for "Java Performance and Garbage Collection" and > "Java Runtime" teams at Google and has contributed more than 20 changes. > His contributions can be found here [3]. > > Votes are due by 12:00 pm PT, August 16, 2018. > > Only current JDK Committers [1] are eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Serguei Spitsyn > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] > http://hg.openjdk.java.net/jdk/jdk/log?revcount=1000&rev=(keyword(%22jcbeyler%40google.com%22)+or+author(jcbeyler))+and+not+desc(%22Merge%22) > > > From mandy.chung at oracle.com Mon Aug 6 18:31:29 2018 From: mandy.chung at oracle.com (mandy chung) Date: Mon, 6 Aug 2018 11:31:29 -0700 Subject: CFV: New JDK Reviewer: Adam Petcher In-Reply-To: <8f94f30f-04c1-7b0f-a9d0-d9f55385dcb9@oracle.com> References: <8f94f30f-04c1-7b0f-a9d0-d9f55385dcb9@oracle.com> Message-ID: <10cd4f59-6705-8064-b215-ab343eecde3d@oracle.com> Vote: yes Mandy From karen.kinnear at oracle.com Mon Aug 6 20:05:41 2018 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Mon, 6 Aug 2018 16:05:41 -0400 Subject: CFV: New JDK Reviewer: Adam Petcher In-Reply-To: <8f94f30f-04c1-7b0f-a9d0-d9f55385dcb9@oracle.com> References: <8f94f30f-04c1-7b0f-a9d0-d9f55385dcb9@oracle.com> Message-ID: Vote: yes thanks, Karen > On Jul 31, 2018, at 10:05 AM, Sean Mullan wrote: > > I hereby nominate Adam Petcher to JDK Reviewer. > > Adam is a member of the Security Libraries Team at Oracle. He has been working on security for the JDK since December 2016 and has made 28 official contributions [3]. Adam is also the lead of 2 significant crypto related JEPs, one which will be delivered in JDK 11, and the other which is currently a Candidate: > > - JEP 324: Key Agreement with Curve25519 and Curve448 (http://openjdk.java.net/jeps/324) > - JEP 339: Edwards-Curve Digital Signature Algorithm (EdDSA) (http://openjdk.java.net/jeps/339) > > In addition, he was a contributor to the TLS 1.3 implementation and wrote code for the session resumption and signature schemes which will be delivered in JDK 11: > > http://hg.openjdk.java.net/jdk/jdk/rev/68fa3d4026ea > > Based on Adam's work on JEPs and the many significant contributions he has made to the JDK, I believe he is fully ready for the Reviewer role. > > Votes are due by 15:00 GMT Tuesday August 14, 2018. > > 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]. > > Sean Mullan > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#reviewer-vote > [3] http://hg.openjdk.java.net/jdk/jdk/search/?rev=%28keyword%28adam.petcher%29%20or%20author%28apetcher%29%29&revcount=200 From jcoomes at twitter.com Mon Aug 6 22:33:32 2018 From: jcoomes at twitter.com (John Coomes) Date: Mon, 6 Aug 2018 15:33:32 -0700 Subject: CFV: New JDK Committer: Jc Beyler In-Reply-To: <5dccf119-c59a-3bb2-76c2-9bc7b309ec2d@oracle.com> References: <5dccf119-c59a-3bb2-76c2-9bc7b309ec2d@oracle.com> Message-ID: Vote: yes -John From aleksej.efimov at oracle.com Tue Aug 7 00:04:06 2018 From: aleksej.efimov at oracle.com (Aleks Efimov) Date: Tue, 7 Aug 2018 01:04:06 +0100 Subject: CFV: New JDK Committer: Daniil Titov In-Reply-To: References: Message-ID: <3b67ba05-a948-b4fe-6451-6f15de8d462f@oracle.com> Vote: yes Best, Aleksei On 08/02/2018 07:08 PM, serguei.spitsyn at oracle.com wrote: > I hereby nominate Daniil Titov (dtitov) to JDK Committer. > > Daniil works for the Oracle Serviceability team and has contributed > more than 20 changes. > His contributions can be found here [3]. > > Votes are due by 12:00 pm PT, August 16, 2018. > > Only current JDK Committers [1] are eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Serguei Spitsyn > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] > http://hg.openjdk.java.net/jdk/jdk/log?revcount=1000&rev=(keyword(%22daniil.titov%40oracle.com%22)+or+author(dtitov))+and+not+desc(%22Merge%22) > > From robbin.ehn at oracle.com Tue Aug 7 06:55:21 2018 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Tue, 7 Aug 2018 08:55:21 +0200 Subject: CFV: New JDK Committer: Jc Beyler In-Reply-To: <5dccf119-c59a-3bb2-76c2-9bc7b309ec2d@oracle.com> References: <5dccf119-c59a-3bb2-76c2-9bc7b309ec2d@oracle.com> Message-ID: <232d6594-0d54-45fa-a078-6b441c82febe@oracle.com> Vote: yes /Robbin On 08/02/2018 08:21 PM, serguei.spitsyn at oracle.com wrote: > I hereby nominate Jean Christophe Beyler (jcbeyler) to JDK Committer. > > Jean Christophe works for "Java Performance and Garbage Collection" and > "Java Runtime" teams at Google and has contributed more than 20 changes. > His contributions can be found here [3]. > > Votes are due by 12:00 pm PT, August 16, 2018. > > Only current JDK Committers [1] are eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Serguei Spitsyn > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] > http://hg.openjdk.java.net/jdk/jdk/log?revcount=1000&rev=(keyword(%22jcbeyler%40google.com%22)+or+author(jcbeyler))+and+not+desc(%22Merge%22) > > > > From per.liden at oracle.com Tue Aug 7 15:37:55 2018 From: per.liden at oracle.com (Per Liden) Date: Tue, 7 Aug 2018 17:37:55 +0200 Subject: CFV: New JDK Committer: Jc Beyler In-Reply-To: <5dccf119-c59a-3bb2-76c2-9bc7b309ec2d@oracle.com> References: <5dccf119-c59a-3bb2-76c2-9bc7b309ec2d@oracle.com> Message-ID: <051704df-f590-0c6b-e393-5fe66ba4e6d7@oracle.com> Vote: yes /Per On 08/02/2018 08:21 PM, serguei.spitsyn at oracle.com wrote: > I hereby nominate Jean Christophe Beyler (jcbeyler) to JDK Committer. > > Jean Christophe works for "Java Performance and Garbage Collection" and > "Java Runtime" teams at Google and has contributed more than 20 changes. > His contributions can be found here [3]. > > Votes are due by 12:00 pm PT, August 16, 2018. > > Only current JDK Committers [1] are eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Serguei Spitsyn > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] > http://hg.openjdk.java.net/jdk/jdk/log?revcount=1000&rev=(keyword(%22jcbeyler%40google.com%22)+or+author(jcbeyler))+and+not+desc(%22Merge%22) > > > > From erik.osterlund at oracle.com Tue Aug 7 15:47:59 2018 From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=) Date: Tue, 7 Aug 2018 17:47:59 +0200 Subject: CFV: New JDK Committer: Jc Beyler In-Reply-To: <5dccf119-c59a-3bb2-76c2-9bc7b309ec2d@oracle.com> References: <5dccf119-c59a-3bb2-76c2-9bc7b309ec2d@oracle.com> Message-ID: <5B69BF2F.3050409@oracle.com> Vote: yes /Erik On 2018-08-02 20:21, serguei.spitsyn at oracle.com wrote: > I hereby nominate Jean Christophe Beyler (jcbeyler) to JDK Committer. > > Jean Christophe works for "Java Performance and Garbage Collection" and > "Java Runtime" teams at Google and has contributed more than 20 changes. > His contributions can be found here [3]. > > Votes are due by 12:00 pm PT, August 16, 2018. > > Only current JDK Committers [1] are eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Serguei Spitsyn > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] > http://hg.openjdk.java.net/jdk/jdk/log?revcount=1000&rev=(keyword(%22jcbeyler%40google.com%22)+or+author(jcbeyler))+and+not+desc(%22Merge%22) > > > From kim.barrett at oracle.com Wed Aug 8 04:50:01 2018 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 8 Aug 2018 00:50:01 -0400 Subject: CFV: New JDK Committer: Jc Beyler In-Reply-To: <5dccf119-c59a-3bb2-76c2-9bc7b309ec2d@oracle.com> References: <5dccf119-c59a-3bb2-76c2-9bc7b309ec2d@oracle.com> Message-ID: vote: yes > On Aug 2, 2018, at 2:21 PM, serguei.spitsyn at oracle.com wrote: > > I hereby nominate Jean Christophe Beyler (jcbeyler) to JDK Committer. > > Jean Christophe works for "Java Performance and Garbage Collection" and > "Java Runtime" teams at Google and has contributed more than 20 changes. > His contributions can be found here [3]. > > Votes are due by 12:00 pm PT, August 16, 2018. > > Only current JDK Committers [1] are eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Serguei Spitsyn > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] http://hg.openjdk.java.net/jdk/jdk/log?revcount=1000&rev=(keyword(%22jcbeyler%40google.com%22)+or+author(jcbeyler))+and+not+desc(%22Merge%22) From Derek.White at cavium.com Wed Aug 8 15:02:24 2018 From: Derek.White at cavium.com (White, Derek) Date: Wed, 8 Aug 2018 15:02:24 +0000 Subject: New JDK Committer: Jc Beyler In-Reply-To: <5dccf119-c59a-3bb2-76c2-9bc7b309ec2d@oracle.com> References: <5dccf119-c59a-3bb2-76c2-9bc7b309ec2d@oracle.com> Message-ID: Vote: yes > -----Original Message----- > From: jdk-dev [mailto:jdk-dev-bounces at openjdk.java.net] On Behalf Of > serguei.spitsyn at oracle.com > Sent: Thursday, August 02, 2018 2:22 PM > To: jdk-dev > Subject: CFV: New JDK Committer: Jc Beyler > > External Email > > I hereby nominate Jean Christophe Beyler (jcbeyler) to JDK Committer. > > Jean Christophe works for "Java Performance and Garbage Collection" and > "Java Runtime" teams at Google and has contributed more than 20 changes. > His contributions can be found here [3]. > > Votes are due by 12:00 pm PT, August 16, 2018. > > Only current JDK Committers [1] are eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Serguei Spitsyn > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] > http://hg.openjdk.java.net/jdk/jdk/log?revcount=1000&rev=(keyword(%22jc > beyler%40google.com%22)+or+author(jcbeyler))+and+not+desc(%22Merge% > 22) > > From erik.gahlin at oracle.com Wed Aug 8 15:55:12 2018 From: erik.gahlin at oracle.com (Erik Gahlin) Date: Wed, 8 Aug 2018 17:55:12 +0200 Subject: CFV: New JDK Committer: Jc Beyler In-Reply-To: <5dccf119-c59a-3bb2-76c2-9bc7b309ec2d@oracle.com> References: <5dccf119-c59a-3bb2-76c2-9bc7b309ec2d@oracle.com> Message-ID: <5B6B1260.80106@oracle.com> Vote: yes Erik On 2018-08-02 20:21, serguei.spitsyn at oracle.com wrote: > I hereby nominate Jean Christophe Beyler (jcbeyler) to JDK Committer. > > Jean Christophe works for "Java Performance and Garbage Collection" and > "Java Runtime" teams at Google and has contributed more than 20 changes. > His contributions can be found here [3]. > > Votes are due by 12:00 pm PT, August 16, 2018. > > Only current JDK Committers [1] are eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Serguei Spitsyn > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] > http://hg.openjdk.java.net/jdk/jdk/log?revcount=1000&rev=(keyword(%22jcbeyler%40google.com%22)+or+author(jcbeyler))+and+not+desc(%22Merge%22) > > > From zhaixiang at loongson.cn Thu Aug 9 08:12:38 2018 From: zhaixiang at loongson.cn (Leslie Zhai) Date: Thu, 9 Aug 2018 16:12:38 +0800 Subject: Request for Approval: Add BFD_VERSION for JDK-8191006: hsdis disassembler plugin does not compile with binutils 2.29+ Message-ID: <39530ae5-f8be-d872-6477-953f9665d8bf@loongson.cn> Hi all, Thanks for David's patch to fix: https://bugs.openjdk.java.net/browse/JDK-8191006 But hsdis plugin does not compiled with binutils old version 2.27, so I just add `BFD_VERSION` for supporting old version binutils: Here is the patch: diff -r 09cc8813ae51 src/utils/hsdis/hsdis.c --- a/src/utils/hsdis/hsdis.c Wed Aug 08 18:38:34 2018 -0700 +++ b/src/utils/hsdis/hsdis.c Thu Aug 09 15:49:31 2018 +0800 @@ -338,10 +338,14 @@ /* Finish linking together the various callback blocks. */ app_data->dinfo.application_data = (void*) app_data; +#if BFD_VERSION >= 229000000 app_data->dfn = disassembler(bfd_get_arch(native_bfd), bfd_big_endian(native_bfd), bfd_get_mach(native_bfd), native_bfd); +#else + app_data->dfn = disassembler(native_bfd); +#endif app_data->dinfo.print_address_func = hsdis_print_address_func; app_data->dinfo.read_memory_func = hsdis_read_memory_func; And I would like to backport the fix to OpenJDK8 updates dev: http://hg.openjdk.java.net/jdk8u/jdk8u-dev So here is the backport patch: diff -r b4ee249eb1c4 src/share/tools/hsdis/hsdis.c --- a/src/share/tools/hsdis/hsdis.c Tue Aug 07 11:55:44 2018 -0400 +++ b/src/share/tools/hsdis/hsdis.c Thu Aug 09 15:49:57 2018 +0800 @@ -337,10 +337,14 @@ /* Finish linking together the various callback blocks. */ app_data->dinfo.application_data = (void*) app_data; +#if BFD_VERSION >= 229000000 app_data->dfn = disassembler(bfd_get_arch(native_bfd), bfd_big_endian(native_bfd), bfd_get_mach(native_bfd), native_bfd); +#else + app_data->dfn = disassembler(native_bfd); +#endif app_data->dinfo.print_address_func = hsdis_print_address_func; app_data->dinfo.read_memory_func = hsdis_read_memory_func; And I make demo[1] to test for OpenJDK8 mips64el[2]. A patch by Loongson! Please sponsor it, thanks a lot! 1. $ ./build/linux-mips64/hsdis-demo Hello, world! ...And now for something completely different: Decoding from 0x120000dd0 to 0x120001090...with decode_instructions_virtual Decoding for CPU 'mips:loongson_3a' main: 0x120000dd0 daddiu sp,sp,-80 0x120000dd4 gssq ra,s8,64(sp) 0x120000dd8 sd gp,56(sp) 0x120000ddc move s8,sp 0x120000de0 lui gp,0x2 0x120000de4 daddu gp,gp,t9 0x120000de8 daddiu gp,gp,-23968 0x120000dec move v0,a0 0x120000df0 sd a1,40(s8) 0x120000df4 sll v0,v0,0x0 0x120000df8 sw v0,32(s8) 0x120000dfc sw zero,0(s8) 0x120000e00 li v0,1 0x120000e04 sw v0,4(s8) 0x120000e08 b 0x0000000120000f6c 0x120000e0c nop 0x120000e10 lw v0,4(s8) 0x120000e14 dsll v0,v0,0x3 0x120000e18 ld v1,40(s8) 0x120000e1c daddu v0,v1,v0 0x120000e20 ld v0,0(v0) 0x120000e24 sd v0,8(s8) 0x120000e28 ld v0,8(s8) 0x120000e2c lb v1,0(v0) 0x120000e30 li v0,45 0x120000e34 bne v1,v0,0x0000000120000f44 0x120000e38 nop 0x120000e3c ld a0,8(s8) 0x120000e40 ld v0,-32696(gp) 0x120000e44 daddiu a1,v0,7424 0x120000e48 ld v0,-32456(gp) 0x120000e4c move t9,v0 0x120000e50 jalr t9 0x120000e54 nop 0x120000e58 bnez v0,0x0000000120000e80 0x120000e5c nop 0x120000e60 ld v0,-32688(gp) 0x120000e64 lw v0,0(v0) 0x120000e68 xori v0,v0,0x1 0x120000e6c move v1,v0 0x120000e70 ld v0,-32688(gp) 0x120000e74 sw v1,0(v0) 0x120000e78 b 0x0000000120000f3c 0x120000e7c nop 0x120000e80 ld a0,8(s8) 0x120000e84 ld v0,-32696(gp) 0x120000e88 daddiu a1,v0,7432 0x120000e8c ld v0,-32456(gp) 0x120000e90 move t9,v0 0x120000e94 jalr t9 0x120000e98 nop 0x120000e9c bnez v0,0x0000000120000ec4 0x120000ea0 nop 0x120000ea4 ld v0,-32680(gp) 0x120000ea8 lw v0,0(v0) 0x120000eac xori v0,v0,0x1 0x120000eb0 move v1,v0 0x120000eb4 ld v0,-32680(gp) 0x120000eb8 sw v1,0(v0) 0x120000ebc b 0x0000000120000f3c 0x120000ec0 nop 0x120000ec4 ld a0,8(s8) 0x120000ec8 ld v0,-32696(gp) 0x120000ecc daddiu a1,v0,7440 0x120000ed0 li a2,9 0x120000ed4 ld v0,-32592(gp) 0x120000ed8 move t9,v0 0x120000edc jalr t9 0x120000ee0 nop 0x120000ee4 bnez v0,0x0000000120000f04 0x120000ee8 nop 0x120000eec ld v0,8(s8) 0x120000ef0 daddiu v1,v0,9 0x120000ef4 ld v0,-32672(gp) 0x120000ef8 sd v1,0(v0) 0x120000efc b 0x0000000120000f3c 0x120000f00 nop 0x120000f04 ld v0,40(s8) 0x120000f08 ld v1,0(v0) 0x120000f0c ld v0,-32696(gp) 0x120000f10 daddiu a0,v0,7456 0x120000f14 move a1,v1 0x120000f18 ld v0,-32472(gp) 0x120000f1c move t9,v0 0x120000f20 jalr t9 0x120000f24 nop 0x120000f28 li a0,2 0x120000f2c ld v0,-32512(gp) 0x120000f30 move t9,v0 0x120000f34 jalr t9 0x120000f38 nop 0x120000f3c b 0x0000000120000f60 0x120000f40 nop 0x120000f44 ld a0,8(s8) 0x120000f48 ld v0,-32664(gp) 0x120000f4c move t9,v0 0x120000f50 bal &greet (0x12000103c) 0x120000f54 nop 0x120000f58 li v0,1 0x120000f5c sw v0,0(s8) 0x120000f60 lw v0,4(s8) 0x120000f64 addiu v0,v0,1 0x120000f68 sw v0,4(s8) 0x120000f6c lw v1,4(s8) 0x120000f70 lw v0,32(s8) 0x120000f74 slt v0,v1,v0 0x120000f78 bnez v0,0x0000000120000e10 0x120000f7c nop 0x120000f80 lw v0,0(s8) 0x120000f84 bnez v0,0x0000000120000fa4 0x120000f88 nop 0x120000f8c ld v0,-32696(gp) 0x120000f90 daddiu a0,v0,7488 0x120000f94 ld v0,-32664(gp) 0x120000f98 move t9,v0 0x120000f9c bal &greet (0x12000103c) 0x120000fa0 nop 0x120000fa4 ld v0,-32696(gp) 0x120000fa8 daddiu a0,v0,7496 0x120000fac ld v0,-32496(gp) 0x120000fb0 move t9,v0 0x120000fb4 jalr t9 0x120000fb8 nop 0x120000fbc ld v0,-32736(gp) 0x120000fc0 sd v0,16(s8) 0x120000fc4 ld v0,-32656(gp) 0x120000fc8 sd v0,24(s8) 0x120000fcc ld a0,16(s8) 0x120000fd0 ld v1,24(s8) 0x120000fd4 ld v0,16(s8) 0x120000fd8 sltu v0,v0,v1 0x120000fdc bnez v0,0x0000000120000ff4 0x120000fe0 nop 0x120000fe4 ld v0,16(s8) 0x120000fe8 daddiu v0,v0,64 0x120000fec b 0x0000000120000ff8 0x120000ff0 nop 0x120000ff4 ld v0,24(s8) 0x120000ff8 move a1,v0 0x120000ffc ld v0,-32648(gp) 0x120001000 move t9,v0 0x120001004 bal 0x0000000120001840 0x120001008 nop 0x12000100c ld v0,-32696(gp) 0x120001010 daddiu a0,v0,7544 0x120001014 ld v0,-32496(gp) 0x120001018 move t9,v0 0x12000101c jalr t9 0x120001020 nop 0x120001024 move sp,s8 0x120001028 gslq ra,s8,64(sp) 0x12000102c ld gp,56(sp) 0x120001030 daddiu sp,sp,80 0x120001034 jr ra 0x120001038 nop greet: 0x12000103c daddiu sp,sp,-48 0x120001040 gssq ra,s8,32(sp) 0x120001044 sd gp,24(sp) 0x120001048 move s8,sp 0x12000104c lui gp,0x2 0x120001050 daddu gp,gp,t9 0x120001054 daddiu gp,gp,-24588 0x120001058 sd a0,0(s8) 0x12000105c ld v0,-32696(gp) 0x120001060 daddiu a0,v0,7552 0x120001064 ld a1,0(s8) 0x120001068 ld v0,-32472(gp) 0x12000106c move t9,v0 0x120001070 jalr t9 0x120001074 nop 0x120001078 move sp,s8 0x12000107c gslq ra,s8,32(sp) 0x120001080 ld gp,24(sp) 0x120001084 daddiu sp,sp,48 0x120001088 jr ra 0x12000108c nop Decoding from 0x120000dd0 to 0x120001090...with old decode_instructions Decoding for CPU 'mips:loongson_3a' main: 0x120000dd0 daddiu sp,sp,-80 0x120000dd4 gssq ra,s8,64(sp) 0x120000dd8 sd gp,56(sp) 0x120000ddc move s8,sp 0x120000de0 lui gp,0x2 0x120000de4 daddu gp,gp,t9 0x120000de8 daddiu gp,gp,-23968 0x120000dec move v0,a0 0x120000df0 sd a1,40(s8) 0x120000df4 sll v0,v0,0x0 0x120000df8 sw v0,32(s8) 0x120000dfc sw zero,0(s8) 0x120000e00 li v0,1 0x120000e04 sw v0,4(s8) 0x120000e08 b 0x0000000120000f6c 0x120000e0c nop 0x120000e10 lw v0,4(s8) 0x120000e14 dsll v0,v0,0x3 0x120000e18 ld v1,40(s8) 0x120000e1c daddu v0,v1,v0 0x120000e20 ld v0,0(v0) 0x120000e24 sd v0,8(s8) 0x120000e28 ld v0,8(s8) 0x120000e2c lb v1,0(v0) 0x120000e30 li v0,45 0x120000e34 bne v1,v0,0x0000000120000f44 0x120000e38 nop 0x120000e3c ld a0,8(s8) 0x120000e40 ld v0,-32696(gp) 0x120000e44 daddiu a1,v0,7424 0x120000e48 ld v0,-32456(gp) 0x120000e4c move t9,v0 0x120000e50 jalr t9 0x120000e54 nop 0x120000e58 bnez v0,0x0000000120000e80 0x120000e5c nop 0x120000e60 ld v0,-32688(gp) 0x120000e64 lw v0,0(v0) 0x120000e68 xori v0,v0,0x1 0x120000e6c move v1,v0 0x120000e70 ld v0,-32688(gp) 0x120000e74 sw v1,0(v0) 0x120000e78 b 0x0000000120000f3c 0x120000e7c nop 0x120000e80 ld a0,8(s8) 0x120000e84 ld v0,-32696(gp) 0x120000e88 daddiu a1,v0,7432 0x120000e8c ld v0,-32456(gp) 0x120000e90 move t9,v0 0x120000e94 jalr t9 0x120000e98 nop 0x120000e9c bnez v0,0x0000000120000ec4 0x120000ea0 nop 0x120000ea4 ld v0,-32680(gp) 0x120000ea8 lw v0,0(v0) 0x120000eac xori v0,v0,0x1 0x120000eb0 move v1,v0 0x120000eb4 ld v0,-32680(gp) 0x120000eb8 sw v1,0(v0) 0x120000ebc b 0x0000000120000f3c 0x120000ec0 nop 0x120000ec4 ld a0,8(s8) 0x120000ec8 ld v0,-32696(gp) 0x120000ecc daddiu a1,v0,7440 0x120000ed0 li a2,9 0x120000ed4 ld v0,-32592(gp) 0x120000ed8 move t9,v0 0x120000edc jalr t9 0x120000ee0 nop 0x120000ee4 bnez v0,0x0000000120000f04 0x120000ee8 nop 0x120000eec ld v0,8(s8) 0x120000ef0 daddiu v1,v0,9 0x120000ef4 ld v0,-32672(gp) 0x120000ef8 sd v1,0(v0) 0x120000efc b 0x0000000120000f3c 0x120000f00 nop 0x120000f04 ld v0,40(s8) 0x120000f08 ld v1,0(v0) 0x120000f0c ld v0,-32696(gp) 0x120000f10 daddiu a0,v0,7456 0x120000f14 move a1,v1 0x120000f18 ld v0,-32472(gp) 0x120000f1c move t9,v0 0x120000f20 jalr t9 0x120000f24 nop 0x120000f28 li a0,2 0x120000f2c ld v0,-32512(gp) 0x120000f30 move t9,v0 0x120000f34 jalr t9 0x120000f38 nop 0x120000f3c b 0x0000000120000f60 0x120000f40 nop 0x120000f44 ld a0,8(s8) 0x120000f48 ld v0,-32664(gp) 0x120000f4c move t9,v0 0x120000f50 bal &greet (0x12000103c) 0x120000f54 nop 0x120000f58 li v0,1 0x120000f5c sw v0,0(s8) 0x120000f60 lw v0,4(s8) 0x120000f64 addiu v0,v0,1 0x120000f68 sw v0,4(s8) 0x120000f6c lw v1,4(s8) 0x120000f70 lw v0,32(s8) 0x120000f74 slt v0,v1,v0 0x120000f78 bnez v0,0x0000000120000e10 0x120000f7c nop 0x120000f80 lw v0,0(s8) 0x120000f84 bnez v0,0x0000000120000fa4 0x120000f88 nop 0x120000f8c ld v0,-32696(gp) 0x120000f90 daddiu a0,v0,7488 0x120000f94 ld v0,-32664(gp) 0x120000f98 move t9,v0 0x120000f9c bal &greet (0x12000103c) 0x120000fa0 nop 0x120000fa4 ld v0,-32696(gp) 0x120000fa8 daddiu a0,v0,7496 0x120000fac ld v0,-32496(gp) 0x120000fb0 move t9,v0 0x120000fb4 jalr t9 0x120000fb8 nop 0x120000fbc ld v0,-32736(gp) 0x120000fc0 sd v0,16(s8) 0x120000fc4 ld v0,-32656(gp) 0x120000fc8 sd v0,24(s8) 0x120000fcc ld a0,16(s8) 0x120000fd0 ld v1,24(s8) 0x120000fd4 ld v0,16(s8) 0x120000fd8 sltu v0,v0,v1 0x120000fdc bnez v0,0x0000000120000ff4 0x120000fe0 nop 0x120000fe4 ld v0,16(s8) 0x120000fe8 daddiu v0,v0,64 0x120000fec b 0x0000000120000ff8 0x120000ff0 nop 0x120000ff4 ld v0,24(s8) 0x120000ff8 move a1,v0 0x120000ffc ld v0,-32648(gp) 0x120001000 move t9,v0 0x120001004 bal 0x0000000120001840 0x120001008 nop 0x12000100c ld v0,-32696(gp) 0x120001010 daddiu a0,v0,7544 0x120001014 ld v0,-32496(gp) 0x120001018 move t9,v0 0x12000101c jalr t9 0x120001020 nop 0x120001024 move sp,s8 0x120001028 gslq ra,s8,64(sp) 0x12000102c ld gp,56(sp) 0x120001030 daddiu sp,sp,80 0x120001034 jr ra 0x120001038 nop greet: 0x12000103c daddiu sp,sp,-48 0x120001040 gssq ra,s8,32(sp) 0x120001044 sd gp,24(sp) 0x120001048 move s8,sp 0x12000104c lui gp,0x2 0x120001050 daddu gp,gp,t9 0x120001054 daddiu gp,gp,-24588 0x120001058 sd a0,0(s8) 0x12000105c ld v0,-32696(gp) 0x120001060 daddiu a0,v0,7552 0x120001064 ld a1,0(s8) 0x120001068 ld v0,-32472(gp) 0x12000106c move t9,v0 0x120001070 jalr t9 0x120001074 nop 0x120001078 move sp,s8 0x12000107c gslq ra,s8,32(sp) 0x120001080 ld gp,24(sp) 0x120001084 daddiu sp,sp,48 0x120001088 jr ra 0x12000108c nop Cheers! 2. http://hg.loongnix.org/jdk8-mips64-public/hotspot/file/tip/src/share/tools/hsdis/Makefile#l85 -- Regards, Leslie Zhai From david.buck at oracle.com Thu Aug 9 09:13:25 2018 From: david.buck at oracle.com (David Buck) Date: Thu, 9 Aug 2018 18:13:25 +0900 Subject: Request for Approval: Add BFD_VERSION for JDK-8191006: hsdis disassembler plugin does not compile with binutils 2.29+ In-Reply-To: <39530ae5-f8be-d872-6477-953f9665d8bf@loongson.cn> References: <39530ae5-f8be-d872-6477-953f9665d8bf@loongson.cn> Message-ID: <1E77ACFD-A6FB-435F-A07D-55A039AB388F@oracle.com> Hi Leslie! What exactly is the use-case for building with older versions of BINUTILS? It would be good to know what benefit(s) there might be that would justify the cost of (slightly) complicating the code. Cheers, -Buck > On Aug 9, 2018, at 17:12, Leslie Zhai wrote: > > Hi all, > > Thanks for David's patch to fix: > > https://bugs.openjdk.java.net/browse/JDK-8191006 > > But hsdis plugin does not compiled with binutils old version 2.27, so I just add `BFD_VERSION` for supporting old version binutils: > > Here is the patch: > > diff -r 09cc8813ae51 src/utils/hsdis/hsdis.c > --- a/src/utils/hsdis/hsdis.c Wed Aug 08 18:38:34 2018 -0700 > +++ b/src/utils/hsdis/hsdis.c Thu Aug 09 15:49:31 2018 +0800 > @@ -338,10 +338,14 @@ > > /* Finish linking together the various callback blocks. */ > app_data->dinfo.application_data = (void*) app_data; > +#if BFD_VERSION >= 229000000 > app_data->dfn = disassembler(bfd_get_arch(native_bfd), > bfd_big_endian(native_bfd), > bfd_get_mach(native_bfd), > native_bfd); > +#else > + app_data->dfn = disassembler(native_bfd); > +#endif > app_data->dinfo.print_address_func = hsdis_print_address_func; > app_data->dinfo.read_memory_func = hsdis_read_memory_func; > > And I would like to backport the fix to OpenJDK8 updates dev: > > http://hg.openjdk.java.net/jdk8u/jdk8u-dev > > So here is the backport patch: > > diff -r b4ee249eb1c4 src/share/tools/hsdis/hsdis.c > --- a/src/share/tools/hsdis/hsdis.c Tue Aug 07 11:55:44 2018 -0400 > +++ b/src/share/tools/hsdis/hsdis.c Thu Aug 09 15:49:57 2018 +0800 > @@ -337,10 +337,14 @@ > > /* Finish linking together the various callback blocks. */ > app_data->dinfo.application_data = (void*) app_data; > +#if BFD_VERSION >= 229000000 > app_data->dfn = disassembler(bfd_get_arch(native_bfd), > bfd_big_endian(native_bfd), > bfd_get_mach(native_bfd), > native_bfd); > +#else > + app_data->dfn = disassembler(native_bfd); > +#endif > app_data->dinfo.print_address_func = hsdis_print_address_func; > app_data->dinfo.read_memory_func = hsdis_read_memory_func; > > And I make demo[1] to test for OpenJDK8 mips64el[2]. > > A patch by Loongson! Please sponsor it, thanks a lot! > > > 1. > > $ ./build/linux-mips64/hsdis-demo > Hello, world! > ...And now for something completely different: > > Decoding from 0x120000dd0 to 0x120001090...with decode_instructions_virtual > Decoding for CPU 'mips:loongson_3a' > main: > 0x120000dd0 daddiu sp,sp,-80 > 0x120000dd4 gssq ra,s8,64(sp) > 0x120000dd8 sd gp,56(sp) > 0x120000ddc move s8,sp > 0x120000de0 lui gp,0x2 > 0x120000de4 daddu gp,gp,t9 > 0x120000de8 daddiu gp,gp,-23968 > 0x120000dec move v0,a0 > 0x120000df0 sd a1,40(s8) > 0x120000df4 sll v0,v0,0x0 > 0x120000df8 sw v0,32(s8) > 0x120000dfc sw zero,0(s8) > 0x120000e00 li v0,1 > 0x120000e04 sw v0,4(s8) > 0x120000e08 b 0x0000000120000f6c > 0x120000e0c nop > 0x120000e10 lw v0,4(s8) > 0x120000e14 dsll v0,v0,0x3 > 0x120000e18 ld v1,40(s8) > 0x120000e1c daddu v0,v1,v0 > 0x120000e20 ld v0,0(v0) > 0x120000e24 sd v0,8(s8) > 0x120000e28 ld v0,8(s8) > 0x120000e2c lb v1,0(v0) > 0x120000e30 li v0,45 > 0x120000e34 bne v1,v0,0x0000000120000f44 > 0x120000e38 nop > 0x120000e3c ld a0,8(s8) > 0x120000e40 ld v0,-32696(gp) > 0x120000e44 daddiu a1,v0,7424 > 0x120000e48 ld v0,-32456(gp) > 0x120000e4c move t9,v0 > 0x120000e50 jalr t9 > 0x120000e54 nop > 0x120000e58 bnez v0,0x0000000120000e80 > 0x120000e5c nop > 0x120000e60 ld v0,-32688(gp) > 0x120000e64 lw v0,0(v0) > 0x120000e68 xori v0,v0,0x1 > 0x120000e6c move v1,v0 > 0x120000e70 ld v0,-32688(gp) > 0x120000e74 sw v1,0(v0) > 0x120000e78 b 0x0000000120000f3c > 0x120000e7c nop > 0x120000e80 ld a0,8(s8) > 0x120000e84 ld v0,-32696(gp) > 0x120000e88 daddiu a1,v0,7432 > 0x120000e8c ld v0,-32456(gp) > 0x120000e90 move t9,v0 > 0x120000e94 jalr t9 > 0x120000e98 nop > 0x120000e9c bnez v0,0x0000000120000ec4 > 0x120000ea0 nop > 0x120000ea4 ld v0,-32680(gp) > 0x120000ea8 lw v0,0(v0) > 0x120000eac xori v0,v0,0x1 > 0x120000eb0 move v1,v0 > 0x120000eb4 ld v0,-32680(gp) > 0x120000eb8 sw v1,0(v0) > 0x120000ebc b 0x0000000120000f3c > 0x120000ec0 nop > 0x120000ec4 ld a0,8(s8) > 0x120000ec8 ld v0,-32696(gp) > 0x120000ecc daddiu a1,v0,7440 > 0x120000ed0 li a2,9 > 0x120000ed4 ld v0,-32592(gp) > 0x120000ed8 move t9,v0 > 0x120000edc jalr t9 > 0x120000ee0 nop > 0x120000ee4 bnez v0,0x0000000120000f04 > 0x120000ee8 nop > 0x120000eec ld v0,8(s8) > 0x120000ef0 daddiu v1,v0,9 > 0x120000ef4 ld v0,-32672(gp) > 0x120000ef8 sd v1,0(v0) > 0x120000efc b 0x0000000120000f3c > 0x120000f00 nop > 0x120000f04 ld v0,40(s8) > 0x120000f08 ld v1,0(v0) > 0x120000f0c ld v0,-32696(gp) > 0x120000f10 daddiu a0,v0,7456 > 0x120000f14 move a1,v1 > 0x120000f18 ld v0,-32472(gp) > 0x120000f1c move t9,v0 > 0x120000f20 jalr t9 > 0x120000f24 nop > 0x120000f28 li a0,2 > 0x120000f2c ld v0,-32512(gp) > 0x120000f30 move t9,v0 > 0x120000f34 jalr t9 > 0x120000f38 nop > 0x120000f3c b 0x0000000120000f60 > 0x120000f40 nop > 0x120000f44 ld a0,8(s8) > 0x120000f48 ld v0,-32664(gp) > 0x120000f4c move t9,v0 > 0x120000f50 bal &greet (0x12000103c) > 0x120000f54 nop > 0x120000f58 li v0,1 > 0x120000f5c sw v0,0(s8) > 0x120000f60 lw v0,4(s8) > 0x120000f64 addiu v0,v0,1 > 0x120000f68 sw v0,4(s8) > 0x120000f6c lw v1,4(s8) > 0x120000f70 lw v0,32(s8) > 0x120000f74 slt v0,v1,v0 > 0x120000f78 bnez v0,0x0000000120000e10 > 0x120000f7c nop > 0x120000f80 lw v0,0(s8) > 0x120000f84 bnez v0,0x0000000120000fa4 > 0x120000f88 nop > 0x120000f8c ld v0,-32696(gp) > 0x120000f90 daddiu a0,v0,7488 > 0x120000f94 ld v0,-32664(gp) > 0x120000f98 move t9,v0 > 0x120000f9c bal &greet (0x12000103c) > 0x120000fa0 nop > 0x120000fa4 ld v0,-32696(gp) > 0x120000fa8 daddiu a0,v0,7496 > 0x120000fac ld v0,-32496(gp) > 0x120000fb0 move t9,v0 > 0x120000fb4 jalr t9 > 0x120000fb8 nop > 0x120000fbc ld v0,-32736(gp) > 0x120000fc0 sd v0,16(s8) > 0x120000fc4 ld v0,-32656(gp) > 0x120000fc8 sd v0,24(s8) > 0x120000fcc ld a0,16(s8) > 0x120000fd0 ld v1,24(s8) > 0x120000fd4 ld v0,16(s8) > 0x120000fd8 sltu v0,v0,v1 > 0x120000fdc bnez v0,0x0000000120000ff4 > 0x120000fe0 nop > 0x120000fe4 ld v0,16(s8) > 0x120000fe8 daddiu v0,v0,64 > 0x120000fec b 0x0000000120000ff8 > 0x120000ff0 nop > 0x120000ff4 ld v0,24(s8) > 0x120000ff8 move a1,v0 > 0x120000ffc ld v0,-32648(gp) > 0x120001000 move t9,v0 > 0x120001004 bal 0x0000000120001840 > 0x120001008 nop > 0x12000100c ld v0,-32696(gp) > 0x120001010 daddiu a0,v0,7544 > 0x120001014 ld v0,-32496(gp) > 0x120001018 move t9,v0 > 0x12000101c jalr t9 > 0x120001020 nop > 0x120001024 move sp,s8 > 0x120001028 gslq ra,s8,64(sp) > 0x12000102c ld gp,56(sp) > 0x120001030 daddiu sp,sp,80 > 0x120001034 jr ra > 0x120001038 nop > greet: > 0x12000103c daddiu sp,sp,-48 > 0x120001040 gssq ra,s8,32(sp) > 0x120001044 sd gp,24(sp) > 0x120001048 move s8,sp > 0x12000104c lui gp,0x2 > 0x120001050 daddu gp,gp,t9 > 0x120001054 daddiu gp,gp,-24588 > 0x120001058 sd a0,0(s8) > 0x12000105c ld v0,-32696(gp) > 0x120001060 daddiu a0,v0,7552 > 0x120001064 ld a1,0(s8) > 0x120001068 ld v0,-32472(gp) > 0x12000106c move t9,v0 > 0x120001070 jalr t9 > 0x120001074 nop > 0x120001078 move sp,s8 > 0x12000107c gslq ra,s8,32(sp) > 0x120001080 ld gp,24(sp) > 0x120001084 daddiu sp,sp,48 > 0x120001088 jr ra > 0x12000108c nop > > Decoding from 0x120000dd0 to 0x120001090...with old decode_instructions > Decoding for CPU 'mips:loongson_3a' > main: > 0x120000dd0 daddiu sp,sp,-80 > 0x120000dd4 gssq ra,s8,64(sp) > 0x120000dd8 sd gp,56(sp) > 0x120000ddc move s8,sp > 0x120000de0 lui gp,0x2 > 0x120000de4 daddu gp,gp,t9 > 0x120000de8 daddiu gp,gp,-23968 > 0x120000dec move v0,a0 > 0x120000df0 sd a1,40(s8) > 0x120000df4 sll v0,v0,0x0 > 0x120000df8 sw v0,32(s8) > 0x120000dfc sw zero,0(s8) > 0x120000e00 li v0,1 > 0x120000e04 sw v0,4(s8) > 0x120000e08 b 0x0000000120000f6c > 0x120000e0c nop > 0x120000e10 lw v0,4(s8) > 0x120000e14 dsll v0,v0,0x3 > 0x120000e18 ld v1,40(s8) > 0x120000e1c daddu v0,v1,v0 > 0x120000e20 ld v0,0(v0) > 0x120000e24 sd v0,8(s8) > 0x120000e28 ld v0,8(s8) > 0x120000e2c lb v1,0(v0) > 0x120000e30 li v0,45 > 0x120000e34 bne v1,v0,0x0000000120000f44 > 0x120000e38 nop > 0x120000e3c ld a0,8(s8) > 0x120000e40 ld v0,-32696(gp) > 0x120000e44 daddiu a1,v0,7424 > 0x120000e48 ld v0,-32456(gp) > 0x120000e4c move t9,v0 > 0x120000e50 jalr t9 > 0x120000e54 nop > 0x120000e58 bnez v0,0x0000000120000e80 > 0x120000e5c nop > 0x120000e60 ld v0,-32688(gp) > 0x120000e64 lw v0,0(v0) > 0x120000e68 xori v0,v0,0x1 > 0x120000e6c move v1,v0 > 0x120000e70 ld v0,-32688(gp) > 0x120000e74 sw v1,0(v0) > 0x120000e78 b 0x0000000120000f3c > 0x120000e7c nop > 0x120000e80 ld a0,8(s8) > 0x120000e84 ld v0,-32696(gp) > 0x120000e88 daddiu a1,v0,7432 > 0x120000e8c ld v0,-32456(gp) > 0x120000e90 move t9,v0 > 0x120000e94 jalr t9 > 0x120000e98 nop > 0x120000e9c bnez v0,0x0000000120000ec4 > 0x120000ea0 nop > 0x120000ea4 ld v0,-32680(gp) > 0x120000ea8 lw v0,0(v0) > 0x120000eac xori v0,v0,0x1 > 0x120000eb0 move v1,v0 > 0x120000eb4 ld v0,-32680(gp) > 0x120000eb8 sw v1,0(v0) > 0x120000ebc b 0x0000000120000f3c > 0x120000ec0 nop > 0x120000ec4 ld a0,8(s8) > 0x120000ec8 ld v0,-32696(gp) > 0x120000ecc daddiu a1,v0,7440 > 0x120000ed0 li a2,9 > 0x120000ed4 ld v0,-32592(gp) > 0x120000ed8 move t9,v0 > 0x120000edc jalr t9 > 0x120000ee0 nop > 0x120000ee4 bnez v0,0x0000000120000f04 > 0x120000ee8 nop > 0x120000eec ld v0,8(s8) > 0x120000ef0 daddiu v1,v0,9 > 0x120000ef4 ld v0,-32672(gp) > 0x120000ef8 sd v1,0(v0) > 0x120000efc b 0x0000000120000f3c > 0x120000f00 nop > 0x120000f04 ld v0,40(s8) > 0x120000f08 ld v1,0(v0) > 0x120000f0c ld v0,-32696(gp) > 0x120000f10 daddiu a0,v0,7456 > 0x120000f14 move a1,v1 > 0x120000f18 ld v0,-32472(gp) > 0x120000f1c move t9,v0 > 0x120000f20 jalr t9 > 0x120000f24 nop > 0x120000f28 li a0,2 > 0x120000f2c ld v0,-32512(gp) > 0x120000f30 move t9,v0 > 0x120000f34 jalr t9 > 0x120000f38 nop > 0x120000f3c b 0x0000000120000f60 > 0x120000f40 nop > 0x120000f44 ld a0,8(s8) > 0x120000f48 ld v0,-32664(gp) > 0x120000f4c move t9,v0 > 0x120000f50 bal &greet (0x12000103c) > 0x120000f54 nop > 0x120000f58 li v0,1 > 0x120000f5c sw v0,0(s8) > 0x120000f60 lw v0,4(s8) > 0x120000f64 addiu v0,v0,1 > 0x120000f68 sw v0,4(s8) > 0x120000f6c lw v1,4(s8) > 0x120000f70 lw v0,32(s8) > 0x120000f74 slt v0,v1,v0 > 0x120000f78 bnez v0,0x0000000120000e10 > 0x120000f7c nop > 0x120000f80 lw v0,0(s8) > 0x120000f84 bnez v0,0x0000000120000fa4 > 0x120000f88 nop > 0x120000f8c ld v0,-32696(gp) > 0x120000f90 daddiu a0,v0,7488 > 0x120000f94 ld v0,-32664(gp) > 0x120000f98 move t9,v0 > 0x120000f9c bal &greet (0x12000103c) > 0x120000fa0 nop > 0x120000fa4 ld v0,-32696(gp) > 0x120000fa8 daddiu a0,v0,7496 > 0x120000fac ld v0,-32496(gp) > 0x120000fb0 move t9,v0 > 0x120000fb4 jalr t9 > 0x120000fb8 nop > 0x120000fbc ld v0,-32736(gp) > 0x120000fc0 sd v0,16(s8) > 0x120000fc4 ld v0,-32656(gp) > 0x120000fc8 sd v0,24(s8) > 0x120000fcc ld a0,16(s8) > 0x120000fd0 ld v1,24(s8) > 0x120000fd4 ld v0,16(s8) > 0x120000fd8 sltu v0,v0,v1 > 0x120000fdc bnez v0,0x0000000120000ff4 > 0x120000fe0 nop > 0x120000fe4 ld v0,16(s8) > 0x120000fe8 daddiu v0,v0,64 > 0x120000fec b 0x0000000120000ff8 > 0x120000ff0 nop > 0x120000ff4 ld v0,24(s8) > 0x120000ff8 move a1,v0 > 0x120000ffc ld v0,-32648(gp) > 0x120001000 move t9,v0 > 0x120001004 bal 0x0000000120001840 > 0x120001008 nop > 0x12000100c ld v0,-32696(gp) > 0x120001010 daddiu a0,v0,7544 > 0x120001014 ld v0,-32496(gp) > 0x120001018 move t9,v0 > 0x12000101c jalr t9 > 0x120001020 nop > 0x120001024 move sp,s8 > 0x120001028 gslq ra,s8,64(sp) > 0x12000102c ld gp,56(sp) > 0x120001030 daddiu sp,sp,80 > 0x120001034 jr ra > 0x120001038 nop > greet: > 0x12000103c daddiu sp,sp,-48 > 0x120001040 gssq ra,s8,32(sp) > 0x120001044 sd gp,24(sp) > 0x120001048 move s8,sp > 0x12000104c lui gp,0x2 > 0x120001050 daddu gp,gp,t9 > 0x120001054 daddiu gp,gp,-24588 > 0x120001058 sd a0,0(s8) > 0x12000105c ld v0,-32696(gp) > 0x120001060 daddiu a0,v0,7552 > 0x120001064 ld a1,0(s8) > 0x120001068 ld v0,-32472(gp) > 0x12000106c move t9,v0 > 0x120001070 jalr t9 > 0x120001074 nop > 0x120001078 move sp,s8 > 0x12000107c gslq ra,s8,32(sp) > 0x120001080 ld gp,24(sp) > 0x120001084 daddiu sp,sp,48 > 0x120001088 jr ra > 0x12000108c nop > Cheers! > > 2. http://hg.loongnix.org/jdk8-mips64-public/hotspot/file/tip/src/share/tools/hsdis/Makefile#l85 > > > -- > Regards, > Leslie Zhai > > From zhaixiang at loongson.cn Thu Aug 9 09:57:14 2018 From: zhaixiang at loongson.cn (Leslie Zhai) Date: Thu, 9 Aug 2018 17:57:14 +0800 Subject: Request for Approval: Add BFD_VERSION for JDK-8191006: hsdis disassembler plugin does not compile with binutils 2.29+ In-Reply-To: <1E77ACFD-A6FB-435F-A07D-55A039AB388F@oracle.com> References: <39530ae5-f8be-d872-6477-953f9665d8bf@loongson.cn> <1E77ACFD-A6FB-435F-A07D-55A039AB388F@oracle.com> Message-ID: <862301fd-2da2-2c71-81ff-ec54a8b36dde@loongson.cn> Hi David, Thanks for your response! Because our operating system[1] use GCC old version toolchain, for example, gcc 4.9.3, binutils-gdb 2.24, and glibc 2.20 for long term support. Fortunately there are some patches had been merged by upstream[2], but we still need to maintain the ones not be approved by upstream, that is the usecase for building with old version of binutils-gdb. And we are migrating[3] to gcc-5/6/7/8 branches from gcc-4-branch. So there might be less and less backport requirement[4] BTW, hsdis perhaps also need nonexecstack flag set for linking with binutils/ld: diff -r 119d4695c1ed hotspot/src/share/tools/hsdis/Makefile --- a/hotspot/src/share/tools/hsdis/Makefile Mon Aug 06 11:15:26 2018 +0800 +++ b/hotspot/src/share/tools/hsdis/Makefile Thu Aug 09 17:56:21 2018 +0800 @@ -94,6 +94,7 @@ endif CFLAGS += -O DLDFLAGS += -shared +DLDFLAGS += -Wl,-z,noexecstack LDFLAGS += -ldl OUTFLAGS += -o $@ else 1. Loongnix http://ftp.loongnix.org/os/loongnix/1.0/liveinst/ 2. https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commit;h=8095d2f70e1a982c006f306be1a9e1c892758914 3. http://github.com/loongson-community/gcc 4. https://gcc.gnu.org/ml/gcc/2018-08/msg00041.html ? 2018?08?09? 17:13, David Buck ??: > Hi Leslie! > > What exactly is the use-case for building with older versions of BINUTILS? It would be good to know what benefit(s) there might be that would justify the cost of (slightly) complicating the code. > > Cheers, > -Buck > >> On Aug 9, 2018, at 17:12, Leslie Zhai wrote: >> >> Hi all, >> >> Thanks for David's patch to fix: >> >> https://bugs.openjdk.java.net/browse/JDK-8191006 >> >> But hsdis plugin does not compiled with binutils old version 2.27, so I just add `BFD_VERSION` for supporting old version binutils: >> >> Here is the patch: >> >> diff -r 09cc8813ae51 src/utils/hsdis/hsdis.c >> --- a/src/utils/hsdis/hsdis.c Wed Aug 08 18:38:34 2018 -0700 >> +++ b/src/utils/hsdis/hsdis.c Thu Aug 09 15:49:31 2018 +0800 >> @@ -338,10 +338,14 @@ >> >> /* Finish linking together the various callback blocks. */ >> app_data->dinfo.application_data = (void*) app_data; >> +#if BFD_VERSION >= 229000000 >> app_data->dfn = disassembler(bfd_get_arch(native_bfd), >> bfd_big_endian(native_bfd), >> bfd_get_mach(native_bfd), >> native_bfd); >> +#else >> + app_data->dfn = disassembler(native_bfd); >> +#endif >> app_data->dinfo.print_address_func = hsdis_print_address_func; >> app_data->dinfo.read_memory_func = hsdis_read_memory_func; >> >> And I would like to backport the fix to OpenJDK8 updates dev: >> >> http://hg.openjdk.java.net/jdk8u/jdk8u-dev >> >> So here is the backport patch: >> >> diff -r b4ee249eb1c4 src/share/tools/hsdis/hsdis.c >> --- a/src/share/tools/hsdis/hsdis.c Tue Aug 07 11:55:44 2018 -0400 >> +++ b/src/share/tools/hsdis/hsdis.c Thu Aug 09 15:49:57 2018 +0800 >> @@ -337,10 +337,14 @@ >> >> /* Finish linking together the various callback blocks. */ >> app_data->dinfo.application_data = (void*) app_data; >> +#if BFD_VERSION >= 229000000 >> app_data->dfn = disassembler(bfd_get_arch(native_bfd), >> bfd_big_endian(native_bfd), >> bfd_get_mach(native_bfd), >> native_bfd); >> +#else >> + app_data->dfn = disassembler(native_bfd); >> +#endif >> app_data->dinfo.print_address_func = hsdis_print_address_func; >> app_data->dinfo.read_memory_func = hsdis_read_memory_func; >> >> And I make demo[1] to test for OpenJDK8 mips64el[2]. >> >> A patch by Loongson! Please sponsor it, thanks a lot! >> >> >> 1. >> >> $ ./build/linux-mips64/hsdis-demo >> Hello, world! >> ...And now for something completely different: >> >> Decoding from 0x120000dd0 to 0x120001090...with decode_instructions_virtual >> Decoding for CPU 'mips:loongson_3a' >> main: >> 0x120000dd0 daddiu sp,sp,-80 >> 0x120000dd4 gssq ra,s8,64(sp) >> 0x120000dd8 sd gp,56(sp) >> 0x120000ddc move s8,sp >> 0x120000de0 lui gp,0x2 >> 0x120000de4 daddu gp,gp,t9 >> 0x120000de8 daddiu gp,gp,-23968 >> 0x120000dec move v0,a0 >> 0x120000df0 sd a1,40(s8) >> 0x120000df4 sll v0,v0,0x0 >> 0x120000df8 sw v0,32(s8) >> 0x120000dfc sw zero,0(s8) >> 0x120000e00 li v0,1 >> 0x120000e04 sw v0,4(s8) >> 0x120000e08 b 0x0000000120000f6c >> 0x120000e0c nop >> 0x120000e10 lw v0,4(s8) >> 0x120000e14 dsll v0,v0,0x3 >> 0x120000e18 ld v1,40(s8) >> 0x120000e1c daddu v0,v1,v0 >> 0x120000e20 ld v0,0(v0) >> 0x120000e24 sd v0,8(s8) >> 0x120000e28 ld v0,8(s8) >> 0x120000e2c lb v1,0(v0) >> 0x120000e30 li v0,45 >> 0x120000e34 bne v1,v0,0x0000000120000f44 >> 0x120000e38 nop >> 0x120000e3c ld a0,8(s8) >> 0x120000e40 ld v0,-32696(gp) >> 0x120000e44 daddiu a1,v0,7424 >> 0x120000e48 ld v0,-32456(gp) >> 0x120000e4c move t9,v0 >> 0x120000e50 jalr t9 >> 0x120000e54 nop >> 0x120000e58 bnez v0,0x0000000120000e80 >> 0x120000e5c nop >> 0x120000e60 ld v0,-32688(gp) >> 0x120000e64 lw v0,0(v0) >> 0x120000e68 xori v0,v0,0x1 >> 0x120000e6c move v1,v0 >> 0x120000e70 ld v0,-32688(gp) >> 0x120000e74 sw v1,0(v0) >> 0x120000e78 b 0x0000000120000f3c >> 0x120000e7c nop >> 0x120000e80 ld a0,8(s8) >> 0x120000e84 ld v0,-32696(gp) >> 0x120000e88 daddiu a1,v0,7432 >> 0x120000e8c ld v0,-32456(gp) >> 0x120000e90 move t9,v0 >> 0x120000e94 jalr t9 >> 0x120000e98 nop >> 0x120000e9c bnez v0,0x0000000120000ec4 >> 0x120000ea0 nop >> 0x120000ea4 ld v0,-32680(gp) >> 0x120000ea8 lw v0,0(v0) >> 0x120000eac xori v0,v0,0x1 >> 0x120000eb0 move v1,v0 >> 0x120000eb4 ld v0,-32680(gp) >> 0x120000eb8 sw v1,0(v0) >> 0x120000ebc b 0x0000000120000f3c >> 0x120000ec0 nop >> 0x120000ec4 ld a0,8(s8) >> 0x120000ec8 ld v0,-32696(gp) >> 0x120000ecc daddiu a1,v0,7440 >> 0x120000ed0 li a2,9 >> 0x120000ed4 ld v0,-32592(gp) >> 0x120000ed8 move t9,v0 >> 0x120000edc jalr t9 >> 0x120000ee0 nop >> 0x120000ee4 bnez v0,0x0000000120000f04 >> 0x120000ee8 nop >> 0x120000eec ld v0,8(s8) >> 0x120000ef0 daddiu v1,v0,9 >> 0x120000ef4 ld v0,-32672(gp) >> 0x120000ef8 sd v1,0(v0) >> 0x120000efc b 0x0000000120000f3c >> 0x120000f00 nop >> 0x120000f04 ld v0,40(s8) >> 0x120000f08 ld v1,0(v0) >> 0x120000f0c ld v0,-32696(gp) >> 0x120000f10 daddiu a0,v0,7456 >> 0x120000f14 move a1,v1 >> 0x120000f18 ld v0,-32472(gp) >> 0x120000f1c move t9,v0 >> 0x120000f20 jalr t9 >> 0x120000f24 nop >> 0x120000f28 li a0,2 >> 0x120000f2c ld v0,-32512(gp) >> 0x120000f30 move t9,v0 >> 0x120000f34 jalr t9 >> 0x120000f38 nop >> 0x120000f3c b 0x0000000120000f60 >> 0x120000f40 nop >> 0x120000f44 ld a0,8(s8) >> 0x120000f48 ld v0,-32664(gp) >> 0x120000f4c move t9,v0 >> 0x120000f50 bal &greet (0x12000103c) >> 0x120000f54 nop >> 0x120000f58 li v0,1 >> 0x120000f5c sw v0,0(s8) >> 0x120000f60 lw v0,4(s8) >> 0x120000f64 addiu v0,v0,1 >> 0x120000f68 sw v0,4(s8) >> 0x120000f6c lw v1,4(s8) >> 0x120000f70 lw v0,32(s8) >> 0x120000f74 slt v0,v1,v0 >> 0x120000f78 bnez v0,0x0000000120000e10 >> 0x120000f7c nop >> 0x120000f80 lw v0,0(s8) >> 0x120000f84 bnez v0,0x0000000120000fa4 >> 0x120000f88 nop >> 0x120000f8c ld v0,-32696(gp) >> 0x120000f90 daddiu a0,v0,7488 >> 0x120000f94 ld v0,-32664(gp) >> 0x120000f98 move t9,v0 >> 0x120000f9c bal &greet (0x12000103c) >> 0x120000fa0 nop >> 0x120000fa4 ld v0,-32696(gp) >> 0x120000fa8 daddiu a0,v0,7496 >> 0x120000fac ld v0,-32496(gp) >> 0x120000fb0 move t9,v0 >> 0x120000fb4 jalr t9 >> 0x120000fb8 nop >> 0x120000fbc ld v0,-32736(gp) >> 0x120000fc0 sd v0,16(s8) >> 0x120000fc4 ld v0,-32656(gp) >> 0x120000fc8 sd v0,24(s8) >> 0x120000fcc ld a0,16(s8) >> 0x120000fd0 ld v1,24(s8) >> 0x120000fd4 ld v0,16(s8) >> 0x120000fd8 sltu v0,v0,v1 >> 0x120000fdc bnez v0,0x0000000120000ff4 >> 0x120000fe0 nop >> 0x120000fe4 ld v0,16(s8) >> 0x120000fe8 daddiu v0,v0,64 >> 0x120000fec b 0x0000000120000ff8 >> 0x120000ff0 nop >> 0x120000ff4 ld v0,24(s8) >> 0x120000ff8 move a1,v0 >> 0x120000ffc ld v0,-32648(gp) >> 0x120001000 move t9,v0 >> 0x120001004 bal 0x0000000120001840 >> 0x120001008 nop >> 0x12000100c ld v0,-32696(gp) >> 0x120001010 daddiu a0,v0,7544 >> 0x120001014 ld v0,-32496(gp) >> 0x120001018 move t9,v0 >> 0x12000101c jalr t9 >> 0x120001020 nop >> 0x120001024 move sp,s8 >> 0x120001028 gslq ra,s8,64(sp) >> 0x12000102c ld gp,56(sp) >> 0x120001030 daddiu sp,sp,80 >> 0x120001034 jr ra >> 0x120001038 nop >> greet: >> 0x12000103c daddiu sp,sp,-48 >> 0x120001040 gssq ra,s8,32(sp) >> 0x120001044 sd gp,24(sp) >> 0x120001048 move s8,sp >> 0x12000104c lui gp,0x2 >> 0x120001050 daddu gp,gp,t9 >> 0x120001054 daddiu gp,gp,-24588 >> 0x120001058 sd a0,0(s8) >> 0x12000105c ld v0,-32696(gp) >> 0x120001060 daddiu a0,v0,7552 >> 0x120001064 ld a1,0(s8) >> 0x120001068 ld v0,-32472(gp) >> 0x12000106c move t9,v0 >> 0x120001070 jalr t9 >> 0x120001074 nop >> 0x120001078 move sp,s8 >> 0x12000107c gslq ra,s8,32(sp) >> 0x120001080 ld gp,24(sp) >> 0x120001084 daddiu sp,sp,48 >> 0x120001088 jr ra >> 0x12000108c nop >> >> Decoding from 0x120000dd0 to 0x120001090...with old decode_instructions >> Decoding for CPU 'mips:loongson_3a' >> main: >> 0x120000dd0 daddiu sp,sp,-80 >> 0x120000dd4 gssq ra,s8,64(sp) >> 0x120000dd8 sd gp,56(sp) >> 0x120000ddc move s8,sp >> 0x120000de0 lui gp,0x2 >> 0x120000de4 daddu gp,gp,t9 >> 0x120000de8 daddiu gp,gp,-23968 >> 0x120000dec move v0,a0 >> 0x120000df0 sd a1,40(s8) >> 0x120000df4 sll v0,v0,0x0 >> 0x120000df8 sw v0,32(s8) >> 0x120000dfc sw zero,0(s8) >> 0x120000e00 li v0,1 >> 0x120000e04 sw v0,4(s8) >> 0x120000e08 b 0x0000000120000f6c >> 0x120000e0c nop >> 0x120000e10 lw v0,4(s8) >> 0x120000e14 dsll v0,v0,0x3 >> 0x120000e18 ld v1,40(s8) >> 0x120000e1c daddu v0,v1,v0 >> 0x120000e20 ld v0,0(v0) >> 0x120000e24 sd v0,8(s8) >> 0x120000e28 ld v0,8(s8) >> 0x120000e2c lb v1,0(v0) >> 0x120000e30 li v0,45 >> 0x120000e34 bne v1,v0,0x0000000120000f44 >> 0x120000e38 nop >> 0x120000e3c ld a0,8(s8) >> 0x120000e40 ld v0,-32696(gp) >> 0x120000e44 daddiu a1,v0,7424 >> 0x120000e48 ld v0,-32456(gp) >> 0x120000e4c move t9,v0 >> 0x120000e50 jalr t9 >> 0x120000e54 nop >> 0x120000e58 bnez v0,0x0000000120000e80 >> 0x120000e5c nop >> 0x120000e60 ld v0,-32688(gp) >> 0x120000e64 lw v0,0(v0) >> 0x120000e68 xori v0,v0,0x1 >> 0x120000e6c move v1,v0 >> 0x120000e70 ld v0,-32688(gp) >> 0x120000e74 sw v1,0(v0) >> 0x120000e78 b 0x0000000120000f3c >> 0x120000e7c nop >> 0x120000e80 ld a0,8(s8) >> 0x120000e84 ld v0,-32696(gp) >> 0x120000e88 daddiu a1,v0,7432 >> 0x120000e8c ld v0,-32456(gp) >> 0x120000e90 move t9,v0 >> 0x120000e94 jalr t9 >> 0x120000e98 nop >> 0x120000e9c bnez v0,0x0000000120000ec4 >> 0x120000ea0 nop >> 0x120000ea4 ld v0,-32680(gp) >> 0x120000ea8 lw v0,0(v0) >> 0x120000eac xori v0,v0,0x1 >> 0x120000eb0 move v1,v0 >> 0x120000eb4 ld v0,-32680(gp) >> 0x120000eb8 sw v1,0(v0) >> 0x120000ebc b 0x0000000120000f3c >> 0x120000ec0 nop >> 0x120000ec4 ld a0,8(s8) >> 0x120000ec8 ld v0,-32696(gp) >> 0x120000ecc daddiu a1,v0,7440 >> 0x120000ed0 li a2,9 >> 0x120000ed4 ld v0,-32592(gp) >> 0x120000ed8 move t9,v0 >> 0x120000edc jalr t9 >> 0x120000ee0 nop >> 0x120000ee4 bnez v0,0x0000000120000f04 >> 0x120000ee8 nop >> 0x120000eec ld v0,8(s8) >> 0x120000ef0 daddiu v1,v0,9 >> 0x120000ef4 ld v0,-32672(gp) >> 0x120000ef8 sd v1,0(v0) >> 0x120000efc b 0x0000000120000f3c >> 0x120000f00 nop >> 0x120000f04 ld v0,40(s8) >> 0x120000f08 ld v1,0(v0) >> 0x120000f0c ld v0,-32696(gp) >> 0x120000f10 daddiu a0,v0,7456 >> 0x120000f14 move a1,v1 >> 0x120000f18 ld v0,-32472(gp) >> 0x120000f1c move t9,v0 >> 0x120000f20 jalr t9 >> 0x120000f24 nop >> 0x120000f28 li a0,2 >> 0x120000f2c ld v0,-32512(gp) >> 0x120000f30 move t9,v0 >> 0x120000f34 jalr t9 >> 0x120000f38 nop >> 0x120000f3c b 0x0000000120000f60 >> 0x120000f40 nop >> 0x120000f44 ld a0,8(s8) >> 0x120000f48 ld v0,-32664(gp) >> 0x120000f4c move t9,v0 >> 0x120000f50 bal &greet (0x12000103c) >> 0x120000f54 nop >> 0x120000f58 li v0,1 >> 0x120000f5c sw v0,0(s8) >> 0x120000f60 lw v0,4(s8) >> 0x120000f64 addiu v0,v0,1 >> 0x120000f68 sw v0,4(s8) >> 0x120000f6c lw v1,4(s8) >> 0x120000f70 lw v0,32(s8) >> 0x120000f74 slt v0,v1,v0 >> 0x120000f78 bnez v0,0x0000000120000e10 >> 0x120000f7c nop >> 0x120000f80 lw v0,0(s8) >> 0x120000f84 bnez v0,0x0000000120000fa4 >> 0x120000f88 nop >> 0x120000f8c ld v0,-32696(gp) >> 0x120000f90 daddiu a0,v0,7488 >> 0x120000f94 ld v0,-32664(gp) >> 0x120000f98 move t9,v0 >> 0x120000f9c bal &greet (0x12000103c) >> 0x120000fa0 nop >> 0x120000fa4 ld v0,-32696(gp) >> 0x120000fa8 daddiu a0,v0,7496 >> 0x120000fac ld v0,-32496(gp) >> 0x120000fb0 move t9,v0 >> 0x120000fb4 jalr t9 >> 0x120000fb8 nop >> 0x120000fbc ld v0,-32736(gp) >> 0x120000fc0 sd v0,16(s8) >> 0x120000fc4 ld v0,-32656(gp) >> 0x120000fc8 sd v0,24(s8) >> 0x120000fcc ld a0,16(s8) >> 0x120000fd0 ld v1,24(s8) >> 0x120000fd4 ld v0,16(s8) >> 0x120000fd8 sltu v0,v0,v1 >> 0x120000fdc bnez v0,0x0000000120000ff4 >> 0x120000fe0 nop >> 0x120000fe4 ld v0,16(s8) >> 0x120000fe8 daddiu v0,v0,64 >> 0x120000fec b 0x0000000120000ff8 >> 0x120000ff0 nop >> 0x120000ff4 ld v0,24(s8) >> 0x120000ff8 move a1,v0 >> 0x120000ffc ld v0,-32648(gp) >> 0x120001000 move t9,v0 >> 0x120001004 bal 0x0000000120001840 >> 0x120001008 nop >> 0x12000100c ld v0,-32696(gp) >> 0x120001010 daddiu a0,v0,7544 >> 0x120001014 ld v0,-32496(gp) >> 0x120001018 move t9,v0 >> 0x12000101c jalr t9 >> 0x120001020 nop >> 0x120001024 move sp,s8 >> 0x120001028 gslq ra,s8,64(sp) >> 0x12000102c ld gp,56(sp) >> 0x120001030 daddiu sp,sp,80 >> 0x120001034 jr ra >> 0x120001038 nop >> greet: >> 0x12000103c daddiu sp,sp,-48 >> 0x120001040 gssq ra,s8,32(sp) >> 0x120001044 sd gp,24(sp) >> 0x120001048 move s8,sp >> 0x12000104c lui gp,0x2 >> 0x120001050 daddu gp,gp,t9 >> 0x120001054 daddiu gp,gp,-24588 >> 0x120001058 sd a0,0(s8) >> 0x12000105c ld v0,-32696(gp) >> 0x120001060 daddiu a0,v0,7552 >> 0x120001064 ld a1,0(s8) >> 0x120001068 ld v0,-32472(gp) >> 0x12000106c move t9,v0 >> 0x120001070 jalr t9 >> 0x120001074 nop >> 0x120001078 move sp,s8 >> 0x12000107c gslq ra,s8,32(sp) >> 0x120001080 ld gp,24(sp) >> 0x120001084 daddiu sp,sp,48 >> 0x120001088 jr ra >> 0x12000108c nop >> Cheers! >> >> 2. http://hg.loongnix.org/jdk8-mips64-public/hotspot/file/tip/src/share/tools/hsdis/Makefile#l85 >> >> >> -- >> Regards, >> Leslie Zhai >> >> -- Regards, Leslie Zhai From mark.reinhold at oracle.com Thu Aug 9 18:16:21 2018 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Thu, 09 Aug 2018 11:16:21 -0700 Subject: JDK 11 is now in Rampdown Phase Two In-Reply-To: <2945911e-7de9-d790-074f-3a035accbe0e@oracle.com> References: <20180726141950.714871664@eggemoggin.niobe.net> <2945911e-7de9-d790-074f-3a035accbe0e@oracle.com> Message-ID: <20180809111621.975227170@eggemoggin.niobe.net> 2018/7/30 9:47:25 -0700, sean.mullan at oracle.com: > For RDP 2, it is my understanding that any P1-P2 bugs that are not test > or doc issues now need approval (according to the Fix-Request Process of > JEP 3) before you can push. Is that correct? If so, I think the Fix > column of the table at the beginning of JEP 3 should say: > > Current P1?P2, with approval Thanks for pointing this out. Fixed. - Mark From mark.reinhold at oracle.com Thu Aug 9 18:45:53 2018 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Thu, 9 Aug 2018 11:45:53 -0700 (PDT) Subject: JDK 11 enters the Release Candidate Phase next week Message-ID: <20180809184553.B1E4F1E28A3@eggemoggin.niobe.net> Per the JDK 11 schedule [1], we are still in Rampdown Phase Two. The stabilization repository, jdk/jdk11, is currently open for P1-P2 bug fixes and late enhancements per the JDK Release Process (JEP 3) [2]. All changes require approval, either via the Fix-Request Process [3] or the Late-Enhancement Request Process [4]. If you?re responsible for any of the bugs on the RDP 2 candidate-bug list [5] then please see JEP 3 for guidance on how to handle them. We?ll tag the first Release Candidate build one week from today. All changes for JDK 11 must be in jdk/jdk11 by 15:00 UTC next Thursday, 16 August [6]. - Mark [1] http://openjdk.java.net/projects/jdk/11/#Schedule [2] http://openjdk.java.net/jeps/3 [3] http://openjdk.java.net/jeps/3#Fix-Request-Process [4] http://openjdk.java.net/jeps/3#Late-Enhancement-Request-Process [5] http://j.mp/jdk-rdp-2 [6] https://www.timeanddate.com/worldclock/fixedtime.html?msg=JDK+11+Release+Candidate+Phase&iso=20180816T15 From mark.reinhold at oracle.com Thu Aug 9 19:05:53 2018 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Thu, 09 Aug 2018 12:05:53 -0700 Subject: CFV: New JDK Committer: Jc Beyler In-Reply-To: <5dccf119-c59a-3bb2-76c2-9bc7b309ec2d@oracle.com> References: <5dccf119-c59a-3bb2-76c2-9bc7b309ec2d@oracle.com> Message-ID: <20180809120553.303281610@eggemoggin.niobe.net> Vote: yes - Mark From iris.clark at oracle.com Thu Aug 9 19:59:27 2018 From: iris.clark at oracle.com (Iris Clark) Date: Thu, 9 Aug 2018 12:59:27 -0700 (PDT) Subject: CFV: New JDK Committer: Jc Beyler In-Reply-To: <5dccf119-c59a-3bb2-76c2-9bc7b309ec2d@oracle.com> References: <5dccf119-c59a-3bb2-76c2-9bc7b309ec2d@oracle.com> Message-ID: Vote: yes iris From aleksej.efimov at oracle.com Fri Aug 10 14:59:42 2018 From: aleksej.efimov at oracle.com (Aleks Efimov) Date: Fri, 10 Aug 2018 15:59:42 +0100 Subject: CFV: New JDK Committer: Jc Beyler In-Reply-To: <5dccf119-c59a-3bb2-76c2-9bc7b309ec2d@oracle.com> References: <5dccf119-c59a-3bb2-76c2-9bc7b309ec2d@oracle.com> Message-ID: <4013ee0f-ffdb-846f-6546-0c4d021cf083@oracle.com> Vote: yes On 08/02/2018 07:21 PM, serguei.spitsyn at oracle.com wrote: > I hereby nominate Jean Christophe Beyler (jcbeyler) to JDK Committer. > > Jean Christophe works for "Java Performance and Garbage Collection" and > "Java Runtime" teams at Google and has contributed more than 20 changes. > His contributions can be found here [3]. > > Votes are due by 12:00 pm PT, August 16, 2018. > > Only current JDK Committers [1] are eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Serguei Spitsyn > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] > http://hg.openjdk.java.net/jdk/jdk/log?revcount=1000&rev=(keyword(%22jcbeyler%40google.com%22)+or+author(jcbeyler))+and+not+desc(%22Merge%22) > > > From karen.kinnear at oracle.com Fri Aug 10 20:43:00 2018 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Fri, 10 Aug 2018 16:43:00 -0400 Subject: CFV: New JDK Committer: Jc Beyler In-Reply-To: References: <5dccf119-c59a-3bb2-76c2-9bc7b309ec2d@oracle.com> Message-ID: <4380A6E7-0721-4530-B776-90090E8AF4EA@oracle.com> Vote: yes Thanks, Karen > On Aug 2, 2018, at 2:28 PM, mikhailo wrote: > > Vote: yes > > Misha > > >> On 08/02/2018 11:21 AM, serguei.spitsyn at oracle.com wrote: >> I hereby nominate Jean Christophe Beyler (jcbeyler) to JDK Committer. >> >> Jean Christophe works for "Java Performance and Garbage Collection" and >> "Java Runtime" teams at Google and has contributed more than 20 changes. >> His contributions can be found here [3]. >> >> Votes are due by 12:00 pm PT, August 16, 2018. >> >> Only current JDK Committers [1] are eligible to vote on this nomination. >> Votes must be cast in the open by replying to this mailing list. >> >> For Lazy Consensus voting instructions, see [2]. >> >> Serguei Spitsyn >> >> [1] http://openjdk.java.net/census >> [2] http://openjdk.java.net/projects/#committer-vote >> [3] http://hg.openjdk.java.net/jdk/jdk/log?revcount=1000&rev=(keyword(%22jcbeyler%40google.com%22)+or+author(jcbeyler))+and+not+desc(%22Merge%22) >> >> >> > From igor.ignatyev at oracle.com Fri Aug 10 20:55:12 2018 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Fri, 10 Aug 2018 13:55:12 -0700 Subject: Result: New JDK Committer: Leonid Mesnik Message-ID: <936C85CE-FE8B-44C7-B4E7-6082B09EBE7C@oracle.com> Voting for Leonid Mesnik[1] is now closed. Yes: 31 Veto: 0 Abstain: 0 According to the Bylaws definition of Lazy Consensus, this is sufficient to approve the nomination. Igor Ignatyev [1] http://mail.openjdk.java.net/pipermail/jdk-dev/2018-July/001670.html From sean.mullan at oracle.com Wed Aug 15 14:35:08 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 15 Aug 2018 10:35:08 -0400 Subject: Result: New JDK Reviewer: Adam Petcher Message-ID: <5195e9b6-2e64-d72d-3096-a6fe1219348e@oracle.com> Voting for Adam Petcher [1] is now closed. Yes: 26 Veto: 0 Abstain: 0 According to the Bylaws definition of Three-Vote Consensus, this is sufficient to approve the nomination. Sean Mullan [1] http://mail.openjdk.java.net/pipermail/jdk-dev/2018-July/001703.html From jonathan.gibbons at oracle.com Wed Aug 15 23:46:19 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 15 Aug 2018 16:46:19 -0700 Subject: jtreg FAQ updates Message-ID: <5B74BB4B.4060504@oracle.com> For those of you that run jtreg, I've made some updates to the jtreg FAQ that is available in builds of jtreg, and on the OpenJDK website. [1] In addition to some general cleanup, I've reorganized it a bit, to create a couple of new sections, "3. Using jtreg" and "5. Organizing tests". Most of section 3 is new, although a few questions were moved from elsewhere; Other new questions include: 4.19 Can I (and should I) write shell tests? 5.5 How should I organize tests, libraries, and other test-related files? 5.6 Can I put more than one test in a file? -- Jon [1] http://openjdk.java.net/jtreg/faq.html (linked under "FAQ" from the main jtreg page http://openjdk.java.net/jtreg/) From martijnverburg at gmail.com Thu Aug 16 06:37:07 2018 From: martijnverburg at gmail.com (Martijn Verburg) Date: Thu, 16 Aug 2018 07:37:07 +0100 Subject: jtreg FAQ updates In-Reply-To: <5B74BB4B.4060504@oracle.com> References: <5B74BB4B.4060504@oracle.com> Message-ID: Great - thank you! On Thu, 16 Aug 2018 at 00:46, Jonathan Gibbons wrote: > For those of you that run jtreg, I've made some updates to the jtreg FAQ > that is available in builds of jtreg, and on the OpenJDK website. [1] > > In addition to some general cleanup, I've reorganized it a bit, to create a > couple of new sections, "3. Using jtreg" and "5. Organizing tests". > Most of section 3 is new, although a few questions were moved from > elsewhere; > Other new questions include: > 4.19 Can I (and should I) write shell tests? > 5.5 How should I organize tests, libraries, and other test-related files? > 5.6 Can I put more than one test in a file? > > -- Jon > > [1] http://openjdk.java.net/jtreg/faq.html > (linked under "FAQ" from the main jtreg page > http://openjdk.java.net/jtreg/) > -- Cheers, Martijn (Sent from Gmail Mobile) From chris.hegarty at oracle.com Thu Aug 16 11:30:33 2018 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 16 Aug 2018 12:30:33 +0100 Subject: jtreg FAQ updates In-Reply-To: <5B74BB4B.4060504@oracle.com> References: <5B74BB4B.4060504@oracle.com> Message-ID: Jon, Thanks for this. A question on testng. > On 16 Aug 2018, at 00:46, Jonathan Gibbons wrote: > ... > 5.6 Can I put more than one test in a file? I think that you can put several jtreg-invoked testng tests in a single file. At least it works for me. For example: /* * @test * @run testng/othervm Test */ /* * @test * @run testng/othervm Test */ , but it is not all that useful. The reason I enquire about this is that we have several long running, and verbose, testng tests, that have several hundred combinations. These test take a long time to run and can generate a lot of data. The approach we?ve taken to date is to effectively create an abstract class that contains all the test logic and data providers. Then have several ?driver? like subtypes that each override a single supertypes moral "test" method and add the testng @Test annotation. Example below. What we?d really like to do is to add several test descriptions to the main test specify something like: /* * @test * @run testng:groups="synchronous"/othervm TestAsync */ /* * @test * @run testng:groups=?asynchronous"/othervm TestAsync */ , or some such syntax that would allow us to pass in a testng test group. This would allow each group the same timeout, jtr output file limit ( if any ), etc, without the need for the extra clutter of the ?driver? files. We have several of test drivers in java/net/httpclient, e.g. ThrowingXXX.java I?ve looked a little at jtreg?s support for testng and I think that this is doable. Before filing an enhancement request, or hacking on the code, is this something that you think would be accepted? I?m not sure if others have come across a need for it before, but it is certainly useful to the work being done by the HTTP Client, and the workaround that exists today is a little crummy. -Chris. $ cat test/jdk/java/net/httpclient/AbstractTest.java import java.util.concurrent.CompletableFuture; import org.testng.annotations.*; public abstract class AbstractTest { @DataProvider(name = "values") public Object[][] values() { return new Object[][] { {1} , {2}, {3} }; } //@Test(dataProvider = "values", groups = "synchronous") void testSync(int value) { System.out.println(value); } //@Test(dataProvider = "values", groups = ?asynchronous") void testAsync(int value) { CompletableFuture.runAsync(() -> System.out.println(value)).join(); } @BeforeTest public void setup() throws Exception { /* ... */ } @AfterTest public void teardown() throws Exception { /* ... */ } // More common code and infrastructure ? } $ cat test/jdk/java/net/httpclient/TestSync.java /* * @test * @build AbstractTest * @run testng/othervm TestSync */ import org.testng.annotations.Test; public class TestSync extends AbstractTest { @Override @Test(dataProvider = "values", groups = "synchronous") void testSync(int value) { super.testSync(value); } } $ cat test/jdk/java/net/httpclient/TestAsync.java /* * @test * @build AbstractTest * @run testng/othervm TestAsync */ import org.testng.annotations.Test; public class TestAsync extends AbstractTest { @Override @Test(dataProvider = "values", groups = ?asynchronous") void testAsync(int value) { super.testAsync(value); } } From jonathan.gibbons at oracle.com Thu Aug 16 15:15:50 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 16 Aug 2018 08:15:50 -0700 Subject: jtreg FAQ updates In-Reply-To: References: <5B74BB4B.4060504@oracle.com> Message-ID: Chris, This seems generally reasonable, and worth filing as an enhancement request, although it might also trigger a Q in the FAQ on "How long should a test take?" -- Jon On 8/16/18 4:30 AM, Chris Hegarty wrote: > Jon, > > Thanks for this. A question on testng. > >> On 16 Aug 2018, at 00:46, Jonathan Gibbons wrote: >> ... >> 5.6 Can I put more than one test in a file? > I think that you can put several jtreg-invoked testng tests in a single > file. At least it works for me. For example: > > /* > * @test > * @run testng/othervm Test > */ > /* > * @test > * @run testng/othervm Test > */ > > , but it is not all that useful. > > The reason I enquire about this is that we have several long running, and > verbose, testng tests, that have several hundred combinations. These test > take a long time to run and can generate a lot of data. The approach we?ve > taken to date is to effectively create an abstract class that contains all the > test logic and data providers. Then have several ?driver? like subtypes that > each override a single supertypes moral "test" method and add the testng > @Test annotation. Example below. > > What we?d really like to do is to add several test descriptions to the main > test specify something like: > /* > * @test > * @run testng:groups="synchronous"/othervm TestAsync > */ > /* > * @test > * @run testng:groups=?asynchronous"/othervm TestAsync > */ > > , or some such syntax that would allow us to pass in a testng test > group. This would allow each group the same timeout, jtr output file > limit ( if any ), etc, without the need for the extra clutter of the ?driver? > files. We have several of test drivers in java/net/httpclient, e.g. > ThrowingXXX.java > > I?ve looked a little at jtreg?s support for testng and I think that this is > doable. Before filing an enhancement request, or hacking on the code, > is this something that you think would be accepted? I?m not sure if > others have come across a need for it before, but it is certainly useful > to the work being done by the HTTP Client, and the workaround that > exists today is a little crummy. > > -Chris. > > $ cat test/jdk/java/net/httpclient/AbstractTest.java > > import java.util.concurrent.CompletableFuture; > import org.testng.annotations.*; > > public abstract class AbstractTest { > > @DataProvider(name = "values") > public Object[][] values() { > return new Object[][] { {1} , {2}, {3} }; > } > > //@Test(dataProvider = "values", groups = "synchronous") > void testSync(int value) { > System.out.println(value); > } > > //@Test(dataProvider = "values", groups = ?asynchronous") > void testAsync(int value) { > CompletableFuture.runAsync(() -> System.out.println(value)).join(); > } > > @BeforeTest > public void setup() throws Exception { /* ... */ } > > @AfterTest > public void teardown() throws Exception { /* ... */ } > > // More common code and infrastructure ? > } > > $ cat test/jdk/java/net/httpclient/TestSync.java > /* > * @test > * @build AbstractTest > * @run testng/othervm TestSync > */ > > import org.testng.annotations.Test; > > public class TestSync extends AbstractTest { > > @Override > @Test(dataProvider = "values", groups = "synchronous") > void testSync(int value) { > super.testSync(value); > } > } > > $ cat test/jdk/java/net/httpclient/TestAsync.java > /* > * @test > * @build AbstractTest > * @run testng/othervm TestAsync > */ > > import org.testng.annotations.Test; > > public class TestAsync extends AbstractTest { > > @Override > @Test(dataProvider = "values", groups = ?asynchronous") > void testAsync(int value) { > super.testAsync(value); > } > } > > > From martinrb at google.com Thu Aug 16 15:18:46 2018 From: martinrb at google.com (Martin Buchholz) Date: Thu, 16 Aug 2018 08:18:46 -0700 Subject: jtreg FAQ updates In-Reply-To: References: <5B74BB4B.4060504@oracle.com> Message-ID: On Thu, Aug 16, 2018 at 4:30 AM, Chris Hegarty wrote: > Jon, > > Thanks for this. A question on testng. > > > On 16 Aug 2018, at 00:46, Jonathan Gibbons > wrote: > > ... > > 5.6 Can I put more than one test in a file? > > I think that you can put several jtreg-invoked testng tests in a single > file. At least it works for me. For example: > > /* > * @test > * @run testng/othervm Test > */ > /* > * @test > * @run testng/othervm Test > */ > > , but it is not all that useful. > I was confused by this as well, but for junit. The existing JSR166TestCase successfully and usefully defines multiple @run junit tests. I think the confusion has to do with """jtreg supports TestNG tests in two ways.""" From mark.reinhold at oracle.com Thu Aug 16 15:48:43 2018 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Thu, 16 Aug 2018 08:48:43 -0700 (PDT) Subject: JDK 11 is now in the Release Candidate Phase Message-ID: <20180816154843.5D801206F7E@eggemoggin.niobe.net> Per the JDK 11 schedule [1], we are now in the Release Candidate phase. The stabilization repository, jdk/jdk11, is open for P1 bug fixes per the JDK Release Process (JEP 3) [2]. All changes require approval via the Fix-Request Process [3]. If you?re responsible for any of the bugs on the RC candidate-bug list [4] then please see JEP 3 for guidance on how to handle them. We?ll tag the first Release Candidate build shortly. - Mark [1] http://openjdk.java.net/projects/jdk/11/#Schedule [2] http://openjdk.java.net/jeps/3 [3] http://openjdk.java.net/jeps/3#Fix-Request-Process [4] http://j.mp/jdk-rc From jonathan.gibbons at oracle.com Thu Aug 16 16:01:00 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 16 Aug 2018 09:01:00 -0700 Subject: jtreg FAQ updates In-Reply-To: References: <5B74BB4B.4060504@oracle.com> Message-ID: <4912836e-c4e2-49b9-1007-30c7f9021997@oracle.com> On 8/16/18 8:18 AM, Martin Buchholz wrote: > > > On Thu, Aug 16, 2018 at 4:30 AM, Chris Hegarty > > wrote: > > Jon, > > Thanks for this. A question on testng. > > > On 16 Aug 2018, at 00:46, Jonathan Gibbons > > > wrote: > > ... > > 5.6? Can I put more than one test in a file? > > I think that you can put several jtreg-invoked testng tests in a > single > file. > The ability to put more than one test in a file is independent of the actions of the test. It's always been undocumented but possible to put multiple tests in a file; it was undocumented (until a while back) because the ability to name the individual tests was imperfect. > At least it works for me. For example: > > ? ?/* > ? ? * @test > ? ? * @run testng/othervm Test > ? ? */ > ? ?/* > ? ? * @test > ? ? * @run testng/othervm Test > ? ? */ > > ? , but it is not all that useful. > I agree that putting multiple tests with the same set of actions is not useful. You would normally want to have different actions in the individual tests, such as with different arguments in some manner. > > I was confused by this as well, but for junit.? The existing > JSR166TestCase successfully and usefully defines multiple @run junit > tests. Yes, JSR166TestCase provides a number of different tests in that one source file. > > I think the confusion has to do with """jtreg supports TestNG tests in > two ways.""" I'm confused by your confusion. Can you say more, so that I can try and improve the text in this area? -- Jon From martinrb at google.com Thu Aug 16 16:26:03 2018 From: martinrb at google.com (Martin Buchholz) Date: Thu, 16 Aug 2018 09:26:03 -0700 Subject: jtreg FAQ updates In-Reply-To: <4912836e-c4e2-49b9-1007-30c7f9021997@oracle.com> References: <5B74BB4B.4060504@oracle.com> <4912836e-c4e2-49b9-1007-30c7f9021997@oracle.com> Message-ID: On Thu, Aug 16, 2018 at 9:01 AM, Jonathan Gibbons < jonathan.gibbons at oracle.com> wrote: > > I was confused by this as well, but for junit. The existing > JSR166TestCase successfully and usefully defines multiple @run junit tests. > > Yes, JSR166TestCase provides a number of different tests in that one > source file. > > > I think the confusion has to do with """jtreg supports TestNG tests in > two ways.""" > > I'm confused by your confusion. Can you say more, so that I can try and > improve the text in this area? > > faq says: """The feature is supported in normal Java tests, in shell tests, and in legacy applet tests. (It is not supported in JUnit or TestNG tests, which do not use explicit test descriptions.)""" But ... Both JUnit and TestNG tests can use """explicit test descriptions""". Unless they are Type 2 tests as described in 6.2 Further confusion - there's documented support for running "implicit" testng tests but I don't see any such support for junit. E.g. there's no documented junit.dirs I can put into TEST.ROOT. From jonathan.gibbons at oracle.com Thu Aug 16 16:37:55 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 16 Aug 2018 09:37:55 -0700 Subject: jtreg FAQ updates In-Reply-To: References: <5B74BB4B.4060504@oracle.com> <4912836e-c4e2-49b9-1007-30c7f9021997@oracle.com> Message-ID: <742b588e-4921-aa51-62c9-246204ed9beb@oracle.com> On 8/16/18 9:26 AM, Martin Buchholz wrote: > > > On Thu, Aug 16, 2018 at 9:01 AM, Jonathan Gibbons > > wrote: > >> I was confused by this as well, but for junit.? The existing >> JSR166TestCase successfully and usefully defines multiple @run >> junit tests. > Yes, JSR166TestCase provides a number of different tests in that > one source file. >> >> I think the confusion has to do with """jtreg supports TestNG >> tests in two ways.""" > I'm confused by your confusion. Can you say more, so that I can > try and improve the text in this area? > > > faq says: > > """The feature is supported in normal Java tests, in shell tests, and > in legacy applet tests. (It is not supported in JUnit or TestNG tests, > which do not use explicit test descriptions.)""" > > But ... Both JUnit and TestNG tests can use """explicit test > descriptions""".? Unless they are Type 2 tests as described in 6.2 > Further confusion - there's documented support for running "implicit" > testng tests but I don't see any such support for junit.? E.g. there's > no documented junit.dirs I can put into TEST.ROOT. OK, thanks for the clarifications;? I will address them in updates to the FAQ. -- Jon From serguei.spitsyn at oracle.com Fri Aug 17 04:33:30 2018 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 16 Aug 2018 21:33:30 -0700 Subject: CFV: New JDK Committer: Daniil Titov In-Reply-To: References: Message-ID: Vote: yes From serguei.spitsyn at oracle.com Fri Aug 17 04:42:48 2018 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 16 Aug 2018 21:42:48 -0700 Subject: CFV: New JDK Committer: Jc Beyler In-Reply-To: <5dccf119-c59a-3bb2-76c2-9bc7b309ec2d@oracle.com> References: <5dccf119-c59a-3bb2-76c2-9bc7b309ec2d@oracle.com> Message-ID: <6011a3f7-de62-a1b8-ae80-7b656754c951@oracle.com> Vote: yes From serguei.spitsyn at oracle.com Fri Aug 17 04:43:33 2018 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 16 Aug 2018 21:43:33 -0700 Subject: Result: New JDK Committer: Daniil Titov Message-ID: <1f6d6ee2-67bf-5908-b50e-cf399821ad28@oracle.com> Voting for Daniil Titov[1] is now closed. Yes: 17 Veto: 0 Abstain: 0 According to the Bylaws definition of Lazy Consensus, this is sufficient to approve the nomination. Serguei Spitsyn [1] http://mail.openjdk.java.net/pipermail/jdk-dev/2018-August/001739.html From serguei.spitsyn at oracle.com Fri Aug 17 04:46:02 2018 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 16 Aug 2018 21:46:02 -0700 Subject: Result: New JDK Committer: Jean Christophe Beyler Message-ID: Voting for Jean Christophe Beyler[1] is now closed. Yes: 40 Veto: 0 Abstain: 0 According to the Bylaws definition of Lazy Consensus, this is sufficient to approve the nomination. Serguei Spitsyn [1] http://mail.openjdk.java.net/pipermail/jdk-dev/2018-August/001741.html From scolebourne at joda.org Fri Aug 17 16:36:26 2018 From: scolebourne at joda.org (Stephen Colebourne) Date: Fri, 17 Aug 2018 17:36:26 +0100 Subject: What does LTS mean for OpenJDK? Message-ID: The LTS (long term support) release Java 11 is nearly upon us. But what does LTS mean in the context of OpenJDK? I'd like to try to get a clear statement of fact in written form, particularly from Oracle. Java 10 has had public $free support, with two security updates over 6 months and pre-built binaries at http://jdk.java.net/10/ What will Java 11 get from Oracle? - 6 months of public $free updates with binaries published at http://jdk.java.net - 3 years of public $free updates with binaries published at http://jdk.java.net - something else? Note! The request is about $free pre-built binaries ready for download. We all know people can pay money for support to multiple vendors. Is any other group (eg. AdoptOpenJDK, RedHat) planning on providing security patched pre-built binaries for $free? If so, for how long? Please provide links. Is Oracle the only OpenJDK member entitled to update http://jdk.java.net ? For those wondering, the Java support page [1] is not relevant here as that refers to Oracle's Java which will not be $free. Nor does this provide clarity [2]. This video [3] at 17:00 appears to provide some answers, but not in written form. The last thread was conspicuous by an absence of Oracle participation [4] thanks Stephen [1] http://www.oracle.com/technetwork/java/javase/eol-135779.html [2] https://blogs.oracle.com/java-platform-group/update-and-faq-on-the-java-se-release-cadence [3[ https://www.youtube.com/watch?v=WlpVeRB00qw&t=0s&list=PLX8CzqL3ArzVnxC6PYxMlngEMv3W1pIkn&index=10 [4] http://mail.openjdk.java.net/pipermail/jdk-dev/2017-November/thread.html#175 From mark.reinhold at oracle.com Fri Aug 17 17:21:18 2018 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Fri, 17 Aug 2018 10:21:18 -0700 Subject: What does LTS mean for OpenJDK? In-Reply-To: References: Message-ID: <20180817102118.894794332@eggemoggin.niobe.net> 2018/8/17 9:36:26 -0700, Stephen Colebourne : > The LTS (long term support) release Java 11 is nearly upon us. But > what does LTS mean in the context of OpenJDK? I'd like to try to get a > clear statement of fact in written form, particularly from Oracle. > > Java 10 has had public $free support, with two security updates over 6 > months and pre-built binaries at http://jdk.java.net/10/ > > What will Java 11 get from Oracle? > - 6 months of public $free updates with binaries published at > http://jdk.java.net > - 3 years of public $free updates with binaries published at http://jdk.java.net > - something else? At least six months of free, GPL-licensed updates with binaries at http://jdk.java.net. (I say ?at least? because that?s the current plan. The plan could change, to a longer time period, if the situation warrants.) > ... > > Is any other group (eg. AdoptOpenJDK, RedHat) planning on providing > security patched pre-built binaries for $free? If so, for how long? > Please provide links. I?ll leave that to others to answer. > Is Oracle the only OpenJDK member entitled to update http://jdk.java.net ? The jdk.java.net site is for builds from Oracle, under various licenses FLOSS and otherwise. It?s not part of the OpenJDK Community. Other implementors have their own distribution sites or related mechanisms. - Mark From mark.reinhold at oracle.com Fri Aug 17 17:27:09 2018 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Fri, 17 Aug 2018 10:27:09 -0700 Subject: JDK 11: No Release Candidate, yet Message-ID: <20180817102709.289730137@eggemoggin.niobe.net> We tagged the first Release Candidate build this morning (jdk-11+27), but since there are some open P1 bugs (http://j.mp/jdk-rc) it?s not actually a Release Candidate. Stay tuned ... - Mark From aph at redhat.com Fri Aug 17 17:33:08 2018 From: aph at redhat.com (Andrew Haley) Date: Fri, 17 Aug 2018 18:33:08 +0100 Subject: What does LTS mean for OpenJDK? In-Reply-To: References: Message-ID: <8ba6b9eb-73ef-da23-e61d-d5b043ecdf32@redhat.com> On 08/17/2018 05:36 PM, Stephen Colebourne wrote: > The LTS (long term support) release Java 11 is nearly upon us. But > what does LTS mean in the context of OpenJDK? I'd like to try to get a > clear statement of fact in written form, particularly from Oracle. I have been discussing with some other organizations sharing the burden of supporting jdk11, and we'll make a public statement when we're ready. Before then, I'll say what I can. OpenJDK is a community project. It's up to the community to support it. In practice this means that a group of organizations and individuals will maintain each OpenJDK LTS release for some period (TBA for 11, but it's sure to be a *lot* longer than six months.) I am certain that there will be a jdk11u project, and it will be properly and professionally run. I think it's likely that I'll be leading the project, but someone else may be chosen. Given that we don't know when Oracle will end their support it's hard to say any more. > Java 10 has had public $free support, with two security updates over 6 > months and pre-built binaries at http://jdk.java.net/10/ > > What will Java 11 get from Oracle? > - 6 months of public $free updates with binaries published at > http://jdk.java.net > - 3 years of public $free updates with binaries published at http://jdk.java.net > - something else? > > Note! The request is about $free pre-built binaries ready for > download. We all know people can pay money for support to multiple > vendors. > > > Is any other group (eg. AdoptOpenJDK, RedHat) planning on providing > security patched pre-built binaries for $free? If so, for how long? Red Hat is committed to support OpenJDK for its customers for some time. Our policy for current versions can be seen at https://access.redhat.com/articles/1299013#OpenJDK_Lifecycle_Dates_and_RHEL_versions Given that Red Hat has an upstream first policy, we will make sure that all security patches are applied to upstream OpenJDK releases and our builds are TCK'd. With regard to providing binaries, I'm aware that any jdkll update project after Oracle ceases to support it will need to provide binaries for several platforms. (java.net is Oracle's proprietary site, so it doesn't make any sense to put them there.) The project will decide exactly where to put those binaries, but in my opinion as long as they are properly authenticated and easy to get it doesn't really matter. Finally, please let me assure you of one thing: whether by Oracle or Red Hat or someone else, JDK LTS releases will continue to be supported. We all have a lot invested in Java, and we won't let it fall. > Please provide links. Hmph. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From mark.reinhold at oracle.com Fri Aug 17 17:44:29 2018 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Fri, 17 Aug 2018 10:44:29 -0700 (PDT) Subject: JEP proposed to target JDK 12: 325: Switch Expressions (Preview) Message-ID: <20180817174429.8BD3E207126@eggemoggin.niobe.net> The following JEP is proposed to target JDK 12: 325: Switch Expressions (Preview) http://openjdk.java.net/jeps/325 Feedback on this proposal is more than welcome, as are reasoned objections. If no such objections are raised by 23:00 UTC on Friday, 24 August, or if they?re raised and then satisfactorily answered, then per the JEP 2.0 process proposal [1] I?ll target this JEP to JDK 12. - Mark [1] http://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html From jonathan.gibbons at oracle.com Fri Aug 17 22:23:31 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Fri, 17 Aug 2018 15:23:31 -0700 Subject: jtreg FAQ updates In-Reply-To: <5B74BB4B.4060504@oracle.com> References: <5B74BB4B.4060504@oracle.com> Message-ID: <5B774AE3.1050902@oracle.com> I've updated the jtreg FAQ, with more details, and more questions, based on all the feedback I've received this past week. You can see the published FAQ [1], or, for those that want to see more detail on the changes, and who don't mind reading Markdown changes, you can see the recent changesets [2]. [1] http://openjdk.java.net/jtreg/faq.html [2] http://hg.openjdk.java.net/code-tools/jtreg/log?revcount=20&rev=454%3Atip+and+keyword%28%22FAQ%22%29 On 08/15/2018 04:46 PM, Jonathan Gibbons wrote: > For those of you that run jtreg, I've made some updates to the jtreg FAQ > that is available in builds of jtreg, and on the OpenJDK website. [1] > > In addition to some general cleanup, I've reorganized it a bit, to > create a > couple of new sections, "3. Using jtreg" and "5. Organizing tests". > Most of section 3 is new, although a few questions were moved from > elsewhere; > Other new questions include: > 4.19 Can I (and should I) write shell tests? > 5.5 How should I organize tests, libraries, and other test-related > files? > 5.6 Can I put more than one test in a file? > > -- Jon > > [1] http://openjdk.java.net/jtreg/faq.html > (linked under "FAQ" from the main jtreg page > http://openjdk.java.net/jtreg/) From david.holmes at oracle.com Fri Aug 17 22:43:45 2018 From: david.holmes at oracle.com (David Holmes) Date: Sat, 18 Aug 2018 08:43:45 +1000 Subject: jtreg FAQ updates In-Reply-To: <5B774AE3.1050902@oracle.com> References: <5B74BB4B.4060504@oracle.com> <5B774AE3.1050902@oracle.com> Message-ID: Hi Jon, Updates look good - thanks! One typo: +that thread group have existed. existed -> exited Cheers, David On 18/08/2018 8:23 AM, Jonathan Gibbons wrote: > I've updated the jtreg FAQ, with more details, and more questions, based > on all the feedback I've received this past week. > > You can see the published FAQ [1], or, for those that want to see more > detail on the changes, and who don't mind reading Markdown changes, you > can see the recent changesets [2]. > > [1] http://openjdk.java.net/jtreg/faq.html > [2] > http://hg.openjdk.java.net/code-tools/jtreg/log?revcount=20&rev=454%3Atip+and+keyword%28%22FAQ%22%29 > > > On 08/15/2018 04:46 PM, Jonathan Gibbons wrote: >> For those of you that run jtreg, I've made some updates to the jtreg FAQ >> that is available in builds of jtreg, and on the OpenJDK website. [1] >> >> In addition to some general cleanup, I've reorganized it a bit, to >> create a >> couple of new sections, "3. Using jtreg" and "5. Organizing tests". >> Most of section 3 is new, although a few questions were moved from >> elsewhere; >> Other new questions include: >> 4.19 Can I (and should I) write shell tests? >> 5.5? How should I organize tests, libraries, and other test-related >> files? >> 5.6? Can I put more than one test in a file? >> >> -- Jon >> >> [1]? http://openjdk.java.net/jtreg/faq.html >> (linked under "FAQ" from the main jtreg page >> http://openjdk.java.net/jtreg/) > From martijnverburg at gmail.com Sat Aug 18 09:14:50 2018 From: martijnverburg at gmail.com (Martijn Verburg) Date: Sat, 18 Aug 2018 10:14:50 +0100 Subject: What does LTS mean for OpenJDK? In-Reply-To: <8ba6b9eb-73ef-da23-e61d-d5b043ecdf32@redhat.com> References: <8ba6b9eb-73ef-da23-e61d-d5b043ecdf32@redhat.com> Message-ID: Hi all, I'll add AdoptOpenJDK's Positioning on this inline. On Fri, 17 Aug 2018 at 18:33, Andrew Haley wrote: > On 08/17/2018 05:36 PM, Stephen Colebourne wrote: > > The LTS (long term support) release Java 11 is nearly upon us. But > > what does LTS mean in the context of OpenJDK? I'd like to try to get a > > clear statement of fact in written form, particularly from Oracle. > > I have been discussing with some other organizations sharing the > burden of supporting jdk11, and we'll make a public statement when > we're ready. Before then, I'll say what I can. > > OpenJDK is a community project. It's up to the community to support > it. In practice this means that a group of organizations and > individuals will maintain each OpenJDK LTS release for some period > (TBA for 11, but it's sure to be a *lot* longer than six months.) I am > certain that there will be a jdk11u project, and it will be properly > and professionally run. I think it's likely that I'll be leading the > project, but someone else may be chosen. Given that we don't know when > Oracle will end their support it's hard to say any more. > Completely agree with this and in a way this is positive thing for OpenJDK. I see a lot more organisations and individuals now committing, or seriously thinking about committing extra engineering folks and $$ into OpenJDK. I think it's fair to say that Oracle has shouldered the majority of the burden (thanks Oracle!) for a long time and it'll be good for everyone if that burden is shared more evenly than it has been. As part of the discussions Andrew mentioned, AdoptOpenJDK offered to build, test and make available OpenJDK LTS binaries for the major (and several minor) platforms. This isn't yet set in concrete but folks broadly thought that was a good idea. So the challenge of having a build and test farm for this joint effort is solved. ---- Some extra statements: AdoptOpenJDK will not offer commercial support. AdoptOpenJDK will take and triage bug reports but will send those bug reports to the appropriate upstream project (OpenJDK, Eclipse OpenJ9, SAPMachine etc) unless it was an AdoptOpenJDK build / test / infra issue. AdoptOpenJDK *as an entity* will not be backporting patches, i.e. There won't be an AdoptOpenJDK 'fork/version' that is materially different from upstream (except for some build script patches for things like Win32 support). However, I imagine many of the volunteers (a chunk of who are OpenJDK authors / committers / reviewers) will join in the jdk11u project / effort that Andrew mentioned, so you'll see crossover of people. We think Andrew is the eminently sensible choice to lead jdk11u and there were more than enough organisations and individuals that indicated they would commit real long term engineering support. I'm personally very comfortable that we'll have a successful, professionally run jdk11u project from Oracle and then subsequently by others (most likely lead by Andrew). For the rest AdoptOpenJDK is adding more robustness, security and testing support to the build farm so we'll be ready when jdk11u requires that service. We welcome more contributors with those slightly rarer skill sets of bash scripting, ansible and other devops style languages and tooling. > > Java 10 has had public $free support, with two security updates over 6 > > months and pre-built binaries at http://jdk.java.net/10/ > > > > What will Java 11 get from Oracle? > > - 6 months of public $free updates with binaries published at > > http://jdk.java.net > > - 3 years of public $free updates with binaries published at > http://jdk.java.net > > - something else? > > > > Note! The request is about $free pre-built binaries ready for > > download. We all know people can pay money for support to multiple > > vendors. > > > > > > Is any other group (eg. AdoptOpenJDK, RedHat) planning on providing > > security patched pre-built binaries for $free? If so, for how long? > > Red Hat is committed to support OpenJDK for its customers for some > time. Our policy for current versions can be seen at > > https://access.redhat.com/articles/1299013#OpenJDK_Lifecycle_Dates_and_RHEL_versions > > Given that Red Hat has an upstream first policy, we will make sure > that all security patches are applied to upstream OpenJDK releases and > our builds are TCK'd. > > With regard to providing binaries, I'm aware that any jdkll update > project after Oracle ceases to support it will need to provide > binaries for several platforms. (java.net is Oracle's proprietary > site, so it doesn't make any sense to put them there.) The project > will decide exactly where to put those binaries, but in my opinion as > long as they are properly authenticated and easy to get it doesn't > really matter. > > Finally, please let me assure you of one thing: whether by Oracle or > Red Hat or someone else, JDK LTS releases will continue to be > supported. We all have a lot invested in Java, and we won't let it > fall. > --- AdoptOpenJDK's current support policy is listed here: https://adoptopenjdk.net/support.html As an extra clarification, support means "We'll keep building the binaries". As mentioned previously AdoptOpenJDK won't as an organization be backporting patches to jdk11u, but several of our volunteers will be participating in that effort. I'll echo Andrew's comment that lots of folks including Oracle are heavily invested in Java. As an example, the AdoptOpenJDK build farm has >300 volunteers from established OpenJDK organisations as well as new folks who came together when they saw a need for collaborating around OpenJDK binary production. HTH - happy to answer any follow up questions. Cheers, Martijn > > > Please provide links. > > Hmph. > > -- > Andrew Haley > Java Platform Lead Engineer > Red Hat UK Ltd. > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 > From scolebourne at joda.org Sun Aug 19 19:03:57 2018 From: scolebourne at joda.org (Stephen Colebourne) Date: Sun, 19 Aug 2018 20:03:57 +0100 Subject: What does LTS mean for OpenJDK? In-Reply-To: References: <8ba6b9eb-73ef-da23-e61d-d5b043ecdf32@redhat.com> Message-ID: Thanks Mark, Andrew, Martijn, Its good to see things coming together. Having $free pre-built Java 11 binaries for at least 3 years from at least one source is key to the success of the ecosystem going forward. If I understand correctly there will be no public $free Oracle JDK for 11 at all. As such developers will be using the OpenJDK build at http://jdk.java.net . I think this is fine, although it will surprise some no doubt. However, this is only during the first 6 months of Java 11. After that developers wanting the $free 11 binaries have to go to some other site. This inconsistency (changing where to find the download) does not seem great to me Would an OpenJDK equivalent of http://jdk.java.net clearly attached to and linked from OpenJDK itself be a suitable solution to the problem? thanks Stephen On Sat, 18 Aug 2018 at 10:15, Martijn Verburg wrote: > > Hi all, > > I'll add AdoptOpenJDK's Positioning on this inline. > > On Fri, 17 Aug 2018 at 18:33, Andrew Haley wrote: >> >> On 08/17/2018 05:36 PM, Stephen Colebourne wrote: >> > The LTS (long term support) release Java 11 is nearly upon us. But >> > what does LTS mean in the context of OpenJDK? I'd like to try to get a >> > clear statement of fact in written form, particularly from Oracle. >> >> I have been discussing with some other organizations sharing the >> burden of supporting jdk11, and we'll make a public statement when >> we're ready. Before then, I'll say what I can. >> >> OpenJDK is a community project. It's up to the community to support >> it. In practice this means that a group of organizations and >> individuals will maintain each OpenJDK LTS release for some period >> (TBA for 11, but it's sure to be a *lot* longer than six months.) I am >> certain that there will be a jdk11u project, and it will be properly >> and professionally run. I think it's likely that I'll be leading the >> project, but someone else may be chosen. Given that we don't know when >> Oracle will end their support it's hard to say any more. > > > Completely agree with this and in a way this is positive thing for OpenJDK. I see a lot more organisations and > individuals now committing, or seriously thinking about committing extra engineering folks and $$ into OpenJDK. > I think it's fair to say that Oracle has shouldered the majority of the burden (thanks Oracle!) for a long time and it'll be > good for everyone if that burden is shared more evenly than it has been. > > As part of the discussions Andrew mentioned, AdoptOpenJDK offered to build, test and make available OpenJDK > LTS binaries for the major (and several minor) platforms. This isn't yet set in concrete but folks broadly thought that > was a good idea. So the challenge of having a build and test farm for this joint effort is solved. > > ---- > Some extra statements: > > AdoptOpenJDK will not offer commercial support. AdoptOpenJDK will take and triage bug reports but will > send those bug reports to the appropriate upstream project (OpenJDK, Eclipse OpenJ9, SAPMachine etc) > unless it was an AdoptOpenJDK build / test / infra issue. > > AdoptOpenJDK *as an entity* will not be backporting patches, i.e. There won't be an AdoptOpenJDK 'fork/version' > that is materially different from upstream (except for some build script patches for things like Win32 support). However, > I imagine many of the volunteers (a chunk of who are OpenJDK authors / committers / reviewers) will join in the jdk11u project > / effort that Andrew mentioned, so you'll see crossover of people. > > We think Andrew is the eminently sensible choice to lead jdk11u and there were more than enough organisations and individuals > that indicated they would commit real long term engineering support. I'm personally very comfortable that we'll have a > successful, professionally run jdk11u project from Oracle and then subsequently by others (most likely lead by Andrew). > > For the rest AdoptOpenJDK is adding more robustness, security and testing support to the build farm so we'll be ready when jdk11u > requires that service. We welcome more contributors with those slightly rarer skill sets of bash scripting, ansible and other devops > style languages and tooling. > >> >> > Java 10 has had public $free support, with two security updates over 6 >> > months and pre-built binaries at http://jdk.java.net/10/ >> > >> > What will Java 11 get from Oracle? >> > - 6 months of public $free updates with binaries published at >> > http://jdk.java.net >> > - 3 years of public $free updates with binaries published at http://jdk.java.net >> > - something else? >> > >> > Note! The request is about $free pre-built binaries ready for >> > download. We all know people can pay money for support to multiple >> > vendors. >> > >> > >> > Is any other group (eg. AdoptOpenJDK, RedHat) planning on providing >> > security patched pre-built binaries for $free? If so, for how long? >> >> Red Hat is committed to support OpenJDK for its customers for some >> time. Our policy for current versions can be seen at >> https://access.redhat.com/articles/1299013#OpenJDK_Lifecycle_Dates_and_RHEL_versions >> >> Given that Red Hat has an upstream first policy, we will make sure >> that all security patches are applied to upstream OpenJDK releases and >> our builds are TCK'd. >> >> With regard to providing binaries, I'm aware that any jdkll update >> project after Oracle ceases to support it will need to provide >> binaries for several platforms. (java.net is Oracle's proprietary >> site, so it doesn't make any sense to put them there.) The project >> will decide exactly where to put those binaries, but in my opinion as >> long as they are properly authenticated and easy to get it doesn't >> really matter. >> >> Finally, please let me assure you of one thing: whether by Oracle or >> Red Hat or someone else, JDK LTS releases will continue to be >> supported. We all have a lot invested in Java, and we won't let it >> fall. > > > --- > > AdoptOpenJDK's current support policy is listed here: https://adoptopenjdk.net/support.html > > As an extra clarification, support means "We'll keep building the binaries". As mentioned previously > AdoptOpenJDK won't as an organization be backporting patches to jdk11u, but several of our volunteers > will be participating in that effort. > > I'll echo Andrew's comment that lots of folks including Oracle are heavily invested in Java. As an example, > the AdoptOpenJDK build farm has >300 volunteers from established OpenJDK organisations as well as > new folks who came together when they saw a need for collaborating around OpenJDK binary production. > > HTH - happy to answer any follow up questions. > > Cheers, > Martijn > >> >> >> > Please provide links. >> >> Hmph. >> >> -- >> Andrew Haley >> Java Platform Lead Engineer >> Red Hat UK Ltd. >> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From aph at redhat.com Sun Aug 19 20:02:40 2018 From: aph at redhat.com (Andrew Haley) Date: Sun, 19 Aug 2018 21:02:40 +0100 Subject: What does LTS mean for OpenJDK? In-Reply-To: References: <8ba6b9eb-73ef-da23-e61d-d5b043ecdf32@redhat.com> Message-ID: On 08/19/2018 08:03 PM, Stephen Colebourne wrote: > However, this is only during the first 6 months of Java 11. After that > developers wanting the $free 11 binaries have to go to some other > site. This inconsistency (changing where to find the download) does > not seem great to me Would an OpenJDK equivalent of > http://jdk.java.net clearly attached to and linked from OpenJDK itself > be a suitable solution to the problem? Probably, yes. We'll work something out. I certainly welcome that the official OpenJDK binaries won't necessarily come only from Oracle, but from some place (or probably places) agreed by the whole community. In the long run it's better that people think of Java as not something given by "them" but created by us as a shared endeavor. Java is a huge deal, and by working together we safeguard its future for as long as people need it. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From dalibor.topic at oracle.com Mon Aug 20 13:23:42 2018 From: dalibor.topic at oracle.com (dalibor topic) Date: Mon, 20 Aug 2018 15:23:42 +0200 Subject: What does LTS mean for OpenJDK? In-Reply-To: References: Message-ID: <4350b6f9-d169-359e-d278-b31220a3d03b@oracle.com> On 17.08.2018 18:36, Stephen Colebourne wrote: > The LTS (long term support) release Java 11 is nearly upon us. But > what does LTS mean in the context of OpenJDK? Please see http://openjdk.java.net/jeps/322 "If a release is part of a series of releases for which an implementor offers long-term support then the value of $OPT should start with "LTS", e.g., 11.0.2+13-LTS. This will cause "LTS" to be displayed prominently in the output of java --version, etc." Whether an implementor decides to offer long term support for a given OpenJDK release, for how long they do it, which platforms they chose to support in this way, is ultimately up to them. So far Oracle, for example, has cumulatively contributed almost 15 years of maintenance to OpenJDK between OpenJDK 6, JDK 7 Updates, JDK 8 Updates, JDK 9 updates and JDK 10 updates across a lot of different OS/CPU platforms. Over the last couple of years, we have developed a model to transition between different teams of maintainers across OpenJDK update releases. For example, Oracle developers maintained OpenJDK 6 for 5 years. After they stepped down, they enabled other developers to take over OpenJDK 6 maintenance. Those developers, focusing on a different set of operating systems from Oracle developers, continued to work on the OpenJDK 6 source code until, eventually, they stopped. Then another set of developers continued where they left, with yet again a different set of operating systems that they cared about. A similar transition has happened with OpenJDK 7 Updates, after almost 4 years of maintenance by Oracle developers. A similar transition would also happen for OpenJDK 8 Updates after January 2019, assuming that a suitable Project Lead steps forward to carry on the maintenance work led by Oracle developers since 2014. Since such transitions are bound to happen more often under the new release cycle, there is a process for them in the JDK Updates Project as described in http://mail.openjdk.java.net/pipermail/jdk-updates-dev/2018-February/000064.html . You can observe that process in the works via the jdk-updates-dev mailing list, specifically with respect to JDK 10 maintenance via http://mail.openjdk.java.net/pipermail/jdk-updates-dev/2018-July/000143.html . > What will Java 11 get from Oracle? Well, long term support, for one, as discussed on http://www.oracle.com/technetwork/java/eol-135779.html . But beside that, it will get a reference implementation in OpenJDK. Followed by, assuming that the transition from JDK 10 to JDK 11 proves to be as smooth as the transition from JDK 9 to JDK 10 was, at least six months of JDK 11 updates maintained by Oracle developers and contributed to the corresponding OpenJDK JDK Updates Project jdk11u repository along with binaries being published at http://jdk.java.net. Finally, JDK 11 would get an orderly maintainer transition process. Specifically, at some point after a jdk11u repo is established in the JDK Updates Project, an e-mail to jdk-updates-dev would announce when Oracle would stop contributing to that particular repository. For JDK 10, it looked like this: http://mail.openjdk.java.net/pipermail/jdk-updates-dev/2018-May/000128.html . After the last OpenJDK JDK 11u release led by Oracle, a call for future 11u maintainers such as http://mail.openjdk.java.net/pipermail/jdk-updates-dev/2018-July/000143.html would go out on the jdk-updates-dev list, and, if someone qualified stepped up on the list, there would be some work to do on an orderly transition of maintainer duties for that repo within the JDK Update Project - rather unexciting things like dealing with updates to hgcheck and jcheck configurations for the repo, for example. You can read the jdk7u-dev mailing list archives from the time of transition, if you want to know the details. Some details will of course end up being slightly different for JDK 11 Updates, since we will use the existing JDK Updates Project for jdk11u, we'll have a single repo instead of a forest, and so on. cheers, dalibor topic -- Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile: +491737185961 ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher Oracle is committed to developing practices and products that help protect the environment From netbeans at post.cz Wed Aug 22 09:16:53 2018 From: netbeans at post.cz (netbeans at post.cz) Date: Wed, 22 Aug 2018 11:16:53 +0200 (CEST) Subject: Reaction to JEP 325/JDK-8192963 Message-ID: <6ZF.3VYTp.vO3EHMXVcI.1RVIe5@seznam.cz> Dear JDK dev. Let me react to JEP 325 (Switch Expressions)?and related https://bugs. openjdk.java.net/browse/JDK-8192963 (https://bugs.openjdk.java.net/browse/JDK-8192963)?as I do know what it is background for this, but could that be fixed more like?syntactic sugar? int value = switch(day) -> { ?? case 1: ???? return 1; ?? case 2: ???? return 2: ?? ... }; as de-sugar: ((Function)(arg) -> {?????????? ?????????? switch(arg) {??????????? ?????????????? case 1 : ?????????????????? return 1; ?????????????? case 2 : ?????????????????? return 2; ?????????????? default: ?????????????????? return 3;????????????????? ?????????? }??????????? }).apply(1); Have a nice. From scolebourne at joda.org Thu Aug 23 12:16:25 2018 From: scolebourne at joda.org (Stephen Colebourne) Date: Thu, 23 Aug 2018 13:16:25 +0100 Subject: JEP proposed to target JDK 12: 325: Switch Expressions (Preview) In-Reply-To: <20180817174429.8BD3E207126@eggemoggin.niobe.net> References: <20180817174429.8BD3E207126@eggemoggin.niobe.net> Message-ID: As I have expressed previously on amber-dev, I find the design adopted here to be overly complex and with a poor syntax choice. There are aspects to like, and the proposal is better than earlier versions. I also acknowledge that this is a proposal to create a preview language feature, however in all likelihood, there will be no further changes to the syntax/design once integrated as a preview. Some specific objections: (FYI, "classic" uses colon and has fallthrough-by-default, "enhanced" uses arrow -> and does not allow fall-through). - the original goal was to add one new language feature (expression switch), yet the solution adds three (classic expression switch, enhanced statement switch & enhanced expression switch). This unnecessarily complicates Java for little gain IMO. - all the evidence I've seen suggests that fallback in switch is very rare, and I'd strongly argue that most developers consider fallthrough-by-default to be a poor feature of Java. Adding a new language feature (classic expression switch) which adds more fallthrough-by-default is a mistake IMO. It is likely that style guides and best practice will recommend against using classic expression switch. I do not accept that consistency ("it makes a 2x2 grid") is a sufficient reason to add a new language feature that will effectively be dead on arrival. - the use of -> as the separator in enhanced switch is undesirable IMO. Objections to the syntax have also been made by some expert group members. The particular problem is that it means something different to the use of -> in lambda expressions. This can result in confusing semi-puzzlers, such as "case RED -> YELLOW -> 6";. - the vast majority of existing switch statements would be more safely expressed using the enhanced form. As such, the enhanced form effectively replaces the classic form in Java - its that much better that classic statement switch will just be abandoned by developers IMO. Given this and the pointlessness of adding classic expression switch, the argument for using the keyword `switch` for the enhanced forms is weak IMO. At my presentations on the topic, the vast majority of developers have come to the conclusion that the enhanced form should use a different keyword, for example `match`, not `switch`. Doing so allows the colon to be used instead of the arrow: var name = match (trafficLight) { case RED: "Red"; case YELLOW: "Yellow"; case GREEN: "Green"; }; - Adding a new keyword/symbol for the expression form (and potentially declaring it an ExpressionStatement instead of having a separate statement form) would IMO be a simpler approach to the problem space, potentially adding just 1 new form rather than 3 as proposed by the JEP. In summary, the world will not end if the JEP 325 progresses, and this proposal is much better than previous ones. However I believe that by taking the route of expanding `switch` rather than using a different keyword/symbol the result has been greater complexity than is necessary to meet the actual goal of "expression switch". thanks Stephen On 17 August 2018 at 18:44, wrote: > The following JEP is proposed to target JDK 12: > > 325: Switch Expressions (Preview) > http://openjdk.java.net/jeps/325 > > Feedback on this proposal is more than welcome, as are reasoned > objections. If no such objections are raised by 23:00 UTC on Friday, > 24 August, or if they?re raised and then satisfactorily answered, then > per the JEP 2.0 process proposal [1] I?ll target this JEP to JDK 12. > > - Mark > > > [1] http://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html From jacks at fasterj.com Thu Aug 23 13:24:36 2018 From: jacks at fasterj.com (Jack Shirazi) Date: Thu, 23 Aug 2018 14:24:36 +0100 Subject: What does LTS mean for OpenJDK? Message-ID: <3092aff1-5568-8828-f7a7-7a514b06f9b5@fasterj.com> Hello Awesome People, There is (still) a lot of confusion in the community about this. Can I give an example of how I understand this to proceed and please comment if wrong (I appreciate not set in stone, this is just an example of how it seems likely from my understanding atm): Let's say Java 12 has been released and Oracle announce a security upgrade. Oracle will apply that to their paid-for Oracle Java 11 build, and also to the OpenJDK Java 12 build but NOT the latest OpenJDK Java 11 build. AdoptOpenJDK will also NOT backport that to the OpenJDK Java 11 build. However the jdk11u project WILL backport that to the OpenJDK Java 11 build, and AdoptOpenJDK will then support that Java 11 upgraded version because it will continue to support Java 11, so that upgraded OpenJDK Java 11 build will then be available (somewhere) for public consumption. Cheers, Jack --- This email has been checked for viruses by AVG. https://www.avg.com From robert.zenz at sibvisions.com Thu Aug 23 13:39:33 2018 From: robert.zenz at sibvisions.com (Robert Zenz) Date: Thu, 23 Aug 2018 13:39:33 +0000 Subject: JEP proposed to target JDK 12: 325: Switch Expressions (Preview) In-Reply-To: <20180817174429.8BD3E207126@eggemoggin.niobe.net> References: <20180817174429.8BD3E207126@eggemoggin.niobe.net> Message-ID: <5B7EB915.8070204@sibvisions.com> Wasn't one of the original complaints about the `switch` statement its `null` behavior? I'm not seeing that addressed in the JEP, neither for the statement nor for the expression. I mean, the following fails with a `NullPointerException`: MyEnum value = null; switch(value) { case MyEnum.A: // Do something break; } I'm not seeing outlined in the JEP how the expression would react to that: MyEnum value = null; int result = switch(value) { case MyEnum.A -> 5; } Also, while we are at that topic, I could not find a JEP for actually fixing the `switch` statement behavior to correctly handle `null`. Has somebody seen one? As an idea for that, something like this should preserve backwards compatibility: MyEnum value = null; // Fails with a NullPointerException switch(value) { case MyEnum.A: // Do something break; } // Succeeds switch(value) { case MyEnum.A: // Do something break; case null: // Do something else. break; } If I'm not mistaken, that is. On 17.08.2018 19:44, mark.reinhold at oracle.com wrote: > The following JEP is proposed to target JDK 12: > > 325: Switch Expressions (Preview) > http://openjdk.java.net/jeps/325 > > Feedback on this proposal is more than welcome, as are reasoned > objections. If no such objections are raised by 23:00 UTC on Friday, > 24 August, or if they?re raised and then satisfactorily answered, then > per the JEP 2.0 process proposal [1] I?ll target this JEP to JDK 12. > > - Mark > > > [1] http://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html > From scolebourne at joda.org Thu Aug 23 14:11:49 2018 From: scolebourne at joda.org (Stephen Colebourne) Date: Thu, 23 Aug 2018 15:11:49 +0100 Subject: JEP proposed to target JDK 12: 325: Switch Expressions (Preview) In-Reply-To: <5B7EB915.8070204@sibvisions.com> References: <20180817174429.8BD3E207126@eggemoggin.niobe.net> <5B7EB915.8070204@sibvisions.com> Message-ID: Null handling was deferred. I believe this is the current spec http://cr.openjdk.java.net/~gbierman/switch-expressions.html (I support the rationale for deferring nulls, see amber-dev/amber-spec-experts) Stephen On 23 August 2018 at 14:39, Robert Zenz wrote: > Wasn't one of the original complaints about the `switch` statement its `null` > behavior? I'm not seeing that addressed in the JEP, neither for the statement > nor for the expression. > > I mean, the following fails with a `NullPointerException`: > > MyEnum value = null; > > switch(value) { > case MyEnum.A: > // Do something > break; > } > > I'm not seeing outlined in the JEP how the expression would react to that: > > MyEnum value = null; > > int result = switch(value) { > case MyEnum.A -> 5; > } > > Also, while we are at that topic, I could not find a JEP for actually fixing the > `switch` statement behavior to correctly handle `null`. Has somebody seen one? > > As an idea for that, something like this should preserve backwards compatibility: > > MyEnum value = null; > > // Fails with a NullPointerException > switch(value) { > case MyEnum.A: > // Do something > break; > } > > // Succeeds > switch(value) { > case MyEnum.A: > // Do something > break; > > case null: > // Do something else. > break; > } > > If I'm not mistaken, that is. > > > On 17.08.2018 19:44, mark.reinhold at oracle.com wrote: >> The following JEP is proposed to target JDK 12: >> >> 325: Switch Expressions (Preview) >> http://openjdk.java.net/jeps/325 >> >> Feedback on this proposal is more than welcome, as are reasoned >> objections. If no such objections are raised by 23:00 UTC on Friday, >> 24 August, or if they?re raised and then satisfactorily answered, then >> per the JEP 2.0 process proposal [1] I?ll target this JEP to JDK 12. >> >> - Mark >> >> >> [1] http://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html >> From benjamin.john.evans at gmail.com Thu Aug 23 15:58:29 2018 From: benjamin.john.evans at gmail.com (Ben Evans) Date: Thu, 23 Aug 2018 11:58:29 -0400 Subject: JEP proposed to target JDK 12: 325: Switch Expressions (Preview) In-Reply-To: References: <20180817174429.8BD3E207126@eggemoggin.niobe.net> Message-ID: I tend to agree with Stephen. In particular, as Brian has so correctly pointed out, most Java developers over-focus on syntax. Therefore, it seems likely that, despite marking a syntax-introducing feature as Preview, early adopters will come to rely on it, and even put code that uses it into production. This then raises the barrier to change the syntax of the Preview Feature. This seems to me to be more pronounced in the case of core language features, as opposed to incubator libraries and modules (e.g. the HTTP client). I also want to ask about the balance we're striking between existing Java developers and newcomers. I would argue that existing Java developers really don't care whether we have a new keyword ('match') for an expression form providing equivalent functionality to a switch statement - existing code needs to be refactored in either case to take advantage of the new capability. On the other hand, I've also been spending a lot of time teaching newcomers to the Java lanaguage over the last year. Given how my students have struggled with default fallthrough, I can't see how introducing a syntax form where the fallthrough behaviour depends upon a minor syntax variation of the switch label is anything other than a compounding of the original sin of importing default fallthrough from C/C++. A separate keyword makes it entirely clear that this is a different language feature and so different behaviour is to be expected. I like this version of the proposal better than previous discussions, but I'm sure in my own mind that as proposed it will be a source of new bugs that could be avoided. By introducing a new keyword we can maintain a clean split between the legacy switch and a syntax that can be cleanly upgraded to full match expressions over subsequent Java versions (which is actually a much better fit, to my mind, to the Preview Feature mechanism). Thanks, Ben On Thu, 23 Aug 2018 at 08:18, Stephen Colebourne wrote: > > As I have expressed previously on amber-dev, I find the design adopted > here to be overly complex and with a poor syntax choice. There are > aspects to like, and the proposal is better than earlier versions. I > also acknowledge that this is a proposal to create a preview language > feature, however in all likelihood, there will be no further changes > to the syntax/design once integrated as a preview. > > Some specific objections: > > (FYI, "classic" uses colon and has fallthrough-by-default, "enhanced" > uses arrow -> and does not allow fall-through). > > - the original goal was to add one new language feature (expression > switch), yet the solution adds three (classic expression switch, > enhanced statement switch & enhanced expression switch). This > unnecessarily complicates Java for little gain IMO. > > - all the evidence I've seen suggests that fallback in switch is very > rare, and I'd strongly argue that most developers consider > fallthrough-by-default to be a poor feature of Java. Adding a new > language feature (classic expression switch) which adds more > fallthrough-by-default is a mistake IMO. It is likely that style > guides and best practice will recommend against using classic > expression switch. I do not accept that consistency ("it makes a 2x2 > grid") is a sufficient reason to add a new language feature that will > effectively be dead on arrival. > > - the use of -> as the separator in enhanced switch is undesirable > IMO. Objections to the syntax have also been made by some expert group > members. The particular problem is that it means something different > to the use of -> in lambda expressions. This can result in confusing > semi-puzzlers, such as "case RED -> YELLOW -> 6";. > > - the vast majority of existing switch statements would be more safely > expressed using the enhanced form. As such, the enhanced form > effectively replaces the classic form in Java - its that much better > that classic statement switch will just be abandoned by developers > IMO. Given this and the pointlessness of adding classic expression > switch, the argument for using the keyword `switch` for the enhanced > forms is weak IMO. At my presentations on the topic, the vast majority > of developers have come to the conclusion that the enhanced form > should use a different keyword, for example `match`, not `switch`. > Doing so allows the colon to be used instead of the arrow: > > var name = match (trafficLight) { > case RED: "Red"; > case YELLOW: "Yellow"; > case GREEN: "Green"; > }; > > - Adding a new keyword/symbol for the expression form (and potentially > declaring it an ExpressionStatement instead of having a separate > statement form) would IMO be a simpler approach to the problem space, > potentially adding just 1 new form rather than 3 as proposed by the > JEP. > > > In summary, the world will not end if the JEP 325 progresses, and this > proposal is much better than previous ones. However I believe that by > taking the route of expanding `switch` rather than using a different > keyword/symbol the result has been greater complexity than is > necessary to meet the actual goal of "expression switch". > > thanks > Stephen > > > On 17 August 2018 at 18:44, wrote: > > The following JEP is proposed to target JDK 12: > > > > 325: Switch Expressions (Preview) > > http://openjdk.java.net/jeps/325 > > > > Feedback on this proposal is more than welcome, as are reasoned > > objections. If no such objections are raised by 23:00 UTC on Friday, > > 24 August, or if they?re raised and then satisfactorily answered, then > > per the JEP 2.0 process proposal [1] I?ll target this JEP to JDK 12. > > > > - Mark > > > > > > [1] http://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html From forax at univ-mlv.fr Thu Aug 23 16:13:14 2018 From: forax at univ-mlv.fr (Remi Forax) Date: Thu, 23 Aug 2018 18:13:14 +0200 (CEST) Subject: JEP proposed to target JDK 12: 325: Switch Expressions (Preview) In-Reply-To: References: <20180817174429.8BD3E207126@eggemoggin.niobe.net> Message-ID: <910726811.616575.1535040794161.JavaMail.zimbra@u-pem.fr> Stephen, We do not need to introduce a new expression form because we already have the arrow syntax and we do not need another keyword because we want to retrofit old switches. We have two goals: 1. We want to get ride of the existing scope rules and to disallow fallthrough, and even more than that, we want to allow users to be able to retrofit their old switch statement which doesn't fallthrough (so using another keyword than switch doesn't help). 2. There is a need for a statement that can have an expression as result, we re-use the arrow syntax of the lambda because it's exactly a statement expression and it already exists in the language*. In these statements, using return means returning from the method hence the break expression. So you have a 2x2 matrix, a switch - is an expression or not - disallow fallthrough or not Apart from the statement switch and the expression switch, we have two others possibilities, a statement switch with no fallthrough (we want that) and an expression switch with fallthrough, you may not like this option but it allows to retrofit an old switch with fallthrough to be expression oriented, thus using a more functional style of writing. regards, R?mi * you right that reusing -> can be confusing because until now you have only see -> in the context of a lambda. The other way to see that issue is to say that allowing to not have the parenthesis for a lambda with one parameter was a design mistake. Because it blurs the difference between an arrow statement and a lambda because the parameters of the lambda are not clearly visible. ----- Mail original ----- > De: "Stephen Colebourne" > ?: "jdk-dev" > Envoy?: Jeudi 23 Ao?t 2018 14:16:25 > Objet: Re: JEP proposed to target JDK 12: 325: Switch Expressions (Preview) > As I have expressed previously on amber-dev, I find the design adopted > here to be overly complex and with a poor syntax choice. There are > aspects to like, and the proposal is better than earlier versions. I > also acknowledge that this is a proposal to create a preview language > feature, however in all likelihood, there will be no further changes > to the syntax/design once integrated as a preview. > > Some specific objections: > > (FYI, "classic" uses colon and has fallthrough-by-default, "enhanced" > uses arrow -> and does not allow fall-through). > > - the original goal was to add one new language feature (expression > switch), yet the solution adds three (classic expression switch, > enhanced statement switch & enhanced expression switch). This > unnecessarily complicates Java for little gain IMO. > > - all the evidence I've seen suggests that fallback in switch is very > rare, and I'd strongly argue that most developers consider > fallthrough-by-default to be a poor feature of Java. Adding a new > language feature (classic expression switch) which adds more > fallthrough-by-default is a mistake IMO. It is likely that style > guides and best practice will recommend against using classic > expression switch. I do not accept that consistency ("it makes a 2x2 > grid") is a sufficient reason to add a new language feature that will > effectively be dead on arrival. > > - the use of -> as the separator in enhanced switch is undesirable > IMO. Objections to the syntax have also been made by some expert group > members. The particular problem is that it means something different > to the use of -> in lambda expressions. This can result in confusing > semi-puzzlers, such as "case RED -> YELLOW -> 6";. > > - the vast majority of existing switch statements would be more safely > expressed using the enhanced form. As such, the enhanced form > effectively replaces the classic form in Java - its that much better > that classic statement switch will just be abandoned by developers > IMO. Given this and the pointlessness of adding classic expression > switch, the argument for using the keyword `switch` for the enhanced > forms is weak IMO. At my presentations on the topic, the vast majority > of developers have come to the conclusion that the enhanced form > should use a different keyword, for example `match`, not `switch`. > Doing so allows the colon to be used instead of the arrow: > > var name = match (trafficLight) { > case RED: "Red"; > case YELLOW: "Yellow"; > case GREEN: "Green"; > }; > > - Adding a new keyword/symbol for the expression form (and potentially > declaring it an ExpressionStatement instead of having a separate > statement form) would IMO be a simpler approach to the problem space, > potentially adding just 1 new form rather than 3 as proposed by the > JEP. > > > In summary, the world will not end if the JEP 325 progresses, and this > proposal is much better than previous ones. However I believe that by > taking the route of expanding `switch` rather than using a different > keyword/symbol the result has been greater complexity than is > necessary to meet the actual goal of "expression switch". > > thanks > Stephen > > > On 17 August 2018 at 18:44, wrote: >> The following JEP is proposed to target JDK 12: >> >> 325: Switch Expressions (Preview) >> http://openjdk.java.net/jeps/325 >> >> Feedback on this proposal is more than welcome, as are reasoned >> objections. If no such objections are raised by 23:00 UTC on Friday, >> 24 August, or if they?re raised and then satisfactorily answered, then >> per the JEP 2.0 process proposal [1] I?ll target this JEP to JDK 12. >> >> - Mark >> >> > > [1] http://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html From martijnverburg at gmail.com Thu Aug 23 16:50:17 2018 From: martijnverburg at gmail.com (Martijn Verburg) Date: Thu, 23 Aug 2018 17:50:17 +0100 Subject: What does LTS mean for OpenJDK? In-Reply-To: <3092aff1-5568-8828-f7a7-7a514b06f9b5@fasterj.com> References: <3092aff1-5568-8828-f7a7-7a514b06f9b5@fasterj.com> Message-ID: Hi Jack, That?s the plan that AdoptOpenJDK and the potential (post Oracle) lead/contributors for 11u are working towards yes! Cheers, Martijn On Thu, 23 Aug 2018 at 14:25, Jack Shirazi wrote: > Hello Awesome People, > > There is (still) a lot of confusion in the community about this. Can I > give an example of how I understand this to proceed and please comment > if wrong (I appreciate not set in stone, this is just an example of how > it seems likely from my understanding atm): > > Let's say Java 12 has been released and Oracle announce a security > upgrade. Oracle will apply that to their paid-for Oracle Java 11 build, > and also to the OpenJDK Java 12 build but NOT the latest OpenJDK Java 11 > build. AdoptOpenJDK will also NOT backport that to the OpenJDK Java 11 > build. However the jdk11u project WILL backport that to the OpenJDK Java > 11 build, and AdoptOpenJDK will then support that Java 11 upgraded > version because it will continue to support Java 11, so that upgraded > OpenJDK Java 11 build will then be available (somewhere) for public > consumption. > > Cheers, Jack > > > --- > This email has been checked for viruses by AVG. > https://www.avg.com > > -- Cheers, Martijn (Sent from Gmail Mobile) From mark.reinhold at oracle.com Thu Aug 23 16:56:13 2018 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Thu, 23 Aug 2018 09:56:13 -0700 Subject: What does LTS mean for OpenJDK? In-Reply-To: <3092aff1-5568-8828-f7a7-7a514b06f9b5@fasterj.com> References: <3092aff1-5568-8828-f7a7-7a514b06f9b5@fasterj.com> Message-ID: <20180823095613.605970009@eggemoggin.niobe.net> 2018/8/23 6:24:36 -0700, Jack Shirazi : > There is (still) a lot of confusion in the community about this. Can I > give an example of how I understand this to proceed and please comment > if wrong (I appreciate not set in stone, this is just an example of how > it seems likely from my understanding atm): > > Let's say Java 12 has been released and Oracle announce a security > upgrade. Oracle will apply that to their paid-for Oracle Java 11 build, > and also to the OpenJDK Java 12 build but NOT the latest OpenJDK Java 11 > build. Correct, assuming that this happens within six months of the release of JDK 12. > AdoptOpenJDK will also NOT backport that to the OpenJDK Java 11 > build. However the jdk11u project WILL backport that to the OpenJDK Java > 11 build, and AdoptOpenJDK will then support that Java 11 upgraded > version because it will continue to support Java 11, so that upgraded > OpenJDK Java 11 build will then be available (somewhere) for public > consumption. As Andrew noted earlier in this thread, a good number of individuals and organizations appear to be interested in working on OpenJDK LTS releases, but there are no specific plans as yet. Stay tuned. - Mark From martijnverburg at gmail.com Thu Aug 23 17:25:57 2018 From: martijnverburg at gmail.com (Martijn Verburg) Date: Thu, 23 Aug 2018 18:25:57 +0100 Subject: What does LTS mean for OpenJDK? In-Reply-To: <20180823095613.605970009@eggemoggin.niobe.net> References: <3092aff1-5568-8828-f7a7-7a514b06f9b5@fasterj.com> <20180823095613.605970009@eggemoggin.niobe.net> Message-ID: Hi all, Wouldn?t normally post this on an OpenJDK mailing list but I will add that there is now a new era of commercial support for Java coming in off the back of this. Oracle and others have put out what I think are very reasonable support offerings and perhaps as an ecosystem we need to start thinking about directly contributing back if we don?t have direct engineering involved in OpenJDK/Java. I appreciate it?s a step change for those who have been used to $free - but I?d encourage folks to look at those options as well as what might come out of the community for OpenJDK. Cheers, Martijn On Thu, 23 Aug 2018 at 17:57, wrote: > 2018/8/23 6:24:36 -0700, Jack Shirazi : > > There is (still) a lot of confusion in the community about this. Can I > > give an example of how I understand this to proceed and please comment > > if wrong (I appreciate not set in stone, this is just an example of how > > it seems likely from my understanding atm): > > > > Let's say Java 12 has been released and Oracle announce a security > > upgrade. Oracle will apply that to their paid-for Oracle Java 11 build, > > and also to the OpenJDK Java 12 build but NOT the latest OpenJDK Java 11 > > build. > > Correct, assuming that this happens within six months of the release of > JDK 12. > > > AdoptOpenJDK will also NOT backport that to the OpenJDK Java 11 > > build. However the jdk11u project WILL backport that to the OpenJDK Java > > 11 build, and AdoptOpenJDK will then support that Java 11 upgraded > > version because it will continue to support Java 11, so that upgraded > > OpenJDK Java 11 build will then be available (somewhere) for public > > consumption. > > As Andrew noted earlier in this thread, a good number of individuals > and organizations appear to be interested in working on OpenJDK LTS > releases, but there are no specific plans as yet. Stay tuned. > > - Mark > -- Cheers, Martijn (Sent from Gmail Mobile) From mark.reinhold at oracle.com Thu Aug 23 23:05:14 2018 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Thu, 23 Aug 2018 16:05:14 -0700 (PDT) Subject: JDK 11: First Release Candidate Message-ID: <20180823230514.2F741207999@eggemoggin.niobe.net> There are no unresolved P1 bugs in build 28, so that is our first JDK 11 Release Candidate -- and if we?re lucky, our last! Binaries available here, as usual: http://jdk.java.net/11 - Mark From robert.zenz at sibvisions.com Fri Aug 24 07:48:59 2018 From: robert.zenz at sibvisions.com (Robert Zenz) Date: Fri, 24 Aug 2018 07:48:59 +0000 Subject: JEP proposed to target JDK 12: 325: Switch Expressions (Preview) In-Reply-To: References: <20180817174429.8BD3E207126@eggemoggin.niobe.net> <5B7EB915.8070204@sibvisions.com> Message-ID: <5B7FB86C.8090804@sibvisions.com> I see, thank you. On 23.08.2018 16:11, Stephen Colebourne wrote: > Null handling was deferred. I believe this is the current spec > http://cr.openjdk.java.net/~gbierman/switch-expressions.html > > (I support the rationale for deferring nulls, see amber-dev/amber-spec-experts) > > Stephen > > On 23 August 2018 at 14:39, Robert Zenz wrote: >> Wasn't one of the original complaints about the `switch` statement its `null` >> behavior? I'm not seeing that addressed in the JEP, neither for the statement >> nor for the expression. >> >> I mean, the following fails with a `NullPointerException`: >> >> MyEnum value = null; >> >> switch(value) { >> case MyEnum.A: >> // Do something >> break; >> } >> >> I'm not seeing outlined in the JEP how the expression would react to that: >> >> MyEnum value = null; >> >> int result = switch(value) { >> case MyEnum.A -> 5; >> } >> >> Also, while we are at that topic, I could not find a JEP for actually fixing the >> `switch` statement behavior to correctly handle `null`. Has somebody seen one? >> >> As an idea for that, something like this should preserve backwards compatibility: >> >> MyEnum value = null; >> >> // Fails with a NullPointerException >> switch(value) { >> case MyEnum.A: >> // Do something >> break; >> } >> >> // Succeeds >> switch(value) { >> case MyEnum.A: >> // Do something >> break; >> >> case null: >> // Do something else. >> break; >> } >> >> If I'm not mistaken, that is. >> >> >> On 17.08.2018 19:44, mark.reinhold at oracle.com wrote: >>> The following JEP is proposed to target JDK 12: >>> >>> 325: Switch Expressions (Preview) >>> http://openjdk.java.net/jeps/325 >>> >>> Feedback on this proposal is more than welcome, as are reasoned >>> objections. If no such objections are raised by 23:00 UTC on Friday, >>> 24 August, or if they?re raised and then satisfactorily answered, then >>> per the JEP 2.0 process proposal [1] I?ll target this JEP to JDK 12. >>> >>> - Mark >>> >>> >>> [1] http://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html >>> From martijnverburg at gmail.com Fri Aug 24 09:28:00 2018 From: martijnverburg at gmail.com (Martijn Verburg) Date: Fri, 24 Aug 2018 10:28:00 +0100 Subject: JDK 11: First Release Candidate In-Reply-To: <20180823230514.2F741207999@eggemoggin.niobe.net> References: <20180823230514.2F741207999@eggemoggin.niobe.net> Message-ID: Congratulations on this milestone! Cheers, Martijn On Fri, 24 Aug 2018 at 00:05, wrote: > There are no unresolved P1 bugs in build 28, so that is our first > JDK 11 Release Candidate -- and if we?re lucky, our last! > > Binaries available here, as usual: http://jdk.java.net/11 > > - Mark > From neugens at redhat.com Fri Aug 24 11:17:24 2018 From: neugens at redhat.com (Mario Torre) Date: Fri, 24 Aug 2018 13:17:24 +0200 Subject: JDK 11: First Release Candidate In-Reply-To: <20180823230514.2F741207999@eggemoggin.niobe.net> References: <20180823230514.2F741207999@eggemoggin.niobe.net> Message-ID: <167d4043-5c35-4040-f8ea-aa614d722430@redhat.com> On 08/24/2018 01:05 AM, mark.reinhold at oracle.com wrote: > There are no unresolved P1 bugs in build 28, so that is our first > JDK 11 Release Candidate -- and if we?re lucky, our last! > > Binaries available here, as usual: http://jdk.java.net/11 > > - Mark Congratulations! Cheers, Mario -- Mario Torre Associate Manager, Software Engineering Red Hat GmbH 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From vladimir.kozlov at oracle.com Mon Aug 27 14:43:22 2018 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 27 Aug 2018 07:43:22 -0700 Subject: CFV: New JDK Committer: Gilles Duboscq Message-ID: I hereby nominate Gilles Duboscq (gdub) to JDK Committer. Gilles works for the Oracle Labs Graal team and has contributed 12 changes (some were not attributed to him). His contributions can be found here [3] and are also listed below. Votes are due by 8:00 am PT, September 10, 2018. Only current JDK Committers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [2]. Thanks, Vladimir Kozlov [1] http://openjdk.java.net/census [2] http://openjdk.java.net/projects/#committer-vote [3] http://hg.openjdk.java.net/jdk/jdk/log?revcount=1000&rev=(keyword(%22gilles.m.duboscq%40oracle.com%22)+or+keyword(%22duboscq%40ssw.jku.at%22)+or+author(gdub))+and+not+desc(%22Merge%22) 8194490: [JVMCI] Move `iterateFrames` to C++ http://hg.openjdk.java.net/jdk/jdk/rev/0dc249f5c260 8167519: [AOT] Failed compilation: java.math.MutableBigInteger.divide3n2n http://hg.openjdk.java.net/jdk/jdk/rev/96e9480fbdec 8141133: [JVMCI] crash during safepoint deopt if rethrow_exception is set http://hg.openjdk.java.net/jdk/jdk/rev/01bb07d23a5b 8182755: [JVMCI] Deoptimization in synchronized methods can lead to a crash or exception when using EnableJVMCI but not UseJVMCICompiler http://hg.openjdk.java.net/jdk/jdk/rev/9c77ebad8c3a 8173278: [JVMCI] query_update_method_data might write outside _trap_hist array http://hg.openjdk.java.net/jdk/jdk/rev/a07cb821130d 8166417: Integrate Graal-core into JDK for AOT compiler http://hg.openjdk.java.net/jdk/jdk/rev/28238583a459 8159236: [JVMCI] Window-saved SPARC registers should not be considered callee-save http://hg.openjdk.java.net/jdk/jdk/rev/576058e9f728 8041628: Javadoc cross-compilation problem http://hg.openjdk.java.net/jdk/jdk/rev/ef280223e694 8031427: AllocObject and Unsafe.allocateInstance segfault for primitive types http://hg.openjdk.java.net/jdk/jdk/rev/1fc87ea15795 8075492: adopt recent IGV http://hg.openjdk.java.net/jdk/jdk/rev/b32fcc177417 8012292: optimized build with GCC broken http://hg.openjdk.java.net/jdk/jdk/rev/fec16b38217a 8003722: More gcc 4.7 compilation errors http://hg.openjdk.java.net/jdk/jdk/rev/8427edf5a77b From vladimir.x.ivanov at oracle.com Mon Aug 27 14:51:01 2018 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Mon, 27 Aug 2018 17:51:01 +0300 Subject: CFV: New JDK Committer: Gilles Duboscq In-Reply-To: References: Message-ID: <245e17e5-3a39-1ea2-795b-bc375b29869e@oracle.com> Vote: yes Best regards, Vladimir Ivanov On 27/08/2018 17:43, Vladimir Kozlov wrote: > I hereby nominate Gilles Duboscq (gdub) to JDK Committer. From goetz.lindenmaier at sap.com Mon Aug 27 14:51:14 2018 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 27 Aug 2018 14:51:14 +0000 Subject: New JDK Committer: Gilles Duboscq In-Reply-To: References: Message-ID: <23aca0f97f0340f6a97857403ce86730@sap.com> vote: yes Best regards, Goetz. > -----Original Message----- > From: jdk-dev On Behalf Of Vladimir > Kozlov > Sent: Montag, 27. August 2018 16:43 > To: jdk-dev at openjdk.java.net > Subject: CFV: New JDK Committer: Gilles Duboscq > > I hereby nominate Gilles Duboscq (gdub) to JDK Committer. > > Gilles works for the Oracle Labs Graal team and has contributed 12 changes > (some were not attributed to him). His > contributions can be found here [3] and are also listed below. > > Votes are due by 8:00 am PT, September 10, 2018. > > Only current JDK Committers [1] are eligible to vote on this nomination. > Votes must be cast in the open by replying to > this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Thanks, > Vladimir Kozlov > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] > http://hg.openjdk.java.net/jdk/jdk/log?revcount=1000&rev=(keyword(%22 > gilles.m.duboscq%40oracle.com%22)+or+keyword(%22duboscq%40ssw.jku. > at%22)+or+author(gdub))+and+not+desc(%22Merge%22) > > 8194490: [JVMCI] Move `iterateFrames` to C++ > http://hg.openjdk.java.net/jdk/jdk/rev/0dc249f5c260 > > 8167519: [AOT] Failed compilation: java.math.MutableBigInteger.divide3n2n > http://hg.openjdk.java.net/jdk/jdk/rev/96e9480fbdec > > 8141133: [JVMCI] crash during safepoint deopt if rethrow_exception is set > http://hg.openjdk.java.net/jdk/jdk/rev/01bb07d23a5b > > 8182755: [JVMCI] Deoptimization in synchronized methods can lead to a > crash or exception when using EnableJVMCI but not > UseJVMCICompiler > http://hg.openjdk.java.net/jdk/jdk/rev/9c77ebad8c3a > > 8173278: [JVMCI] query_update_method_data might write outside > _trap_hist array > http://hg.openjdk.java.net/jdk/jdk/rev/a07cb821130d > > 8166417: Integrate Graal-core into JDK for AOT compiler > http://hg.openjdk.java.net/jdk/jdk/rev/28238583a459 > > 8159236: [JVMCI] Window-saved SPARC registers should not be considered > callee-save > http://hg.openjdk.java.net/jdk/jdk/rev/576058e9f728 > > 8041628: Javadoc cross-compilation problem > http://hg.openjdk.java.net/jdk/jdk/rev/ef280223e694 > > 8031427: AllocObject and Unsafe.allocateInstance segfault for primitive types > http://hg.openjdk.java.net/jdk/jdk/rev/1fc87ea15795 > > 8075492: adopt recent IGV > http://hg.openjdk.java.net/jdk/jdk/rev/b32fcc177417 > > 8012292: optimized build with GCC broken > http://hg.openjdk.java.net/jdk/jdk/rev/fec16b38217a > > 8003722: More gcc 4.7 compilation errors > http://hg.openjdk.java.net/jdk/jdk/rev/8427edf5a77b From volker.simonis at gmail.com Mon Aug 27 15:00:56 2018 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 27 Aug 2018 17:00:56 +0200 Subject: CFV: New JDK Committer: Gilles Duboscq In-Reply-To: References: Message-ID: Vote: yes On Mon, Aug 27, 2018 at 4:43 PM Vladimir Kozlov wrote: > > I hereby nominate Gilles Duboscq (gdub) to JDK Committer. > > Gilles works for the Oracle Labs Graal team and has contributed 12 changes (some were not attributed to him). His > contributions can be found here [3] and are also listed below. > > Votes are due by 8:00 am PT, September 10, 2018. > > Only current JDK Committers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to > this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Thanks, > Vladimir Kozlov > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] > http://hg.openjdk.java.net/jdk/jdk/log?revcount=1000&rev=(keyword(%22gilles.m.duboscq%40oracle.com%22)+or+keyword(%22duboscq%40ssw.jku.at%22)+or+author(gdub))+and+not+desc(%22Merge%22) > > 8194490: [JVMCI] Move `iterateFrames` to C++ > http://hg.openjdk.java.net/jdk/jdk/rev/0dc249f5c260 > > 8167519: [AOT] Failed compilation: java.math.MutableBigInteger.divide3n2n > http://hg.openjdk.java.net/jdk/jdk/rev/96e9480fbdec > > 8141133: [JVMCI] crash during safepoint deopt if rethrow_exception is set > http://hg.openjdk.java.net/jdk/jdk/rev/01bb07d23a5b > > 8182755: [JVMCI] Deoptimization in synchronized methods can lead to a crash or exception when using EnableJVMCI but not > UseJVMCICompiler > http://hg.openjdk.java.net/jdk/jdk/rev/9c77ebad8c3a > > 8173278: [JVMCI] query_update_method_data might write outside _trap_hist array > http://hg.openjdk.java.net/jdk/jdk/rev/a07cb821130d > > 8166417: Integrate Graal-core into JDK for AOT compiler > http://hg.openjdk.java.net/jdk/jdk/rev/28238583a459 > > 8159236: [JVMCI] Window-saved SPARC registers should not be considered callee-save > http://hg.openjdk.java.net/jdk/jdk/rev/576058e9f728 > > 8041628: Javadoc cross-compilation problem > http://hg.openjdk.java.net/jdk/jdk/rev/ef280223e694 > > 8031427: AllocObject and Unsafe.allocateInstance segfault for primitive types > http://hg.openjdk.java.net/jdk/jdk/rev/1fc87ea15795 > > 8075492: adopt recent IGV > http://hg.openjdk.java.net/jdk/jdk/rev/b32fcc177417 > > 8012292: optimized build with GCC broken > http://hg.openjdk.java.net/jdk/jdk/rev/fec16b38217a > > 8003722: More gcc 4.7 compilation errors > http://hg.openjdk.java.net/jdk/jdk/rev/8427edf5a77b From yumin.qi at gmail.com Mon Aug 27 16:20:15 2018 From: yumin.qi at gmail.com (yumin qi) Date: Mon, 27 Aug 2018 09:20:15 -0700 Subject: CFV: New JDK Committer: Gilles Duboscq In-Reply-To: References: Message-ID: Vote: Yes On Mon, Aug 27, 2018 at 7:43 AM Vladimir Kozlov wrote: > I hereby nominate Gilles Duboscq (gdub) to JDK Committer. > > Gilles works for the Oracle Labs Graal team and has contributed 12 changes > (some were not attributed to him). His > contributions can be found here [3] and are also listed below. > > Votes are due by 8:00 am PT, September 10, 2018. > > Only current JDK Committers [1] are eligible to vote on this nomination. > Votes must be cast in the open by replying to > this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Thanks, > Vladimir Kozlov > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] > > http://hg.openjdk.java.net/jdk/jdk/log?revcount=1000&rev=(keyword(%22gilles.m.duboscq%40oracle.com%22)+or+keyword(%22duboscq%40ssw.jku.at%22)+or+author(gdub))+and+not+desc(%22Merge%22) > > 8194490: [JVMCI] Move `iterateFrames` to C++ > http://hg.openjdk.java.net/jdk/jdk/rev/0dc249f5c260 > > 8167519: [AOT] Failed compilation: java.math.MutableBigInteger.divide3n2n > http://hg.openjdk.java.net/jdk/jdk/rev/96e9480fbdec > > 8141133: [JVMCI] crash during safepoint deopt if rethrow_exception is set > http://hg.openjdk.java.net/jdk/jdk/rev/01bb07d23a5b > > 8182755: [JVMCI] Deoptimization in synchronized methods can lead to a > crash or exception when using EnableJVMCI but not > UseJVMCICompiler > http://hg.openjdk.java.net/jdk/jdk/rev/9c77ebad8c3a > > 8173278: [JVMCI] query_update_method_data might write outside _trap_hist > array > http://hg.openjdk.java.net/jdk/jdk/rev/a07cb821130d > > 8166417: Integrate Graal-core into JDK for AOT compiler > http://hg.openjdk.java.net/jdk/jdk/rev/28238583a459 > > 8159236: [JVMCI] Window-saved SPARC registers should not be considered > callee-save > http://hg.openjdk.java.net/jdk/jdk/rev/576058e9f728 > > 8041628: Javadoc cross-compilation problem > http://hg.openjdk.java.net/jdk/jdk/rev/ef280223e694 > > 8031427: AllocObject and Unsafe.allocateInstance segfault for primitive > types > http://hg.openjdk.java.net/jdk/jdk/rev/1fc87ea15795 > > 8075492: adopt recent IGV > http://hg.openjdk.java.net/jdk/jdk/rev/b32fcc177417 > > 8012292: optimized build with GCC broken > http://hg.openjdk.java.net/jdk/jdk/rev/fec16b38217a > > 8003722: More gcc 4.7 compilation errors > http://hg.openjdk.java.net/jdk/jdk/rev/8427edf5a77b > From sgehwolf at redhat.com Mon Aug 27 16:45:25 2018 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Mon, 27 Aug 2018 18:45:25 +0200 Subject: CFV: New JDK Committer: Gilles Duboscq In-Reply-To: References: Message-ID: <84aa0e3e0cd7272f3ddfff8824b6703d8f0ee7ca.camel@redhat.com> Vote: yes On Mon, 2018-08-27 at 07:43 -0700, Vladimir Kozlov wrote: > I hereby nominate Gilles Duboscq (gdub) to JDK Committer. > > Gilles works for the Oracle Labs Graal team and has contributed 12 > changes (some were not attributed to him). His > contributions can be found here [3] and are also listed below. > > Votes are due by 8:00 am PT, September 10, 2018. > > Only current JDK Committers [1] are eligible to vote on this > nomination. Votes must be cast in the open by replying to > this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Thanks, > Vladimir Kozlov > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] > http://hg.openjdk.java.net/jdk/jdk/log?revcount=1000&rev=(keyword(%22gilles.m.duboscq%40oracle.com%22)+or+keyword(%22duboscq%40ssw.jku.at%22)+or+author(gdub))+and+not+desc(%22Merge%22 > ) > > 8194490: [JVMCI] Move `iterateFrames` to C++ > http://hg.openjdk.java.net/jdk/jdk/rev/0dc249f5c260 > > 8167519: [AOT] Failed compilation: > java.math.MutableBigInteger.divide3n2n > http://hg.openjdk.java.net/jdk/jdk/rev/96e9480fbdec > > 8141133: [JVMCI] crash during safepoint deopt if rethrow_exception is > set > http://hg.openjdk.java.net/jdk/jdk/rev/01bb07d23a5b > > 8182755: [JVMCI] Deoptimization in synchronized methods can lead to a > crash or exception when using EnableJVMCI but not > UseJVMCICompiler > http://hg.openjdk.java.net/jdk/jdk/rev/9c77ebad8c3a > > 8173278: [JVMCI] query_update_method_data might write outside > _trap_hist array > http://hg.openjdk.java.net/jdk/jdk/rev/a07cb821130d > > 8166417: Integrate Graal-core into JDK for AOT compiler > http://hg.openjdk.java.net/jdk/jdk/rev/28238583a459 > > 8159236: [JVMCI] Window-saved SPARC registers should not be > considered callee-save > http://hg.openjdk.java.net/jdk/jdk/rev/576058e9f728 > > 8041628: Javadoc cross-compilation problem > http://hg.openjdk.java.net/jdk/jdk/rev/ef280223e694 > > 8031427: AllocObject and Unsafe.allocateInstance segfault for > primitive types > http://hg.openjdk.java.net/jdk/jdk/rev/1fc87ea15795 > > 8075492: adopt recent IGV > http://hg.openjdk.java.net/jdk/jdk/rev/b32fcc177417 > > 8012292: optimized build with GCC broken > http://hg.openjdk.java.net/jdk/jdk/rev/fec16b38217a > > 8003722: More gcc 4.7 compilation errors > http://hg.openjdk.java.net/jdk/jdk/rev/8427edf5a77b From serguei.spitsyn at oracle.com Mon Aug 27 16:51:04 2018 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 27 Aug 2018 09:51:04 -0700 Subject: CFV: New JDK Committer: Gilles Duboscq In-Reply-To: References: Message-ID: <189f523c-3eb0-d6aa-3364-25d820a44deb@oracle.com> Vote: yes From dean.long at oracle.com Mon Aug 27 17:01:14 2018 From: dean.long at oracle.com (dean.long at oracle.com) Date: Mon, 27 Aug 2018 10:01:14 -0700 Subject: CFV: New JDK Committer: Gilles Duboscq In-Reply-To: References: Message-ID: Vote: yes dl From cthalinger at twitter.com Mon Aug 27 17:02:09 2018 From: cthalinger at twitter.com (Christian Thalinger) Date: Mon, 27 Aug 2018 19:02:09 +0200 Subject: CFV: New JDK Committer: Gilles Duboscq In-Reply-To: References: Message-ID: <952E1FB7-E6D6-4CD1-B0AD-B8C8AAD7A138@twitter.com> Vote: yes > On Aug 27, 2018, at 4:43 PM, Vladimir Kozlov wrote: > > I hereby nominate Gilles Duboscq (gdub) to JDK Committer. > > Gilles works for the Oracle Labs Graal team and has contributed 12 changes (some were not attributed to him). His contributions can be found here [3] and are also listed below. > > Votes are due by 8:00 am PT, September 10, 2018. > > Only current JDK Committers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Thanks, > Vladimir Kozlov > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] http://hg.openjdk.java.net/jdk/jdk/log?revcount=1000&rev=(keyword(%22gilles.m.duboscq%40oracle.com%22)+or+keyword(%22duboscq%40ssw.jku.at%22)+or+author(gdub))+and+not+desc(%22Merge%22) > > 8194490: [JVMCI] Move `iterateFrames` to C++ > http://hg.openjdk.java.net/jdk/jdk/rev/0dc249f5c260 > > 8167519: [AOT] Failed compilation: java.math.MutableBigInteger.divide3n2n > http://hg.openjdk.java.net/jdk/jdk/rev/96e9480fbdec > > 8141133: [JVMCI] crash during safepoint deopt if rethrow_exception is set > http://hg.openjdk.java.net/jdk/jdk/rev/01bb07d23a5b > > 8182755: [JVMCI] Deoptimization in synchronized methods can lead to a crash or exception when using EnableJVMCI but not UseJVMCICompiler > http://hg.openjdk.java.net/jdk/jdk/rev/9c77ebad8c3a > > 8173278: [JVMCI] query_update_method_data might write outside _trap_hist array > http://hg.openjdk.java.net/jdk/jdk/rev/a07cb821130d > > 8166417: Integrate Graal-core into JDK for AOT compiler > http://hg.openjdk.java.net/jdk/jdk/rev/28238583a459 > > 8159236: [JVMCI] Window-saved SPARC registers should not be considered callee-save > http://hg.openjdk.java.net/jdk/jdk/rev/576058e9f728 > > 8041628: Javadoc cross-compilation problem > http://hg.openjdk.java.net/jdk/jdk/rev/ef280223e694 > > 8031427: AllocObject and Unsafe.allocateInstance segfault for primitive types > http://hg.openjdk.java.net/jdk/jdk/rev/1fc87ea15795 > > 8075492: adopt recent IGV > http://hg.openjdk.java.net/jdk/jdk/rev/b32fcc177417 > > 8012292: optimized build with GCC broken > http://hg.openjdk.java.net/jdk/jdk/rev/fec16b38217a > > 8003722: More gcc 4.7 compilation errors > http://hg.openjdk.java.net/jdk/jdk/rev/8427edf5a77b From Peter.B.Kessler at Oracle.COM Mon Aug 27 17:54:34 2018 From: Peter.B.Kessler at Oracle.COM (Peter B. Kessler) Date: Mon, 27 Aug 2018 10:54:34 -0700 Subject: CFV: New JDK Committer: Gilles Duboscq In-Reply-To: References: Message-ID: <53bdb28e-6791-446e-af46-031c9c2ae781@Oracle.COM> Vote: yes ... peter On 08/27/18 07:43 AM, Vladimir Kozlov wrote: > I hereby nominate Gilles Duboscq (gdub) to JDK Committer. > > Gilles works for the Oracle Labs Graal team and has contributed 12 changes (some were not attributed to him). His contributions can be found here [3] and are also listed below. > > Votes are due by 8:00 am PT, September 10, 2018. > > Only current JDK Committers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Thanks, > Vladimir Kozlov > .... From jiangli.zhou at oracle.com Mon Aug 27 20:33:23 2018 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Mon, 27 Aug 2018 13:33:23 -0700 Subject: RFR: JDK-8202951: Implementation of JEPJDK-8204247: Include default CDS (Class Data Sharing) archive in JDK binary Message-ID: Please review the implementation for JEP JDK-8204247 (https://bugs.openjdk.java.net/browse/JDK-8204247). The goal of the JEP is to include a default CDS archive in JDK 12 binary distribution (downloadable from http://jdk.java.net/12/). The default CDS archive is generated using the default classlist (resides in the lib/ directory) at JDK build time. Any comments/suggestions are highly appreciated. All makefile changes in the webrev are contributed by Erik Joelsson (many thanks!!). This is a combination of efforts from different teams and individuals. Thanks to everyone who has been involved in the JEP & implementation discussions, testing and bug fixing! ? JEP: https://bugs.openjdk.java.net/browse/JDK-8204247 ? RFE: https://bugs.openjdk.java.net/browse/JDK-8202951 ? webrev: http://cr.openjdk.java.net/~jiangli/8202951/webrev.00/ Two sanity test cases for the default CDS archive are included test/hotspot/jtreg/runtime/SharedArchiveFile. They are not intended for in-depth CDS functional testing, which is already covered by the existing cds/appcds tests and all tiered tests executing with the default CDS archive enabled. As part of the webrev, test/jdk/javax/imageio/plugins/png/ItxtUtf8Test.java is also fixed to use larger java heap (JDK-8209739 , https://bugs.openjdk.java.net/browse/JDK-8209739). Tests executed: ?- several rounds of tier1 - tier8 via mach5 ?- JCK lang, api and vm tests via mach5 Thanks! Calvin, Ioi, Jiangli From mark.reinhold at oracle.com Mon Aug 27 23:19:55 2018 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Mon, 27 Aug 2018 16:19:55 -0700 Subject: JEP proposed to target JDK 12: 325: Switch Expressions (Preview) In-Reply-To: <20180817174429.8BD3E207126@eggemoggin.niobe.net> References: <20180817174429.8BD3E207126@eggemoggin.niobe.net> Message-ID: <20180827161955.277660311@eggemoggin.niobe.net> 2018/8/17 10:44:29 -0700, mark.reinhold at oracle.com: > The following JEP is proposed to target JDK 12: > > 325: Switch Expressions (Preview) > http://openjdk.java.net/jeps/325 > > Feedback on this proposal is more than welcome, as are reasoned > objections. If no such objections are raised by 23:00 UTC on Friday, > 24 August, or if they?re raised and then satisfactorily answered, then > per the JEP 2.0 process proposal [1] I?ll target this JEP to JDK 12. The few objections raised here are not new, having already been raised and answered over on the amber-dev and amber-spec-experts lists. I?ve therefore targeted this JEP to JDK 12. - Mark From roman at kennke.org Mon Aug 27 23:46:55 2018 From: roman at kennke.org (Roman Kennke) Date: Tue, 28 Aug 2018 01:46:55 +0200 Subject: JEP proposed to target JDK 12: 325: Switch Expressions (Preview) In-Reply-To: <20180827161955.277660311@eggemoggin.niobe.net> References: <20180817174429.8BD3E207126@eggemoggin.niobe.net> <20180827161955.277660311@eggemoggin.niobe.net> Message-ID: <3906c197-ae9d-ee8f-7b91-4c0ccb70ef0d@kennke.org> > 2018/8/17 10:44:29 -0700, mark.reinhold at oracle.com: >> The following JEP is proposed to target JDK 12: >> >> 325: Switch Expressions (Preview) >> http://openjdk.java.net/jeps/325 >> >> Feedback on this proposal is more than welcome, as are reasoned >> objections. If no such objections are raised by 23:00 UTC on Friday, >> 24 August, or if they?re raised and then satisfactorily answered, then >> per the JEP 2.0 process proposal [1] I?ll target this JEP to JDK 12. > > The few objections raised here are not new, having already been raised > and answered over on the amber-dev and amber-spec-experts lists. I?ve > therefore targeted this JEP to JDK 12. I am not following amber-dev nor amber-spec-experts. I found the objections raised here very reasonable, in particular the objection to not include a controversial feature as 'preview' which would then manifest itself by people using it. I can't see that those objections have been 'satisfactorily answered'. If they have been satisfactorily answered on any of the amber-* mailing lists, maybe it would be worth to repeat that here for those of use who don't follow those lists. I'd find an answer satisfactory if those who raised it agree and state here that they're ok. In particular, I don't actually see any need to include a half-baked (language-) feature as preview. Thanks, Roman From brian.goetz at oracle.com Tue Aug 28 00:02:55 2018 From: brian.goetz at oracle.com (Brian Goetz) Date: Mon, 27 Aug 2018 20:02:55 -0400 Subject: JEP proposed to target JDK 12: 325: Switch Expressions (Preview) In-Reply-To: <20180827161955.277660311@eggemoggin.niobe.net> References: <20180817174429.8BD3E207126@eggemoggin.niobe.net> <20180827161955.277660311@eggemoggin.niobe.net> Message-ID: <5e5df50e-1bb3-f743-30b7-05efdbe501e1@oracle.com> > > The few objections raised here are not new, having already been raised > and answered over on the amber-dev and amber-spec-experts lists. I?ve > therefore targeted this JEP to JDK 12. > As Mark says, the issues raised on this thread were already considered and discussed at some length during the design of the feature.? But, for the convenience of readers here, I will summarize for the record some of the reasons why these suggestions were not incorporated into the final design of the feature when they came around the first time. Stephen raised several specific objections, which I'll summarize as: ?- You're increasing complexity by adding three features, one of which is silly, and which gives us more fallthrough rather than less, which is surely a move in the wrong direction! ?- I don't love the syntax. ?- You should have created a new syntactic form (hereafter, "snitch", for "new switch") and left classic switch for dead, rather than piling more complexity on existing switch, because existing switch is hopelessly tied to the dumb idea of fallthrough.? Die, fallthrough, die. Ben expressed general agreement, and specifically for the "you should have killed switch and made something new" position.? While I understand where these opinions come from, and we did consider these issues seriously, we concluded that abstracting the existing switch construct as we did was a better long-term path. Ben also raised the excellent point that language design is a balance between the interests of experienced developers and of newcomers -- a concern we struggle with in every single feature, and which also played into our decision here. The first sentiment, which I've seen expressed in a few places, relies on a somewhat tortured notion of "feature".? We have not added three features (enhanced statement switch, classic expression switch, enhanced expression switch), as much as added _two_ features, defined at a very different level: ?- The ability for switch to be an expression or a statement ?- The choice of classic case labels or enhanced case labels, where the latter are single consequent, fallthrough-free, and free of the confusing scoping of the classic switch block (essentially, fixing most of the things people complain about with respect to switch.) ?These features work orthogonally, so that you can mix and match them freely, and I don't think anyone could reasonably object that either is frivolous or undesirable.? So while they do give rise to four combinations, these combinations are not features in themselves.? Defining the improvements to switch as orthogonal choices makes the design and implementation _simpler_, not more complex, as we can then reason about the semantics of a particular combination based on the semantics of simpler orthogonal primitives. The fact that some combinations of these features are more desirable than others is not evidence that a mistake was made.? This is often the natural consequence of providing simple primitives that can be combined orthogonally; some of the combinations are always going to be more sensible than others, and that's fine.? So while "classic expression switch" may seem silly, and will almost certainly be rarely used in practice, that doesn't mean that we should distort the language design to prevent it.? In fact, doing so would increase, not decrease, the complexity, as it introduces arbitrary constraints and special cases.? (As a possibly tortured analogy, while we might almost never write a combination of public setter and private getter, that's no reason to try and outlaw that combination.) As to syntax preferences ... because syntax is so deeply subjective, there is never going to be a syntax that satisfies everyone.? And, people being what they are, they tend to only complain about the things they disagree with, and are quiet about the things they agree with.? So any syntax decision (whatever it is) is going to be met with some degree of "I don't like it" or "I would have preferred X" -- but again, that isn't necessarily actionable or dispositive.? The syntax choice we made here is consistent with how similar things are done in similar languages -- and we think it will, perhaps after a few days of initial brain-retraining, be well-understood and accepted by Java developers. The final concern is a combination of pragmatism and language evolution philosophy -- whether it is better to abandon an existing feature and create a replacement, or to try and rehabilitate or generalize an existing feature.? While we asked ourselves many times whether switch could indeed be rehabilitated (not just in the context of this smaller feature, but in the context of the bigger feature arc of pattern matching), we found that, at each turn, it was more practical to rehabilitate it than one might have initially thought.? And we felt it better to build on the existing feature that is well understood and well documented, than to create a wholly new one, just because the old one was imperfect. Ben expressed concerns along the lines of "think of the students" with respect to the proliferation of switch forms, but the reality with a separate "snitch" form would most likely be worse.? Students would not be fully absolved of the need to learn "old switch", not only because they will encounter code that uses it, but because snitch would almost certainly be tilted towards the "happy cases", which, while common, are not universal.? And by un-anchoring snitch from switch, the differences would likely be more arbitrary.? So new students would encounter a language with two suspiciously similar constructs, but subtly different in harder-to-understand ways, and wonder why there are two ways to do it.? The burning hulk of "old switch" would lie forever on the roadside, but unable to be ever hauled away.? Its nice to think that we can invent the ideal "snitch" construct, and just leave "switch" in the past, but that's a fantasy. Now, if switch were truly broken, it might be different.? But for all the distaste of fallthrough-by-default, the existing switch construct is _not_ fundamentally broken; it's not just what we'd design now if we had a clean sheet of paper.? (BTW, fallthrough itself is not a problem, and sometimes is essential; the real mistake was fallthrough _by default_.)? Therefore, while we did consider whether it would be necessary to retire "switch" to pasture, we found no evidence that this was actually necessary -- and found that it was possible to enhance switch to support all the desired behaviors, rather than to abandon it, however tempting the latter course might initially seem.? Enhancing switch builds on the existing understanding of Java developers; abandoning it for snitch invalidates that understanding. At a meta level, this inclination -- "just abandon switch and build something better" -- illustrates a common temptation that is best avoided: over-rotating towards the desire to "fix" the mistakes of the past because they offend us, and because the current opportunity seems "the last chance" to right a wrong that's been bugging us for years.? These are natural motivations, but they are frequently siren-songs that lure us away from the path that calmer reason might otherwise have chosen.? Yes, it would have been better if switch were designed differently 20 years ago, but that was billions of programmer-hours and lines of code ago, and the calculus is very different with such a large existing base of code and user understanding.? So, while I understand why it feels like an "opportunity missed", the cost of "seizing" this opportunity was too great, and the benefit too small.? Its natural to regret that we can't fix the mistakes of the past, but in this case, it would have been the wrong choice. The preview mechanism will allow us to gather feedback on the feature from actual use, rather than theorizing from no examples, and potentially adjust the specification before final release if warranted.? So if any _new_ issues up come as a result of actual experience, we are happy to hear about them. From openjdk at haupz.de Tue Aug 28 04:31:59 2018 From: openjdk at haupz.de (Michael Haupt) Date: Tue, 28 Aug 2018 06:31:59 +0200 Subject: CFV: New JDK Committer: Gilles Duboscq In-Reply-To: References: Message-ID: Vote: yes > Am 27.08.2018 um 16:43 schrieb Vladimir Kozlov : > > I hereby nominate Gilles Duboscq (gdub) to JDK Committer. > > Gilles works for the Oracle Labs Graal team and has contributed 12 changes (some were not attributed to him). His contributions can be found here [3] and are also listed below. > > Votes are due by 8:00 am PT, September 10, 2018. > > Only current JDK Committers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Thanks, > Vladimir Kozlov > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] http://hg.openjdk.java.net/jdk/jdk/log?revcount=1000&rev=(keyword(%22gilles.m.duboscq%40oracle.com%22)+or+keyword(%22duboscq%40ssw.jku.at%22)+or+author(gdub))+and+not+desc(%22Merge%22) > > 8194490: [JVMCI] Move `iterateFrames` to C++ > http://hg.openjdk.java.net/jdk/jdk/rev/0dc249f5c260 > > 8167519: [AOT] Failed compilation: java.math.MutableBigInteger.divide3n2n > http://hg.openjdk.java.net/jdk/jdk/rev/96e9480fbdec > > 8141133: [JVMCI] crash during safepoint deopt if rethrow_exception is set > http://hg.openjdk.java.net/jdk/jdk/rev/01bb07d23a5b > > 8182755: [JVMCI] Deoptimization in synchronized methods can lead to a crash or exception when using EnableJVMCI but not UseJVMCICompiler > http://hg.openjdk.java.net/jdk/jdk/rev/9c77ebad8c3a > > 8173278: [JVMCI] query_update_method_data might write outside _trap_hist array > http://hg.openjdk.java.net/jdk/jdk/rev/a07cb821130d > > 8166417: Integrate Graal-core into JDK for AOT compiler > http://hg.openjdk.java.net/jdk/jdk/rev/28238583a459 > > 8159236: [JVMCI] Window-saved SPARC registers should not be considered callee-save > http://hg.openjdk.java.net/jdk/jdk/rev/576058e9f728 > > 8041628: Javadoc cross-compilation problem > http://hg.openjdk.java.net/jdk/jdk/rev/ef280223e694 > > 8031427: AllocObject and Unsafe.allocateInstance segfault for primitive types > http://hg.openjdk.java.net/jdk/jdk/rev/1fc87ea15795 > > 8075492: adopt recent IGV > http://hg.openjdk.java.net/jdk/jdk/rev/b32fcc177417 > > 8012292: optimized build with GCC broken > http://hg.openjdk.java.net/jdk/jdk/rev/fec16b38217a > > 8003722: More gcc 4.7 compilation errors > http://hg.openjdk.java.net/jdk/jdk/rev/8427edf5a77b From tobias.hartmann at oracle.com Tue Aug 28 06:10:09 2018 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Tue, 28 Aug 2018 08:10:09 +0200 Subject: CFV: New JDK Committer: Gilles Duboscq In-Reply-To: References: Message-ID: Vote: yes Best regards, Tobias On 27.08.2018 16:43, Vladimir Kozlov wrote: > I hereby nominate Gilles Duboscq (gdub) to JDK Committer. > > Gilles works for the Oracle Labs Graal team and has contributed 12 changes (some were not attributed > to him). His contributions can be found here [3] and are also listed below. > > Votes are due by 8:00 am PT, September 10, 2018. > > Only current JDK Committers [1] are eligible to vote on this nomination. Votes must be cast in the > open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Thanks, > Vladimir Kozlov > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] > http://hg.openjdk.java.net/jdk/jdk/log?revcount=1000&rev=(keyword(%22gilles.m.duboscq%40oracle.com%22)+or+keyword(%22duboscq%40ssw.jku.at%22)+or+author(gdub))+and+not+desc(%22Merge%22) > > > 8194490: [JVMCI] Move `iterateFrames` to C++ > ? http://hg.openjdk.java.net/jdk/jdk/rev/0dc249f5c260 > > 8167519: [AOT] Failed compilation: java.math.MutableBigInteger.divide3n2n > ? http://hg.openjdk.java.net/jdk/jdk/rev/96e9480fbdec > > 8141133: [JVMCI] crash during safepoint deopt if rethrow_exception is set > ? http://hg.openjdk.java.net/jdk/jdk/rev/01bb07d23a5b > > 8182755: [JVMCI] Deoptimization in synchronized methods can lead to a crash or exception when using > EnableJVMCI but not UseJVMCICompiler > ? http://hg.openjdk.java.net/jdk/jdk/rev/9c77ebad8c3a > > 8173278: [JVMCI] query_update_method_data might write outside _trap_hist array > ? http://hg.openjdk.java.net/jdk/jdk/rev/a07cb821130d > > 8166417: Integrate Graal-core into JDK for AOT compiler > ? http://hg.openjdk.java.net/jdk/jdk/rev/28238583a459 > > 8159236: [JVMCI] Window-saved SPARC registers should not be considered callee-save > ? http://hg.openjdk.java.net/jdk/jdk/rev/576058e9f728 > > 8041628: Javadoc cross-compilation problem > ? http://hg.openjdk.java.net/jdk/jdk/rev/ef280223e694 > > 8031427: AllocObject and Unsafe.allocateInstance segfault for primitive types > ? http://hg.openjdk.java.net/jdk/jdk/rev/1fc87ea15795 > > 8075492: adopt recent IGV > ? http://hg.openjdk.java.net/jdk/jdk/rev/b32fcc177417 > > 8012292: optimized build with GCC broken > ? http://hg.openjdk.java.net/jdk/jdk/rev/fec16b38217a > > 8003722: More gcc 4.7 compilation errors > ? http://hg.openjdk.java.net/jdk/jdk/rev/8427edf5a77b From adinn at redhat.com Tue Aug 28 10:05:58 2018 From: adinn at redhat.com (Andrew Dinn) Date: Tue, 28 Aug 2018 11:05:58 +0100 Subject: CFV: New JDK Committer: Gilles Duboscq In-Reply-To: References: Message-ID: <1f1189ec-70eb-98ef-8421-3c5226ab55a3@redhat.com> Vote: yes On 27/08/18 15:43, Vladimir Kozlov wrote: > I hereby nominate Gilles Duboscq (gdub) to JDK Committer. > > Gilles works for the Oracle Labs Graal team and has contributed 12 > changes (some were not attributed to him). His contributions can be > found here [3] and are also listed below. > > Votes are due by 8:00 am PT, September 10, 2018. > > Only current JDK Committers [1] are eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Thanks, > Vladimir Kozlov > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] > http://hg.openjdk.java.net/jdk/jdk/log?revcount=1000&rev=(keyword(%22gilles.m.duboscq%40oracle.com%22)+or+keyword(%22duboscq%40ssw.jku.at%22)+or+author(gdub))+and+not+desc(%22Merge%22) > > > 8194490: [JVMCI] Move `iterateFrames` to C++ > ? http://hg.openjdk.java.net/jdk/jdk/rev/0dc249f5c260 > > 8167519: [AOT] Failed compilation: java.math.MutableBigInteger.divide3n2n > ? http://hg.openjdk.java.net/jdk/jdk/rev/96e9480fbdec > > 8141133: [JVMCI] crash during safepoint deopt if rethrow_exception is set > ? http://hg.openjdk.java.net/jdk/jdk/rev/01bb07d23a5b > > 8182755: [JVMCI] Deoptimization in synchronized methods can lead to a > crash or exception when using EnableJVMCI but not UseJVMCICompiler > ? http://hg.openjdk.java.net/jdk/jdk/rev/9c77ebad8c3a > > 8173278: [JVMCI] query_update_method_data might write outside _trap_hist > array > ? http://hg.openjdk.java.net/jdk/jdk/rev/a07cb821130d > > 8166417: Integrate Graal-core into JDK for AOT compiler > ? http://hg.openjdk.java.net/jdk/jdk/rev/28238583a459 > > 8159236: [JVMCI] Window-saved SPARC registers should not be considered > callee-save > ? http://hg.openjdk.java.net/jdk/jdk/rev/576058e9f728 > > 8041628: Javadoc cross-compilation problem > ? http://hg.openjdk.java.net/jdk/jdk/rev/ef280223e694 > > 8031427: AllocObject and Unsafe.allocateInstance segfault for primitive > types > ? http://hg.openjdk.java.net/jdk/jdk/rev/1fc87ea15795 > > 8075492: adopt recent IGV > ? http://hg.openjdk.java.net/jdk/jdk/rev/b32fcc177417 > > 8012292: optimized build with GCC broken > ? http://hg.openjdk.java.net/jdk/jdk/rev/fec16b38217a > > 8003722: More gcc 4.7 compilation errors > ? http://hg.openjdk.java.net/jdk/jdk/rev/8427edf5a77b > -- regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From erik.joelsson at oracle.com Tue Aug 28 16:25:32 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 28 Aug 2018 09:25:32 -0700 Subject: RFR: JDK-8202951: Implementation of JEPJDK-8204247: Include default CDS (Class Data Sharing) archive in JDK binary In-Reply-To: References: Message-ID: Build changes look good to me (but should probably get review from someone else). /Erik On 2018-08-27 13:33, Jiangli Zhou wrote: > Please review the implementation for JEP JDK-8204247 > (https://bugs.openjdk.java.net/browse/JDK-8204247). The goal of the > JEP is to include a default CDS archive in JDK 12 binary distribution > (downloadable from http://jdk.java.net/12/). The default CDS archive > is generated using the default classlist (resides in the lib/ > directory) at JDK build time. Any comments/suggestions are highly > appreciated. > > All makefile changes in the webrev are contributed by Erik Joelsson > (many thanks!!). > > This is a combination of efforts from different teams and individuals. > Thanks to everyone who has been involved in the JEP & implementation > discussions, testing and bug fixing! > > ? JEP: https://bugs.openjdk.java.net/browse/JDK-8204247 > ? RFE: https://bugs.openjdk.java.net/browse/JDK-8202951 > ? webrev: http://cr.openjdk.java.net/~jiangli/8202951/webrev.00/ > > Two sanity test cases for the default CDS archive are included > test/hotspot/jtreg/runtime/SharedArchiveFile. They are not intended > for in-depth CDS functional testing, which is already covered by the > existing cds/appcds tests and all tiered tests executing with the > default CDS archive enabled. > > As part of the webrev, > test/jdk/javax/imageio/plugins/png/ItxtUtf8Test.java is also fixed to > use larger java heap (JDK-8209739 > , https://bugs.openjdk.java.net/browse/JDK-8209739). > > Tests executed: > ?- several rounds of tier1 - tier8 via mach5 > ?- JCK lang, api and vm tests via mach5 > > > Thanks! > Calvin, Ioi, Jiangli > > From ioi.lam at oracle.com Tue Aug 28 16:33:17 2018 From: ioi.lam at oracle.com (Ioi Lam) Date: Tue, 28 Aug 2018 09:33:17 -0700 Subject: RFR: JDK-8202951: Implementation of JEPJDK-8204247: Include default CDS (Class Data Sharing) archive in JDK binary In-Reply-To: References: Message-ID: <979f56e4-07b4-8c52-c426-6ca5a839b6a3@oracle.com> The JVM and test changes look good. I just have one comment: CheckDefaultArchiveFile.java ? 51????? if (!Platform.isDefaultCDSArchiveSupported()) { ? 52???????????? if (Files.notExists(jsa)) { ? 53???????????????? System.out.println("Passed. " + vmString + ? 54??????????????????????????????????? ": no default classes.jsa file"); ? 55???????????? } else { ? 56???????????????? throw new RuntimeException(vmString + "contains " + jsaString); ? 57???????????? } People may manually do "java -Xshare:dump" on their own platforms and them run the hotspot tests. It seems too strict to treat this as an error. I think this block should be removed. Thanks - Ioi On 8/28/18 9:25 AM, Erik Joelsson wrote: > Build changes look good to me (but should probably get review from > someone else). > > /Erik > > > On 2018-08-27 13:33, Jiangli Zhou wrote: >> Please review the implementation for JEP JDK-8204247 >> (https://bugs.openjdk.java.net/browse/JDK-8204247). The goal of the >> JEP is to include a default CDS archive in JDK 12 binary distribution >> (downloadable from http://jdk.java.net/12/). The default CDS archive >> is generated using the default classlist (resides in the lib/ >> directory) at JDK build time. Any comments/suggestions are highly >> appreciated. >> >> All makefile changes in the webrev are contributed by Erik Joelsson >> (many thanks!!). >> >> This is a combination of efforts from different teams and >> individuals. Thanks to everyone who has been involved in the JEP & >> implementation discussions, testing and bug fixing! >> >> ? JEP: https://bugs.openjdk.java.net/browse/JDK-8204247 >> ? RFE: https://bugs.openjdk.java.net/browse/JDK-8202951 >> ? webrev: http://cr.openjdk.java.net/~jiangli/8202951/webrev.00/ >> >> Two sanity test cases for the default CDS archive are included >> test/hotspot/jtreg/runtime/SharedArchiveFile. They are not intended >> for in-depth CDS functional testing, which is already covered by the >> existing cds/appcds tests and all tiered tests executing with the >> default CDS archive enabled. >> >> As part of the webrev, >> test/jdk/javax/imageio/plugins/png/ItxtUtf8Test.java is also fixed to >> use larger java heap (JDK-8209739 >> , https://bugs.openjdk.java.net/browse/JDK-8209739). >> >> Tests executed: >> ?- several rounds of tier1 - tier8 via mach5 >> ?- JCK lang, api and vm tests via mach5 >> >> >> Thanks! >> Calvin, Ioi, Jiangli >> >> > From jiangli.zhou at oracle.com Tue Aug 28 17:12:18 2018 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Tue, 28 Aug 2018 10:12:18 -0700 Subject: CFV: New JDK Committer: Gilles Duboscq In-Reply-To: References: Message-ID: Vote: yes Best regards, Jiangli On 8/27/18 7:43 AM, Vladimir Kozlov wrote: > I hereby nominate Gilles Duboscq (gdub) to JDK Committer. > > Gilles works for the Oracle Labs Graal team and has contributed 12 > changes (some were not attributed to him). His contributions can be > found here [3] and are also listed below. > > Votes are due by 8:00 am PT, September 10, 2018. > > Only current JDK Committers [1] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing > list. > > For Lazy Consensus voting instructions, see [2]. > > Thanks, > Vladimir Kozlov > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] > http://hg.openjdk.java.net/jdk/jdk/log?revcount=1000&rev=(keyword(%22gilles.m.duboscq%40oracle.com%22)+or+keyword(%22duboscq%40ssw.jku.at%22)+or+author(gdub))+and+not+desc(%22Merge%22) > > 8194490: [JVMCI] Move `iterateFrames` to C++ > ? http://hg.openjdk.java.net/jdk/jdk/rev/0dc249f5c260 > > 8167519: [AOT] Failed compilation: java.math.MutableBigInteger.divide3n2n > ? http://hg.openjdk.java.net/jdk/jdk/rev/96e9480fbdec > > 8141133: [JVMCI] crash during safepoint deopt if rethrow_exception is set > ? http://hg.openjdk.java.net/jdk/jdk/rev/01bb07d23a5b > > 8182755: [JVMCI] Deoptimization in synchronized methods can lead to a > crash or exception when using EnableJVMCI but not UseJVMCICompiler > ? http://hg.openjdk.java.net/jdk/jdk/rev/9c77ebad8c3a > > 8173278: [JVMCI] query_update_method_data might write outside > _trap_hist array > ? http://hg.openjdk.java.net/jdk/jdk/rev/a07cb821130d > > 8166417: Integrate Graal-core into JDK for AOT compiler > ? http://hg.openjdk.java.net/jdk/jdk/rev/28238583a459 > > 8159236: [JVMCI] Window-saved SPARC registers should not be considered > callee-save > ? http://hg.openjdk.java.net/jdk/jdk/rev/576058e9f728 > > 8041628: Javadoc cross-compilation problem > ? http://hg.openjdk.java.net/jdk/jdk/rev/ef280223e694 > > 8031427: AllocObject and Unsafe.allocateInstance segfault for > primitive types > ? http://hg.openjdk.java.net/jdk/jdk/rev/1fc87ea15795 > > 8075492: adopt recent IGV > ? http://hg.openjdk.java.net/jdk/jdk/rev/b32fcc177417 > > 8012292: optimized build with GCC broken > ? http://hg.openjdk.java.net/jdk/jdk/rev/fec16b38217a > > 8003722: More gcc 4.7 compilation errors > ? http://hg.openjdk.java.net/jdk/jdk/rev/8427edf5a77b From jiangli.zhou at oracle.com Tue Aug 28 17:50:39 2018 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Tue, 28 Aug 2018 10:50:39 -0700 Subject: RFR: JDK-8202951: Implementation of JEPJDK-8204247: Include default CDS (Class Data Sharing) archive in JDK binary In-Reply-To: References: Message-ID: Thanks, Erik! Jiangli On 8/28/18 9:25 AM, Erik Joelsson wrote: > Build changes look good to me (but should probably get review from > someone else). > > /Erik > > > On 2018-08-27 13:33, Jiangli Zhou wrote: >> Please review the implementation for JEP JDK-8204247 >> (https://bugs.openjdk.java.net/browse/JDK-8204247). The goal of the >> JEP is to include a default CDS archive in JDK 12 binary distribution >> (downloadable from http://jdk.java.net/12/). The default CDS archive >> is generated using the default classlist (resides in the lib/ >> directory) at JDK build time. Any comments/suggestions are highly >> appreciated. >> >> All makefile changes in the webrev are contributed by Erik Joelsson >> (many thanks!!). >> >> This is a combination of efforts from different teams and >> individuals. Thanks to everyone who has been involved in the JEP & >> implementation discussions, testing and bug fixing! >> >> ? JEP: https://bugs.openjdk.java.net/browse/JDK-8204247 >> ? RFE: https://bugs.openjdk.java.net/browse/JDK-8202951 >> ? webrev: http://cr.openjdk.java.net/~jiangli/8202951/webrev.00/ >> >> Two sanity test cases for the default CDS archive are included >> test/hotspot/jtreg/runtime/SharedArchiveFile. They are not intended >> for in-depth CDS functional testing, which is already covered by the >> existing cds/appcds tests and all tiered tests executing with the >> default CDS archive enabled. >> >> As part of the webrev, >> test/jdk/javax/imageio/plugins/png/ItxtUtf8Test.java is also fixed to >> use larger java heap (JDK-8209739 >> , https://bugs.openjdk.java.net/browse/JDK-8209739). >> >> Tests executed: >> ?- several rounds of tier1 - tier8 via mach5 >> ?- JCK lang, api and vm tests via mach5 >> >> >> Thanks! >> Calvin, Ioi, Jiangli >> >> > From jiangli.zhou at oracle.com Tue Aug 28 18:09:30 2018 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Tue, 28 Aug 2018 11:09:30 -0700 Subject: RFR: JDK-8202951: Implementation of JEPJDK-8204247: Include default CDS (Class Data Sharing) archive in JDK binary In-Reply-To: <979f56e4-07b4-8c52-c426-6ca5a839b6a3@oracle.com> References: <979f56e4-07b4-8c52-c426-6ca5a839b6a3@oracle.com> Message-ID: <1af91463-05f5-30ed-7ef0-eeb558e12451@oracle.com> On 8/28/18 9:33 AM, Ioi Lam wrote: > The JVM and test changes look good. I just have one comment: > > > CheckDefaultArchiveFile.java > > ? 51????? if (!Platform.isDefaultCDSArchiveSupported()) { > ? 52???????????? if (Files.notExists(jsa)) { > ? 53???????????????? System.out.println("Passed. " + vmString + > ? 54??????????????????????????????????? ": no default classes.jsa file"); > ? 55???????????? } else { > ? 56???????????????? throw new RuntimeException(vmString + "contains " > + jsaString); > ? 57???????????? } > > > People may manually do "java -Xshare:dump" on their own platforms and > them run the hotspot tests. It seems too strict to treat this as an > error. > > I think this block should be removed. That's probably a common scenario. I agree, it is too strict. Will remove the block. Thanks! Jiangli > > Thanks > > - Ioi > > > On 8/28/18 9:25 AM, Erik Joelsson wrote: >> Build changes look good to me (but should probably get review from >> someone else). >> >> /Erik >> >> >> On 2018-08-27 13:33, Jiangli Zhou wrote: >>> Please review the implementation for JEP JDK-8204247 >>> (https://bugs.openjdk.java.net/browse/JDK-8204247). The goal of the >>> JEP is to include a default CDS archive in JDK 12 binary >>> distribution (downloadable from http://jdk.java.net/12/). The >>> default CDS archive is generated using the default classlist >>> (resides in the lib/ directory) at JDK build time. Any >>> comments/suggestions are highly appreciated. >>> >>> All makefile changes in the webrev are contributed by Erik Joelsson >>> (many thanks!!). >>> >>> This is a combination of efforts from different teams and >>> individuals. Thanks to everyone who has been involved in the JEP & >>> implementation discussions, testing and bug fixing! >>> >>> ? JEP: https://bugs.openjdk.java.net/browse/JDK-8204247 >>> ? RFE: https://bugs.openjdk.java.net/browse/JDK-8202951 >>> ? webrev: http://cr.openjdk.java.net/~jiangli/8202951/webrev.00/ >>> >>> Two sanity test cases for the default CDS archive are included >>> test/hotspot/jtreg/runtime/SharedArchiveFile. They are not intended >>> for in-depth CDS functional testing, which is already covered by the >>> existing cds/appcds tests and all tiered tests executing with the >>> default CDS archive enabled. >>> >>> As part of the webrev, >>> test/jdk/javax/imageio/plugins/png/ItxtUtf8Test.java is also fixed >>> to use larger java heap (JDK-8209739 >>> , https://bugs.openjdk.java.net/browse/JDK-8209739). >>> >>> Tests executed: >>> ?- several rounds of tier1 - tier8 via mach5 >>> ?- JCK lang, api and vm tests via mach5 >>> >>> >>> Thanks! >>> Calvin, Ioi, Jiangli >>> >>> >> > From vladimir.kozlov at oracle.com Tue Aug 28 19:22:23 2018 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 28 Aug 2018 12:22:23 -0700 Subject: CFV: New JDK Committer: Gilles Duboscq In-Reply-To: References: Message-ID: <096ebf08-59ec-8c0c-c4e8-f9471ac5184f@oracle.com> Vote: yes On 8/27/18 7:43 AM, Vladimir Kozlov wrote: > I hereby nominate Gilles Duboscq (gdub) to JDK Committer. > > Gilles works for the Oracle Labs Graal team and has contributed 12 changes (some were not attributed > to him). His contributions can be found here [3] and are also listed below. > > Votes are due by 8:00 am PT, September 10, 2018. > > Only current JDK Committers [1] are eligible to vote on this nomination. Votes must be cast in the > open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Thanks, > Vladimir Kozlov > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] > http://hg.openjdk.java.net/jdk/jdk/log?revcount=1000&rev=(keyword(%22gilles.m.duboscq%40oracle.com%22)+or+keyword(%22duboscq%40ssw.jku.at%22)+or+author(gdub))+and+not+desc(%22Merge%22) > > > 8194490: [JVMCI] Move `iterateFrames` to C++ > ? http://hg.openjdk.java.net/jdk/jdk/rev/0dc249f5c260 > > 8167519: [AOT] Failed compilation: java.math.MutableBigInteger.divide3n2n > ? http://hg.openjdk.java.net/jdk/jdk/rev/96e9480fbdec > > 8141133: [JVMCI] crash during safepoint deopt if rethrow_exception is set > ? http://hg.openjdk.java.net/jdk/jdk/rev/01bb07d23a5b > > 8182755: [JVMCI] Deoptimization in synchronized methods can lead to a crash or exception when using > EnableJVMCI but not UseJVMCICompiler > ? http://hg.openjdk.java.net/jdk/jdk/rev/9c77ebad8c3a > > 8173278: [JVMCI] query_update_method_data might write outside _trap_hist array > ? http://hg.openjdk.java.net/jdk/jdk/rev/a07cb821130d > > 8166417: Integrate Graal-core into JDK for AOT compiler > ? http://hg.openjdk.java.net/jdk/jdk/rev/28238583a459 > > 8159236: [JVMCI] Window-saved SPARC registers should not be considered callee-save > ? http://hg.openjdk.java.net/jdk/jdk/rev/576058e9f728 > > 8041628: Javadoc cross-compilation problem > ? http://hg.openjdk.java.net/jdk/jdk/rev/ef280223e694 > > 8031427: AllocObject and Unsafe.allocateInstance segfault for primitive types > ? http://hg.openjdk.java.net/jdk/jdk/rev/1fc87ea15795 > > 8075492: adopt recent IGV > ? http://hg.openjdk.java.net/jdk/jdk/rev/b32fcc177417 > > 8012292: optimized build with GCC broken > ? http://hg.openjdk.java.net/jdk/jdk/rev/fec16b38217a > > 8003722: More gcc 4.7 compilation errors > ? http://hg.openjdk.java.net/jdk/jdk/rev/8427edf5a77b From jesper.wilhelmsson at oracle.com Tue Aug 28 19:28:59 2018 From: jesper.wilhelmsson at oracle.com (jesper.wilhelmsson at oracle.com) Date: Tue, 28 Aug 2018 21:28:59 +0200 Subject: JEP: Limit Speculative Execution - Draft published Message-ID: <51EBF203-E35F-4AA3-837A-B2081F35F968@oracle.com> FYI, I?ve published a draft JEP [1] to cover the work needed to limit speculative execution for Java applications. This JEP covers the initial work to make use of new C++ compiler options to limit speculative execution in native code in the JDK. Some changes related to this work have been through a first round of review [2]. The changes required to limit speculative execution in code generated by the JVM is in development, in collaboration with the OpenJDK Vulnerability Group, and details will be added to the JEP as the work progresses. [1] http://openjdk.java.net/jeps/8207206 [2] http://mail.openjdk.java.net/pipermail/build-dev/2018-June/022247.html Thanks, /Jesper From mark.reinhold at oracle.com Tue Aug 28 21:16:29 2018 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Tue, 28 Aug 2018 14:16:29 -0700 Subject: JEP proposed to target JDK 12: 325: Switch Expressions (Preview) In-Reply-To: <3906c197-ae9d-ee8f-7b91-4c0ccb70ef0d@kennke.org> References: <20180817174429.8BD3E207126@eggemoggin.niobe.net> <20180827161955.277660311@eggemoggin.niobe.net> <3906c197-ae9d-ee8f-7b91-4c0ccb70ef0d@kennke.org> Message-ID: <20180828141629.440418022@eggemoggin.niobe.net> 2018/8/27 16:46:55 -0700, Roman Kennke : >> 2018/8/17 10:44:29 -0700, mark.reinhold at oracle.com: >>> The following JEP is proposed to target JDK 12: >>> >>> 325: Switch Expressions (Preview) >>> http://openjdk.java.net/jeps/325 >>> >>> Feedback on this proposal is more than welcome, as are reasoned >>> objections. If no such objections are raised by 23:00 UTC on Friday, >>> 24 August, or if they?re raised and then satisfactorily answered, then >>> per the JEP 2.0 process proposal [1] I?ll target this JEP to JDK 12. >> >> The few objections raised here are not new, having already been raised >> and answered over on the amber-dev and amber-spec-experts lists. I?ve >> therefore targeted this JEP to JDK 12. > > I am not following amber-dev nor amber-spec-experts. I found the > objections raised here very reasonable, in particular the objection to > not include a controversial feature as 'preview' which would then > manifest itself by people using it. That a few people don?t like a feature does not make it ?controversial.? Aside from that, the very point of a preview language feature is to invite further feedback without completely committing to the current design, so of course people will use it (we hope!). They?re highly unlikely to use it in production, however, since preview features must be enabled explicitly, on the command line, at both compile time and run time [1]. We?re thus free to revise this design, based on new information, before it?s etched into the stone of the language. Yet ... > I can't see that those objections > have been 'satisfactorily answered'. If they have been satisfactorily > answered on any of the amber-* mailing lists, maybe it would be worth to > repeat that here for those of use who don't follow those lists. This is a fair point. We can?t expect everyone to follow the progress of every JEP in complete detail, so if objections to targeting a JEP are raised then it?s reasonable to ask its owner to summarize previous relevant discussions and answers in response -- which, in this case, Brian has now done. > I'd find > an answer satisfactory if those who raised it agree and state here that > they're ok. Here I must disagree. If someone makes a suggestion during the development of a JEP, and that suggestion is reasonably rejected at that time, then if they really, really want to they can re-raise that suggestion as an objection when the JEP is proposed to target a specific release. To require that the objection be answered to their satisfaction, however, would open the door to design by consensus, which I doubt anyone actually wants. In such a case it is reasonable to ask if Committers who didn?t raise the objection are satisfied with the answers as summarized by the JEP?s owner. (Even then, however, complete consensus is not a criterion for targeting.) So -- are you satisfied with Brian?s response? - Mark [1] http://openjdk.java.net/jeps/12#Example-use-of-preview-features From roman at kennke.org Tue Aug 28 22:13:04 2018 From: roman at kennke.org (Roman Kennke) Date: Wed, 29 Aug 2018 00:13:04 +0200 Subject: JEP proposed to target JDK 12: 325: Switch Expressions (Preview) In-Reply-To: <5e5df50e-1bb3-f743-30b7-05efdbe501e1@oracle.com> References: <20180817174429.8BD3E207126@eggemoggin.niobe.net> <20180827161955.277660311@eggemoggin.niobe.net> <5e5df50e-1bb3-f743-30b7-05efdbe501e1@oracle.com> Message-ID: <27322446-0584-e3e2-a68b-2b3372b125bf@kennke.org> Thank you, Brian, for your explanations. It does help me to understand the situation much better. Roman >> The few objections raised here are not new, having already been raised >> and answered over on the amber-dev and amber-spec-experts lists.? I?ve >> therefore targeted this JEP to JDK 12. >> > > As Mark says, the issues raised on this thread were already considered > and discussed at some length during the design of the feature.? But, for > the convenience of readers here, I will summarize for the record some of > the reasons why these suggestions were not incorporated into the final > design of the feature when they came around the first time. > > Stephen raised several specific objections, which I'll summarize as: > > ?- You're increasing complexity by adding three features, one of which > is silly, and which gives us more fallthrough rather than less, which is > surely a move in the wrong direction! > ?- I don't love the syntax. > ?- You should have created a new syntactic form (hereafter, "snitch", > for "new switch") and left classic switch for dead, rather than piling > more complexity on existing switch, because existing switch is > hopelessly tied to the dumb idea of fallthrough.? Die, fallthrough, die. > > Ben expressed general agreement, and specifically for the "you should > have killed switch and made something new" position.? While I understand > where these opinions come from, and we did consider these issues > seriously, we concluded that abstracting the existing switch construct > as we did was a better long-term path. > > Ben also raised the excellent point that language design is a balance > between the interests of experienced developers and of newcomers -- a > concern we struggle with in every single feature, and which also played > into our decision here. > > > The first sentiment, which I've seen expressed in a few places, relies > on a somewhat tortured notion of "feature".? We have not added three > features (enhanced statement switch, classic expression switch, enhanced > expression switch), as much as added _two_ features, defined at a very > different level: > > ?- The ability for switch to be an expression or a statement > ?- The choice of classic case labels or enhanced case labels, where the > latter are single consequent, fallthrough-free, and free of the > confusing scoping of the classic switch block (essentially, fixing most > of the things people complain about with respect to switch.) > > ?These features work orthogonally, so that you can mix and match them > freely, and I don't think anyone could reasonably object that either is > frivolous or undesirable.? So while they do give rise to four > combinations, these combinations are not features in themselves.? > Defining the improvements to switch as orthogonal choices makes the > design and implementation _simpler_, not more complex, as we can then > reason about the semantics of a particular combination based on the > semantics of simpler orthogonal primitives. > > The fact that some combinations of these features are more desirable > than others is not evidence that a mistake was made.? This is often the > natural consequence of providing simple primitives that can be combined > orthogonally; some of the combinations are always going to be more > sensible than others, and that's fine.? So while "classic expression > switch" may seem silly, and will almost certainly be rarely used in > practice, that doesn't mean that we should distort the language design > to prevent it.? In fact, doing so would increase, not decrease, the > complexity, as it introduces arbitrary constraints and special cases.? > (As a possibly tortured analogy, while we might almost never write a > combination of public setter and private getter, that's no reason to try > and outlaw that combination.) > > As to syntax preferences ... because syntax is so deeply subjective, > there is never going to be a syntax that satisfies everyone.? And, > people being what they are, they tend to only complain about the things > they disagree with, and are quiet about the things they agree with.? So > any syntax decision (whatever it is) is going to be met with some degree > of "I don't like it" or "I would have preferred X" -- but again, that > isn't necessarily actionable or dispositive.? The syntax choice we made > here is consistent with how similar things are done in similar languages > -- and we think it will, perhaps after a few days of initial > brain-retraining, be well-understood and accepted by Java developers. > > The final concern is a combination of pragmatism and language evolution > philosophy -- whether it is better to abandon an existing feature and > create a replacement, or to try and rehabilitate or generalize an > existing feature.? While we asked ourselves many times whether switch > could indeed be rehabilitated (not just in the context of this smaller > feature, but in the context of the bigger feature arc of pattern > matching), we found that, at each turn, it was more practical to > rehabilitate it than one might have initially thought.? And we felt it > better to build on the existing feature that is well understood and well > documented, than to create a wholly new one, just because the old one > was imperfect. > > Ben expressed concerns along the lines of "think of the students" with > respect to the proliferation of switch forms, but the reality with a > separate "snitch" form would most likely be worse.? Students would not > be fully absolved of the need to learn "old switch", not only because > they will encounter code that uses it, but because snitch would almost > certainly be tilted towards the "happy cases", which, while common, are > not universal.? And by un-anchoring snitch from switch, the differences > would likely be more arbitrary.? So new students would encounter a > language with two suspiciously similar constructs, but subtly different > in harder-to-understand ways, and wonder why there are two ways to do > it.? The burning hulk of "old switch" would lie forever on the roadside, > but unable to be ever hauled away.? Its nice to think that we can invent > the ideal "snitch" construct, and just leave "switch" in the past, but > that's a fantasy. > > Now, if switch were truly broken, it might be different.? But for all > the distaste of fallthrough-by-default, the existing switch construct is > _not_ fundamentally broken; it's not just what we'd design now if we had > a clean sheet of paper.? (BTW, fallthrough itself is not a problem, and > sometimes is essential; the real mistake was fallthrough _by default_.)? > Therefore, while we did consider whether it would be necessary to retire > "switch" to pasture, we found no evidence that this was actually > necessary -- and found that it was possible to enhance switch to support > all the desired behaviors, rather than to abandon it, however tempting > the latter course might initially seem.? Enhancing switch builds on the > existing understanding of Java developers; abandoning it for snitch > invalidates that understanding. > > At a meta level, this inclination -- "just abandon switch and build > something better" -- illustrates a common temptation that is best > avoided: over-rotating towards the desire to "fix" the mistakes of the > past because they offend us, and because the current opportunity seems > "the last chance" to right a wrong that's been bugging us for years.? > These are natural motivations, but they are frequently siren-songs that > lure us away from the path that calmer reason might otherwise have > chosen.? Yes, it would have been better if switch were designed > differently 20 years ago, but that was billions of programmer-hours and > lines of code ago, and the calculus is very different with such a large > existing base of code and user understanding.? So, while I understand > why it feels like an "opportunity missed", the cost of "seizing" this > opportunity was too great, and the benefit too small.? Its natural to > regret that we can't fix the mistakes of the past, but in this case, it > would have been the wrong choice. > > The preview mechanism will allow us to gather feedback on the feature > from actual use, rather than theorizing from no examples, and > potentially adjust the specification before final release if warranted.? > So if any _new_ issues up come as a result of actual experience, we are > happy to hear about them. > > > From scolebourne at joda.org Tue Aug 28 22:14:28 2018 From: scolebourne at joda.org (Stephen Colebourne) Date: Tue, 28 Aug 2018 23:14:28 +0100 Subject: JEP proposed to target JDK 12: 325: Switch Expressions (Preview) In-Reply-To: <20180828141629.440418022@eggemoggin.niobe.net> References: <20180817174429.8BD3E207126@eggemoggin.niobe.net> <20180827161955.277660311@eggemoggin.niobe.net> <3906c197-ae9d-ee8f-7b91-4c0ccb70ef0d@kennke.org> <20180828141629.440418022@eggemoggin.niobe.net> Message-ID: On Tue, 28 Aug 2018 at 22:17, wrote: > 2018/8/27 16:46:55 -0700, Roman Kennke : > > I'd find > > an answer satisfactory if those who raised it agree and state here that > > they're ok. > > Here I must disagree. > > If someone makes a suggestion during the development of a JEP, and that > suggestion is reasonably rejected at that time, then if they really, > really want to they can re-raise that suggestion as an objection when > the JEP is proposed to target a specific release. To require that the > objection be answered to their satisfaction, however, would open the > door to design by consensus, which I doubt anyone actually wants. I agree with Mark here in that it is perfectly OK to consider objections and move on. I'm not going to be convinced that the proposed change is the best choice for Java. Brian's explanation is reasonable enough and I won't argue it point-by-point (despite the pejorative "snitch"). I just happen to believe that once the good conclusions were reached in basic semantic terms, the final leap as to the implications of those semantics was not taken. If it had been, the further syntactic simplification I proposed was there for the taking, something that I firmly believe would have been in the long term interests of Java (and where Brian and I simply disagree). I've made my point, and so has Ben. Without further input, it has to be time to move on. Stephen From roman at kennke.org Tue Aug 28 22:19:40 2018 From: roman at kennke.org (Roman Kennke) Date: Wed, 29 Aug 2018 00:19:40 +0200 Subject: JEP proposed to target JDK 12: 325: Switch Expressions (Preview) In-Reply-To: <20180828141629.440418022@eggemoggin.niobe.net> References: <20180817174429.8BD3E207126@eggemoggin.niobe.net> <20180827161955.277660311@eggemoggin.niobe.net> <3906c197-ae9d-ee8f-7b91-4c0ccb70ef0d@kennke.org> <20180828141629.440418022@eggemoggin.niobe.net> Message-ID: >>>> The following JEP is proposed to target JDK 12: >>>> >>>> 325: Switch Expressions (Preview) >>>> http://openjdk.java.net/jeps/325 >>>> >>>> Feedback on this proposal is more than welcome, as are reasoned >>>> objections. If no such objections are raised by 23:00 UTC on Friday, >>>> 24 August, or if they?re raised and then satisfactorily answered, then >>>> per the JEP 2.0 process proposal [1] I?ll target this JEP to JDK 12. >>> >>> The few objections raised here are not new, having already been raised >>> and answered over on the amber-dev and amber-spec-experts lists. I?ve >>> therefore targeted this JEP to JDK 12. >> >> I am not following amber-dev nor amber-spec-experts. I found the >> objections raised here very reasonable, in particular the objection to >> not include a controversial feature as 'preview' which would then >> manifest itself by people using it. > > That a few people don?t like a feature does not make it ?controversial.? > > Aside from that, the very point of a preview language feature is to > invite further feedback without completely committing to the current > design, so of course people will use it (we hope!). They?re highly > unlikely to use it in production, however, since preview features must > be enabled explicitly, on the command line, at both compile time and > run time [1]. We?re thus free to revise this design, based on new > information, before it?s etched into the stone of the language. I was not fully aware of the implications of 'preview feature', that it has to be enabled at compile&runtime and so on. Thanks for the pointer. > Yet ... > >> I can't see that those objections >> have been 'satisfactorily answered'. If they have been satisfactorily >> answered on any of the amber-* mailing lists, maybe it would be worth to >> repeat that here for those of use who don't follow those lists. > > This is a fair point. We can?t expect everyone to follow the progress > of every JEP in complete detail, so if objections to targeting a JEP > are raised then it?s reasonable to ask its owner to summarize previous > relevant discussions and answers in response -- which, in this case, > Brian has now done. Yes, thank you! >> an answer satisfactory if those who raised it agree and state here that >> they're ok. > > Here I must disagree. > > If someone makes a suggestion during the development of a JEP, and that > suggestion is reasonably rejected at that time, then if they really, > really want to they can re-raise that suggestion as an objection when > the JEP is proposed to target a specific release. To require that the > objection be answered to their satisfaction, however, would open the > door to design by consensus, which I doubt anyone actually wants. Hmm, totally true. > In such a case it is reasonable to ask if Committers who didn?t raise > the objection are satisfied with the answers as summarized by the JEP?s > owner. (Even then, however, complete consensus is not a criterion for > targeting.) > > So -- are you satisfied with Brian?s response? I am. Thank you and Brian. Roman From roman at kennke.org Tue Aug 28 22:33:00 2018 From: roman at kennke.org (Roman Kennke) Date: Wed, 29 Aug 2018 00:33:00 +0200 Subject: JEP proposed to target JDK 12: 325: Switch Expressions (Preview) In-Reply-To: <3906c197-ae9d-ee8f-7b91-4c0ccb70ef0d@kennke.org> References: <20180817174429.8BD3E207126@eggemoggin.niobe.net> <20180827161955.277660311@eggemoggin.niobe.net> <3906c197-ae9d-ee8f-7b91-4c0ccb70ef0d@kennke.org> Message-ID: <0e92c4cc-98d5-4cb9-592e-d6e9be7395ab@kennke.org> > an answer satisfactory if those who raised it agree and state here that > they're ok. In particular, I don't actually see any need to include a > half-baked (language-) feature as preview. I did not want to come across harsh and devalue the many hours of work that went into the project by the various contributors. Please accept my apology. My criticism was in no way intended to target the amber project or the JEP 325 in question here. From my outside perspective it just seemed to me that a few people raised objections to targeting the JEP to JDK 12, those objections have not (in my perception) been adequately addressed, and then the JEP has simply been accepted to target JDK 12. It did seem bit heavy-handed to me. Brian's and Mark's comments did help to understand the situation better. Thanks! Roman From john.r.rose at oracle.com Tue Aug 28 23:18:58 2018 From: john.r.rose at oracle.com (John Rose) Date: Tue, 28 Aug 2018 16:18:58 -0700 Subject: JEP proposed to target JDK 12: 325: Switch Expressions (Preview) In-Reply-To: <0e92c4cc-98d5-4cb9-592e-d6e9be7395ab@kennke.org> References: <20180817174429.8BD3E207126@eggemoggin.niobe.net> <20180827161955.277660311@eggemoggin.niobe.net> <3906c197-ae9d-ee8f-7b91-4c0ccb70ef0d@kennke.org> <0e92c4cc-98d5-4cb9-592e-d6e9be7395ab@kennke.org> Message-ID: <15103D75-95E4-4404-8BC5-1FEF1D52B946@oracle.com> To those of us in the loop on the switch/snitch design, a very long loop, this decision process does not seem heavy handed at all. The detailed discussion happens elsewhere than jdk-dev and anybody can subscribe or browse amber-dev to see, if not all of it (which would be impossible unless cameras followed all of us around), at least all relevant checkpoints and public comments and discussion. It is necessary to division of labor for stuff to happen in tidy corners like amber-dev. Meanwhile this list jdk-dev summarizes that work and formalizes decisions. Formality on one channel doesn?t imply abruptness if discussion has competed in another channel. And we wouldn?t expect to micro-manage or re-discuss or re-litigate lower level decisions on this list unless the lower level list were unusually dysfunctional ? which it isn?t, in my opinion. HTH ? John On Aug 28, 2018, at 3:33 PM, Roman Kennke wrote: > > >> an answer satisfactory if those who raised it agree and state here that >> they're ok. In particular, I don't actually see any need to include a >> half-baked (language-) feature as preview. > > I did not want to come across harsh and devalue the many hours of work > that went into the project by the various contributors. Please accept my > apology. My criticism was in no way intended to target the amber project > or the JEP 325 in question here. > > From my outside perspective it just seemed to me that a few people > raised objections to targeting the JEP to JDK 12, those objections have > not (in my perception) been adequately addressed, and then the JEP has > simply been accepted to target JDK 12. It did seem bit heavy-handed to > me. Brian's and Mark's comments did help to understand the situation > better. Thanks! > > Roman > > > > From benjamin.john.evans at gmail.com Tue Aug 28 23:51:34 2018 From: benjamin.john.evans at gmail.com (Ben Evans) Date: Tue, 28 Aug 2018 19:51:34 -0400 Subject: JEP proposed to target JDK 12: 325: Switch Expressions (Preview) In-Reply-To: <5e5df50e-1bb3-f743-30b7-05efdbe501e1@oracle.com> References: <20180817174429.8BD3E207126@eggemoggin.niobe.net> <20180827161955.277660311@eggemoggin.niobe.net> <5e5df50e-1bb3-f743-30b7-05efdbe501e1@oracle.com> Message-ID: Thank you Brian for taking the time to lay out the reasoning. I'm going to have to disagree with the conclusions that you've reached, but we definitely need to move on. The only other point I wanted to make is that I think it is rather unfortunate that the first Preview language feature we're getting is this one, as it is so obviously a foundational feature for something much more far-reaching. I worry that, far from being an area where we can change course based on experience, once this has shipped in 12 it will basically become an invitation for Sunk Cost Fallacy reasoning, regardless of how usable the feature is in practice. I guess we'll find out in March... Thanks, Ben On Mon, 27 Aug 2018 at 20:05, Brian Goetz wrote: > > > > > > The few objections raised here are not new, having already been raised > > and answered over on the amber-dev and amber-spec-experts lists. I?ve > > therefore targeted this JEP to JDK 12. > > > > As Mark says, the issues raised on this thread were already considered > and discussed at some length during the design of the feature. But, for > the convenience of readers here, I will summarize for the record some of > the reasons why these suggestions were not incorporated into the final > design of the feature when they came around the first time. > > Stephen raised several specific objections, which I'll summarize as: > > - You're increasing complexity by adding three features, one of which > is silly, and which gives us more fallthrough rather than less, which is > surely a move in the wrong direction! > - I don't love the syntax. > - You should have created a new syntactic form (hereafter, "snitch", > for "new switch") and left classic switch for dead, rather than piling > more complexity on existing switch, because existing switch is > hopelessly tied to the dumb idea of fallthrough. Die, fallthrough, die. > > Ben expressed general agreement, and specifically for the "you should > have killed switch and made something new" position. While I understand > where these opinions come from, and we did consider these issues > seriously, we concluded that abstracting the existing switch construct > as we did was a better long-term path. > > Ben also raised the excellent point that language design is a balance > between the interests of experienced developers and of newcomers -- a > concern we struggle with in every single feature, and which also played > into our decision here. > > > The first sentiment, which I've seen expressed in a few places, relies > on a somewhat tortured notion of "feature". We have not added three > features (enhanced statement switch, classic expression switch, enhanced > expression switch), as much as added _two_ features, defined at a very > different level: > > - The ability for switch to be an expression or a statement > - The choice of classic case labels or enhanced case labels, where the > latter are single consequent, fallthrough-free, and free of the > confusing scoping of the classic switch block (essentially, fixing most > of the things people complain about with respect to switch.) > > These features work orthogonally, so that you can mix and match them > freely, and I don't think anyone could reasonably object that either is > frivolous or undesirable. So while they do give rise to four > combinations, these combinations are not features in themselves. > Defining the improvements to switch as orthogonal choices makes the > design and implementation _simpler_, not more complex, as we can then > reason about the semantics of a particular combination based on the > semantics of simpler orthogonal primitives. > > The fact that some combinations of these features are more desirable > than others is not evidence that a mistake was made. This is often the > natural consequence of providing simple primitives that can be combined > orthogonally; some of the combinations are always going to be more > sensible than others, and that's fine. So while "classic expression > switch" may seem silly, and will almost certainly be rarely used in > practice, that doesn't mean that we should distort the language design > to prevent it. In fact, doing so would increase, not decrease, the > complexity, as it introduces arbitrary constraints and special cases. > (As a possibly tortured analogy, while we might almost never write a > combination of public setter and private getter, that's no reason to try > and outlaw that combination.) > > As to syntax preferences ... because syntax is so deeply subjective, > there is never going to be a syntax that satisfies everyone. And, > people being what they are, they tend to only complain about the things > they disagree with, and are quiet about the things they agree with. So > any syntax decision (whatever it is) is going to be met with some degree > of "I don't like it" or "I would have preferred X" -- but again, that > isn't necessarily actionable or dispositive. The syntax choice we made > here is consistent with how similar things are done in similar languages > -- and we think it will, perhaps after a few days of initial > brain-retraining, be well-understood and accepted by Java developers. > > The final concern is a combination of pragmatism and language evolution > philosophy -- whether it is better to abandon an existing feature and > create a replacement, or to try and rehabilitate or generalize an > existing feature. While we asked ourselves many times whether switch > could indeed be rehabilitated (not just in the context of this smaller > feature, but in the context of the bigger feature arc of pattern > matching), we found that, at each turn, it was more practical to > rehabilitate it than one might have initially thought. And we felt it > better to build on the existing feature that is well understood and well > documented, than to create a wholly new one, just because the old one > was imperfect. > > Ben expressed concerns along the lines of "think of the students" with > respect to the proliferation of switch forms, but the reality with a > separate "snitch" form would most likely be worse. Students would not > be fully absolved of the need to learn "old switch", not only because > they will encounter code that uses it, but because snitch would almost > certainly be tilted towards the "happy cases", which, while common, are > not universal. And by un-anchoring snitch from switch, the differences > would likely be more arbitrary. So new students would encounter a > language with two suspiciously similar constructs, but subtly different > in harder-to-understand ways, and wonder why there are two ways to do > it. The burning hulk of "old switch" would lie forever on the roadside, > but unable to be ever hauled away. Its nice to think that we can invent > the ideal "snitch" construct, and just leave "switch" in the past, but > that's a fantasy. > > Now, if switch were truly broken, it might be different. But for all > the distaste of fallthrough-by-default, the existing switch construct is > _not_ fundamentally broken; it's not just what we'd design now if we had > a clean sheet of paper. (BTW, fallthrough itself is not a problem, and > sometimes is essential; the real mistake was fallthrough _by default_.) > Therefore, while we did consider whether it would be necessary to retire > "switch" to pasture, we found no evidence that this was actually > necessary -- and found that it was possible to enhance switch to support > all the desired behaviors, rather than to abandon it, however tempting > the latter course might initially seem. Enhancing switch builds on the > existing understanding of Java developers; abandoning it for snitch > invalidates that understanding. > > At a meta level, this inclination -- "just abandon switch and build > something better" -- illustrates a common temptation that is best > avoided: over-rotating towards the desire to "fix" the mistakes of the > past because they offend us, and because the current opportunity seems > "the last chance" to right a wrong that's been bugging us for years. > These are natural motivations, but they are frequently siren-songs that > lure us away from the path that calmer reason might otherwise have > chosen. Yes, it would have been better if switch were designed > differently 20 years ago, but that was billions of programmer-hours and > lines of code ago, and the calculus is very different with such a large > existing base of code and user understanding. So, while I understand > why it feels like an "opportunity missed", the cost of "seizing" this > opportunity was too great, and the benefit too small. Its natural to > regret that we can't fix the mistakes of the past, but in this case, it > would have been the wrong choice. > > The preview mechanism will allow us to gather feedback on the feature > from actual use, rather than theorizing from no examples, and > potentially adjust the specification before final release if warranted. > So if any _new_ issues up come as a result of actual experience, we are > happy to hear about them. > > From rschmitt at pobox.com Wed Aug 29 00:06:48 2018 From: rschmitt at pobox.com (Ryan Schmitt) Date: Tue, 28 Aug 2018 17:06:48 -0700 Subject: JEP proposed to target JDK 12: 325: Switch Expressions (Preview) In-Reply-To: References: <20180817174429.8BD3E207126@eggemoggin.niobe.net> <20180827161955.277660311@eggemoggin.niobe.net> <5e5df50e-1bb3-f743-30b7-05efdbe501e1@oracle.com> Message-ID: I seem to recall that people made similar predictions about the six-month release train, that it wouldn't work because the temptation to deviate from the basic principle would be too great. And yet it seems to be working so far, so I don't really see any cause for concern over experimental language features. On Tue, Aug 28, 2018 at 4:51 PM, Ben Evans wrote: > Thank you Brian for taking the time to lay out the reasoning. > > I'm going to have to disagree with the conclusions that you've > reached, but we definitely need to move on. > > The only other point I wanted to make is that I think it is rather > unfortunate that the first Preview language feature we're getting is > this one, as it is so obviously a foundational feature for something > much more far-reaching. I worry that, far from being an area where we > can change course based on experience, once this has shipped in 12 it > will basically become an invitation for Sunk Cost Fallacy reasoning, > regardless of how usable the feature is in practice. I guess we'll > find out in March... > > Thanks, > > Ben > > On Mon, 27 Aug 2018 at 20:05, Brian Goetz wrote: > > > > > > > > > > The few objections raised here are not new, having already been raised > > > and answered over on the amber-dev and amber-spec-experts lists. I?ve > > > therefore targeted this JEP to JDK 12. > > > > > > > As Mark says, the issues raised on this thread were already considered > > and discussed at some length during the design of the feature. But, for > > the convenience of readers here, I will summarize for the record some of > > the reasons why these suggestions were not incorporated into the final > > design of the feature when they came around the first time. > > > > Stephen raised several specific objections, which I'll summarize as: > > > > - You're increasing complexity by adding three features, one of which > > is silly, and which gives us more fallthrough rather than less, which is > > surely a move in the wrong direction! > > - I don't love the syntax. > > - You should have created a new syntactic form (hereafter, "snitch", > > for "new switch") and left classic switch for dead, rather than piling > > more complexity on existing switch, because existing switch is > > hopelessly tied to the dumb idea of fallthrough. Die, fallthrough, die. > > > > Ben expressed general agreement, and specifically for the "you should > > have killed switch and made something new" position. While I understand > > where these opinions come from, and we did consider these issues > > seriously, we concluded that abstracting the existing switch construct > > as we did was a better long-term path. > > > > Ben also raised the excellent point that language design is a balance > > between the interests of experienced developers and of newcomers -- a > > concern we struggle with in every single feature, and which also played > > into our decision here. > > > > > > The first sentiment, which I've seen expressed in a few places, relies > > on a somewhat tortured notion of "feature". We have not added three > > features (enhanced statement switch, classic expression switch, enhanced > > expression switch), as much as added _two_ features, defined at a very > > different level: > > > > - The ability for switch to be an expression or a statement > > - The choice of classic case labels or enhanced case labels, where the > > latter are single consequent, fallthrough-free, and free of the > > confusing scoping of the classic switch block (essentially, fixing most > > of the things people complain about with respect to switch.) > > > > These features work orthogonally, so that you can mix and match them > > freely, and I don't think anyone could reasonably object that either is > > frivolous or undesirable. So while they do give rise to four > > combinations, these combinations are not features in themselves. > > Defining the improvements to switch as orthogonal choices makes the > > design and implementation _simpler_, not more complex, as we can then > > reason about the semantics of a particular combination based on the > > semantics of simpler orthogonal primitives. > > > > The fact that some combinations of these features are more desirable > > than others is not evidence that a mistake was made. This is often the > > natural consequence of providing simple primitives that can be combined > > orthogonally; some of the combinations are always going to be more > > sensible than others, and that's fine. So while "classic expression > > switch" may seem silly, and will almost certainly be rarely used in > > practice, that doesn't mean that we should distort the language design > > to prevent it. In fact, doing so would increase, not decrease, the > > complexity, as it introduces arbitrary constraints and special cases. > > (As a possibly tortured analogy, while we might almost never write a > > combination of public setter and private getter, that's no reason to try > > and outlaw that combination.) > > > > As to syntax preferences ... because syntax is so deeply subjective, > > there is never going to be a syntax that satisfies everyone. And, > > people being what they are, they tend to only complain about the things > > they disagree with, and are quiet about the things they agree with. So > > any syntax decision (whatever it is) is going to be met with some degree > > of "I don't like it" or "I would have preferred X" -- but again, that > > isn't necessarily actionable or dispositive. The syntax choice we made > > here is consistent with how similar things are done in similar languages > > -- and we think it will, perhaps after a few days of initial > > brain-retraining, be well-understood and accepted by Java developers. > > > > The final concern is a combination of pragmatism and language evolution > > philosophy -- whether it is better to abandon an existing feature and > > create a replacement, or to try and rehabilitate or generalize an > > existing feature. While we asked ourselves many times whether switch > > could indeed be rehabilitated (not just in the context of this smaller > > feature, but in the context of the bigger feature arc of pattern > > matching), we found that, at each turn, it was more practical to > > rehabilitate it than one might have initially thought. And we felt it > > better to build on the existing feature that is well understood and well > > documented, than to create a wholly new one, just because the old one > > was imperfect. > > > > Ben expressed concerns along the lines of "think of the students" with > > respect to the proliferation of switch forms, but the reality with a > > separate "snitch" form would most likely be worse. Students would not > > be fully absolved of the need to learn "old switch", not only because > > they will encounter code that uses it, but because snitch would almost > > certainly be tilted towards the "happy cases", which, while common, are > > not universal. And by un-anchoring snitch from switch, the differences > > would likely be more arbitrary. So new students would encounter a > > language with two suspiciously similar constructs, but subtly different > > in harder-to-understand ways, and wonder why there are two ways to do > > it. The burning hulk of "old switch" would lie forever on the roadside, > > but unable to be ever hauled away. Its nice to think that we can invent > > the ideal "snitch" construct, and just leave "switch" in the past, but > > that's a fantasy. > > > > Now, if switch were truly broken, it might be different. But for all > > the distaste of fallthrough-by-default, the existing switch construct is > > _not_ fundamentally broken; it's not just what we'd design now if we had > > a clean sheet of paper. (BTW, fallthrough itself is not a problem, and > > sometimes is essential; the real mistake was fallthrough _by default_.) > > Therefore, while we did consider whether it would be necessary to retire > > "switch" to pasture, we found no evidence that this was actually > > necessary -- and found that it was possible to enhance switch to support > > all the desired behaviors, rather than to abandon it, however tempting > > the latter course might initially seem. Enhancing switch builds on the > > existing understanding of Java developers; abandoning it for snitch > > invalidates that understanding. > > > > At a meta level, this inclination -- "just abandon switch and build > > something better" -- illustrates a common temptation that is best > > avoided: over-rotating towards the desire to "fix" the mistakes of the > > past because they offend us, and because the current opportunity seems > > "the last chance" to right a wrong that's been bugging us for years. > > These are natural motivations, but they are frequently siren-songs that > > lure us away from the path that calmer reason might otherwise have > > chosen. Yes, it would have been better if switch were designed > > differently 20 years ago, but that was billions of programmer-hours and > > lines of code ago, and the calculus is very different with such a large > > existing base of code and user understanding. So, while I understand > > why it feels like an "opportunity missed", the cost of "seizing" this > > opportunity was too great, and the benefit too small. Its natural to > > regret that we can't fix the mistakes of the past, but in this case, it > > would have been the wrong choice. > > > > The preview mechanism will allow us to gather feedback on the feature > > from actual use, rather than theorizing from no examples, and > > potentially adjust the specification before final release if warranted. > > So if any _new_ issues up come as a result of actual experience, we are > > happy to hear about them. > > > > > From brian.goetz at oracle.com Wed Aug 29 00:21:12 2018 From: brian.goetz at oracle.com (Brian Goetz) Date: Tue, 28 Aug 2018 20:21:12 -0400 Subject: JEP proposed to target JDK 12: 325: Switch Expressions (Preview) In-Reply-To: References: <20180817174429.8BD3E207126@eggemoggin.niobe.net> <20180827161955.277660311@eggemoggin.niobe.net> <5e5df50e-1bb3-f743-30b7-05efdbe501e1@oracle.com> Message-ID: <64e6c4a0-e754-9df4-68ee-435d2d3b7684@oracle.com> I think there's a lot of misunderstanding about what Preview is, and is for, floating around. A Preview language feature still needs to be Done, to the same level of Done, as a permanent feature.? The difference is that we have a (short) "grace period" where we have a chance to correct serious errors that have leaked past the usual process, without having to pay the Incompatibility Penalty.? With our new cadence, I expect that most non-trivial language features will go through the Preview mechanism going forward.? This does not mean they are experimental, or of lower quality, or have had less thought put into them.? But, it does sometimes happen that we discover unexpected interactions only after things have been tried by a broader audience, and for this, Preview gives us a short window to correct such issues if they are found early enough. As to "but this is really just a foundation for a bigger feature", I think that will also be true of many more features in this new world, because the rapid cadence encourages us to break things down into smaller chunks where possible.? This feature did "sediment out" from the broader pattern match effort for earlier delivery (and we actually narrowed the scope several times during the sedimentation process) but, while it is clearly needed by pattern matching, it is also darn useful on its own! So, I don't think there's anything unfortunate at all here -- this is just the New World, where we deliver smaller features, more often, and vet them through a Preview process where we have an opportunity to take a mulligan if we really borked things up (but we expect most of the time, we won't need this parachute.) On 8/28/2018 7:51 PM, Ben Evans wrote: > The only other point I wanted to make is that I think it is rather > unfortunate that the first Preview language feature we're getting is > this one, as it is so obviously a foundational feature for something > much more far-reaching. I worry that, far from being an area where we > can change course based on experience, once this has shipped in 12 it > will basically become an invitation for Sunk Cost Fallacy reasoning, > regardless of how usable the feature is in practice. I guess we'll > find out in March... From joe.darcy at oracle.com Wed Aug 29 00:55:24 2018 From: joe.darcy at oracle.com (Joseph D. Darcy) Date: Tue, 28 Aug 2018 17:55:24 -0700 Subject: JEP proposed to target JDK 12: 325: Switch Expressions (Preview) In-Reply-To: <64e6c4a0-e754-9df4-68ee-435d2d3b7684@oracle.com> References: <20180817174429.8BD3E207126@eggemoggin.niobe.net> <20180827161955.277660311@eggemoggin.niobe.net> <5e5df50e-1bb3-f743-30b7-05efdbe501e1@oracle.com> <64e6c4a0-e754-9df4-68ee-435d2d3b7684@oracle.com> Message-ID: <5B85EEFC.5010805@oracle.com> Hello, On 8/28/2018 5:21 PM, Brian Goetz wrote: > I think there's a lot of misunderstanding about what Preview is, and > is for, floating around. > > A Preview language feature still needs to be Done, to the same level > of Done, as a permanent feature. The difference is that we have a > (short) "grace period" where we have a chance to correct serious > errors that have leaked past the usual process, without having to pay > the Incompatibility Penalty. With our new cadence, I expect that most > non-trivial language features will go through the Preview mechanism > going forward. This does not mean they are experimental, or of lower > quality, or have had less thought put into them. But, it does > sometimes happen that we discover unexpected interactions only after > things have been tried by a broader audience, and for this, Preview > gives us a short window to correct such issues if they are found early > enough. [snip] I'll again [1] offer an example of the benefit of having a grace period of some sort for developing language changes. Back during Project Coin, the initial production-ready, well-tested, and fully-spec'ed implementation of try-with-resources threw a NullPointerException if the resource being managed was null. Five months after builds with this implementation were available, we received compelling feedback that it would be better for the try-with-resources statement to ignore a null resource. We consciously considered what to do about nulls at the beginning, but in response to feedback from experience using the feature, we changed our minds. The release schedule of JDK 7 accommodated changing the null handing, but we would have preferred the feedback sooner of course. If we had received the feedback a few months later than we did, we would have faced the unattractive choice of keeping a suboptimal design or breaking behavioral compatibility of a language feature. Under the new six month release cadence, the preview language feature mechanism both provides additional time for developers to provide feedback and for the language development team to act on it. -Joe [1] http://mail.openjdk.java.net/pipermail/jdk-dev/2018-January/000547.html From jiangli.zhou at oracle.com Wed Aug 29 01:32:59 2018 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Tue, 28 Aug 2018 18:32:59 -0700 Subject: RFR: JDK-8202951: Implementation of JEPJDK-8204247: Include default CDS (Class Data Sharing) archive in JDK binary In-Reply-To: <1af91463-05f5-30ed-7ef0-eeb558e12451@oracle.com> References: <979f56e4-07b4-8c52-c426-6ca5a839b6a3@oracle.com> <1af91463-05f5-30ed-7ef0-eeb558e12451@oracle.com> Message-ID: Here is the updated webre with CheckDefaultArchiveFile.java changes. ? http://cr.openjdk.java.net/~jiangli/8202951/webrev.01/ Thanks, Jiangli On 8/28/18 11:09 AM, Jiangli Zhou wrote: > On 8/28/18 9:33 AM, Ioi Lam wrote: >> The JVM and test changes look good. I just have one comment: >> >> >> CheckDefaultArchiveFile.java >> >> ? 51????? if (!Platform.isDefaultCDSArchiveSupported()) { >> ? 52???????????? if (Files.notExists(jsa)) { >> ? 53???????????????? System.out.println("Passed. " + vmString + >> ? 54??????????????????????????????????? ": no default classes.jsa >> file"); >> ? 55???????????? } else { >> ? 56???????????????? throw new RuntimeException(vmString + "contains >> " + jsaString); >> ? 57???????????? } >> >> >> People may manually do "java -Xshare:dump" on their own platforms and >> them run the hotspot tests. It seems too strict to treat this as an >> error. >> >> I think this block should be removed. > That's probably a common scenario. I agree, it is too strict. Will > remove the block. > > Thanks! > > Jiangli > >> >> Thanks >> >> - Ioi >> >> >> On 8/28/18 9:25 AM, Erik Joelsson wrote: >>> Build changes look good to me (but should probably get review from >>> someone else). >>> >>> /Erik >>> >>> >>> On 2018-08-27 13:33, Jiangli Zhou wrote: >>>> Please review the implementation for JEP JDK-8204247 >>>> (https://bugs.openjdk.java.net/browse/JDK-8204247). The goal of the >>>> JEP is to include a default CDS archive in JDK 12 binary >>>> distribution (downloadable from http://jdk.java.net/12/). The >>>> default CDS archive is generated using the default classlist >>>> (resides in the lib/ directory) at JDK build time. Any >>>> comments/suggestions are highly appreciated. >>>> >>>> All makefile changes in the webrev are contributed by Erik Joelsson >>>> (many thanks!!). >>>> >>>> This is a combination of efforts from different teams and >>>> individuals. Thanks to everyone who has been involved in the JEP & >>>> implementation discussions, testing and bug fixing! >>>> >>>> ? JEP: https://bugs.openjdk.java.net/browse/JDK-8204247 >>>> ? RFE: https://bugs.openjdk.java.net/browse/JDK-8202951 >>>> ? webrev: http://cr.openjdk.java.net/~jiangli/8202951/webrev.00/ >>>> >>>> Two sanity test cases for the default CDS archive are included >>>> test/hotspot/jtreg/runtime/SharedArchiveFile. They are not intended >>>> for in-depth CDS functional testing, which is already covered by >>>> the existing cds/appcds tests and all tiered tests executing with >>>> the default CDS archive enabled. >>>> >>>> As part of the webrev, >>>> test/jdk/javax/imageio/plugins/png/ItxtUtf8Test.java is also fixed >>>> to use larger java heap (JDK-8209739 >>>> , https://bugs.openjdk.java.net/browse/JDK-8209739). >>>> >>>> Tests executed: >>>> ?- several rounds of tier1 - tier8 via mach5 >>>> ?- JCK lang, api and vm tests via mach5 >>>> >>>> >>>> Thanks! >>>> Calvin, Ioi, Jiangli >>>> >>>> >>> >> > From naoto.sato at oracle.com Wed Aug 29 01:37:48 2018 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Tue, 28 Aug 2018 18:37:48 -0700 Subject: CFV: New JDK Committer: Leo Jiang Message-ID: <3b449fd5-bbdb-c67a-a68f-bcabd8cfa105@oracle.com> I hereby nominate Leo Jiang (ljiang) to JDK Committer. Leo works for the Oracle localization team and has contributed more than 30 changes. His contributions can be found here [3]. Votes are due by 19:00 pm PT, September 11, 2018. Only current JDK Committers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [2]. Naoto Sato [1] http://openjdk.java.net/census [2] http://openjdk.java.net/projects/#committer-vote [3] http://hg.openjdk.java.net/jdk/jdk/log?revcount=100&rev=(keyword(%22li.jiang%40oracle.com%22)+or+author(ljiang)) From eric.caspole at oracle.com Wed Aug 29 02:40:36 2018 From: eric.caspole at oracle.com (Eric Caspole) Date: Tue, 28 Aug 2018 22:40:36 -0400 Subject: CFV: New JDK Committer: Leo Jiang In-Reply-To: <3b449fd5-bbdb-c67a-a68f-bcabd8cfa105@oracle.com> References: <3b449fd5-bbdb-c67a-a68f-bcabd8cfa105@oracle.com> Message-ID: <5c850084-b90b-b4b7-985b-2f4159e97dd1@oracle.com> Vote: yes Regards, Eric On 8/28/2018 9:37 PM, naoto.sato at oracle.com wrote: > I hereby nominate Leo Jiang (ljiang) to JDK Committer. > > Leo works for the Oracle localization team and has contributed more > than 30 changes. His contributions can be found here [3]. > > Votes are due by 19:00 pm PT, September 11, 2018. > > Only current JDK Committers [1] are eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Naoto Sato > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] > http://hg.openjdk.java.net/jdk/jdk/log?revcount=100&rev=(keyword(%22li.jiang%40oracle.com%22)+or+author(ljiang)) From huizhe.wang at oracle.com Wed Aug 29 04:07:35 2018 From: huizhe.wang at oracle.com (Joe Wang) Date: Tue, 28 Aug 2018 21:07:35 -0700 Subject: CFV: New JDK Committer: Leo Jiang In-Reply-To: <3b449fd5-bbdb-c67a-a68f-bcabd8cfa105@oracle.com> References: <3b449fd5-bbdb-c67a-a68f-bcabd8cfa105@oracle.com> Message-ID: <5B861C07.3070403@oracle.com> Vote: yes Best, Joe (userid: joehw) On 8/28/18, 6:37 PM, naoto.sato at oracle.com wrote: > I hereby nominate Leo Jiang (ljiang) to JDK Committer. > From ioi.lam at oracle.com Wed Aug 29 04:17:04 2018 From: ioi.lam at oracle.com (Ioi Lam) Date: Tue, 28 Aug 2018 21:17:04 -0700 Subject: RFR: JDK-8202951: Implementation of JEPJDK-8204247: Include default CDS (Class Data Sharing) archive in JDK binary In-Reply-To: References: <979f56e4-07b4-8c52-c426-6ca5a839b6a3@oracle.com> <1af91463-05f5-30ed-7ef0-eeb558e12451@oracle.com> Message-ID: <3aee8562-5c41-fcf7-1565-5e45566c2e0a@oracle.com> Looks good. Thanks! - Ioi On 8/28/18 6:32 PM, Jiangli Zhou wrote: > Here is the updated webre with CheckDefaultArchiveFile.java changes. > > ? http://cr.openjdk.java.net/~jiangli/8202951/webrev.01/ > > Thanks, > Jiangli > > On 8/28/18 11:09 AM, Jiangli Zhou wrote: >> On 8/28/18 9:33 AM, Ioi Lam wrote: >>> The JVM and test changes look good. I just have one comment: >>> >>> >>> CheckDefaultArchiveFile.java >>> >>> ? 51????? if (!Platform.isDefaultCDSArchiveSupported()) { >>> ? 52???????????? if (Files.notExists(jsa)) { >>> ? 53???????????????? System.out.println("Passed. " + vmString + >>> ? 54??????????????????????????????????? ": no default classes.jsa >>> file"); >>> ? 55???????????? } else { >>> ? 56???????????????? throw new RuntimeException(vmString + "contains >>> " + jsaString); >>> ? 57???????????? } >>> >>> >>> People may manually do "java -Xshare:dump" on their own platforms >>> and them run the hotspot tests. It seems too strict to treat this as >>> an error. >>> >>> I think this block should be removed. >> That's probably a common scenario. I agree, it is too strict. Will >> remove the block. >> >> Thanks! >> >> Jiangli >> >>> >>> Thanks >>> >>> - Ioi >>> >>> >>> On 8/28/18 9:25 AM, Erik Joelsson wrote: >>>> Build changes look good to me (but should probably get review from >>>> someone else). >>>> >>>> /Erik >>>> >>>> >>>> On 2018-08-27 13:33, Jiangli Zhou wrote: >>>>> Please review the implementation for JEP JDK-8204247 >>>>> (https://bugs.openjdk.java.net/browse/JDK-8204247). The goal of >>>>> the JEP is to include a default CDS archive in JDK 12 binary >>>>> distribution (downloadable from http://jdk.java.net/12/). The >>>>> default CDS archive is generated using the default classlist >>>>> (resides in the lib/ directory) at JDK build time. Any >>>>> comments/suggestions are highly appreciated. >>>>> >>>>> All makefile changes in the webrev are contributed by Erik >>>>> Joelsson (many thanks!!). >>>>> >>>>> This is a combination of efforts from different teams and >>>>> individuals. Thanks to everyone who has been involved in the JEP & >>>>> implementation discussions, testing and bug fixing! >>>>> >>>>> ? JEP: https://bugs.openjdk.java.net/browse/JDK-8204247 >>>>> ? RFE: https://bugs.openjdk.java.net/browse/JDK-8202951 >>>>> ? webrev: http://cr.openjdk.java.net/~jiangli/8202951/webrev.00/ >>>>> >>>>> Two sanity test cases for the default CDS archive are included >>>>> test/hotspot/jtreg/runtime/SharedArchiveFile. They are not >>>>> intended for in-depth CDS functional testing, which is already >>>>> covered by the existing cds/appcds tests and all tiered tests >>>>> executing with the default CDS archive enabled. >>>>> >>>>> As part of the webrev, >>>>> test/jdk/javax/imageio/plugins/png/ItxtUtf8Test.java is also fixed >>>>> to use larger java heap (JDK-8209739 >>>>> , https://bugs.openjdk.java.net/browse/JDK-8209739). >>>>> >>>>> Tests executed: >>>>> ?- several rounds of tier1 - tier8 via mach5 >>>>> ?- JCK lang, api and vm tests via mach5 >>>>> >>>>> >>>>> Thanks! >>>>> Calvin, Ioi, Jiangli >>>>> >>>>> >>>> >>> >> > From amy.lu at oracle.com Wed Aug 29 05:07:12 2018 From: amy.lu at oracle.com (Amy Lu) Date: Wed, 29 Aug 2018 13:07:12 +0800 Subject: CFV: New JDK Committer: Leo Jiang In-Reply-To: <3b449fd5-bbdb-c67a-a68f-bcabd8cfa105@oracle.com> References: <3b449fd5-bbdb-c67a-a68f-bcabd8cfa105@oracle.com> Message-ID: <4d48f0df-c64f-94d4-9e98-17e35ee3a27f@oracle.com> Vote: Yes /Amy On 2018/8/29 9:37 AM, naoto.sato at oracle.com wrote: > I hereby nominate Leo Jiang (ljiang) to JDK Committer. > > Leo works for the Oracle localization team and has contributed more > than 30 changes. His contributions can be found here [3]. > > Votes are due by 19:00 pm PT, September 11, 2018. > > Only current JDK Committers [1] are eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Naoto Sato > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] > http://hg.openjdk.java.net/jdk/jdk/log?revcount=100&rev=(keyword(%22li.jiang%40oracle.com%22)+or+author(ljiang)) From sha.jiang at oracle.com Wed Aug 29 05:35:29 2018 From: sha.jiang at oracle.com (sha.jiang at oracle.com) Date: Wed, 29 Aug 2018 13:35:29 +0800 Subject: CFV: New JDK Committer: Leo Jiang In-Reply-To: <3b449fd5-bbdb-c67a-a68f-bcabd8cfa105@oracle.com> References: <3b449fd5-bbdb-c67a-a68f-bcabd8cfa105@oracle.com> Message-ID: <7f0a35a6-1e70-84d5-08ac-f4af5a2bf12b@oracle.com> Vote: Yes Best regards, John Jiang On 2018/8/29 09:37, naoto.sato at oracle.com wrote: > I hereby nominate Leo Jiang (ljiang) to JDK Committer. > > Leo works for the Oracle localization team and has contributed more > than 30 changes. His contributions can be found here [3]. > > Votes are due by 19:00 pm PT, September 11, 2018. > > Only current JDK Committers [1] are eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Naoto Sato > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] > http://hg.openjdk.java.net/jdk/jdk/log?revcount=100&rev=(keyword(%22li.jiang%40oracle.com%22)+or+author(ljiang)) > From huaming.li at oracle.com Wed Aug 29 06:25:56 2018 From: huaming.li at oracle.com (Hamlin Li) Date: Wed, 29 Aug 2018 14:25:56 +0800 Subject: CFV: New JDK Committer: Leo Jiang In-Reply-To: <3b449fd5-bbdb-c67a-a68f-bcabd8cfa105@oracle.com> References: <3b449fd5-bbdb-c67a-a68f-bcabd8cfa105@oracle.com> Message-ID: <58146772-dc5a-9832-ad71-cb9e7952c613@oracle.com> Vote: yes -Hamlin On 2018/8/29 9:37 AM, naoto.sato at oracle.com wrote: > I hereby nominate Leo Jiang (ljiang) to JDK Committer. > > Leo works for the Oracle localization team and has contributed more > than 30 changes. His contributions can be found here [3]. > > Votes are due by 19:00 pm PT, September 11, 2018. > > Only current JDK Committers [1] are eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Naoto Sato > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] > http://hg.openjdk.java.net/jdk/jdk/log?revcount=100&rev=(keyword(%22li.jiang%40oracle.com%22)+or+author(ljiang)) From frank.yuan at oracle.com Wed Aug 29 07:02:16 2018 From: frank.yuan at oracle.com (Frank Yuan) Date: Wed, 29 Aug 2018 15:02:16 +0800 Subject: New JDK Committer: Leo Jiang In-Reply-To: <3b449fd5-bbdb-c67a-a68f-bcabd8cfa105@oracle.com> References: <3b449fd5-bbdb-c67a-a68f-bcabd8cfa105@oracle.com> Message-ID: <060001d43f66$3a0cd2c0$ae267840$@oracle.com> Vote: yes Frank > -----Original Message----- > From: jdk-dev [mailto:jdk-dev-bounces at openjdk.java.net] On Behalf Of naoto.sato at oracle.com > Sent: Wednesday, August 29, 2018 9:38 AM > To: jdk-dev > Subject: CFV: New JDK Committer: Leo Jiang > > I hereby nominate Leo Jiang (ljiang) to JDK Committer. > > Leo works for the Oracle localization team and has contributed more than > 30 changes. His contributions can be found here [3]. > > Votes are due by 19:00 pm PT, September 11, 2018. > > Only current JDK Committers [1] are eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Naoto Sato > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] > http://hg.openjdk.java.net/jdk/jdk/log?revcount=100&rev=(keyword(%22li.jiang%40oracle.com%22)+or+author(ljiang)) From daniel.fuchs at oracle.com Wed Aug 29 09:33:04 2018 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Wed, 29 Aug 2018 10:33:04 +0100 Subject: CFV: New JDK Committer: Leo Jiang In-Reply-To: <3b449fd5-bbdb-c67a-a68f-bcabd8cfa105@oracle.com> References: <3b449fd5-bbdb-c67a-a68f-bcabd8cfa105@oracle.com> Message-ID: <3c774d2d-e5f4-0f4a-df94-cd3953e82915@oracle.com> Vote: yes best regards, -- daniel On 29/08/2018 02:37, naoto.sato at oracle.com wrote: > I hereby nominate Leo Jiang (ljiang) to JDK Committer. From sean.coffey at oracle.com Wed Aug 29 09:36:56 2018 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Wed, 29 Aug 2018 10:36:56 +0100 Subject: CFV: New JDK Committer: Leo Jiang In-Reply-To: <3b449fd5-bbdb-c67a-a68f-bcabd8cfa105@oracle.com> References: <3b449fd5-bbdb-c67a-a68f-bcabd8cfa105@oracle.com> Message-ID: <0afdf9ba-d24b-01ae-7294-e5aab65aaa41@oracle.com> Vote: yes Regards, Sean. On 29/08/18 02:37, naoto.sato at oracle.com wrote: > I hereby nominate Leo Jiang (ljiang) to JDK Committer. > > Leo works for the Oracle localization team and has contributed more > than 30 changes. His contributions can be found here [3]. > > Votes are due by 19:00 pm PT, September 11, 2018. > > Only current JDK Committers [1] are eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Naoto Sato > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] > http://hg.openjdk.java.net/jdk/jdk/log?revcount=100&rev=(keyword(%22li.jiang%40oracle.com%22)+or+author(ljiang)) From weijun.wang at oracle.com Wed Aug 29 11:35:56 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 29 Aug 2018 19:35:56 +0800 Subject: CFV: New JDK Committer: Leo Jiang In-Reply-To: <3b449fd5-bbdb-c67a-a68f-bcabd8cfa105@oracle.com> References: <3b449fd5-bbdb-c67a-a68f-bcabd8cfa105@oracle.com> Message-ID: <6B1F2C13-118B-43AC-BAFE-B49020FBB140@oracle.com> Vote: yes -weijun > On Aug 29, 2018, at 9:37 AM, naoto.sato at oracle.com wrote: > > I hereby nominate Leo Jiang (ljiang) to JDK Committer. From magnus.ihse.bursie at oracle.com Wed Aug 29 11:53:38 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 29 Aug 2018 13:53:38 +0200 Subject: RFR: JDK-8202951: Implementation of JEPJDK-8204247: Include default CDS (Class Data Sharing) archive in JDK binary In-Reply-To: References: Message-ID: On 2018-08-28 18:25, Erik Joelsson wrote: > Build changes look good to me (but should probably get review from > someone else). I'm (as usually) not as happy as Erik. ;-) In Images.gmk, you have added this rule: ????????? $@ -Xshare:dump -Xmx128M -Xms128M $(LOG_INFO) It took me a while to grasp. You are relying on $(JIMAGE_TARGET_FILE) to evaluate to bin/java. But that is only incidentally so. This file is just picked arbitrarily to represent when the entire image is done, for make. Please use $(JRE_IMAGE_DIR)/bin/java instead. The logic in jdk-options.m4 is broken. If indeed it is not possible to use cds archive with zero, then things will break since it will still be built if using --enable-cds-archive! What you should do is to set default to true unless using cross compilation or zero. If the user explicitly sets --enable-cds-archive, and it's not possible, a fatal error should be generated. Apart from this, I'm more on Erik's line. :-) /Magnus > > /Erik > > > On 2018-08-27 13:33, Jiangli Zhou wrote: >> Please review the implementation for JEP JDK-8204247 >> (https://bugs.openjdk.java.net/browse/JDK-8204247). The goal of the >> JEP is to include a default CDS archive in JDK 12 binary distribution >> (downloadable from http://jdk.java.net/12/). The default CDS archive >> is generated using the default classlist (resides in the lib/ >> directory) at JDK build time. Any comments/suggestions are highly >> appreciated. >> >> All makefile changes in the webrev are contributed by Erik Joelsson >> (many thanks!!). >> >> This is a combination of efforts from different teams and >> individuals. Thanks to everyone who has been involved in the JEP & >> implementation discussions, testing and bug fixing! >> >> ? JEP: https://bugs.openjdk.java.net/browse/JDK-8204247 >> ? RFE: https://bugs.openjdk.java.net/browse/JDK-8202951 >> ? webrev: http://cr.openjdk.java.net/~jiangli/8202951/webrev.00/ >> >> Two sanity test cases for the default CDS archive are included >> test/hotspot/jtreg/runtime/SharedArchiveFile. They are not intended >> for in-depth CDS functional testing, which is already covered by the >> existing cds/appcds tests and all tiered tests executing with the >> default CDS archive enabled. >> >> As part of the webrev, >> test/jdk/javax/imageio/plugins/png/ItxtUtf8Test.java is also fixed to >> use larger java heap (JDK-8209739 >> , https://bugs.openjdk.java.net/browse/JDK-8209739). >> >> Tests executed: >> ?- several rounds of tier1 - tier8 via mach5 >> ?- JCK lang, api and vm tests via mach5 >> >> >> Thanks! >> Calvin, Ioi, Jiangli >> >> > From xuelei.fan at oracle.com Wed Aug 29 14:03:09 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 29 Aug 2018 07:03:09 -0700 Subject: CFV: New JDK Committer: Leo Jiang In-Reply-To: <4d48f0df-c64f-94d4-9e98-17e35ee3a27f@oracle.com> References: <3b449fd5-bbdb-c67a-a68f-bcabd8cfa105@oracle.com> <4d48f0df-c64f-94d4-9e98-17e35ee3a27f@oracle.com> Message-ID: Vote: Yes Xuelei On 8/28/2018 10:07 PM, Amy Lu wrote: > Vote: Yes > > /Amy > > On 2018/8/29 9:37 AM, naoto.sato at oracle.com wrote: >> I hereby nominate Leo Jiang (ljiang) to JDK Committer. >> >> Leo works for the Oracle localization team and has contributed more >> than 30 changes. His contributions can be found here [3]. >> >> Votes are due by 19:00 pm PT, September 11, 2018. >> >> Only current JDK Committers [1] are eligible to vote on this nomination. >> Votes must be cast in the open by replying to this mailing list. >> >> For Lazy Consensus voting instructions, see [2]. >> >> Naoto Sato >> >> [1] http://openjdk.java.net/census >> [2] http://openjdk.java.net/projects/#committer-vote >> [3] >> http://hg.openjdk.java.net/jdk/jdk/log?revcount=100&rev=(keyword(%22li.jiang%40oracle.com%22)+or+author(ljiang)) >> > From erik.joelsson at oracle.com Wed Aug 29 15:45:43 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 29 Aug 2018 08:45:43 -0700 Subject: RFR: JDK-8202951: Implementation of JEPJDK-8204247: Include default CDS (Class Data Sharing) archive in JDK binary In-Reply-To: References: Message-ID: <8e17729f-9f5b-4d7c-a8cf-e0d3ffeeb694@oracle.com> Hello Magnus, As the author of the build changes I will answer this. On 2018-08-29 04:53, Magnus Ihse Bursie wrote: > On 2018-08-28 18:25, Erik Joelsson wrote: >> Build changes look good to me (but should probably get review from >> someone else). > > I'm (as usually) not as happy as Erik. ;-) > > In Images.gmk, you have added this rule: > ????????? $@ -Xshare:dump -Xmx128M -Xms128M $(LOG_INFO) > > It took me a while to grasp. You are relying on $(JIMAGE_TARGET_FILE) > to evaluate to bin/java. But that is only incidentally so. This file > is just picked arbitrarily to represent when the entire image is done, > for make. Please use $(JRE_IMAGE_DIR)/bin/java instead. > I can agree with this part. That was a bit of a hack done in a hurry. > The logic in jdk-options.m4 is broken. If indeed it is not possible to > use cds archive with zero, then things will break since it will still > be built if using --enable-cds-archive! > > What you should do is to set default to true unless using cross > compilation or zero. If the user explicitly sets --enable-cds-archive, > and it's not possible, a fatal error should be generated. > Here I'm not as sure. I deliberately let it be possible to override the default behavior for zero as someone might want to fix that at some point, you never know. For cross compilation it's just not possible ever so that's different. Maybe my reasoning is invalid. /Erik > Apart from this, I'm more on Erik's line. :-) > > /Magnus > > > >> >> /Erik >> >> >> On 2018-08-27 13:33, Jiangli Zhou wrote: >>> Please review the implementation for JEP JDK-8204247 >>> (https://bugs.openjdk.java.net/browse/JDK-8204247). The goal of the >>> JEP is to include a default CDS archive in JDK 12 binary >>> distribution (downloadable from http://jdk.java.net/12/). The >>> default CDS archive is generated using the default classlist >>> (resides in the lib/ directory) at JDK build time. Any >>> comments/suggestions are highly appreciated. >>> >>> All makefile changes in the webrev are contributed by Erik Joelsson >>> (many thanks!!). >>> >>> This is a combination of efforts from different teams and >>> individuals. Thanks to everyone who has been involved in the JEP & >>> implementation discussions, testing and bug fixing! >>> >>> ? JEP: https://bugs.openjdk.java.net/browse/JDK-8204247 >>> ? RFE: https://bugs.openjdk.java.net/browse/JDK-8202951 >>> ? webrev: http://cr.openjdk.java.net/~jiangli/8202951/webrev.00/ >>> >>> Two sanity test cases for the default CDS archive are included >>> test/hotspot/jtreg/runtime/SharedArchiveFile. They are not intended >>> for in-depth CDS functional testing, which is already covered by the >>> existing cds/appcds tests and all tiered tests executing with the >>> default CDS archive enabled. >>> >>> As part of the webrev, >>> test/jdk/javax/imageio/plugins/png/ItxtUtf8Test.java is also fixed >>> to use larger java heap (JDK-8209739 >>> , https://bugs.openjdk.java.net/browse/JDK-8209739). >>> >>> Tests executed: >>> ?- several rounds of tier1 - tier8 via mach5 >>> ?- JCK lang, api and vm tests via mach5 >>> >>> >>> Thanks! >>> Calvin, Ioi, Jiangli >>> >>> >> > From xueming.shen at oracle.com Wed Aug 29 17:26:58 2018 From: xueming.shen at oracle.com (Xueming Shen) Date: Wed, 29 Aug 2018 10:26:58 -0700 Subject: CFV: New JDK Committer: Leo Jiang In-Reply-To: <3c774d2d-e5f4-0f4a-df94-cd3953e82915@oracle.com> References: <3b449fd5-bbdb-c67a-a68f-bcabd8cfa105@oracle.com> <3c774d2d-e5f4-0f4a-df94-cd3953e82915@oracle.com> Message-ID: <5B86D762.6020803@oracle.com> Vote: yes > > On 29/08/2018 02:37, naoto.sato at oracle.com wrote: >> I hereby nominate Leo Jiang (ljiang) to JDK Committer. From jiangli.zhou at oracle.com Wed Aug 29 21:45:14 2018 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Wed, 29 Aug 2018 14:45:14 -0700 Subject: RFR: JDK-8202951: Implementation of JEPJDK-8204247: Include default CDS (Class Data Sharing) archive in JDK binary In-Reply-To: <8e17729f-9f5b-4d7c-a8cf-e0d3ffeeb694@oracle.com> References: <8e17729f-9f5b-4d7c-a8cf-e0d3ffeeb694@oracle.com> Message-ID: Hi Erik and Magnus, I updated Images.gmk accordingly. Magnus, thanks for reviewing! http://cr.openjdk.java.net/~jiangli/8202951/webrev.02/make/Images.gmk.frames.html Complete webrev: http://cr.openjdk.java.net/~jiangli/8202951/webrev.02/ Please see comments below. On 8/29/18 8:45 AM, Erik Joelsson wrote: > > Hello Magnus, > > As the author of the build changes I will answer this. > > On 2018-08-29 04:53, Magnus Ihse Bursie wrote: >> On 2018-08-28 18:25, Erik Joelsson wrote: >>> Build changes look good to me (but should probably get review from >>> someone else). >> >> I'm (as usually) not as happy as Erik. ;-) >> >> In Images.gmk, you have added this rule: >> ????????? $@ -Xshare:dump -Xmx128M -Xms128M $(LOG_INFO) >> >> It took me a while to grasp. You are relying on $(JIMAGE_TARGET_FILE) >> to evaluate to bin/java. But that is only incidentally so. This file >> is just picked arbitrarily to represent when the entire image is >> done, for make. Please use $(JRE_IMAGE_DIR)/bin/java instead. >> > I can agree with this part. That was a bit of a hack done in a hurry. >> The logic in jdk-options.m4 is broken. If indeed it is not possible >> to use cds archive with zero, then things will break since it will >> still be built if using --enable-cds-archive! >> >> What you should do is to set default to true unless using cross >> compilation or zero. If the user explicitly sets >> --enable-cds-archive, and it's not possible, a fatal error should be >> generated. >> > Here I'm not as sure. I deliberately let it be possible to override > the default behavior for zero as someone might want to fix that at > some point, you never know. For cross compilation it's just not > possible ever so that's different. Maybe my reasoning is invalid. I think that's reasonable. Thanks! Jiangli > > /Erik >> Apart from this, I'm more on Erik's line. :-) >> >> /Magnus >> >> >> >>> >>> /Erik >>> >>> >>> On 2018-08-27 13:33, Jiangli Zhou wrote: >>>> Please review the implementation for JEP JDK-8204247 >>>> (https://bugs.openjdk.java.net/browse/JDK-8204247). The goal of the >>>> JEP is to include a default CDS archive in JDK 12 binary >>>> distribution (downloadable from http://jdk.java.net/12/). The >>>> default CDS archive is generated using the default classlist >>>> (resides in the lib/ directory) at JDK build time. Any >>>> comments/suggestions are highly appreciated. >>>> >>>> All makefile changes in the webrev are contributed by Erik Joelsson >>>> (many thanks!!). >>>> >>>> This is a combination of efforts from different teams and >>>> individuals. Thanks to everyone who has been involved in the JEP & >>>> implementation discussions, testing and bug fixing! >>>> >>>> ? JEP: https://bugs.openjdk.java.net/browse/JDK-8204247 >>>> ? RFE: https://bugs.openjdk.java.net/browse/JDK-8202951 >>>> ? webrev: http://cr.openjdk.java.net/~jiangli/8202951/webrev.00/ >>>> >>>> Two sanity test cases for the default CDS archive are included >>>> test/hotspot/jtreg/runtime/SharedArchiveFile. They are not intended >>>> for in-depth CDS functional testing, which is already covered by >>>> the existing cds/appcds tests and all tiered tests executing with >>>> the default CDS archive enabled. >>>> >>>> As part of the webrev, >>>> test/jdk/javax/imageio/plugins/png/ItxtUtf8Test.java is also fixed >>>> to use larger java heap (JDK-8209739 >>>> , https://bugs.openjdk.java.net/browse/JDK-8209739). >>>> >>>> Tests executed: >>>> ?- several rounds of tier1 - tier8 via mach5 >>>> ?- JCK lang, api and vm tests via mach5 >>>> >>>> >>>> Thanks! >>>> Calvin, Ioi, Jiangli >>>> >>>> >>> >> > From magnus.ihse.bursie at oracle.com Thu Aug 30 10:56:04 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 30 Aug 2018 12:56:04 +0200 Subject: RFR: JDK-8202951: Implementation of JEPJDK-8204247: Include default CDS (Class Data Sharing) archive in JDK binary In-Reply-To: <8e17729f-9f5b-4d7c-a8cf-e0d3ffeeb694@oracle.com> References: <8e17729f-9f5b-4d7c-a8cf-e0d3ffeeb694@oracle.com> Message-ID: On 2018-08-29 17:45, Erik Joelsson wrote: > > Hello Magnus, > > As the author of the build changes I will answer this. > > On 2018-08-29 04:53, Magnus Ihse Bursie wrote: >> On 2018-08-28 18:25, Erik Joelsson wrote: >>> Build changes look good to me (but should probably get review from >>> someone else). >> >> I'm (as usually) not as happy as Erik. ;-) >> >> In Images.gmk, you have added this rule: >> ????????? $@ -Xshare:dump -Xmx128M -Xms128M $(LOG_INFO) >> >> It took me a while to grasp. You are relying on $(JIMAGE_TARGET_FILE) >> to evaluate to bin/java. But that is only incidentally so. This file >> is just picked arbitrarily to represent when the entire image is >> done, for make. Please use $(JRE_IMAGE_DIR)/bin/java instead. >> > I can agree with this part. That was a bit of a hack done in a hurry. >> The logic in jdk-options.m4 is broken. If indeed it is not possible >> to use cds archive with zero, then things will break since it will >> still be built if using --enable-cds-archive! >> >> What you should do is to set default to true unless using cross >> compilation or zero. If the user explicitly sets >> --enable-cds-archive, and it's not possible, a fatal error should be >> generated. >> > Here I'm not as sure. I deliberately let it be possible to override > the default behavior for zero as someone might want to fix that at > some point, you never know. For cross compilation it's just not > possible ever so that's different. Maybe my reasoning is invalid. I see. I still think it would have made more sense, in that case, to set the default to false if using zero, but allow override. But I'm not going to insist on that. However, if the problem with zero is not that it's technically impossible, just that it's not tested, I think the message should be changed from "[no, not possible with JVM variant zero]" to just "[no]" with a comment in the configure script that it's off by default since it's not tested. Apart from that, Jiangli's latest webrev looks good. Jiangli: If you fix it like I suggested, you do not need to respin the webrev. /Magnus > > /Erik >> Apart from this, I'm more on Erik's line. :-) >> >> /Magnus >> >> >> >>> >>> /Erik >>> >>> >>> On 2018-08-27 13:33, Jiangli Zhou wrote: >>>> Please review the implementation for JEP JDK-8204247 >>>> (https://bugs.openjdk.java.net/browse/JDK-8204247). The goal of the >>>> JEP is to include a default CDS archive in JDK 12 binary >>>> distribution (downloadable from http://jdk.java.net/12/). The >>>> default CDS archive is generated using the default classlist >>>> (resides in the lib/ directory) at JDK build time. Any >>>> comments/suggestions are highly appreciated. >>>> >>>> All makefile changes in the webrev are contributed by Erik Joelsson >>>> (many thanks!!). >>>> >>>> This is a combination of efforts from different teams and >>>> individuals. Thanks to everyone who has been involved in the JEP & >>>> implementation discussions, testing and bug fixing! >>>> >>>> ? JEP: https://bugs.openjdk.java.net/browse/JDK-8204247 >>>> ? RFE: https://bugs.openjdk.java.net/browse/JDK-8202951 >>>> ? webrev: http://cr.openjdk.java.net/~jiangli/8202951/webrev.00/ >>>> >>>> Two sanity test cases for the default CDS archive are included >>>> test/hotspot/jtreg/runtime/SharedArchiveFile. They are not intended >>>> for in-depth CDS functional testing, which is already covered by >>>> the existing cds/appcds tests and all tiered tests executing with >>>> the default CDS archive enabled. >>>> >>>> As part of the webrev, >>>> test/jdk/javax/imageio/plugins/png/ItxtUtf8Test.java is also fixed >>>> to use larger java heap (JDK-8209739 >>>> , https://bugs.openjdk.java.net/browse/JDK-8209739). >>>> >>>> Tests executed: >>>> ?- several rounds of tier1 - tier8 via mach5 >>>> ?- JCK lang, api and vm tests via mach5 >>>> >>>> >>>> Thanks! >>>> Calvin, Ioi, Jiangli >>>> >>>> >>> >> > From jiangli.zhou at oracle.com Thu Aug 30 18:26:42 2018 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Thu, 30 Aug 2018 11:26:42 -0700 Subject: RFR: JDK-8202951: Implementation of JEPJDK-8204247: Include default CDS (Class Data Sharing) archive in JDK binary In-Reply-To: References: <8e17729f-9f5b-4d7c-a8cf-e0d3ffeeb694@oracle.com> Message-ID: Hi Magnus, Sounds good. Will update the message. Thanks! Jiangli On 8/30/18 3:56 AM, Magnus Ihse Bursie wrote: > On 2018-08-29 17:45, Erik Joelsson wrote: >> >> Hello Magnus, >> >> As the author of the build changes I will answer this. >> >> On 2018-08-29 04:53, Magnus Ihse Bursie wrote: >>> On 2018-08-28 18:25, Erik Joelsson wrote: >>>> Build changes look good to me (but should probably get review from >>>> someone else). >>> >>> I'm (as usually) not as happy as Erik. ;-) >>> >>> In Images.gmk, you have added this rule: >>> ????????? $@ -Xshare:dump -Xmx128M -Xms128M $(LOG_INFO) >>> >>> It took me a while to grasp. You are relying on >>> $(JIMAGE_TARGET_FILE) to evaluate to bin/java. But that is only >>> incidentally so. This file is just picked arbitrarily to represent >>> when the entire image is done, for make. Please use >>> $(JRE_IMAGE_DIR)/bin/java instead. >>> >> I can agree with this part. That was a bit of a hack done in a hurry. >>> The logic in jdk-options.m4 is broken. If indeed it is not possible >>> to use cds archive with zero, then things will break since it will >>> still be built if using --enable-cds-archive! >>> >>> What you should do is to set default to true unless using cross >>> compilation or zero. If the user explicitly sets >>> --enable-cds-archive, and it's not possible, a fatal error should be >>> generated. >>> >> Here I'm not as sure. I deliberately let it be possible to override >> the default behavior for zero as someone might want to fix that at >> some point, you never know. For cross compilation it's just not >> possible ever so that's different. Maybe my reasoning is invalid. > > I see. I still think it would have made more sense, in that case, to > set the default to false if using zero, but allow override. But I'm > not going to insist on that. > > However, if the problem with zero is not that it's technically > impossible, just that it's not tested, I think the message should be > changed from "[no, not possible with JVM variant zero]" to just "[no]" > with a comment in the configure script that it's off by default since > it's not tested. > > Apart from that, Jiangli's latest webrev looks good. > > Jiangli: If you fix it like I suggested, you do not need to respin the > webrev. > > /Magnus > >> >> /Erik >>> Apart from this, I'm more on Erik's line. :-) >>> >>> /Magnus >>> >>> >>> >>>> >>>> /Erik >>>> >>>> >>>> On 2018-08-27 13:33, Jiangli Zhou wrote: >>>>> Please review the implementation for JEP JDK-8204247 >>>>> (https://bugs.openjdk.java.net/browse/JDK-8204247). The goal of >>>>> the JEP is to include a default CDS archive in JDK 12 binary >>>>> distribution (downloadable from http://jdk.java.net/12/). The >>>>> default CDS archive is generated using the default classlist >>>>> (resides in the lib/ directory) at JDK build time. Any >>>>> comments/suggestions are highly appreciated. >>>>> >>>>> All makefile changes in the webrev are contributed by Erik >>>>> Joelsson (many thanks!!). >>>>> >>>>> This is a combination of efforts from different teams and >>>>> individuals. Thanks to everyone who has been involved in the JEP & >>>>> implementation discussions, testing and bug fixing! >>>>> >>>>> ? JEP: https://bugs.openjdk.java.net/browse/JDK-8204247 >>>>> ? RFE: https://bugs.openjdk.java.net/browse/JDK-8202951 >>>>> ? webrev: http://cr.openjdk.java.net/~jiangli/8202951/webrev.00/ >>>>> >>>>> Two sanity test cases for the default CDS archive are included >>>>> test/hotspot/jtreg/runtime/SharedArchiveFile. They are not >>>>> intended for in-depth CDS functional testing, which is already >>>>> covered by the existing cds/appcds tests and all tiered tests >>>>> executing with the default CDS archive enabled. >>>>> >>>>> As part of the webrev, >>>>> test/jdk/javax/imageio/plugins/png/ItxtUtf8Test.java is also fixed >>>>> to use larger java heap (JDK-8209739 >>>>> , https://bugs.openjdk.java.net/browse/JDK-8209739). >>>>> >>>>> Tests executed: >>>>> ?- several rounds of tier1 - tier8 via mach5 >>>>> ?- JCK lang, api and vm tests via mach5 >>>>> >>>>> >>>>> Thanks! >>>>> Calvin, Ioi, Jiangli >>>>> >>>>> >>>> >>> >> > From mark.reinhold at oracle.com Thu Aug 30 22:49:17 2018 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Thu, 30 Aug 2018 15:49:17 -0700 Subject: JEP proposed to target JDK 12: 326: Raw String Literals (Preview) Message-ID: <20180830154917.372576318@eggemoggin.niobe.net> The following JEP is proposed to target JDK 12: 326: Raw String Literals (Preview) http://openjdk.java.net/jeps/326 Feedback on this proposal is more than welcome, as are reasoned objections. If no such objections are raised by 23:00 UTC on Thursday, 6 September, or if they?re raised and then satisfactorily answered, then per the JEP 2.0 process proposal [1] I?ll target this JEP to JDK 12. When reviewing this proposal please bear in mind that, just like JEP 325 (Switch Expressions) [2], this is a Preview Language Feature, per JEP 12 [3]. - Mark [1] http://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html [2] http://openjdk.java.net/jeps/325 [3] http://openjdk.java.net/jeps/12 From cossack5 at mail.ru Fri Aug 31 17:16:53 2018 From: cossack5 at mail.ru (=?UTF-8?B?0KHQtdGA0LPQtdC5INCn0LDRg9C70LjQvQ==?=) Date: Fri, 31 Aug 2018 20:16:53 +0300 Subject: =?UTF-8?B?UHJvdmlkZSBhcGkgZm9yIGFjY2Vzc2luZyBieXRlY29kZSBmcm9tIGphdmEu?= =?UTF-8?B?bGFuZy5yZWZsZWN0Lk1ldGhvZC4=?= Message-ID: <1535735813.95987216@f416.i.mail.ru> Hi, In .NET we can retrieve bytecode array from reflected class, e.g.: MethodInfo mi = typeof (Example).GetMethod( "MethodBodyExample" ); MethodBody mb = mi.GetMethodBody(); var bytes= mb.GetILAsByteArray(); How about having something like this in java ? Leveraging this, it would be possible to get bytecode of currently loaded classes (including lambdas), killing the need to load class as a resource.? ? ?????????, ?????? ??????