From lois.foltan at oracle.com Tue May 1 11:43:39 2018 From: lois.foltan at oracle.com (Lois Foltan) Date: Tue, 1 May 2018 07:43:39 -0400 Subject: CFV: New JDK Reviewer: Roman Kennke In-Reply-To: References: Message-ID: <53234f3c-27db-1beb-47c6-dd71077fc6ef@oracle.com> Vote: yes Lois On 4/27/2018 6:15 AM, Andrew Dinn wrote: > I hereby nominate Roman Kennke (rkennke) to JDK Project Reviewer. > > Roman is a member of the OpenJDK Members group and has contributed 57 > changesets[1] to the JDK project. This includes contributions to the > Shark JIT, 2d graphics, AArch64 runtime and JIT, core JVM runtime, and > GC implementation and interface. Roman is also a prolific contributor to > the Shenandoah project and has been responsible for liasing with the ZGC > team to enable merging of Shenandoah and ZGC into the upstream JDK code > base. > > Votes are due by 12:00 BST May 11, 2018. > > Only current JDK Reviewers [2] 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 [3]. > > Andrew Dinn > > [1] > http://hg.openjdk.java.net/jdk/jdk/search/?rev=%28keyword%28%22rkennke%40redhat.com%22%29%20or%20author%28rkennke%29%29&revcount=100 > [2] http://openjdk.java.net/census > [3] http://openjdk.java.net/projects/#reviewer-vote > > regards, > > > Andrew Dinn > ----------- > Senior Principal Software Engineer > Red Hat UK Ltd > Registered in England and Wales under Company Registration No. 03798903 > Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From paul.sandoz at oracle.com Tue May 1 16:31:57 2018 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 1 May 2018 09:31:57 -0700 Subject: CFV: New JDK Reviewer: Roman Kennke In-Reply-To: References: Message-ID: <4EC9CCB5-9488-4597-9F5F-D767AF96C8E9@oracle.com> Vote: yes Paul. From erik.helin at oracle.com Tue May 1 17:16:07 2018 From: erik.helin at oracle.com (Erik Helin) Date: Tue, 1 May 2018 19:16:07 +0200 Subject: CFV: New JDK Reviewer: Roman Kennke In-Reply-To: References: Message-ID: <61385afb-bee7-e7cb-0a9a-2a58cfe8b944@oracle.com> Vote: yes. Thanks, Erik On 04/27/2018 12:15 PM, Andrew Dinn wrote: > I hereby nominate Roman Kennke (rkennke) to JDK Project Reviewer. > > Roman is a member of the OpenJDK Members group and has contributed 57 > changesets[1] to the JDK project. This includes contributions to the > Shark JIT, 2d graphics, AArch64 runtime and JIT, core JVM runtime, and > GC implementation and interface. Roman is also a prolific contributor to > the Shenandoah project and has been responsible for liasing with the ZGC > team to enable merging of Shenandoah and ZGC into the upstream JDK code > base. > > Votes are due by 12:00 BST May 11, 2018. > > Only current JDK Reviewers [2] 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 [3]. > > Andrew Dinn > > [1] > http://hg.openjdk.java.net/jdk/jdk/search/?rev=%28keyword%28%22rkennke%40redhat.com%22%29%20or%20author%28rkennke%29%29&revcount=100 > [2] http://openjdk.java.net/census > [3] http://openjdk.java.net/projects/#reviewer-vote > > regards, > > > Andrew Dinn > ----------- > Senior Principal Software Engineer > Red Hat UK Ltd > Registered in England and Wales under Company Registration No. 03798903 > Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander > From kim.barrett at oracle.com Wed May 2 02:56:56 2018 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 1 May 2018 22:56:56 -0400 Subject: =?utf-8?Q?CFV=3A_New_JDK_Reviewer=3A_Erik_=C3=96sterlund?= Message-ID: <0BC4E9D8-6C68-43D2-9006-1A04C341D841@oracle.com> I hearby nominate Erik ?sterlund (eosterlund) to JDK Project Reviewer. Erik is a JDK Project Committer and has contributed 54 changesets[1] to the OpenJDK project. This includes substantial revisions to core components such as Atomic and OrderAccess, and leading the effort to provide a better interface between the GC and other VM components, e.g. the Access API and various refactorings around BarrierSet. He has also contributed to the ZGC project, particularly the SPARC port. Votes are due by 12:00 EDT May 16, 2018. Only current JDK Reviewers [2] 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 [3]. Kim Barrett [1] http://hg.openjdk.java.net/jdk/jdk/search/?rev=%28keyword%28%22erik.osterlund%40oracle.com%22%29%20or%20keyword%28%22erik.osterlund%40lnu.se%22%29%20or%20author%28eosterlund%29%29&revcount=100 [2] http://openjdk.java.net/census [3] http://openjdk.java.net/projects/#reviewer-vote From kim.barrett at oracle.com Wed May 2 02:58:55 2018 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 1 May 2018 22:58:55 -0400 Subject: =?utf-8?Q?Re=3A_CFV=3A_New_JDK_Reviewer=3A_Erik_=C3=96sterlund?= In-Reply-To: <0BC4E9D8-6C68-43D2-9006-1A04C341D841@oracle.com> References: <0BC4E9D8-6C68-43D2-9006-1A04C341D841@oracle.com> Message-ID: Vote: yes > On May 1, 2018, at 10:56 PM, Kim Barrett wrote: > > I hearby nominate Erik ?sterlund (eosterlund) to JDK Project Reviewer. > > Erik is a JDK Project Committer and has contributed 54 changesets[1] > to the OpenJDK project. This includes substantial revisions to core > components such as Atomic and OrderAccess, and leading the effort to > provide a better interface between the GC and other VM components, > e.g. the Access API and various refactorings around BarrierSet. He has > also contributed to the ZGC project, particularly the SPARC port. > > Votes are due by 12:00 EDT May 16, 2018. > > Only current JDK Reviewers [2] 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 [3]. > > Kim Barrett > > [1] http://hg.openjdk.java.net/jdk/jdk/search/?rev=%28keyword%28%22erik.osterlund%40oracle.com%22%29%20or%20keyword%28%22erik.osterlund%40lnu.se%22%29%20or%20author%28eosterlund%29%29&revcount=100 > [2] http://openjdk.java.net/census > [3] http://openjdk.java.net/projects/#reviewer-vote From jiangli.zhou at oracle.com Wed May 2 03:02:47 2018 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Tue, 1 May 2018 20:02:47 -0700 Subject: =?utf-8?Q?Re:_CFV:_New_JDK_Reviewer:_Erik_=C3=96sterlund?= In-Reply-To: <0BC4E9D8-6C68-43D2-9006-1A04C341D841@oracle.com> References: <0BC4E9D8-6C68-43D2-9006-1A04C341D841@oracle.com> Message-ID: Vote: yes Thanks, Jiangli > On May 1, 2018, at 7:56 PM, Kim Barrett wrote: > > I hearby nominate Erik ?sterlund (eosterlund) to JDK Project Reviewer. > > Erik is a JDK Project Committer and has contributed 54 changesets[1] > to the OpenJDK project. This includes substantial revisions to core > components such as Atomic and OrderAccess, and leading the effort to > provide a better interface between the GC and other VM components, > e.g. the Access API and various refactorings around BarrierSet. He has > also contributed to the ZGC project, particularly the SPARC port. > > Votes are due by 12:00 EDT May 16, 2018. > > Only current JDK Reviewers [2] 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 [3]. > > Kim Barrett > > [1] http://hg.openjdk.java.net/jdk/jdk/search/?rev=%28keyword%28%22erik.osterlund%40oracle.com%22%29%20or%20keyword%28%22erik.osterlund%40lnu.se%22%29%20or%20author%28eosterlund%29%29&revcount=100 > [2] http://openjdk.java.net/census > [3] http://openjdk.java.net/projects/#reviewer-vote > From david.holmes at oracle.com Wed May 2 04:12:10 2018 From: david.holmes at oracle.com (David Holmes) Date: Wed, 2 May 2018 14:12:10 +1000 Subject: =?UTF-8?Q?Re:_CFV:_New_JDK_Reviewer:_Erik_=c3=96sterlund?= In-Reply-To: <0BC4E9D8-6C68-43D2-9006-1A04C341D841@oracle.com> References: <0BC4E9D8-6C68-43D2-9006-1A04C341D841@oracle.com> Message-ID: <676d889b-b67b-e635-7b11-9b9b907d75dc@oracle.com> Vote: yes David On 2/05/2018 12:56 PM, Kim Barrett wrote: > I hearby nominate Erik ?sterlund (eosterlund) to JDK Project Reviewer. > > Erik is a JDK Project Committer and has contributed 54 changesets[1] > to the OpenJDK project. This includes substantial revisions to core > components such as Atomic and OrderAccess, and leading the effort to > provide a better interface between the GC and other VM components, > e.g. the Access API and various refactorings around BarrierSet. He has > also contributed to the ZGC project, particularly the SPARC port. > > Votes are due by 12:00 EDT May 16, 2018. > > Only current JDK Reviewers [2] 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 [3]. > > Kim Barrett > > [1] http://hg.openjdk.java.net/jdk/jdk/search/?rev=%28keyword%28%22erik.osterlund%40oracle.com%22%29%20or%20keyword%28%22erik.osterlund%40lnu.se%22%29%20or%20author%28eosterlund%29%29&revcount=100 > [2] http://openjdk.java.net/census > [3] http://openjdk.java.net/projects/#reviewer-vote > From goetz.lindenmaier at sap.com Wed May 2 06:20:23 2018 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 2 May 2018 06:20:23 +0000 Subject: =?utf-8?B?UkU6IE5ldyBKREsgUmV2aWV3ZXI6IEVyaWsgw5ZzdGVybHVuZA==?= In-Reply-To: <0BC4E9D8-6C68-43D2-9006-1A04C341D841@oracle.com> References: <0BC4E9D8-6C68-43D2-9006-1A04C341D841@oracle.com> Message-ID: <668ae75f207445e593a80177ddd0171a@sap.com> vote: yes Best regards, Goetz. > -----Original Message----- > From: jdk-dev [mailto:jdk-dev-bounces at openjdk.java.net] On Behalf Of Kim > Barrett > Sent: Mittwoch, 2. Mai 2018 04:57 > To: jdk-dev > Subject: CFV: New JDK Reviewer: Erik ?sterlund > > I hearby nominate Erik ?sterlund (eosterlund) to JDK Project Reviewer. > > Erik is a JDK Project Committer and has contributed 54 changesets[1] > to the OpenJDK project. This includes substantial revisions to core > components such as Atomic and OrderAccess, and leading the effort to > provide a better interface between the GC and other VM components, > e.g. the Access API and various refactorings around BarrierSet. He has > also contributed to the ZGC project, particularly the SPARC port. > > Votes are due by 12:00 EDT May 16, 2018. > > Only current JDK Reviewers [2] 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 [3]. > > Kim Barrett > > [1] > http://hg.openjdk.java.net/jdk/jdk/search/?rev=%28keyword%28%22erik.o > sterlund%40oracle.com%22%29%20or%20keyword%28%22erik.osterlund%4 > 0lnu.se%22%29%20or%20author%28eosterlund%29%29&revcount=100 > [2] http://openjdk.java.net/census > [3] http://openjdk.java.net/projects/#reviewer-vote From tobias.hartmann at oracle.com Wed May 2 06:50:35 2018 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Wed, 2 May 2018 08:50:35 +0200 Subject: =?UTF-8?Q?Re:_CFV:_New_JDK_Reviewer:_Erik_=c3=96sterlund?= In-Reply-To: <0BC4E9D8-6C68-43D2-9006-1A04C341D841@oracle.com> References: <0BC4E9D8-6C68-43D2-9006-1A04C341D841@oracle.com> Message-ID: <46a80ee3-3e41-d460-0231-d9c394c41b4b@oracle.com> Vote: yes On 02.05.2018 04:56, Kim Barrett wrote: > I hearby nominate Erik ?sterlund (eosterlund) to JDK Project Reviewer. > > Erik is a JDK Project Committer and has contributed 54 changesets[1] > to the OpenJDK project. This includes substantial revisions to core > components such as Atomic and OrderAccess, and leading the effort to > provide a better interface between the GC and other VM components, > e.g. the Access API and various refactorings around BarrierSet. He has > also contributed to the ZGC project, particularly the SPARC port. > > Votes are due by 12:00 EDT May 16, 2018. > > Only current JDK Reviewers [2] 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 [3]. > > Kim Barrett > > [1] http://hg.openjdk.java.net/jdk/jdk/search/?rev=%28keyword%28%22erik.osterlund%40oracle.com%22%29%20or%20keyword%28%22erik.osterlund%40lnu.se%22%29%20or%20author%28eosterlund%29%29&revcount=100 > [2] http://openjdk.java.net/census > [3] http://openjdk.java.net/projects/#reviewer-vote > From tobias.hartmann at oracle.com Wed May 2 06:52:03 2018 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Wed, 2 May 2018 08:52:03 +0200 Subject: CFV: New JDK Reviewer: Roman Kennke In-Reply-To: References: Message-ID: <4ed9edd8-b849-1f69-7e1f-c992009b788b@oracle.com> Vote: yes On 27.04.2018 12:15, Andrew Dinn wrote: > I hereby nominate Roman Kennke (rkennke) to JDK Project Reviewer. > > Roman is a member of the OpenJDK Members group and has contributed 57 > changesets[1] to the JDK project. This includes contributions to the > Shark JIT, 2d graphics, AArch64 runtime and JIT, core JVM runtime, and > GC implementation and interface. Roman is also a prolific contributor to > the Shenandoah project and has been responsible for liasing with the ZGC > team to enable merging of Shenandoah and ZGC into the upstream JDK code > base. > > Votes are due by 12:00 BST May 11, 2018. > > Only current JDK Reviewers [2] 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 [3]. > > Andrew Dinn > > [1] > http://hg.openjdk.java.net/jdk/jdk/search/?rev=%28keyword%28%22rkennke%40redhat.com%22%29%20or%20author%28rkennke%29%29&revcount=100 > [2] http://openjdk.java.net/census > [3] http://openjdk.java.net/projects/#reviewer-vote > > regards, > > > Andrew Dinn > ----------- > Senior Principal Software Engineer > Red Hat UK Ltd > Registered in England and Wales under Company Registration No. 03798903 > Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander > From ashipile at redhat.com Wed May 2 07:00:51 2018 From: ashipile at redhat.com (Aleksey Shipilev) Date: Wed, 2 May 2018 09:00:51 +0200 Subject: =?UTF-8?Q?Re:_CFV:_New_JDK_Reviewer:_Erik_=c3=96sterlund?= In-Reply-To: <0BC4E9D8-6C68-43D2-9006-1A04C341D841@oracle.com> References: <0BC4E9D8-6C68-43D2-9006-1A04C341D841@oracle.com> Message-ID: <944dfbca-249a-ef22-6fb7-45c3788e0024@redhat.com> Vote: yes On 05/02/2018 04:56 AM, Kim Barrett wrote: > I hearby nominate Erik ?sterlund (eosterlund) to JDK Project Reviewer. -Aleksey From sean.coffey at oracle.com Wed May 2 07:17:40 2018 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Wed, 2 May 2018 08:17:40 +0100 Subject: CFV: New JDK Committer: Bhanu Prakash Gopularam Message-ID: <04ae142d-174c-0715-81fc-bad7629adc91@oracle.com> I hereby nominate Bhanu Prakash Gopularam (bgopularam) to JDK Project Committer. Bhanu has been working in the Update Release SQE team for last 3.5 years. In Jan 2018 he received his Ph.D degree from University of Mysore for research work on Data Security using Identity and Attribute based Cryptographic schemes. He has contributed a range of fixes to the JDK Project [0]. Votes are due by 10:00 GMT on May 16th 2018 Only current JDK Project 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]. regards, Sean. [0] http://hg.openjdk.java.net/jdk/jdk/log?revcount=200&rev=(author(bgopularam)+or+desc(%22bhanu.prakash.gopularam%40oracle.com%22))+and+not+merge() [1] http://openjdk.java.net/census [2] http://openjdk.java.net/projects/#committer-vote From sundararajan.athijegannathan at oracle.com Wed May 2 07:30:20 2018 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Wed, 02 May 2018 13:00:20 +0530 Subject: CFV: New JDK Committer: Bhanu Prakash Gopularam In-Reply-To: <04ae142d-174c-0715-81fc-bad7629adc91@oracle.com> References: <04ae142d-174c-0715-81fc-bad7629adc91@oracle.com> Message-ID: <5AE9690C.1080201@oracle.com> Vote: yes -Sundar On 02/05/18, 12:47 PM, Se?n Coffey wrote: > I hereby nominate Bhanu Prakash Gopularam (bgopularam) to JDK Project > Committer. > > Bhanu has been working in the Update Release SQE team for last 3.5 > years. In Jan 2018 he received his Ph.D degree from University of > Mysore for research work on Data Security using Identity and Attribute > based Cryptographic schemes. > > He has contributed a range of fixes to the JDK Project [0]. > > Votes are due by 10:00 GMT on May 16th 2018 > > Only current JDK Project 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]. > > regards, > Sean. > > [0] > http://hg.openjdk.java.net/jdk/jdk/log?revcount=200&rev=(author(bgopularam)+or+desc(%22bhanu.prakash.gopularam%40oracle.com%22))+and+not+merge() > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > From sean.coffey at oracle.com Wed May 2 07:30:21 2018 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Wed, 2 May 2018 08:30:21 +0100 Subject: CFV: New JDK Committer: Bhanu Prakash Gopularam In-Reply-To: <04ae142d-174c-0715-81fc-bad7629adc91@oracle.com> References: <04ae142d-174c-0715-81fc-bad7629adc91@oracle.com> Message-ID: <519db691-6986-1b0a-36b6-7526d3b5f1c4@oracle.com> Vote: yes regards, Sean. On 02/05/2018 08:17, Se?n Coffey wrote: > I hereby nominate Bhanu Prakash Gopularam (bgopularam) to JDK Project > Committer. > > Bhanu has been working in the Update Release SQE team for last 3.5 > years. In Jan 2018 he received his Ph.D degree from University of > Mysore for research work on Data Security using Identity and Attribute > based Cryptographic schemes. > > He has contributed a range of fixes to the JDK Project [0]. > > Votes are due by 10:00 GMT on May 16th 2018 > > Only current JDK Project 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]. > > regards, > Sean. > > [0] > http://hg.openjdk.java.net/jdk/jdk/log?revcount=200&rev=(author(bgopularam)+or+desc(%22bhanu.prakash.gopularam%40oracle.com%22))+and+not+merge() > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > From adinn at redhat.com Wed May 2 07:49:12 2018 From: adinn at redhat.com (Andrew Dinn) Date: Wed, 2 May 2018 08:49:12 +0100 Subject: =?UTF-8?Q?Re:_CFV:_New_JDK_Reviewer:_Erik_=c3=96sterlund?= In-Reply-To: <0BC4E9D8-6C68-43D2-9006-1A04C341D841@oracle.com> References: <0BC4E9D8-6C68-43D2-9006-1A04C341D841@oracle.com> Message-ID: <40f087a3-78bd-912c-bc15-f0ead90ca73b@redhat.com> Vote: yes On 02/05/18 03:56, Kim Barrett wrote: > I hearby nominate Erik ?sterlund (eosterlund) to JDK Project Reviewer. > > Erik is a JDK Project Committer and has contributed 54 changesets[1] > to the OpenJDK project. This includes substantial revisions to core > components such as Atomic and OrderAccess, and leading the effort to > provide a better interface between the GC and other VM components, > e.g. the Access API and various refactorings around BarrierSet. He has > also contributed to the ZGC project, particularly the SPARC port. > > Votes are due by 12:00 EDT May 16, 2018. > > Only current JDK Reviewers [2] 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 [3]. > > Kim Barrett > > [1] http://hg.openjdk.java.net/jdk/jdk/search/?rev=%28keyword%28%22erik.osterlund%40oracle.com%22%29%20or%20keyword%28%22erik.osterlund%40lnu.se%22%29%20or%20author%28eosterlund%29%29&revcount=100 > [2] http://openjdk.java.net/census > [3] http://openjdk.java.net/projects/#reviewer-vote > > -- regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From jesper.wilhelmsson at oracle.com Wed May 2 07:51:52 2018 From: jesper.wilhelmsson at oracle.com (jesper.wilhelmsson at oracle.com) Date: Wed, 2 May 2018 09:51:52 +0200 Subject: =?utf-8?Q?Re=3A_CFV=3A_New_JDK_Reviewer=3A_Erik_=C3=96sterlund?= In-Reply-To: <0BC4E9D8-6C68-43D2-9006-1A04C341D841@oracle.com> References: <0BC4E9D8-6C68-43D2-9006-1A04C341D841@oracle.com> Message-ID: Vote: Yes /Jesper > On 2 May 2018, at 04:56, Kim Barrett wrote: > > I hearby nominate Erik ?sterlund (eosterlund) to JDK Project Reviewer. > > Erik is a JDK Project Committer and has contributed 54 changesets[1] > to the OpenJDK project. This includes substantial revisions to core > components such as Atomic and OrderAccess, and leading the effort to > provide a better interface between the GC and other VM components, > e.g. the Access API and various refactorings around BarrierSet. He has > also contributed to the ZGC project, particularly the SPARC port. > > Votes are due by 12:00 EDT May 16, 2018. > > Only current JDK Reviewers [2] 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 [3]. > > Kim Barrett > > [1] http://hg.openjdk.java.net/jdk/jdk/search/?rev=%28keyword%28%22erik.osterlund%40oracle.com%22%29%20or%20keyword%28%22erik.osterlund%40lnu.se%22%29%20or%20author%28eosterlund%29%29&revcount=100 > [2] http://openjdk.java.net/census > [3] http://openjdk.java.net/projects/#reviewer-vote > From stefan.johansson at oracle.com Wed May 2 07:53:17 2018 From: stefan.johansson at oracle.com (Stefan Johansson) Date: Wed, 2 May 2018 09:53:17 +0200 Subject: =?UTF-8?Q?Re:_CFV:_New_JDK_Reviewer:_Erik_=c3=96sterlund?= In-Reply-To: <0BC4E9D8-6C68-43D2-9006-1A04C341D841@oracle.com> References: <0BC4E9D8-6C68-43D2-9006-1A04C341D841@oracle.com> Message-ID: <5AE96E6D.7060500@oracle.com> Vote: yes On 2018-05-02 04:56, Kim Barrett wrote: > I hearby nominate Erik ?sterlund (eosterlund) to JDK Project Reviewer. > > Erik is a JDK Project Committer and has contributed 54 changesets[1] > to the OpenJDK project. This includes substantial revisions to core > components such as Atomic and OrderAccess, and leading the effort to > provide a better interface between the GC and other VM components, > e.g. the Access API and various refactorings around BarrierSet. He has > also contributed to the ZGC project, particularly the SPARC port. > > Votes are due by 12:00 EDT May 16, 2018. > > Only current JDK Reviewers [2] 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 [3]. > > Kim Barrett > > [1] http://hg.openjdk.java.net/jdk/jdk/search/?rev=%28keyword%28%22erik.osterlund%40oracle.com%22%29%20or%20keyword%28%22erik.osterlund%40lnu.se%22%29%20or%20author%28eosterlund%29%29&revcount=100 > [2] http://openjdk.java.net/census > [3] http://openjdk.java.net/projects/#reviewer-vote > From aph at redhat.com Wed May 2 07:59:29 2018 From: aph at redhat.com (Andrew Haley) Date: Wed, 2 May 2018 08:59:29 +0100 Subject: CFV: New JDK Reviewer: Roman Kennke In-Reply-To: References: Message-ID: <72c226cf-f3a2-f28f-1942-e1a0200f0e7b@redhat.com> Vote: yes -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From thomas.schatzl at oracle.com Wed May 2 08:15:07 2018 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Wed, 02 May 2018 10:15:07 +0200 Subject: CFV: New JDK Reviewer: Erik =?ISO-8859-1?Q?=D6sterlund?= In-Reply-To: <0BC4E9D8-6C68-43D2-9006-1A04C341D841@oracle.com> References: <0BC4E9D8-6C68-43D2-9006-1A04C341D841@oracle.com> Message-ID: <1525248907.2291.0.camel@oracle.com> vote: yes Thomas From per.liden at oracle.com Wed May 2 08:21:21 2018 From: per.liden at oracle.com (Per Liden) Date: Wed, 2 May 2018 10:21:21 +0200 Subject: =?UTF-8?Q?Re:_CFV:_New_JDK_Reviewer:_Erik_=c3=96sterlund?= In-Reply-To: <0BC4E9D8-6C68-43D2-9006-1A04C341D841@oracle.com> References: <0BC4E9D8-6C68-43D2-9006-1A04C341D841@oracle.com> Message-ID: <114a6884-0e30-0b13-5557-333495237245@oracle.com> Vote: yes /Per On 2018-05-02 04:56, Kim Barrett wrote: > I hearby nominate Erik ?sterlund (eosterlund) to JDK Project Reviewer. > > Erik is a JDK Project Committer and has contributed 54 changesets[1] > to the OpenJDK project. This includes substantial revisions to core > components such as Atomic and OrderAccess, and leading the effort to > provide a better interface between the GC and other VM components, > e.g. the Access API and various refactorings around BarrierSet. He has > also contributed to the ZGC project, particularly the SPARC port. > > Votes are due by 12:00 EDT May 16, 2018. > > Only current JDK Reviewers [2] 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 [3]. > > Kim Barrett > > [1] http://hg.openjdk.java.net/jdk/jdk/search/?rev=%28keyword%28%22erik.osterlund%40oracle.com%22%29%20or%20keyword%28%22erik.osterlund%40lnu.se%22%29%20or%20author%28eosterlund%29%29&revcount=100 > [2] http://openjdk.java.net/census > [3] http://openjdk.java.net/projects/#reviewer-vote > From stefan.karlsson at oracle.com Wed May 2 08:21:07 2018 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Wed, 2 May 2018 10:21:07 +0200 Subject: =?UTF-8?Q?Re:_CFV:_New_JDK_Reviewer:_Erik_=c3=96sterlund?= In-Reply-To: <0BC4E9D8-6C68-43D2-9006-1A04C341D841@oracle.com> References: <0BC4E9D8-6C68-43D2-9006-1A04C341D841@oracle.com> Message-ID: <36c33fee-eb42-03f2-5dfd-04a3d2ed3034@oracle.com> Vote: yes StefanK On 2018-05-02 04:56, Kim Barrett wrote: > I hearby nominate Erik ?sterlund (eosterlund) to JDK Project Reviewer. > > Erik is a JDK Project Committer and has contributed 54 changesets[1] > to the OpenJDK project. This includes substantial revisions to core > components such as Atomic and OrderAccess, and leading the effort to > provide a better interface between the GC and other VM components, > e.g. the Access API and various refactorings around BarrierSet. He has > also contributed to the ZGC project, particularly the SPARC port. > > Votes are due by 12:00 EDT May 16, 2018. > > Only current JDK Reviewers [2] 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 [3]. > > Kim Barrett > > [1] http://hg.openjdk.java.net/jdk/jdk/search/?rev=%28keyword%28%22erik.osterlund%40oracle.com%22%29%20or%20keyword%28%22erik.osterlund%40lnu.se%22%29%20or%20author%28eosterlund%29%29&revcount=100 > [2] http://openjdk.java.net/census > [3] http://openjdk.java.net/projects/#reviewer-vote > From magnus.ihse.bursie at oracle.com Wed May 2 06:58:00 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 2 May 2018 08:58:00 +0200 Subject: RFR: JDK-8200083: Bump bootjdk requirement for JDK 11 to JDK 10 In-Reply-To: <8d60d95e-f943-8692-918e-58273adddeb4@oracle.com> References: <25e4a09b-f436-a831-648c-1c0afd111c70@oracle.com> <8d60d95e-f943-8692-918e-58273adddeb4@oracle.com> Message-ID: <2BAFC298-0401-4B7D-B304-4D496CD62B11@oracle.com> Looks good to me. /Magnus > 30 apr. 2018 kl. 17:34 skrev Erik Joelsson : > > Hello, > > I'm re-starting this review with the original proposed patch. This changes the required boot-JDK in configure from the set "9 10 or 11" to "10 or 11". It also changes what Oracle uses in its automated build environment setup from 9 GA to 10 GA. > > I do this based on the proposal [1] to retain the historical N - 1 boot-JDK policy, which has not met any objections yet. > > http://cr.openjdk.java.net/~erikj/8200083/webrev.01/ > > /Erik > > [1] http://mail.openjdk.java.net/pipermail/jdk-dev/2018-April/001075.html > >> On 2018-03-21 14:51, Erik Joelsson wrote: >> Now that JDK 10 has been officially released we can update the boot jdk requirement for JDK 11. Cross posting this to jdk-dev to raise awareness of this rather disruptive change. >> >> This patch changes the requirement on boot jdk version in configure (and updates the configuration that controls what JDK to use as boot in Oracle's internal build system). >> >> Webrev: http://cr.openjdk.java.net/~erikj/8200083/webrev.01/ >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8200083 >> >> /Erik > From rachna.goel at oracle.com Wed May 2 08:29:06 2018 From: rachna.goel at oracle.com (Rachna Goel) Date: Wed, 2 May 2018 13:59:06 +0530 Subject: CFV: New JDK Committer: Bhanu Prakash Gopularam In-Reply-To: <04ae142d-174c-0715-81fc-bad7629adc91@oracle.com> References: <04ae142d-174c-0715-81fc-bad7629adc91@oracle.com> Message-ID: Vote: yes On 5/2/18 12:47 PM, Se?n Coffey wrote: > I hereby nominate Bhanu Prakash Gopularam (bgopularam) to JDK Project > Committer. > > Bhanu has been working in the Update Release SQE team for last 3.5 > years. In Jan 2018 he received his Ph.D degree from University of > Mysore for research work on Data Security using Identity and Attribute > based Cryptographic schemes. > > He has contributed a range of fixes to the JDK Project [0]. > > Votes are due by 10:00 GMT on May 16th 2018 > > Only current JDK Project 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]. > > regards, > Sean. > > [0] > http://hg.openjdk.java.net/jdk/jdk/log?revcount=200&rev=(author(bgopularam)+or+desc(%22bhanu.prakash.gopularam%40oracle.com%22))+and+not+merge() > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > -- Thanks, Rachna From erik.helin at oracle.com Wed May 2 08:26:54 2018 From: erik.helin at oracle.com (Erik Helin) Date: Wed, 2 May 2018 10:26:54 +0200 Subject: =?UTF-8?Q?Re:_CFV:_New_JDK_Reviewer:_Erik_=c3=96sterlund?= In-Reply-To: <0BC4E9D8-6C68-43D2-9006-1A04C341D841@oracle.com> References: <0BC4E9D8-6C68-43D2-9006-1A04C341D841@oracle.com> Message-ID: Vote: yes Thanks, Erik On 05/02/2018 04:56 AM, Kim Barrett wrote: > I hearby nominate Erik ?sterlund (eosterlund) to JDK Project Reviewer. > > Erik is a JDK Project Committer and has contributed 54 changesets[1] > to the OpenJDK project. This includes substantial revisions to core > components such as Atomic and OrderAccess, and leading the effort to > provide a better interface between the GC and other VM components, > e.g. the Access API and various refactorings around BarrierSet. He has > also contributed to the ZGC project, particularly the SPARC port. > > Votes are due by 12:00 EDT May 16, 2018. > > Only current JDK Reviewers [2] 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 [3]. > > Kim Barrett > > [1] http://hg.openjdk.java.net/jdk/jdk/search/?rev=%28keyword%28%22erik.osterlund%40oracle.com%22%29%20or%20keyword%28%22erik.osterlund%40lnu.se%22%29%20or%20author%28eosterlund%29%29&revcount=100 > [2] http://openjdk.java.net/census > [3] http://openjdk.java.net/projects/#reviewer-vote > From volker.simonis at gmail.com Wed May 2 08:33:11 2018 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 2 May 2018 10:33:11 +0200 Subject: =?UTF-8?Q?Re=3A_CFV=3A_New_JDK_Reviewer=3A_Erik_=C3=96sterlund?= In-Reply-To: <0BC4E9D8-6C68-43D2-9006-1A04C341D841@oracle.com> References: <0BC4E9D8-6C68-43D2-9006-1A04C341D841@oracle.com> Message-ID: Vote: yes On Wed, May 2, 2018 at 4:56 AM, Kim Barrett wrote: > I hearby nominate Erik ?sterlund (eosterlund) to JDK Project Reviewer. > > Erik is a JDK Project Committer and has contributed 54 changesets[1] > to the OpenJDK project. This includes substantial revisions to core > components such as Atomic and OrderAccess, and leading the effort to > provide a better interface between the GC and other VM components, > e.g. the Access API and various refactorings around BarrierSet. He has > also contributed to the ZGC project, particularly the SPARC port. > > Votes are due by 12:00 EDT May 16, 2018. > > Only current JDK Reviewers [2] 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 [3]. > > Kim Barrett > > [1] http://hg.openjdk.java.net/jdk/jdk/search/?rev=%28keyword%28%22erik.osterlund%40oracle.com%22%29%20or%20keyword%28%22erik.osterlund%40lnu.se%22%29%20or%20author%28eosterlund%29%29&revcount=100 > [2] http://openjdk.java.net/census > [3] http://openjdk.java.net/projects/#reviewer-vote > From martin.doerr at sap.com Wed May 2 08:37:24 2018 From: martin.doerr at sap.com (Doerr, Martin) Date: Wed, 2 May 2018 08:37:24 +0000 Subject: =?utf-8?B?UkU6IE5ldyBKREsgUmV2aWV3ZXI6IEVyaWsgw5ZzdGVybHVuZA==?= In-Reply-To: <0BC4E9D8-6C68-43D2-9006-1A04C341D841@oracle.com> References: <0BC4E9D8-6C68-43D2-9006-1A04C341D841@oracle.com> Message-ID: <1c7437241c7740969f0b2458c20b8439@sap.com> Vote: yes Regards, Martin From markus.gronlund at oracle.com Wed May 2 08:38:43 2018 From: markus.gronlund at oracle.com (Markus Gronlund) Date: Wed, 2 May 2018 01:38:43 -0700 (PDT) Subject: =?utf-8?B?UkU6IENGVjogTmV3IEpESyBSZXZpZXdlcjogRXJpayDDlnN0ZXJsdW5k?= In-Reply-To: <0BC4E9D8-6C68-43D2-9006-1A04C341D841@oracle.com> References: <0BC4E9D8-6C68-43D2-9006-1A04C341D841@oracle.com> Message-ID: Vote: yes Thanks Markus -----Original Message----- From: Kim Barrett Sent: den 2 maj 2018 04:57 To: jdk-dev Subject: CFV: New JDK Reviewer: Erik ?sterlund I hearby nominate Erik ?sterlund (eosterlund) to JDK Project Reviewer. Erik is a JDK Project Committer and has contributed 54 changesets[1] to the OpenJDK project. This includes substantial revisions to core components such as Atomic and OrderAccess, and leading the effort to provide a better interface between the GC and other VM components, e.g. the Access API and various refactorings around BarrierSet. He has also contributed to the ZGC project, particularly the SPARC port. Votes are due by 12:00 EDT May 16, 2018. Only current JDK Reviewers [2] 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 [3]. Kim Barrett [1] http://hg.openjdk.java.net/jdk/jdk/search/?rev=%28keyword%28%22erik.osterlund%40oracle.com%22%29%20or%20keyword%28%22erik.osterlund%40lnu.se%22%29%20or%20author%28eosterlund%29%29&revcount=100 [2] http://openjdk.java.net/census [3] http://openjdk.java.net/projects/#reviewer-vote From daniel.fuchs at oracle.com Wed May 2 09:42:24 2018 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Wed, 2 May 2018 10:42:24 +0100 Subject: =?UTF-8?Q?Re:_CFV:_New_JDK_Reviewer:_Erik_=c3=96sterlund?= In-Reply-To: <0BC4E9D8-6C68-43D2-9006-1A04C341D841@oracle.com> References: <0BC4E9D8-6C68-43D2-9006-1A04C341D841@oracle.com> Message-ID: <21679b1b-e117-64ce-c672-b53919283253@oracle.com> Vote: yes best regards, -- daniel On 02/05/2018 03:56, Kim Barrett wrote: > I hearby nominate Erik ?sterlund (eosterlund) to JDK Project Reviewer. > From claes.redestad at oracle.com Wed May 2 10:18:38 2018 From: claes.redestad at oracle.com (Claes Redestad) Date: Wed, 2 May 2018 12:18:38 +0200 Subject: =?UTF-8?Q?Re:_CFV:_New_JDK_Reviewer:_Erik_=c3=96sterlund?= In-Reply-To: <0BC4E9D8-6C68-43D2-9006-1A04C341D841@oracle.com> References: <0BC4E9D8-6C68-43D2-9006-1A04C341D841@oracle.com> Message-ID: <7f9a9421-fe01-05c1-0aa6-17b07dd9cbf0@oracle.com> Vote: yes /Claes On 2018-05-02 04:56, Kim Barrett wrote: > I hearby nominate Erik ?sterlund (eosterlund) to JDK Project Reviewer. From zgu at redhat.com Wed May 2 10:23:02 2018 From: zgu at redhat.com (Zhengyu Gu) Date: Wed, 2 May 2018 06:23:02 -0400 Subject: =?UTF-8?Q?Re:_CFV:_New_JDK_Reviewer:_Erik_=c3=96sterlund?= In-Reply-To: <0BC4E9D8-6C68-43D2-9006-1A04C341D841@oracle.com> References: <0BC4E9D8-6C68-43D2-9006-1A04C341D841@oracle.com> Message-ID: Vote: yes -Zhengyu On 05/01/2018 10:56 PM, Kim Barrett wrote: > I hearby nominate Erik ?sterlund (eosterlund) to JDK Project Reviewer. > > Erik is a JDK Project Committer and has contributed 54 changesets[1] > to the OpenJDK project. This includes substantial revisions to core > components such as Atomic and OrderAccess, and leading the effort to > provide a better interface between the GC and other VM components, > e.g. the Access API and various refactorings around BarrierSet. He has > also contributed to the ZGC project, particularly the SPARC port. > > Votes are due by 12:00 EDT May 16, 2018. > > Only current JDK Reviewers [2] 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 [3]. > > Kim Barrett > > [1] http://hg.openjdk.java.net/jdk/jdk/search/?rev=%28keyword%28%22erik.osterlund%40oracle.com%22%29%20or%20keyword%28%22erik.osterlund%40lnu.se%22%29%20or%20author%28eosterlund%29%29&revcount=100 > [2] http://openjdk.java.net/census > [3] http://openjdk.java.net/projects/#reviewer-vote > From lois.foltan at oracle.com Wed May 2 10:26:48 2018 From: lois.foltan at oracle.com (Lois Foltan) Date: Wed, 2 May 2018 06:26:48 -0400 Subject: =?UTF-8?Q?Re:_CFV:_New_JDK_Reviewer:_Erik_=c3=96sterlund?= In-Reply-To: <0BC4E9D8-6C68-43D2-9006-1A04C341D841@oracle.com> References: <0BC4E9D8-6C68-43D2-9006-1A04C341D841@oracle.com> Message-ID: Vote: yes Lois On 5/1/2018 10:56 PM, Kim Barrett wrote: > I hearby nominate Erik ?sterlund (eosterlund) to JDK Project Reviewer. > > Erik is a JDK Project Committer and has contributed 54 changesets[1] > to the OpenJDK project. This includes substantial revisions to core > components such as Atomic and OrderAccess, and leading the effort to > provide a better interface between the GC and other VM components, > e.g. the Access API and various refactorings around BarrierSet. He has > also contributed to the ZGC project, particularly the SPARC port. > > Votes are due by 12:00 EDT May 16, 2018. > > Only current JDK Reviewers [2] 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 [3]. > > Kim Barrett > > [1] http://hg.openjdk.java.net/jdk/jdk/search/?rev=%28keyword%28%22erik.osterlund%40oracle.com%22%29%20or%20keyword%28%22erik.osterlund%40lnu.se%22%29%20or%20author%28eosterlund%29%29&revcount=100 > [2] http://openjdk.java.net/census > [3] http://openjdk.java.net/projects/#reviewer-vote > From robbin.ehn at oracle.com Wed May 2 11:28:48 2018 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Wed, 2 May 2018 13:28:48 +0200 Subject: =?UTF-8?Q?Re:_CFV:_New_JDK_Reviewer:_Erik_=c3=96sterlund?= In-Reply-To: <0BC4E9D8-6C68-43D2-9006-1A04C341D841@oracle.com> References: <0BC4E9D8-6C68-43D2-9006-1A04C341D841@oracle.com> Message-ID: Vote: yes On 2018-05-02 04:56, Kim Barrett wrote: > I hearby nominate Erik ?sterlund (eosterlund) to JDK Project Reviewer. > > Erik is a JDK Project Committer and has contributed 54 changesets[1] > to the OpenJDK project. This includes substantial revisions to core > components such as Atomic and OrderAccess, and leading the effort to > provide a better interface between the GC and other VM components, > e.g. the Access API and various refactorings around BarrierSet. He has > also contributed to the ZGC project, particularly the SPARC port. > > Votes are due by 12:00 EDT May 16, 2018. > > Only current JDK Reviewers [2] 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 [3]. > > Kim Barrett > > [1] http://hg.openjdk.java.net/jdk/jdk/search/?rev=%28keyword%28%22erik.osterlund%40oracle.com%22%29%20or%20keyword%28%22erik.osterlund%40lnu.se%22%29%20or%20author%28eosterlund%29%29&revcount=100 > [2] http://openjdk.java.net/census > [3] http://openjdk.java.net/projects/#reviewer-vote > From robbin.ehn at oracle.com Wed May 2 11:29:26 2018 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Wed, 2 May 2018 13:29:26 +0200 Subject: CFV: New JDK Reviewer: Roman Kennke In-Reply-To: References: Message-ID: Vote: yes On 2018-04-27 12:15, Andrew Dinn wrote: > I hereby nominate Roman Kennke (rkennke) to JDK Project Reviewer. > > Roman is a member of the OpenJDK Members group and has contributed 57 > changesets[1] to the JDK project. This includes contributions to the > Shark JIT, 2d graphics, AArch64 runtime and JIT, core JVM runtime, and > GC implementation and interface. Roman is also a prolific contributor to > the Shenandoah project and has been responsible for liasing with the ZGC > team to enable merging of Shenandoah and ZGC into the upstream JDK code > base. > > Votes are due by 12:00 BST May 11, 2018. > > Only current JDK Reviewers [2] 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 [3]. > > Andrew Dinn > > [1] > http://hg.openjdk.java.net/jdk/jdk/search/?rev=%28keyword%28%22rkennke%40redhat.com%22%29%20or%20author%28rkennke%29%29&revcount=100 > [2] http://openjdk.java.net/census > [3] http://openjdk.java.net/projects/#reviewer-vote > > regards, > > > Andrew Dinn > ----------- > Senior Principal Software Engineer > Red Hat UK Ltd > Registered in England and Wales under Company Registration No. 03798903 > Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander > From rahul.v.raghavan at oracle.com Wed May 2 11:52:46 2018 From: rahul.v.raghavan at oracle.com (Rahul Raghavan) Date: Wed, 2 May 2018 17:22:46 +0530 Subject: CFV: New JDK Committer: Bhanu Prakash Gopularam In-Reply-To: <04ae142d-174c-0715-81fc-bad7629adc91@oracle.com> References: <04ae142d-174c-0715-81fc-bad7629adc91@oracle.com> Message-ID: Vote: yes - Rahul On Wednesday 02 May 2018 12:47 PM, Se?n Coffey wrote: > I hereby nominate Bhanu Prakash Gopularam (bgopularam) to JDK Project > Committer. > > Bhanu has been working in the Update Release SQE team for last 3.5 > years. In Jan 2018 he received his Ph.D degree from University of Mysore > for research work on Data Security using Identity and Attribute based > Cryptographic schemes. > > He has contributed a range of fixes to the JDK Project [0]. > > Votes are due by 10:00 GMT on May 16th 2018 > > Only current JDK Project 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]. > > regards, > Sean. > > [0] > http://hg.openjdk.java.net/jdk/jdk/log?revcount=200&rev=(author(bgopularam)+or+desc(%22bhanu.prakash.gopularam%40oracle.com%22))+and+not+merge() > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > From coleen.phillimore at oracle.com Wed May 2 11:55:54 2018 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Wed, 2 May 2018 07:55:54 -0400 Subject: =?UTF-8?Q?Re:_CFV:_New_JDK_Reviewer:_Erik_=c3=96sterlund?= In-Reply-To: <0BC4E9D8-6C68-43D2-9006-1A04C341D841@oracle.com> References: <0BC4E9D8-6C68-43D2-9006-1A04C341D841@oracle.com> Message-ID: <977534ba-a511-1e6b-867b-2a76a006810a@oracle.com> Vote: yes On 5/1/18 10:56 PM, Kim Barrett wrote: > I hearby nominate Erik ?sterlund (eosterlund) to JDK Project Reviewer. > > Erik is a JDK Project Committer and has contributed 54 changesets[1] > to the OpenJDK project. This includes substantial revisions to core > components such as Atomic and OrderAccess, and leading the effort to > provide a better interface between the GC and other VM components, > e.g. the Access API and various refactorings around BarrierSet. He has > also contributed to the ZGC project, particularly the SPARC port. > > Votes are due by 12:00 EDT May 16, 2018. > > Only current JDK Reviewers [2] 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 [3]. > > Kim Barrett > > [1] http://hg.openjdk.java.net/jdk/jdk/search/?rev=%28keyword%28%22erik.osterlund%40oracle.com%22%29%20or%20keyword%28%22erik.osterlund%40lnu.se%22%29%20or%20author%28eosterlund%29%29&revcount=100 > [2] http://openjdk.java.net/census > [3] http://openjdk.java.net/projects/#reviewer-vote > From nadeeshtv at gmail.com Wed May 2 12:11:49 2018 From: nadeeshtv at gmail.com (nadeesh t v) Date: Wed, 2 May 2018 14:11:49 +0200 Subject: CFV: New JDK Committer: Bhanu Prakash Gopularam In-Reply-To: References: <04ae142d-174c-0715-81fc-bad7629adc91@oracle.com> Message-ID: Vote: Yes Regards, Nadeesh On Wed, May 2, 2018 at 1:52 PM, Rahul Raghavan wrote: > Vote: yes > > - Rahul > > On Wednesday 02 May 2018 12:47 PM, Se?n Coffey wrote: > >> I hereby nominate Bhanu Prakash Gopularam (bgopularam) to JDK Project >> Committer. >> >> Bhanu has been working in the Update Release SQE team for last 3.5 years. >> In Jan 2018 he received his Ph.D degree from University of Mysore for >> research work on Data Security using Identity and Attribute based >> Cryptographic schemes. >> >> He has contributed a range of fixes to the JDK Project [0]. >> >> Votes are due by 10:00 GMT on May 16th 2018 >> >> Only current JDK Project 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]. >> >> regards, >> Sean. >> >> [0] http://hg.openjdk.java.net/jdk/jdk/log?revcount=200&rev=(aut >> hor(bgopularam)+or+desc(%22bhanu.prakash.gopularam%40oracle. >> com%22))+and+not+merge() >> [1] http://openjdk.java.net/census >> [2] http://openjdk.java.net/projects/#committer-vote >> >> -- Thanks and Regards, Nadeesh TV From vyom.tewari at oracle.com Wed May 2 12:38:35 2018 From: vyom.tewari at oracle.com (vyom tewari) Date: Wed, 2 May 2018 18:08:35 +0530 Subject: CFV: New JDK Committer: Bhanu Prakash Gopularam In-Reply-To: <04ae142d-174c-0715-81fc-bad7629adc91@oracle.com> References: <04ae142d-174c-0715-81fc-bad7629adc91@oracle.com> Message-ID: <0bb39780-fb28-2118-ea2e-9cc0ce856342@oracle.com> Vote: yes On Wednesday 02 May 2018 12:47 PM, Se?n Coffey wrote: > I hereby nominate Bhanu Prakash Gopularam (bgopularam) to JDK Project > Committer. > > Bhanu has been working in the Update Release SQE team for last 3.5 > years. In Jan 2018 he received his Ph.D degree from University of > Mysore for research work on Data Security using Identity and Attribute > based Cryptographic schemes. > > He has contributed a range of fixes to the JDK Project [0]. > > Votes are due by 10:00 GMT on May 16th 2018 > > Only current JDK Project 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]. > > regards, > Sean. > > [0] > http://hg.openjdk.java.net/jdk/jdk/log?revcount=200&rev=(author(bgopularam)+or+desc(%22bhanu.prakash.gopularam%40oracle.com%22))+and+not+merge() > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > From daniel.daugherty at oracle.com Wed May 2 12:55:49 2018 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 2 May 2018 08:55:49 -0400 Subject: =?UTF-8?Q?Re:_CFV:_New_JDK_Reviewer:_Erik_=c3=96sterlund?= In-Reply-To: <0BC4E9D8-6C68-43D2-9006-1A04C341D841@oracle.com> References: <0BC4E9D8-6C68-43D2-9006-1A04C341D841@oracle.com> Message-ID: Vote: yes Dan On 5/1/18 10:56 PM, Kim Barrett wrote: > I hearby nominate Erik ?sterlund (eosterlund) to JDK Project Reviewer. > > Erik is a JDK Project Committer and has contributed 54 changesets[1] > to the OpenJDK project. This includes substantial revisions to core > components such as Atomic and OrderAccess, and leading the effort to > provide a better interface between the GC and other VM components, > e.g. the Access API and various refactorings around BarrierSet. He has > also contributed to the ZGC project, particularly the SPARC port. > > Votes are due by 12:00 EDT May 16, 2018. > > Only current JDK Reviewers [2] 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 [3]. > > Kim Barrett > > [1] http://hg.openjdk.java.net/jdk/jdk/search/?rev=%28keyword%28%22erik.osterlund%40oracle.com%22%29%20or%20keyword%28%22erik.osterlund%40lnu.se%22%29%20or%20author%28eosterlund%29%29&revcount=100 > [2] http://openjdk.java.net/census > [3] http://openjdk.java.net/projects/#reviewer-vote > > From felix.yang at oracle.com Wed May 2 13:28:19 2018 From: felix.yang at oracle.com (Felix Yang) Date: Wed, 2 May 2018 21:28:19 +0800 Subject: CFV: New JDK Committer: Bhanu Prakash Gopularam In-Reply-To: <04ae142d-174c-0715-81fc-bad7629adc91@oracle.com> References: <04ae142d-174c-0715-81fc-bad7629adc91@oracle.com> Message-ID: Vote: yes Regards, Felix On 2018/5/2 15:17, Se?n Coffey wrote: > I hereby nominate Bhanu Prakash Gopularam (bgopularam) to JDK Project > Committer. > > Bhanu has been working in the Update Release SQE team for last 3.5 > years. In Jan 2018 he received his Ph.D degree from University of > Mysore for research work on Data Security using Identity and Attribute > based Cryptographic schemes. > > He has contributed a range of fixes to the JDK Project [0]. > > Votes are due by 10:00 GMT on May 16th 2018 > > Only current JDK Project 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]. > > regards, > Sean. > > [0] > http://hg.openjdk.java.net/jdk/jdk/log?revcount=200&rev=(author(bgopularam)+or+desc(%22bhanu.prakash.gopularam%40oracle.com%22))+and+not+merge() > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > From volker.simonis at gmail.com Wed May 2 15:03:17 2018 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 2 May 2018 17:03:17 +0200 Subject: License and Usage Terms of generated API documentation Message-ID: Hi, we currently build OpenJDK and make it available from various sources (e.g. GitHub, apt-get server, DockerHub). We also build the API documentation (i.e. JavaDoc) and would like to make it available from our project page as well. However the default API doc produced by the build looks as follows: http://cr.openjdk.java.net/~simonis/webrevs/2018/jdk10-api-doc/overview-summary.html Especially the footer seems to be weired and only valid for the API doc hosted by Oracle itself. It reads as follows: Use is subject to "license terms" and the "documentation redistribution policy". "license terms" links to http://www.oracle.com/technetwork/java/javase/terms/license/java10speclicense.html which redirects to http://download.oracle.com/otndocs/jcp/java_se-10-final-spec/license.html "documentation redistribution policy" links to http://www.oracle.com/technetwork/java/redist-137594.html Especially the "documentation redistribution policy" is very strict. It states: "The Java SE API Specification is not redistributable." This is a very strong statement. While it may be fine for the API documentation hosted by Oracle (under https://docs.oracle.com/javase/10/docs/api/overview-summary.html) I doubt this can be valid for the OpenJDK API documentation which was produced exclusively from GPLv2 licensed sources (actually even GPLv2 plus Classpath Exception). From my understanding the whole HTML tree generated by "make docs-image" should be by default licensed under GPLv2 as well. I would therefore like to propose to make the following variables from "make/Docs.gmk" configurable with corresponding configure flags: JAVADOC_BASE_URL := http://www.oracle.com/pls/topic/lookup?ctx=javase10&id=homepage BUG_SUBMIT_URL := http://bugreport.java.com/bugreport/ COPYRIGHT_URL := {@docroot}/../legal/copyright.html LICENSE_URL := http://www.oracle.com/technetwork/java/javase/terms/license/java10speclicense.html REDISTRIBUTION_URL := http://www.oracle.com/technetwork/java/redist-137594.html "JAVADOC_BASE_URL" should by default point to an OpenJDK site (although I'm not sure which one will be best suited). It seems strange that the default documentation generated from an OpenSource project like OpenJDK points to some Oracle-proprietary documentation. "BUG_SUBMIT_URL" should use the value of the already existing "--with-vendor-bug-url" if that was set at configure time. "COPYRIGHT_URL" currently points to "copyright.html" which doesn't exist neither in the OpenJDK sources nor in the generated images. Not sure what would be a useful default value here. Maybe just leave it empty? "Copyright ? 1993, 2018, Oracle.." already seems self-explanatory and clear enough. "LICENSE_URL" and "REDISTRIBUTION_URL" should both by default point to the GPLv2+CPE LICENSE file and this LICENSE file should be copied into the API doc HTML tree (much like it is copied into the various subdirectories of the "legel/" directory of an OpenJDK image) I can open an issue for this topic and propose an implementation if there's consensus on this topic. Thank you and best regards, Volker From vladimir.kozlov at oracle.com Wed May 2 16:15:54 2018 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 2 May 2018 09:15:54 -0700 Subject: =?UTF-8?Q?Re:_CFV:_New_JDK_Reviewer:_Erik_=c3=96sterlund?= In-Reply-To: <0BC4E9D8-6C68-43D2-9006-1A04C341D841@oracle.com> References: <0BC4E9D8-6C68-43D2-9006-1A04C341D841@oracle.com> Message-ID: Vote: yes On 5/1/18 7:56 PM, Kim Barrett wrote: > I hearby nominate Erik ?sterlund (eosterlund) to JDK Project Reviewer. > > Erik is a JDK Project Committer and has contributed 54 changesets[1] > to the OpenJDK project. This includes substantial revisions to core > components such as Atomic and OrderAccess, and leading the effort to > provide a better interface between the GC and other VM components, > e.g. the Access API and various refactorings around BarrierSet. He has > also contributed to the ZGC project, particularly the SPARC port. > > Votes are due by 12:00 EDT May 16, 2018. > > Only current JDK Reviewers [2] 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 [3]. > > Kim Barrett > > [1] http://hg.openjdk.java.net/jdk/jdk/search/?rev=%28keyword%28%22erik.osterlund%40oracle.com%22%29%20or%20keyword%28%22erik.osterlund%40lnu.se%22%29%20or%20author%28eosterlund%29%29&revcount=100 > [2] http://openjdk.java.net/census > [3] http://openjdk.java.net/projects/#reviewer-vote > From vladimir.x.ivanov at oracle.com Wed May 2 17:18:40 2018 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Wed, 2 May 2018 10:18:40 -0700 Subject: =?UTF-8?Q?Re:_CFV:_New_JDK_Reviewer:_Erik_=c3=96sterlund?= In-Reply-To: <0BC4E9D8-6C68-43D2-9006-1A04C341D841@oracle.com> References: <0BC4E9D8-6C68-43D2-9006-1A04C341D841@oracle.com> Message-ID: <16039fae-52c6-4b08-e553-38e75aa0d9c0@oracle.com> Vote: yes Best regards, Vladimir Ivanov On 5/1/18 19:56, Kim Barrett wrote: > I hearby nominate Erik ?sterlund (eosterlund) to JDK Project Reviewer. From zgu at redhat.com Wed May 2 19:47:54 2018 From: zgu at redhat.com (Zhengyu Gu) Date: Wed, 2 May 2018 15:47:54 -0400 Subject: jdk/submit status Message-ID: <9fd398a1-e580-1102-dafa-565cf20005f1@redhat.com> Hi, I have a few submits to jdk/submit repo since yesterday afternoon, and haven't gotten any results back. Is it still offline? or does it support JDK-#######-# branch name? (all my submits have names like this). Thanks, -Zhengyu From christian.tornqvist at oracle.com Wed May 2 19:53:56 2018 From: christian.tornqvist at oracle.com (Christian Tornqvist) Date: Wed, 2 May 2018 15:53:56 -0400 Subject: jdk/submit status In-Reply-To: <9fd398a1-e580-1102-dafa-565cf20005f1@redhat.com> References: <9fd398a1-e580-1102-dafa-565cf20005f1@redhat.com> Message-ID: Hi Zhengyu, The regular expression for matching the branch name was incorrectly set for the JDK submit-repo, I?ve fixed that now and the jobs should be launching shortly. Your JDK-8199868-1 branch is processing right now. Sorry for the inconvenience! Thanks, Christian > On May 2, 2018, at 3:47 54PM, Zhengyu Gu wrote: > > Hi, > > I have a few submits to jdk/submit repo since yesterday afternoon, and haven't gotten any results back. > > Is it still offline? or does it support JDK-#######-# branch name? (all my submits have names like this). > > Thanks, > > -Zhengyu From zgu at redhat.com Wed May 2 19:59:35 2018 From: zgu at redhat.com (Zhengyu Gu) Date: Wed, 2 May 2018 15:59:35 -0400 Subject: jdk/submit status In-Reply-To: References: <9fd398a1-e580-1102-dafa-565cf20005f1@redhat.com> Message-ID: <62619695-f8a3-54e0-81d6-0a47543076e5@redhat.com> On 05/02/2018 03:53 PM, Christian Tornqvist wrote: > Hi Zhengyu, > > The regular expression for matching the branch name was incorrectly set for the JDK submit-repo, I?ve fixed that now and the jobs should be launching shortly. Your JDK-8199868-1 branch is processing right now. Sorry for the inconvenience! > Thanks, Christian! -Zhengyu > Thanks, > Christian > >> On May 2, 2018, at 3:47 54PM, Zhengyu Gu wrote: >> >> Hi, >> >> I have a few submits to jdk/submit repo since yesterday afternoon, and haven't gotten any results back. >> >> Is it still offline? or does it support JDK-#######-# branch name? (all my submits have names like this). >> >> Thanks, >> >> -Zhengyu > From jini.george at oracle.com Thu May 3 01:24:31 2018 From: jini.george at oracle.com (Jini George) Date: Thu, 3 May 2018 06:54:31 +0530 Subject: CFV: New JDK Committer: Bhanu Prakash Gopularam In-Reply-To: <04ae142d-174c-0715-81fc-bad7629adc91@oracle.com> References: <04ae142d-174c-0715-81fc-bad7629adc91@oracle.com> Message-ID: <923697c9-7234-5577-e128-c15cc506e811@oracle.com> Vote: yes On 5/2/2018 12:47 PM, Se?n Coffey wrote: > I hereby nominate Bhanu Prakash Gopularam (bgopularam) to JDK Project > Committer. > > Bhanu has been working in the Update Release SQE team for last 3.5 > years. In Jan 2018 he received his Ph.D degree from University of Mysore > for research work on Data Security using Identity and Attribute based > Cryptographic schemes. > > He has contributed a range of fixes to the JDK Project [0]. > > Votes are due by 10:00 GMT on May 16th 2018 > > Only current JDK Project 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]. > > regards, > Sean. > > [0] > http://hg.openjdk.java.net/jdk/jdk/log?revcount=200&rev=(author(bgopularam)+or+desc(%22bhanu.prakash.gopularam%40oracle.com%22))+and+not+merge() > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > From jayathirth.d.v at oracle.com Thu May 3 06:43:12 2018 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Wed, 2 May 2018 23:43:12 -0700 (PDT) Subject: CFV: New JDK Committer: Bhanu Prakash Gopularam In-Reply-To: <04ae142d-174c-0715-81fc-bad7629adc91@oracle.com> References: <04ae142d-174c-0715-81fc-bad7629adc91@oracle.com> Message-ID: <3e3839ae-e230-4db5-b9f0-32f4a777ce88@default> Vote : Yes Thanks, Jay -----Original Message----- From: Se?n Coffey Sent: Wednesday, May 02, 2018 12:48 PM To: jdk-dev at openjdk.java.net Subject: CFV: New JDK Committer: Bhanu Prakash Gopularam I hereby nominate Bhanu Prakash Gopularam (bgopularam) to JDK Project Committer. Bhanu has been working in the Update Release SQE team for last 3.5 years. In Jan 2018 he received his Ph.D degree from University of Mysore for research work on Data Security using Identity and Attribute based Cryptographic schemes. He has contributed a range of fixes to the JDK Project [0]. Votes are due by 10:00 GMT on May 16th 2018 Only current JDK Project 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]. regards, Sean. [0] http://hg.openjdk.java.net/jdk/jdk/log?revcount=200&rev=(author(bgopularam)+or+desc(%22bhanu.prakash.gopularam%40oracle.com%22))+and+not+merge() [1] http://openjdk.java.net/census [2] http://openjdk.java.net/projects/#committer-vote From frank.yuan at oracle.com Thu May 3 07:26:51 2018 From: frank.yuan at oracle.com (Frank Yuan) Date: Thu, 3 May 2018 15:26:51 +0800 Subject: New JDK Committer: Bhanu Prakash Gopularam In-Reply-To: <04ae142d-174c-0715-81fc-bad7629adc91@oracle.com> References: <04ae142d-174c-0715-81fc-bad7629adc91@oracle.com> Message-ID: <053d01d3e2b0$20f699f0$62e3cdd0$@oracle.com> Vote: yes Regards, Frank > -----Original Message----- > From: jdk-dev [mailto:jdk-dev-bounces at openjdk.java.net] On Behalf Of Se?n Coffey > Sent: Wednesday, May 02, 2018 3:18 PM > To: jdk-dev at openjdk.java.net > Subject: CFV: New JDK Committer: Bhanu Prakash Gopularam > > I hereby nominate Bhanu Prakash Gopularam (bgopularam) to JDK Project > Committer. > > Bhanu has been working in the Update Release SQE team for last 3.5 > years. In Jan 2018 he received his Ph.D degree from University of Mysore > for research work on Data Security using Identity and Attribute based > Cryptographic schemes. > > He has contributed a range of fixes to the JDK Project [0]. > > Votes are due by 10:00 GMT on May 16th 2018 > > Only current JDK Project 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]. > > regards, > Sean. > > [0] > http://hg.openjdk.java.net/jdk/jdk/log?revcount=200&rev=(author(bgopularam)+or+desc(%22bhanu.prakash.gopularam%40oracle.com%2 > 2))+and+not+merge() > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote From magnus.ihse.bursie at oracle.com Thu May 3 08:02:43 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 3 May 2018 10:02:43 +0200 Subject: CFV: New JDK Reviewer: Roman Kennke In-Reply-To: References: Message-ID: <34b95447-4537-5ac1-f0cf-66afaadd338f@oracle.com> Vote: yes /Magnus On 2018-04-27 12:15, Andrew Dinn wrote: > I hereby nominate Roman Kennke (rkennke) to JDK Project Reviewer. > > Roman is a member of the OpenJDK Members group and has contributed 57 > changesets[1] to the JDK project. This includes contributions to the > Shark JIT, 2d graphics, AArch64 runtime and JIT, core JVM runtime, and > GC implementation and interface. Roman is also a prolific contributor to > the Shenandoah project and has been responsible for liasing with the ZGC > team to enable merging of Shenandoah and ZGC into the upstream JDK code > base. > > Votes are due by 12:00 BST May 11, 2018. > > Only current JDK Reviewers [2] 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 [3]. > > Andrew Dinn > > [1] > http://hg.openjdk.java.net/jdk/jdk/search/?rev=%28keyword%28%22rkennke%40redhat.com%22%29%20or%20author%28rkennke%29%29&revcount=100 > [2] http://openjdk.java.net/census > [3] http://openjdk.java.net/projects/#reviewer-vote > > regards, > > > Andrew Dinn > ----------- > Senior Principal Software Engineer > Red Hat UK Ltd > Registered in England and Wales under Company Registration No. 03798903 > Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From magnus.ihse.bursie at oracle.com Thu May 3 08:03:39 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 3 May 2018 10:03:39 +0200 Subject: =?UTF-8?Q?Re:_CFV:_New_JDK_Reviewer:_Erik_=c3=96sterlund?= In-Reply-To: <0BC4E9D8-6C68-43D2-9006-1A04C341D841@oracle.com> References: <0BC4E9D8-6C68-43D2-9006-1A04C341D841@oracle.com> Message-ID: Vote: yes /Magnus On 2018-05-02 04:56, Kim Barrett wrote: > I hearby nominate Erik ?sterlund (eosterlund) to JDK Project Reviewer. > > Erik is a JDK Project Committer and has contributed 54 changesets[1] > to the OpenJDK project. This includes substantial revisions to core > components such as Atomic and OrderAccess, and leading the effort to > provide a better interface between the GC and other VM components, > e.g. the Access API and various refactorings around BarrierSet. He has > also contributed to the ZGC project, particularly the SPARC port. > > Votes are due by 12:00 EDT May 16, 2018. > > Only current JDK Reviewers [2] 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 [3]. > > Kim Barrett > > [1] http://hg.openjdk.java.net/jdk/jdk/search/?rev=%28keyword%28%22erik.osterlund%40oracle.com%22%29%20or%20keyword%28%22erik.osterlund%40lnu.se%22%29%20or%20author%28eosterlund%29%29&revcount=100 > [2] http://openjdk.java.net/census > [3] http://openjdk.java.net/projects/#reviewer-vote > From huaming.li at oracle.com Thu May 3 08:09:20 2018 From: huaming.li at oracle.com (Hamlin Li) Date: Thu, 3 May 2018 16:09:20 +0800 Subject: CFV: New JDK Committer: Bhanu Prakash Gopularam In-Reply-To: <04ae142d-174c-0715-81fc-bad7629adc91@oracle.com> References: <04ae142d-174c-0715-81fc-bad7629adc91@oracle.com> Message-ID: <62270537-09de-42c4-d4e7-27d6ca7174d5@oracle.com> Vote: Yes On 02/05/2018 3:17 PM, Se?n Coffey wrote: > I hereby nominate Bhanu Prakash Gopularam (bgopularam) to JDK Project > Committer. > > Bhanu has been working in the Update Release SQE team for last 3.5 > years. In Jan 2018 he received his Ph.D degree from University of > Mysore for research work on Data Security using Identity and Attribute > based Cryptographic schemes. > > He has contributed a range of fixes to the JDK Project [0]. > > Votes are due by 10:00 GMT on May 16th 2018 > > Only current JDK Project 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]. > > regards, > Sean. > > [0] > http://hg.openjdk.java.net/jdk/jdk/log?revcount=200&rev=(author(bgopularam)+or+desc(%22bhanu.prakash.gopularam%40oracle.com%22))+and+not+merge() > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > From sibabrata.sahoo at oracle.com Thu May 3 08:38:23 2018 From: sibabrata.sahoo at oracle.com (Sibabrata Sahoo) Date: Thu, 3 May 2018 01:38:23 -0700 (PDT) Subject: CFV: New JDK Committer: Bhanu Prakash Gopularam In-Reply-To: <04ae142d-174c-0715-81fc-bad7629adc91@oracle.com> References: <04ae142d-174c-0715-81fc-bad7629adc91@oracle.com> Message-ID: <3da2f884-4948-4a82-99e1-fcc9385f21af@default> Vote: yes -----Original Message----- From: Se?n Coffey Sent: Wednesday, May 02, 2018 12:48 PM To: jdk-dev at openjdk.java.net Subject: CFV: New JDK Committer: Bhanu Prakash Gopularam I hereby nominate Bhanu Prakash Gopularam (bgopularam) to JDK Project Committer. Bhanu has been working in the Update Release SQE team for last 3.5 years. In Jan 2018 he received his Ph.D degree from University of Mysore for research work on Data Security using Identity and Attribute based Cryptographic schemes. He has contributed a range of fixes to the JDK Project [0]. Votes are due by 10:00 GMT on May 16th 2018 Only current JDK Project 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]. regards, Sean. [0] http://hg.openjdk.java.net/jdk/jdk/log?revcount=200&rev=(author(bgopularam)+or+desc(%22bhanu.prakash.gopularam%40oracle.com%22))+and+not+merge() [1] http://openjdk.java.net/census [2] http://openjdk.java.net/projects/#committer-vote From sha.jiang at oracle.com Thu May 3 08:47:31 2018 From: sha.jiang at oracle.com (sha.jiang at oracle.com) Date: Thu, 3 May 2018 16:47:31 +0800 Subject: CFV: New JDK Committer: Bhanu Prakash Gopularam In-Reply-To: <04ae142d-174c-0715-81fc-bad7629adc91@oracle.com> References: <04ae142d-174c-0715-81fc-bad7629adc91@oracle.com> Message-ID: <5e388ecc-a231-4ed2-6bc2-cc90e7f106cc@oracle.com> Vote: yes On 02/05/2018 15:17, Se?n Coffey wrote: > I hereby nominate Bhanu Prakash Gopularam (bgopularam) to JDK Project > Committer. > > Bhanu has been working in the Update Release SQE team for last 3.5 > years. In Jan 2018 he received his Ph.D degree from University of > Mysore for research work on Data Security using Identity and Attribute > based Cryptographic schemes. > > He has contributed a range of fixes to the JDK Project [0]. > > Votes are due by 10:00 GMT on May 16th 2018 > > Only current JDK Project 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]. > > regards, > Sean. > > [0] > http://hg.openjdk.java.net/jdk/jdk/log?revcount=200&rev=(author(bgopularam)+or+desc(%22bhanu.prakash.gopularam%40oracle.com%22))+and+not+merge() > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > > From nishit.jain at oracle.com Thu May 3 09:33:04 2018 From: nishit.jain at oracle.com (Nishit Jain) Date: Thu, 3 May 2018 15:03:04 +0530 Subject: CFV: New JDK Committer: Bhanu Prakash Gopularam In-Reply-To: <04ae142d-174c-0715-81fc-bad7629adc91@oracle.com> References: <04ae142d-174c-0715-81fc-bad7629adc91@oracle.com> Message-ID: <1a2d6ebc-1acd-0cda-972d-6484e8df0c0a@oracle.com> Vote: Yes Regards, Nishit Jain On 02-05-2018 12:47, Se?n Coffey wrote: > I hereby nominate Bhanu Prakash Gopularam (bgopularam) to JDK Project > Committer. > > Bhanu has been working in the Update Release SQE team for last 3.5 > years. In Jan 2018 he received his Ph.D degree from University of > Mysore for research work on Data Security using Identity and Attribute > based Cryptographic schemes. > > He has contributed a range of fixes to the JDK Project [0]. > > Votes are due by 10:00 GMT on May 16th 2018 > > Only current JDK Project 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]. > > regards, > Sean. > > [0] > http://hg.openjdk.java.net/jdk/jdk/log?revcount=200&rev=(author(bgopularam)+or+desc(%22bhanu.prakash.gopularam%40oracle.com%22))+and+not+merge() > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > From magnus.ihse.bursie at oracle.com Thu May 3 10:21:52 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 3 May 2018 12:21:52 +0200 Subject: License and Usage Terms of generated API documentation In-Reply-To: References: Message-ID: <2bb6b950-da35-5e8c-b868-fef39b3bf365@oracle.com> On 2018-05-02 17:03, Volker Simonis wrote: > Hi, > > we currently build OpenJDK and make it available from various sources > (e.g. GitHub, apt-get server, DockerHub). We also build the API > documentation (i.e. JavaDoc) and would like to make it available from > our project page as well. However the default API doc produced by the > build looks as follows: > > http://cr.openjdk.java.net/~simonis/webrevs/2018/jdk10-api-doc/overview-summary.html > > Especially the footer seems to be weired and only valid for the API > doc hosted by Oracle itself. It reads as follows: > > Use is subject to "license terms" and the "documentation redistribution policy". > > "license terms" links to > http://www.oracle.com/technetwork/java/javase/terms/license/java10speclicense.html > which redirects to > http://download.oracle.com/otndocs/jcp/java_se-10-final-spec/license.html > > "documentation redistribution policy" links to > http://www.oracle.com/technetwork/java/redist-137594.html > > Especially the "documentation redistribution policy" is very strict. It states: > > "The Java SE API Specification is not redistributable." > > This is a very strong statement. While it may be fine for the API > documentation hosted by Oracle (under > https://docs.oracle.com/javase/10/docs/api/overview-summary.html) I > doubt this can be valid for the OpenJDK API documentation which was > produced exclusively from GPLv2 licensed sources (actually even GPLv2 > plus Classpath Exception). From my understanding the whole HTML tree > generated by "make docs-image" should be by default licensed under > GPLv2 as well. > > I would therefore like to propose to make the following variables from > "make/Docs.gmk" configurable with corresponding configure flags: > > JAVADOC_BASE_URL := > http://www.oracle.com/pls/topic/lookup?ctx=javase10&id=homepage > BUG_SUBMIT_URL := http://bugreport.java.com/bugreport/ > COPYRIGHT_URL := {@docroot}/../legal/copyright.html > LICENSE_URL := http://www.oracle.com/technetwork/java/javase/terms/license/java10speclicense.html > REDISTRIBUTION_URL := http://www.oracle.com/technetwork/java/redist-137594.html > > "JAVADOC_BASE_URL" should by default point to an OpenJDK site > (although I'm not sure which one will be best suited). It seems > strange that the default documentation generated from an OpenSource > project like OpenJDK points to some Oracle-proprietary documentation. > > "BUG_SUBMIT_URL" should use the value of the already existing > "--with-vendor-bug-url" if that was set at configure time. > > "COPYRIGHT_URL" currently points to "copyright.html" which doesn't > exist neither in the OpenJDK sources nor in the generated images. Not > sure what would be a useful default value here. Maybe just leave it > empty? "Copyright ? 1993, 2018, Oracle.." already seems > self-explanatory and clear enough. > > "LICENSE_URL" and "REDISTRIBUTION_URL" should both by default point to > the GPLv2+CPE LICENSE file and this LICENSE file should be copied into > the API doc HTML tree (much like it is copied into the various > subdirectories of the "legel/" directory of an OpenJDK image) > > I can open an issue for this topic and propose an implementation if > there's consensus on this topic. > > Thank you and best regards, > Volker Since you added build-dev, I'll chip in some of my cents. The code in the make file has been around like Forever. The current implementation is just what has been ported between frameworks and source control systems and updated for changes in release version and URL schemes. I agree that is odd that the Oracle URL is hard-coded. On the other hand, there is no common place where generated OpenJDK documents are published. (The Oracle site technically speaking documents the Java Platform API, not the OpenJDK, even if any actual difference is minimal to non-existant wrt docs.) It would make sense to me to have a OpenJDK-based documentation driven by the community. I'm guessing it's no easy thing to create this, though. A lot of links on the interwebz are pointing to the docs at docs.oracle.com, and it would probably be quite messy if the same (or even worse, almost the same) documentation were published both at docs.oracle.com and java.net. Also, the question arises as to who should do the hosting, and how. So it's definitely a community issue to resolve, and one in which Oracle's legacy is important to take into consideration. Until a consensus of a better solution for hosting the generated documentation is reached, I'd like to avoid changing the build code. That will just open for an uneccessary split in what constitutes the proper documentation URL. /Magnus From Michael.Rasmussen at roguewave.com Thu May 3 11:00:38 2018 From: Michael.Rasmussen at roguewave.com (Michael Rasmussen) Date: Thu, 3 May 2018 11:00:38 +0000 Subject: License and Usage Terms of generated API documentation In-Reply-To: <2bb6b950-da35-5e8c-b868-fef39b3bf365@oracle.com> References: , <2bb6b950-da35-5e8c-b868-fef39b3bf365@oracle.com> Message-ID: On 2018-05-03 13:21, Magnus Ihse Bursie wrote: > A lot of links on the interwebz are pointing to the docs at > docs.oracle.com, and it would probably be quite messy if the same (or > even worse, almost the same) documentation were published both at > docs.oracle.com and java.net. Well, until quite recently, that was the case. The docs were available at both download.java.net and docs.oracle.com (though download.java.net seemed to basically just be a proxy for docs.oracle.com) Google still returns results for download.java.net for the Java 10 docs, for instance this link: https://download.java.net/java/jdk10/docs/api/java/lang/Integer.html ( https://i.imgur.com/4ZugUQa.png ) Also, the Java 11 EA docs are on download.java.net: https://download.java.net/java/early_access/jdk11/docs/api/index.html?overview-summary.html /Michael From artem.smotrakov at gmail.com Thu May 3 11:55:19 2018 From: artem.smotrakov at gmail.com (Artem Smotrakov) Date: Thu, 3 May 2018 13:55:19 +0200 Subject: CFV: New JDK Committer: Bhanu Prakash Gopularam In-Reply-To: <04ae142d-174c-0715-81fc-bad7629adc91@oracle.com> References: <04ae142d-174c-0715-81fc-bad7629adc91@oracle.com> Message-ID: Vote: yes Artem 2018-05-02 9:17 GMT+02:00 Se?n Coffey : > I hereby nominate Bhanu Prakash Gopularam (bgopularam) to JDK Project > Committer. > > Bhanu has been working in the Update Release SQE team for last 3.5 years. > In Jan 2018 he received his Ph.D degree from University of Mysore for > research work on Data Security using Identity and Attribute based > Cryptographic schemes. > > He has contributed a range of fixes to the JDK Project [0]. > > Votes are due by 10:00 GMT on May 16th 2018 > > Only current JDK Project 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]. > > regards, > Sean. > > [0] http://hg.openjdk.java.net/jdk/jdk/log?revcount=200&rev=(aut > hor(bgopularam)+or+desc(%22bhanu.prakash.gopularam%40oracle. > com%22))+and+not+merge() > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > > From volker.simonis at gmail.com Thu May 3 12:16:11 2018 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 3 May 2018 14:16:11 +0200 Subject: License and Usage Terms of generated API documentation In-Reply-To: <2bb6b950-da35-5e8c-b868-fef39b3bf365@oracle.com> References: <2bb6b950-da35-5e8c-b868-fef39b3bf365@oracle.com> Message-ID: On Thu, May 3, 2018 at 12:21 PM, Magnus Ihse Bursie wrote: > On 2018-05-02 17:03, Volker Simonis wrote: >> >> Hi, >> >> we currently build OpenJDK and make it available from various sources >> (e.g. GitHub, apt-get server, DockerHub). We also build the API >> documentation (i.e. JavaDoc) and would like to make it available from >> our project page as well. However the default API doc produced by the >> build looks as follows: >> >> >> http://cr.openjdk.java.net/~simonis/webrevs/2018/jdk10-api-doc/overview-summary.html >> >> Especially the footer seems to be weired and only valid for the API >> doc hosted by Oracle itself. It reads as follows: >> >> Use is subject to "license terms" and the "documentation redistribution >> policy". >> >> "license terms" links to >> >> http://www.oracle.com/technetwork/java/javase/terms/license/java10speclicense.html >> which redirects to >> http://download.oracle.com/otndocs/jcp/java_se-10-final-spec/license.html >> >> "documentation redistribution policy" links to >> http://www.oracle.com/technetwork/java/redist-137594.html >> >> Especially the "documentation redistribution policy" is very strict. It >> states: >> >> "The Java SE API Specification is not redistributable." >> >> This is a very strong statement. While it may be fine for the API >> documentation hosted by Oracle (under >> https://docs.oracle.com/javase/10/docs/api/overview-summary.html) I >> doubt this can be valid for the OpenJDK API documentation which was >> produced exclusively from GPLv2 licensed sources (actually even GPLv2 >> plus Classpath Exception). From my understanding the whole HTML tree >> generated by "make docs-image" should be by default licensed under >> GPLv2 as well. >> >> I would therefore like to propose to make the following variables from >> "make/Docs.gmk" configurable with corresponding configure flags: >> >> JAVADOC_BASE_URL := >> http://www.oracle.com/pls/topic/lookup?ctx=javase10&id=homepage >> BUG_SUBMIT_URL := http://bugreport.java.com/bugreport/ >> COPYRIGHT_URL := {@docroot}/../legal/copyright.html >> LICENSE_URL := >> http://www.oracle.com/technetwork/java/javase/terms/license/java10speclicense.html >> REDISTRIBUTION_URL := >> http://www.oracle.com/technetwork/java/redist-137594.html >> >> "JAVADOC_BASE_URL" should by default point to an OpenJDK site >> (although I'm not sure which one will be best suited). It seems >> strange that the default documentation generated from an OpenSource >> project like OpenJDK points to some Oracle-proprietary documentation. >> >> "BUG_SUBMIT_URL" should use the value of the already existing >> "--with-vendor-bug-url" if that was set at configure time. >> >> "COPYRIGHT_URL" currently points to "copyright.html" which doesn't >> exist neither in the OpenJDK sources nor in the generated images. Not >> sure what would be a useful default value here. Maybe just leave it >> empty? "Copyright ? 1993, 2018, Oracle.." already seems >> self-explanatory and clear enough. >> >> "LICENSE_URL" and "REDISTRIBUTION_URL" should both by default point to >> the GPLv2+CPE LICENSE file and this LICENSE file should be copied into >> the API doc HTML tree (much like it is copied into the various >> subdirectories of the "legel/" directory of an OpenJDK image) >> >> I can open an issue for this topic and propose an implementation if >> there's consensus on this topic. >> >> Thank you and best regards, >> Volker > > Since you added build-dev, I'll chip in some of my cents. > > The code in the make file has been around like Forever. The current > implementation is just what has been ported between frameworks and source > control systems and updated for changes in release version and URL schemes. > Thanks for confirming this. That was my impression as well :) > I agree that is odd that the Oracle URL is hard-coded. On the other hand, > there is no common place where generated OpenJDK documents are published. > (The Oracle site technically speaking documents the Java Platform API, not > the OpenJDK, even if any actual difference is minimal to non-existant wrt > docs.) > > It would make sense to me to have a OpenJDK-based documentation driven by > the community. I'm guessing it's no easy thing to create this, though. A lot > of links on the interwebz are pointing to the docs at docs.oracle.com, and > it would probably be quite messy if the same (or even worse, almost the > same) documentation were published both at docs.oracle.com and java.net. > Also, the question arises as to who should do the hosting, and how. > > So it's definitely a community issue to resolve, and one in which Oracle's > legacy is important to take into consideration. > > Until a consensus of a better solution for hosting the generated > documentation is reached, I'd like to avoid changing the build code. That > will just open for an uneccessary split in what constitutes the proper > documentation URL. > The JAVADOC_BASE_URL is the minor issue here and I agree that it would be not easy to create a community driven documentation of the same or at least similar quality as we have today from Oracle. Nevertheless I don't see why we shouldn't be able to make this URL configurable at configure time. The main issue are the two links to "LICENSE_URL" and "REDISTRIBUTION_URL" which clearly refer to the API-docs published by Oracle. I just want to be able to publish these API-docs myself without having to refer to these restrictive licenses. The change itself, to make these URLs configurable at configure time, would be trivial (and again, I'm not against leaving the default "as-is" if this is important for you). > /Magnus > From mark.reinhold at oracle.com Thu May 3 22:17:41 2018 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Thu, 03 May 2018 15:17:41 -0700 Subject: Result: New JDK Committer: Pankaj Bansal In-Reply-To: <8cae46ab-e879-5d01-1909-7a9c52560192@oracle.com> References: <8cae46ab-e879-5d01-1909-7a9c52560192@oracle.com> Message-ID: <20180503151741.28901490@eggemoggin.niobe.net> 2018/4/26 13:06:24 -0700, sergey.bylokhov at oracle.com: > Voting for Pankaj Bansal [1] is now closed. > > Yes: 9 > Veto: 0 > Abstain: 0 > > According to the Bylaws definition of Lazy Consensus, this is > sufficient to approve the nomination. So recorded. - Mark From christoph.langer at sap.com Fri May 4 15:00:56 2018 From: christoph.langer at sap.com (Langer, Christoph) Date: Fri, 4 May 2018 15:00:56 +0000 Subject: =?utf-8?B?UkU6IE5ldyBKREsgUmV2aWV3ZXI6IEVyaWsgw5ZzdGVybHVuZA==?= In-Reply-To: <0BC4E9D8-6C68-43D2-9006-1A04C341D841@oracle.com> References: <0BC4E9D8-6C68-43D2-9006-1A04C341D841@oracle.com> Message-ID: Vote: yes Best regards Christoph > -----Original Message----- > From: jdk-dev [mailto:jdk-dev-bounces at openjdk.java.net] On Behalf Of Kim > Barrett > Sent: Mittwoch, 2. Mai 2018 04:57 > To: jdk-dev > Subject: CFV: New JDK Reviewer: Erik ?sterlund > > I hearby nominate Erik ?sterlund (eosterlund) to JDK Project Reviewer. > > Erik is a JDK Project Committer and has contributed 54 changesets[1] > to the OpenJDK project. This includes substantial revisions to core > components such as Atomic and OrderAccess, and leading the effort to > provide a better interface between the GC and other VM components, > e.g. the Access API and various refactorings around BarrierSet. He has > also contributed to the ZGC project, particularly the SPARC port. > > Votes are due by 12:00 EDT May 16, 2018. > > Only current JDK Reviewers [2] 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 [3]. > > Kim Barrett > > [1] > http://hg.openjdk.java.net/jdk/jdk/search/?rev=%28keyword%28%22erik.o > sterlund%40oracle.com%22%29%20or%20keyword%28%22erik.osterlund%4 > 0lnu.se%22%29%20or%20author%28eosterlund%29%29&revcount=100 > [2] http://openjdk.java.net/census > [3] http://openjdk.java.net/projects/#reviewer-vote From karen.kinnear at oracle.com Fri May 4 15:18:39 2018 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Fri, 4 May 2018 11:18:39 -0400 Subject: =?utf-8?Q?Re=3A_CFV=3A_New_JDK_Reviewer=3A_Erik_=C3=96sterlund?= In-Reply-To: <0BC4E9D8-6C68-43D2-9006-1A04C341D841@oracle.com> References: <0BC4E9D8-6C68-43D2-9006-1A04C341D841@oracle.com> Message-ID: <295B1EEE-F9E8-4863-B6ED-B2194DD77D99@oracle.com> Vote: yes Karen > On May 1, 2018, at 10:56 PM, Kim Barrett wrote: > > I hearby nominate Erik ?sterlund (eosterlund) to JDK Project Reviewer. > > Erik is a JDK Project Committer and has contributed 54 changesets[1] > to the OpenJDK project. This includes substantial revisions to core > components such as Atomic and OrderAccess, and leading the effort to > provide a better interface between the GC and other VM components, > e.g. the Access API and various refactorings around BarrierSet. He has > also contributed to the ZGC project, particularly the SPARC port. > > Votes are due by 12:00 EDT May 16, 2018. > > Only current JDK Reviewers [2] 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 [3]. > > Kim Barrett > > [1] http://hg.openjdk.java.net/jdk/jdk/search/?rev=%28keyword%28%22erik.osterlund%40oracle.com%22%29%20or%20keyword%28%22erik.osterlund%40lnu.se%22%29%20or%20author%28eosterlund%29%29&revcount=100 > [2] http://openjdk.java.net/census > [3] http://openjdk.java.net/projects/#reviewer-vote > From thomas.stuefe at gmail.com Sat May 5 05:18:01 2018 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Sat, 5 May 2018 07:18:01 +0200 Subject: JBS is not reachable Message-ID: Hi all, I seem to have more and more trouble accessing JBS lately. Currently it times out three out of four times for me. Is this problem known? Thanks, Thomas From mark.reinhold at oracle.com Mon May 7 09:07:59 2018 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Mon, 07 May 2018 10:07:59 +0100 Subject: JEP proposed to target JDK 11: 324: Key Agreement with Curve25519 and Curve448 In-Reply-To: <20180426210744.E349B1BA1E2@eggemoggin.niobe.net> References: <20180426210744.E349B1BA1E2@eggemoggin.niobe.net> Message-ID: <20180507100759.226394003@eggemoggin.niobe.net> 2018/4/26 22:07:44 +0100, mark.reinhold at oracle.com: > The following JEP is proposed to target JDK 11: > > 324: Key Agreement with Curve25519 and Curve448 > http://openjdk.java.net/jeps/324 > > Feedback on this proposal is more than welcome, as are reasoned > objections. If no such objections are raised by 23:00 UTC on Thursday, > 3 May, or if they're raised and then satisfactorily answered, then > per the JEP 2.0 process proposal [1] I'll target this JEP to JDK 11. Hearing no objections, I?ve targeted this JEP to JDK 11. - Mark From mark.reinhold at oracle.com Mon May 7 09:08:07 2018 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Mon, 07 May 2018 10:08:07 +0100 Subject: JEP proposed to target JDK 11: 328: Flight Recorder In-Reply-To: <20180426210745.0F9301BA1E6@eggemoggin.niobe.net> References: <20180426210745.0F9301BA1E6@eggemoggin.niobe.net> Message-ID: <20180507100807.573467816@eggemoggin.niobe.net> 2018/4/26 22:07:45 +0100, mark.reinhold at oracle.com: > The following JEP is proposed to target JDK 11: > > 328: Flight Recorder > http://openjdk.java.net/jeps/328 > > Feedback on this proposal is more than welcome, as are reasoned > objections. If no such objections are raised by 23:00 UTC on Thursday, > 3 May, or if they're raised and then satisfactorily answered, then > per the JEP 2.0 process proposal [1] I'll target this JEP to JDK 11. Hearing no objections, I?ve targeted this JEP to JDK 11. - Mark From mark.reinhold at oracle.com Mon May 7 09:08:21 2018 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Mon, 07 May 2018 10:08:21 +0100 Subject: JEP proposed to target JDK 11: 327: Unicode 10 In-Reply-To: <20180426210745.032051BA1E4@eggemoggin.niobe.net> References: <20180426210745.032051BA1E4@eggemoggin.niobe.net> Message-ID: <20180507100821.83945372@eggemoggin.niobe.net> 2018/4/26 22:07:45 +0100, mark.reinhold at oracle.com: > The following JEP is proposed to target JDK 11: > > 327: Unicode 10 > http://openjdk.java.net/jeps/327 > > Feedback on this proposal is more than welcome, as are reasoned > objections. If no such objections are raised by 23:00 UTC on Thursday, > 3 May, or if they're raised and then satisfactorily answered, then > per the JEP 2.0 process proposal [1] I'll target this JEP to JDK 11. Hearing no objections, I?ve targeted this JEP to JDK 11. - Mark From mark.reinhold at oracle.com Mon May 7 09:31:58 2018 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Mon, 07 May 2018 10:31:58 +0100 Subject: License and Usage Terms of generated API documentation In-Reply-To: References: <2bb6b950-da35-5e8c-b868-fef39b3bf365@oracle.com> Message-ID: <20180507103158.909726963@eggemoggin.niobe.net> 2018/5/3 13:16:11 +0100, volker.simonis at gmail.com: > On Thu, May 3, 2018 at 12:21 PM, magnus.ihse.bursie at oracle.com wrote: >> ... >> >> Until a consensus of a better solution for hosting the generated >> documentation is reached, I'd like to avoid changing the build code. That >> will just open for an uneccessary split in what constitutes the proper >> documentation URL. > > The JAVADOC_BASE_URL is the minor issue here and I agree that it would > be not easy to create a community driven documentation of the same or > at least similar quality as we have today from Oracle. We should publish the API Javadoc somewhere on OpenJDK at some point, but that?s not something that we can do today -- if nothing else, we?d have to set up a CDN to front these very popular pages. > Nevertheless I > don't see why we shouldn't be able to make this URL configurable at > configure time. Agreed. > The main issue are the two links to "LICENSE_URL" and > "REDISTRIBUTION_URL" which clearly refer to the API-docs published by > Oracle. I just want to be able to publish these API-docs myself > without having to refer to these restrictive licenses. The change > itself, to make these URLs configurable at configure time, would be > trivial (and again, I'm not against leaving the default "as-is" if > this is important for you). Making these things configurable is a fine idea, but I agree with Magnus that it?d be simpler for now to retain the current values as defaults. - Mark From Roger.Riggs at Oracle.com Mon May 7 15:38:52 2018 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Mon, 7 May 2018 11:38:52 -0400 Subject: CFV: New JDK Committer: Bhanu Prakash Gopularam In-Reply-To: <04ae142d-174c-0715-81fc-bad7629adc91@oracle.com> References: <04ae142d-174c-0715-81fc-bad7629adc91@oracle.com> Message-ID: <7c9c3fd8-ec92-4fd7-37af-fb0fe7787345@Oracle.com> Vote: Yes On 5/2/2018 3:17 AM, Se?n Coffey wrote: > I hereby nominate Bhanu Prakash Gopularam (bgopularam) to JDK Project > Committer. From serguei.spitsyn at oracle.com Mon May 7 21:38:33 2018 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 7 May 2018 14:38:33 -0700 Subject: =?UTF-8?Q?Re:_CFV:_New_JDK_Reviewer:_Erik_=c3=96sterlund?= In-Reply-To: <0BC4E9D8-6C68-43D2-9006-1A04C341D841@oracle.com> References: <0BC4E9D8-6C68-43D2-9006-1A04C341D841@oracle.com> Message-ID: Vote: yes From thomas.stuefe at gmail.com Tue May 8 04:49:12 2018 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Tue, 8 May 2018 06:49:12 +0200 Subject: =?UTF-8?Q?Re=3A_CFV=3A_New_JDK_Reviewer=3A_Erik_=C3=96sterlund?= In-Reply-To: <0BC4E9D8-6C68-43D2-9006-1A04C341D841@oracle.com> References: <0BC4E9D8-6C68-43D2-9006-1A04C341D841@oracle.com> Message-ID: Vote: yes. On Wed, May 2, 2018 at 4:56 AM, Kim Barrett wrote: > I hearby nominate Erik ?sterlund (eosterlund) to JDK Project Reviewer. > > Erik is a JDK Project Committer and has contributed 54 changesets[1] > to the OpenJDK project. This includes substantial revisions to core > components such as Atomic and OrderAccess, and leading the effort to > provide a better interface between the GC and other VM components, > e.g. the Access API and various refactorings around BarrierSet. He has > also contributed to the ZGC project, particularly the SPARC port. > > Votes are due by 12:00 EDT May 16, 2018. > > Only current JDK Reviewers [2] 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 [3]. > > Kim Barrett > > [1] http://hg.openjdk.java.net/jdk/jdk/search/?rev=%28keyword%28%22erik.osterlund%40oracle.com%22%29%20or%20keyword%28%22erik.osterlund%40lnu.se%22%29%20or%20author%28eosterlund%29%29&revcount=100 > [2] http://openjdk.java.net/census > [3] http://openjdk.java.net/projects/#reviewer-vote > From sean.mullan at oracle.com Tue May 8 14:07:40 2018 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 8 May 2018 10:07:40 -0400 Subject: CFV: New JDK Committer: Bhanu Prakash Gopularam In-Reply-To: <04ae142d-174c-0715-81fc-bad7629adc91@oracle.com> References: <04ae142d-174c-0715-81fc-bad7629adc91@oracle.com> Message-ID: Vote: yes --Sean From jamsheed.c.m at oracle.com Tue May 8 14:54:03 2018 From: jamsheed.c.m at oracle.com (jamsheed) Date: Tue, 8 May 2018 20:24:03 +0530 Subject: CFV: New JDK Committer: Bhanu Prakash Gopularam In-Reply-To: References: <04ae142d-174c-0715-81fc-bad7629adc91@oracle.com> Message-ID: Vote: Yes Best regards, Jamsheed From gnu.andrew at redhat.com Wed May 9 16:21:23 2018 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 9 May 2018 17:21:23 +0100 Subject: CFV: New JDK Reviewer: Roman Kennke In-Reply-To: References: Message-ID: On 27 April 2018 at 11:15, Andrew Dinn wrote: > I hereby nominate Roman Kennke (rkennke) to JDK Project Reviewer. > > Roman is a member of the OpenJDK Members group and has contributed 57 > changesets[1] to the JDK project. This includes contributions to the > Shark JIT, 2d graphics, AArch64 runtime and JIT, core JVM runtime, and > GC implementation and interface. Roman is also a prolific contributor to > the Shenandoah project and has been responsible for liasing with the ZGC > team to enable merging of Shenandoah and ZGC into the upstream JDK code > base. > > Votes are due by 12:00 BST May 11, 2018. > > Only current JDK Reviewers [2] 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 [3]. > > Andrew Dinn > > [1] > http://hg.openjdk.java.net/jdk/jdk/search/?rev=%28keyword%28%22rkennke%40redhat.com%22%29%20or%20author%28rkennke%29%29&revcount=100 > [2] http://openjdk.java.net/census > [3] http://openjdk.java.net/projects/#reviewer-vote > > regards, > > > Andrew Dinn > ----------- > Senior Principal Software Engineer > Red Hat UK Ltd > Registered in England and Wales under Company Registration No. 03798903 > Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander Vote: Yes. -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Web Site: http://fuseyism.com Twitter: https://twitter.com/gnu_andrew_java PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From sharath.ballal at oracle.com Wed May 9 16:45:52 2018 From: sharath.ballal at oracle.com (Sharath Ballal) Date: Wed, 9 May 2018 09:45:52 -0700 (PDT) Subject: CFV: New JDK Committer: Bhanu Prakash Gopularam In-Reply-To: <04ae142d-174c-0715-81fc-bad7629adc91@oracle.com> References: <04ae142d-174c-0715-81fc-bad7629adc91@oracle.com> Message-ID: Vote: Yes Thanks, Sharath -----Original Message----- From: Se?n Coffey Sent: Wednesday, May 02, 2018 12:48 PM To: jdk-dev at openjdk.java.net Subject: CFV: New JDK Committer: Bhanu Prakash Gopularam I hereby nominate Bhanu Prakash Gopularam (bgopularam) to JDK Project Committer. From joe.darcy at oracle.com Thu May 10 16:32:53 2018 From: joe.darcy at oracle.com (joe darcy) Date: Thu, 10 May 2018 09:32:53 -0700 Subject: FYI, two updates to CSR functionality after Jira upgrade: backport support and better issue creation Message-ID: Hello, With the recent Jira upgrade to JBS, there were two improvements to the CSR functionality: 1) CSRs can now be created for Backport issue types. When a change is being made to multiple release trains, but the nature of the fix differs in the different release trains, separate CSRs should be filed for each distinct change. 2) When a CSR is first created, the same window is opened as when an issue is "Edit"-ed. This allows easy access to all the fields of a CSR, including compatibility impact and scope. Cheers, -Joe From joe.darcy at oracle.com Thu May 10 17:56:03 2018 From: joe.darcy at oracle.com (joe darcy) Date: Thu, 10 May 2018 10:56:03 -0700 Subject: Proposed implementation of JEP 182 in JDK 11: drop javac support for -source/-target/--release 6 Message-ID: Hello, As background, JEP 182 "Policy for Retiring javac -source and -target Options" (http://openjdk.java.net/jeps/182) puts forth a "one plus three back" policy for the supported range of -source and -target arguments to javac. (As of JDK 9, a matching range of arguments is supported for the --release option.) This policy was formulated under the old release model before the six month release cadence. Under this policy, support for the 5/1.5 argument was removed in JDK 9. JDK 10 added support for a 10 argument and retained all the older values that were supported under JDK 9. JDK 6 first shipped at the end of 2006, which will be nearly 12 years before the planned JDK 11 GA date. JDK 7 first shipped in 2011. Given the age of JDK 6, I think it is reasonable in 2018 for JDK 11 to drop support for -source/-target/--release 1.6/6, leaving support for 7, 8, 9, 10, and 11. This provides support for four rather than three older versions in JDK 11, but better matches the time span of releases discussed in the JEP. Future code reviews of the implementation of this removal and related work ??? JDK-8028563: Remove javac support for 6/1.6 source and target values ??? JDK-8173606: Deprecate constructors of 7-era visitors would take place on compiler-dev. Comments? Cheers, -Joe From forax at univ-mlv.fr Thu May 10 18:38:42 2018 From: forax at univ-mlv.fr (Remi Forax) Date: Thu, 10 May 2018 20:38:42 +0200 (CEST) Subject: Proposed implementation of JEP 182 in JDK 11: drop javac support for -source/-target/--release 6 In-Reply-To: References: Message-ID: <261741852.1302972.1525977522871.JavaMail.zimbra@u-pem.fr> Hi Joe, this is really a big change, there are two good reason to not do that now: - There is really a good chance that it will split the ecosystem because while Android as now adopted the OpenJDK, there are few phones that support the Android version built on top of the OpenJDK. As a library writer, i do not want to have to support two version of my library, the one compatible with 6, the once compatible with a more recent version of the OpenJDK. I agree with you that 6 is an old release but we should not base our decision only on the release date of 6 but also on the current state of the ecosystem. - This is the kind of change that should be done at the start of the development of a release, with a notice before, and not in the middle of the development, here, you are changing the whole story of how to migrate to 11, i think developer deserves to be aware of this kind of change in advance. The good news is that we are now only 4 months from the start of the development of 12, which is plenty of time to announce that the support of 6 in the compiler will be remove in 12 and not a long time to wait before actually doing the actual change. regards, R?mi ----- Mail original ----- > De: "joe darcy" > ?: "jdk-dev" > Envoy?: Jeudi 10 Mai 2018 19:56:03 > Objet: Proposed implementation of JEP 182 in JDK 11: drop javac support for -source/-target/--release 6 > Hello, > > As background, JEP 182 "Policy for Retiring javac -source and -target > Options" (http://openjdk.java.net/jeps/182) puts forth a "one plus three > back" policy for the supported range of -source and -target arguments to > javac. (As of JDK 9, a matching range of arguments is supported for the > --release option.) > > This policy was formulated under the old release model before the six > month release cadence. > > Under this policy, support for the 5/1.5 argument was removed in JDK 9. > JDK 10 added support for a 10 argument and retained all the older values > that were supported under JDK 9. > > JDK 6 first shipped at the end of 2006, which will be nearly 12 years > before the planned JDK 11 GA date. JDK 7 first shipped in 2011. > > Given the age of JDK 6, I think it is reasonable in 2018 for JDK 11 to > drop support for -source/-target/--release 1.6/6, leaving support for 7, > 8, 9, 10, and 11. This provides support for four rather than three older > versions in JDK 11, but better matches the time span of releases > discussed in the JEP. > > Future code reviews of the implementation of this removal and related work > > ??? JDK-8028563: Remove javac support for 6/1.6 source and target values > ??? JDK-8173606: Deprecate constructors of 7-era visitors > > would take place on compiler-dev. > > Comments? > > Cheers, > > -Joe From benjamin.john.evans at gmail.com Thu May 10 18:56:26 2018 From: benjamin.john.evans at gmail.com (Ben Evans) Date: Thu, 10 May 2018 19:56:26 +0100 Subject: Proposed implementation of JEP 182 in JDK 11: drop javac support for -source/-target/--release 6 In-Reply-To: <261741852.1302972.1525977522871.JavaMail.zimbra@u-pem.fr> References: <261741852.1302972.1525977522871.JavaMail.zimbra@u-pem.fr> Message-ID: Hi Remi, I'm going to take issue with both of your reasons. Sorry about that :) 1. That Android chose an approach to their ecosystem (adoption over everything else) is scarcely the fault of the mainstream Java community, and we shouldn't sacrifice our forward progress for their potential marginal convenience. Gentle additional pressure on older Android users to upgrade and stop being walking security liabilities is IMO a good thing. 2. This is a major milestone, and I would argue that it is important that it lands on an LTS release & avoid baking the capability to generate Java 6 bytecode into the ecosystem for another LTS cycle (which are quite long). Thanks, Ben On Thu, May 10, 2018 at 7:38 PM, Remi Forax wrote: > Hi Joe, > this is really a big change, there are two good reason to not do that now: > - There is really a good chance that it will split the ecosystem because while Android as now adopted the OpenJDK, there are few phones that support the Android version built on top of the OpenJDK. As a library writer, i do not want to have to support two version of my library, the one compatible with 6, the once compatible with a more recent version of the OpenJDK. > I agree with you that 6 is an old release but we should not base our decision only on the release date of 6 but also on the current state of the ecosystem. > - This is the kind of change that should be done at the start of the development of a release, with a notice before, and not in the middle of the development, here, you are changing the whole story of how to migrate to 11, i think developer deserves to be aware of this kind of change in advance. > > The good news is that we are now only 4 months from the start of the development of 12, which is plenty of time to announce that the support of 6 in the compiler will be remove in 12 and not a long time to wait before actually doing the actual change. > > regards, > R?mi > > ----- Mail original ----- >> De: "joe darcy" >> ?: "jdk-dev" >> Envoy?: Jeudi 10 Mai 2018 19:56:03 >> Objet: Proposed implementation of JEP 182 in JDK 11: drop javac support for -source/-target/--release 6 > >> Hello, >> >> As background, JEP 182 "Policy for Retiring javac -source and -target >> Options" (http://openjdk.java.net/jeps/182) puts forth a "one plus three >> back" policy for the supported range of -source and -target arguments to >> javac. (As of JDK 9, a matching range of arguments is supported for the >> --release option.) >> >> This policy was formulated under the old release model before the six >> month release cadence. >> >> Under this policy, support for the 5/1.5 argument was removed in JDK 9. >> JDK 10 added support for a 10 argument and retained all the older values >> that were supported under JDK 9. >> >> JDK 6 first shipped at the end of 2006, which will be nearly 12 years >> before the planned JDK 11 GA date. JDK 7 first shipped in 2011. >> >> Given the age of JDK 6, I think it is reasonable in 2018 for JDK 11 to >> drop support for -source/-target/--release 1.6/6, leaving support for 7, >> 8, 9, 10, and 11. This provides support for four rather than three older >> versions in JDK 11, but better matches the time span of releases >> discussed in the JEP. >> >> Future code reviews of the implementation of this removal and related work >> >> JDK-8028563: Remove javac support for 6/1.6 source and target values >> JDK-8173606: Deprecate constructors of 7-era visitors >> >> would take place on compiler-dev. >> >> Comments? >> >> Cheers, >> >> -Joe From forax at univ-mlv.fr Thu May 10 21:05:14 2018 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Thu, 10 May 2018 23:05:14 +0200 (CEST) Subject: Proposed implementation of JEP 182 in JDK 11: drop javac support for -source/-target/--release 6 In-Reply-To: References: <261741852.1302972.1525977522871.JavaMail.zimbra@u-pem.fr> Message-ID: <1381258429.1336532.1525986314341.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "Ben Evans" > ?: "Remi Forax" > Cc: "joe darcy" , "jdk-dev" > Envoy?: Jeudi 10 Mai 2018 20:56:26 > Objet: Re: Proposed implementation of JEP 182 in JDK 11: drop javac support for -source/-target/--release 6 > Hi Remi, Hi Ben, > > I'm going to take issue with both of your reasons. Sorry about that :) :) > > 1. That Android chose an approach to their ecosystem (adoption over > everything else) is scarcely the fault of the mainstream Java > community, and we shouldn't sacrifice our forward progress for their > potential marginal convenience. I do not think it slow our forward progress, if you take a look to the past, at some point in the past, some people decide to stay on 1.4, while others were already use 6, we end up with more choices, each library developers decide if it makes sense for their library to still be compatible with 1.4 or not. Some new libraries emerge, been developed for 6 from the beginning, using using generics, annotations, offering even more choices. Back in the nowadays world, some libraries will choose to stay on 6 while some moved to use lambdas, default methods, that's doesn't slow us but offer us more choice. > Gentle additional pressure on older Android users to upgrade and stop being walking security liabilities is IMO a good thing. That's another discussion. My wife as a fully patched Android that only support 1.6. > > 2. This is a major milestone, and I would argue that it is important > that it lands on an LTS release & avoid baking the capability to > generate Java 6 bytecode into the ecosystem for another LTS cycle > (which are quite long). This is exactly the kind of change i would like to appear at the beginning of a new LTS cycle than at the end, so library maintainers have the time to think how to deal with that instead of rushing a support at the end of a LTS cycle. We need to move forward, everybody agree with that, but there is no need to rush, we only need to wait 4 months. > > Thanks, > > Ben regards, R?mi > > > On Thu, May 10, 2018 at 7:38 PM, Remi Forax wrote: >> Hi Joe, >> this is really a big change, there are two good reason to not do that now: >> - There is really a good chance that it will split the ecosystem because while >> Android as now adopted the OpenJDK, there are few phones that support the >> Android version built on top of the OpenJDK. As a library writer, i do not want >> to have to support two version of my library, the one compatible with 6, the >> once compatible with a more recent version of the OpenJDK. >> I agree with you that 6 is an old release but we should not base our decision >> only on the release date of 6 but also on the current state of the ecosystem. >> - This is the kind of change that should be done at the start of the development >> of a release, with a notice before, and not in the middle of the development, >> here, you are changing the whole story of how to migrate to 11, i think >> developer deserves to be aware of this kind of change in advance. >> >> The good news is that we are now only 4 months from the start of the development >> of 12, which is plenty of time to announce that the support of 6 in the >> compiler will be remove in 12 and not a long time to wait before actually doing >> the actual change. >> >> regards, >> R?mi >> >> ----- Mail original ----- >>> De: "joe darcy" >>> ?: "jdk-dev" >>> Envoy?: Jeudi 10 Mai 2018 19:56:03 >>> Objet: Proposed implementation of JEP 182 in JDK 11: drop javac support for >>> -source/-target/--release 6 >> >>> Hello, >>> >>> As background, JEP 182 "Policy for Retiring javac -source and -target >>> Options" (http://openjdk.java.net/jeps/182) puts forth a "one plus three >>> back" policy for the supported range of -source and -target arguments to >>> javac. (As of JDK 9, a matching range of arguments is supported for the >>> --release option.) >>> >>> This policy was formulated under the old release model before the six >>> month release cadence. >>> >>> Under this policy, support for the 5/1.5 argument was removed in JDK 9. >>> JDK 10 added support for a 10 argument and retained all the older values >>> that were supported under JDK 9. >>> >>> JDK 6 first shipped at the end of 2006, which will be nearly 12 years >>> before the planned JDK 11 GA date. JDK 7 first shipped in 2011. >>> >>> Given the age of JDK 6, I think it is reasonable in 2018 for JDK 11 to >>> drop support for -source/-target/--release 1.6/6, leaving support for 7, >>> 8, 9, 10, and 11. This provides support for four rather than three older >>> versions in JDK 11, but better matches the time span of releases >>> discussed in the JEP. >>> >>> Future code reviews of the implementation of this removal and related work >>> >>> JDK-8028563: Remove javac support for 6/1.6 source and target values >>> JDK-8173606: Deprecate constructors of 7-era visitors >>> >>> would take place on compiler-dev. >>> >>> Comments? >>> >>> Cheers, >>> > >> -Joe From ebourg at apache.org Thu May 10 22:26:45 2018 From: ebourg at apache.org (Emmanuel Bourg) Date: Fri, 11 May 2018 00:26:45 +0200 Subject: Proposed implementation of JEP 182 in JDK 11: drop javac support for -source/-target/--release 6 In-Reply-To: References: Message-ID: <921f66be-6071-0c6f-e2cb-2b9d51824620@apache.org> Le 10/05/2018 ? 19:56, joe.darcy at oracle.com (joe darcy) a ?crit?: > Given the age of JDK 6, I think it is reasonable in 2018 for JDK 11 to > drop support for -source/-target/--release 1.6/6, leaving support for 7, > 8, 9, 10, and 11. This provides support for four rather than three older > versions in JDK 11, but better matches the time span of releases > discussed in the JEP. The short lived releases don't really matter in this context, most developers just skip them and aim for the LTS releases. I think the JEP 182 policy should be translated to "one + 3 LTS back", so for Java 11 that would mean supporting 6, 7, 8, (9, 10), and 11. With this logic the next Java 17 LTS would support 7, 8, (9, 10), 11, (12, 13, 14, 15, 16), and 17. I suggest dropping the oldest version in the release immediately following the newest LTS (so Java 6 support would be removed in JDK 12, and Java 7 support would go away in JDK 18). Emmanuel Bourg From scolebourne at joda.org Thu May 10 22:31:51 2018 From: scolebourne at joda.org (Stephen Colebourne) Date: Thu, 10 May 2018 23:31:51 +0100 Subject: Proposed implementation of JEP 182 in JDK 11: drop javac support for -source/-target/--release 6 In-Reply-To: References: Message-ID: On 10 May 2018 at 18:56, joe darcy wrote: > Given the age of JDK 6, I think it is reasonable in 2018 for JDK 11 to drop > support for -source/-target/--release 1.6/6, leaving support for 7, 8, 9, > 10, and 11. This provides support for four rather than three older versions > in JDK 11, but better matches the time span of releases discussed in the > JEP. This would cause me personally a fair bit of pain, as I have projects that are based on Java 6 using the release flag that cannot be upgraded to Java 7 or 8. Currently, the release flag allows me to use the latest Java compiler to perform a release with module-info, yet still produce a jar file compatible with Java 6. Without this flag I would have to use an older compiler (Java 10 I suppose) even when that version is supposed to be obsolete. On 10 May 2018 at 23:26, Emmanuel Bourg wrote: > The short lived releases don't really matter in this context, most > developers just skip them and aim for the LTS releases. I think the JEP > 182 policy should be translated to "one + 3 LTS back", so for Java 11 > that would mean supporting 6, 7, 8, (9, 10), and 11. This seems like a better approach. For me personally, I could keep using the LTS Java 11 to build Java 6 files for the next 3 years, which is better than having to use an unpatched insecure Java 10 JDK. And I don't think I'd object to support for 6 being dropped in 12 either. Stephen From fridrich.strba at suse.com Fri May 11 04:02:27 2018 From: fridrich.strba at suse.com (Fridrich Strba) Date: Fri, 11 May 2018 06:02:27 +0200 Subject: Proposed implementation of JEP 182 in JDK 11: drop javac support for -source/-target/--release 6 In-Reply-To: References: Message-ID: Not like I have anything to add to Stephen's opinion. Just give you a context about what we do in SUSE. For the while, our SUSE Linux Enterprise 15 will be released before OpenJDK 11 and we will have to make the OpenJDK 11 the default Java as a maintenance update. All our packages that don't use any 7+ features are built using source 6 and target 6. Changing that at this point of the release cycle would be quite error prone, not considering that we speak about hundreds of packages. So, I would be thankful to the Java luminaries not to do this change in 11. Just my 2 cents Fridrich On 11/05/18 00:31, Stephen Colebourne wrote: > On 10 May 2018 at 18:56, joe darcy wrote: >> Given the age of JDK 6, I think it is reasonable in 2018 for JDK 11 to drop >> support for -source/-target/--release 1.6/6, leaving support for 7, 8, 9, >> 10, and 11. This provides support for four rather than three older versions >> in JDK 11, but better matches the time span of releases discussed in the >> JEP. > > This would cause me personally a fair bit of pain, as I have projects > that are based on Java 6 using the release flag that cannot be > upgraded to Java 7 or 8. Currently, the release flag allows me to use > the latest Java compiler to perform a release with module-info, yet > still produce a jar file compatible with Java 6. Without this flag I > would have to use an older compiler (Java 10 I suppose) even when that > version is supposed to be obsolete. > > On 10 May 2018 at 23:26, Emmanuel Bourg wrote: >> The short lived releases don't really matter in this context, most >> developers just skip them and aim for the LTS releases. I think the JEP >> 182 policy should be translated to "one + 3 LTS back", so for Java 11 >> that would mean supporting 6, 7, 8, (9, 10), and 11. > > This seems like a better approach. For me personally, I could keep > using the LTS Java 11 to build Java 6 files for the next 3 years, > which is better than having to use an unpatched insecure Java 10 JDK. > And I don't think I'd object to support for 6 being dropped in 12 > either. > > Stephen > From joe.darcy at oracle.com Fri May 11 05:21:22 2018 From: joe.darcy at oracle.com (joe darcy) Date: Thu, 10 May 2018 22:21:22 -0700 Subject: Proposed implementation of JEP 182 in JDK 11: drop javac support for -source/-target/--release 6 In-Reply-To: References: Message-ID: <44b994b5-3857-a63c-7139-7e1d75f6792a@oracle.com> Hi Fridrich, Thanks for the feedback. FYI, in case you are not already aware of the option, I recommend using "javac --release N" for your builds directly or indirectly in preference to "javac -source N -target N". The major difference is that --release N restricts the API on the bootclasspath (or module equivalent) to the API from JDK N, reducing the need to use 3rd party tools like Animal Sniffer to monitor API usage. The --release option to javac is available in JDK 9 and later. HTH, -Joe On 5/10/2018 9:02 PM, Fridrich Strba wrote: > Not like I have anything to add to Stephen's opinion. Just give you a > context about what we do in SUSE. For the while, our SUSE Linux > Enterprise 15 will be released before OpenJDK 11 and we will have to > make the OpenJDK 11 the default Java as a maintenance update. All our > packages that don't use any 7+ features are built using source 6 and > target 6. Changing that at this point of the release cycle would be > quite error prone, not considering that we speak about hundreds of > packages. So, I would be thankful to the Java luminaries not to do this > change in 11. > > Just my 2 cents > > Fridrich > > From adinn at redhat.com Fri May 11 13:36:16 2018 From: adinn at redhat.com (Andrew Dinn) Date: Fri, 11 May 2018 14:36:16 +0100 Subject: Result: New JDK Reviewer: Roman Kennke Message-ID: <6d5ea179-fec8-e60d-9313-aa54b8dd57a7@redhat.com> Voting for Roman Kennke [1] is now closed. Yes: 31 Veto: 0 Abstain: 0 According to the Bylaws definition of Three-Vote Consensus, this is sufficient to approve the nomination. Andrew Dinn [1] http://mail.openjdk.java.net/pipermail/jdk-dev/2018-April/001088.html From joe.darcy at oracle.com Fri May 11 17:19:17 2018 From: joe.darcy at oracle.com (joe darcy) Date: Fri, 11 May 2018 10:19:17 -0700 Subject: Proposed implementation of JEP 182 in JDK 11: drop javac support for -source/-target/--release 6 In-Reply-To: <921f66be-6071-0c6f-e2cb-2b9d51824620@apache.org> References: <921f66be-6071-0c6f-e2cb-2b9d51824620@apache.org> Message-ID: <52ec8836-cd8f-8096-d23e-5470f4a015f0@oracle.com> On 5/10/2018 3:26 PM, Emmanuel Bourg wrote: > Le 10/05/2018 ? 19:56, joe.darcy at oracle.com (joe darcy) a ?crit?: > >> Given the age of JDK 6, I think it is reasonable in 2018 for JDK 11 to >> drop support for -source/-target/--release 1.6/6, leaving support for 7, >> 8, 9, 10, and 11. This provides support for four rather than three older >> versions in JDK 11, but better matches the time span of releases >> discussed in the JEP. > The short lived releases don't really matter in this context, most > developers just skip them and aim for the LTS releases. I think the JEP > 182 policy should be translated to "one + 3 LTS back", so for Java 11 > that would mean supporting 6, 7, 8, (9, 10), and 11. With this logic the > next Java 17 LTS would support 7, 8, (9, 10), 11, (12, 13, 14, 15, 16), > and 17. I suggest dropping the oldest version in the release immediately > following the newest LTS (so Java 6 support would be removed in JDK 12, > and Java 7 support would go away in JDK 18). Copying a comment I left this January in the bug database view of JEP 182: > Note that with the six month release cadence > (http://mail.openjdk.java.net/pipermail/discuss/2017-September/004281.html) > being used starting with JDK 10, the chronical range covered by "one > plus three back" would be much shortened. In due course, this policy > will be updated accordingly, possibly taking into account LTS (long > term support) releases and possibly offering a sparse set of values. > For example, one possible policy would be to support the last two LTS > releases and each release after the most recent LTS, but not the > releases between those two LTS releases. https://bugs.openjdk.java.net/browse/JDK-8046172?focusedCommentId=14145783&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14145783 In example, the LTS release of JDK 18 would support 18, 17, 16, 15, 14, 13, 12, 11 (LTS), 8 (effectively a LTS) with 9 and 10 *not* being supported. Cheers, -Joe From ebourg at apache.org Fri May 11 22:02:56 2018 From: ebourg at apache.org (Emmanuel Bourg) Date: Sat, 12 May 2018 00:02:56 +0200 Subject: Proposed implementation of JEP 182 in JDK 11: drop javac support for -source/-target/--release 6 In-Reply-To: References: Message-ID: Le 11/05/2018 ? 06:02, Fridrich Strba a ?crit?: > Not like I have anything to add to Stephen's opinion. Just give you a > context about what we do in SUSE. For the while, our SUSE Linux > Enterprise 15 will be released before OpenJDK 11 and we will have to > make the OpenJDK 11 the default Java as a maintenance update. All our > packages that don't use any 7+ features are built using source 6 and > target 6. Changing that at this point of the release cycle would be > quite error prone, not considering that we speak about hundreds of > packages. So, I would be thankful to the Java luminaries not to do this > change in 11. We are facing the same issue in Debian/Ubuntu where we maintain ~1300 Java based packages. We opted to patch Ant [1] and Maven [2] (plexus-compiler actually) to automatically bump the source/target level to the minimum supported by the current JDK. This covers about 80% of the packages maintained. The remaining 20% are fixed manually, one by one. So far the Java 9/10/11 transition has led us to update ~300 packages, and unfortunately we are far from being done yet [3][4]. Emmanuel Bourg [1] https://salsa.debian.org/java-team/ant/blob/master/debian/patches/0013-auto-adjust-target.patch [2] https://salsa.debian.org/java-team/plexus-compiler/blob/master/debian/patches/auto-adjust-language-level.patch [3] https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=default-java9;users=debian-java at lists.debian.org [4] https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=default-java10;users=debian-java at lists.debian.org From ebourg at apache.org Fri May 11 22:43:46 2018 From: ebourg at apache.org (Emmanuel Bourg) Date: Sat, 12 May 2018 00:43:46 +0200 Subject: Proposed implementation of JEP 182 in JDK 11: drop javac support for -source/-target/--release 6 In-Reply-To: <52ec8836-cd8f-8096-d23e-5470f4a015f0@oracle.com> References: <921f66be-6071-0c6f-e2cb-2b9d51824620@apache.org> <52ec8836-cd8f-8096-d23e-5470f4a015f0@oracle.com> Message-ID: <127173df-731b-9abf-f2d4-7b9ff1563ea7@apache.org> Le 11/05/2018 ? 19:19, joe darcy a ?crit?: > In example, the LTS release of JDK 18 would support 18, 17, 16, 15, 14, > 13, 12, 11 (LTS), 8 (effectively a LTS) with 9 and 10 *not* being > supported. Dropping the older non LTS releases is less of an issue. I'd suggest adjusting the source/target/release value automatically with a warning to the next supported version to avoid breaking the old projects targeting them. Supporting only two LTS releases back, spanning 6 years with the new release cadence, feels a bit short compared to the 16 years we enjoyed with Java 8. That was quite a lot, and the level 1.2 and 1.3 were probably not much used at this point, but 1.4 was still commonly found in the wild. Supporting three LTS back would be less radical and more in line with the backward support we experienced since Java 6. Emmanuel Bourg From Alan.Bateman at oracle.com Mon May 14 13:51:16 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 14 May 2018 14:51:16 +0100 Subject: Proposed implementation of JEP 182 in JDK 11: drop javac support for -source/-target/--release 6 In-Reply-To: References: Message-ID: <1cf311f2-f915-f458-3f04-389a892b5977@oracle.com> On 11/05/2018 23:02, Emmanuel Bourg wrote: > : > We are facing the same issue in Debian/Ubuntu where we maintain ~1300 > Java based packages. We opted to patch Ant [1] and Maven [2] > (plexus-compiler actually) to automatically bump the source/target level > to the minimum supported by the current JDK. This covers about 80% of > the packages maintained. The remaining 20% are fixed manually, one by > one. So far the Java 9/10/11 transition has led us to update ~300 > packages, and unfortunately we are far from being done yet [3][4]. > Do the upstream projects have maintainers and are there bugs submitted to the issue trackers of the upstream projects? Just curious as it seems that many of the issues are you wrestling with won't be solved by extending the support for `--release 6` to yet another release. Instead it seems, at least based on a quick browse of the bug report logs, that many of the issues relate to things were deprecated and eventually removed (javah, extensions mechanism, the legacy doclet API, ....) and it makes me wonder if some of these "packages" are actively maintained or not. -Alan From dalibor.topic at oracle.com Mon May 14 14:35:49 2018 From: dalibor.topic at oracle.com (dalibor topic) Date: Mon, 14 May 2018 16:35:49 +0200 Subject: Proposed implementation of JEP 182 in JDK 11: drop javac support for -source/-target/--release 6 In-Reply-To: References: Message-ID: <056958a2-ffa2-604c-9fa1-a9e3af8f803a@oracle.com> On 10.05.2018 19:56, joe darcy wrote: > Given the age of JDK 6, I think it is reasonable in 2018 for JDK 11 to > drop support for -source/-target/--release 1.6/6, leaving support for 7, > 8, 9, 10, and 11. It would be nice to drop support for 9, as well, since it's done, and its users should be moving on to 10. 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 forax at univ-mlv.fr Mon May 14 14:43:05 2018 From: forax at univ-mlv.fr (Remi Forax) Date: Mon, 14 May 2018 16:43:05 +0200 (CEST) Subject: Proposed implementation of JEP 182 in JDK 11: drop javac support for -source/-target/--release 6 In-Reply-To: <056958a2-ffa2-604c-9fa1-a9e3af8f803a@oracle.com> References: <056958a2-ffa2-604c-9fa1-a9e3af8f803a@oracle.com> Message-ID: <2036491285.340682.1526308985185.JavaMail.zimbra@u-pem.fr> Hi Dalibor, ----- Mail original ----- > De: "dalibor topic" > ?: "jdk-dev" > Envoy?: Lundi 14 Mai 2018 16:35:49 > Objet: Re: Proposed implementation of JEP 182 in JDK 11: drop javac support for -source/-target/--release 6 > On 10.05.2018 19:56, joe darcy wrote: >> Given the age of JDK 6, I think it is reasonable in 2018 for JDK 11 to >> drop support for -source/-target/--release 1.6/6, leaving support for 7, >> 8, 9, 10, and 11. > > It would be nice to drop support for 9, as well, since it's done, and > its users should be moving on to 10. Why only 9, if i follow you, we should also drop the support for 10 because when 11 will be out, 10 support will not be supported too. I think it's better to drop the support of 9 and 10 when the support for 8 (the LTS) will be dropped. > > cheers, > dalibor topic R?mi From dalibor.topic at oracle.com Mon May 14 14:51:15 2018 From: dalibor.topic at oracle.com (dalibor topic) Date: Mon, 14 May 2018 16:51:15 +0200 Subject: Proposed implementation of JEP 182 in JDK 11: drop javac support for -source/-target/--release 6 In-Reply-To: <2036491285.340682.1526308985185.JavaMail.zimbra@u-pem.fr> References: <056958a2-ffa2-604c-9fa1-a9e3af8f803a@oracle.com> <2036491285.340682.1526308985185.JavaMail.zimbra@u-pem.fr> Message-ID: On 14.05.2018 16:43, Remi Forax wrote: > Hi Dalibor, > > ----- Mail original ----- >> De: "dalibor topic" >> ?: "jdk-dev" >> Envoy?: Lundi 14 Mai 2018 16:35:49 >> Objet: Re: Proposed implementation of JEP 182 in JDK 11: drop javac support for -source/-target/--release 6 > >> On 10.05.2018 19:56, joe darcy wrote: >>> Given the age of JDK 6, I think it is reasonable in 2018 for JDK 11 to >>> drop support for -source/-target/--release 1.6/6, leaving support for 7, >>> 8, 9, 10, and 11. >> >> It would be nice to drop support for 9, as well, since it's done, and >> its users should be moving on to 10. > > Why only 9, if i follow you, we should also drop the support for 10 because when 11 will be out, 10 support will not be supported too. That depends on whether someone steps up to maintain it, or not. We don't know that yet - it's a question that will only post itself after the second JDK 10 update. We do know that for 9 no one stepped up to maintain it after the second update, though, so it's done. In any case, support for 10 in javac is useful for bootstrapping 11. So keeping it supported in the 11 javac keeps a botstrapping path available from 10 to 11. Since one can't bootstrap 11 with 9, there is no equivalent argument for keeping support for 9 around. ;) cheers, dalibor topic > I think it's better to drop the support of 9 and 10 when the support for 8 (the LTS) will be dropped. > >> >> cheers, >> dalibor topic > > R?mi > -- 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 fridrich.strba at suse.com Mon May 14 15:05:53 2018 From: fridrich.strba at suse.com (Fridrich Strba) Date: Mon, 14 May 2018 17:05:53 +0200 Subject: Proposed implementation of JEP 182 in JDK 11: drop javac support for -source/-target/--release 6 In-Reply-To: <1cf311f2-f915-f458-3f04-389a892b5977@oracle.com> References: <1cf311f2-f915-f458-3f04-389a892b5977@oracle.com> Message-ID: <995e086c-06b2-a96c-424e-1e2b6b464993@suse.com> Alan, On 14/05/18 15:51, Alan Bateman wrote: > Do the upstream projects have maintainers and are there bugs submitted > to the issue trackers of the upstream projects? Just curious as it seems > that many of the issues are you wrestling with won't be solved by > extending the support for `--release 6` to yet another release. Instead > it seems, at least based on a quick browse of the bug report logs, that > many of the issues relate to things were deprecated and eventually > removed (javah, extensions mechanism, the legacy doclet API, ....) and > it makes me wonder if some of these "packages" are actively maintained > or not. This is not an objection in principle to dropping some compatibilities. This is just us begging you for mercy at this moment. If one of the first commits to the jdk tree after jdk10 branch-off was deprecating the --release 6 option, I would have enough time to switch all packages to --release 8 compatibility as to be on the safe side. At this moment, since at the day or SLE release, OpenJDK 10 will be active and OpenJDK 11 not even released, I will have to push OpenJDK 11 to SLE as a maintenance update. If suddenly hundreds of packages stop building because we specify 6 as compatibility, I will be in a deep s**t. So, I am begging you for mercy for this time. That is all I am asking for. Cheers Fridrich From joe.darcy at oracle.com Mon May 14 23:33:18 2018 From: joe.darcy at oracle.com (joe darcy) Date: Mon, 14 May 2018 16:33:18 -0700 Subject: Proposed implementation of JEP 182 in JDK 11: drop javac support for -source/-target/--release 6 In-Reply-To: <995e086c-06b2-a96c-424e-1e2b6b464993@suse.com> References: <1cf311f2-f915-f458-3f04-389a892b5977@oracle.com> <995e086c-06b2-a96c-424e-1e2b6b464993@suse.com> Message-ID: <19ffb1fb-2175-3c9b-1cc3-1061f5481741@oracle.com> On 5/14/2018 8:05 AM, Fridrich Strba wrote: > Alan, > > On 14/05/18 15:51, Alan Bateman wrote: >> Do the upstream projects have maintainers and are there bugs submitted >> to the issue trackers of the upstream projects? Just curious as it seems >> that many of the issues are you wrestling with won't be solved by >> extending the support for `--release 6` to yet another release. Instead >> it seems, at least based on a quick browse of the bug report logs, that >> many of the issues relate to things were deprecated and eventually >> removed (javah, extensions mechanism, the legacy doclet API, ....) and >> it makes me wonder if some of these "packages" are actively maintained >> or not. > This is not an objection in principle to dropping some compatibilities. > This is just us begging you for mercy at this moment. If one of the > first commits to the jdk tree after jdk10 branch-off was deprecating the > --release 6 option, I would have enough time to switch all packages to > --release 8 compatibility as to be on the safe side. At this moment, > since at the day or SLE release, OpenJDK 10 will be active and OpenJDK > 11 not even released, I will have to push OpenJDK 11 to SLE as a > maintenance update. If suddenly hundreds of packages stop building > because we specify 6 as compatibility, I will be in a deep s**t. So, I > am begging you for mercy for this time. That is all I am asking for. > Note that as of JDK 9 javac prints out warnings message like ??? warning: [options] source value 1.6 is obsolete and will be removed in a future release ??? warning: [options] target value 1.6 is obsolete and will be removed in a future release upon use of 6/1.6 as an argument to -source/-target/--release. In other words, the 6/1.6 release value is already "deprecated", but still accepted. After 6/1.6 is removed, 7/1.7 will be deprecated in turn. Cheers, -Joe From harold.seigel at oracle.com Tue May 15 18:07:35 2018 From: harold.seigel at oracle.com (Harold David Seigel) Date: Tue, 15 May 2018 14:07:35 -0400 Subject: =?UTF-8?Q?Re:_CFV:_New_JDK_Reviewer:_Erik_=c3=96sterlund?= In-Reply-To: <0BC4E9D8-6C68-43D2-9006-1A04C341D841@oracle.com> References: <0BC4E9D8-6C68-43D2-9006-1A04C341D841@oracle.com> Message-ID: Vote: yes Harold On 5/1/2018 10:56 PM, Kim Barrett wrote: > I hearby nominate Erik ?sterlund (eosterlund) to JDK Project Reviewer. > > Erik is a JDK Project Committer and has contributed 54 changesets[1] > to the OpenJDK project. This includes substantial revisions to core > components such as Atomic and OrderAccess, and leading the effort to > provide a better interface between the GC and other VM components, > e.g. the Access API and various refactorings around BarrierSet. He has > also contributed to the ZGC project, particularly the SPARC port. > > Votes are due by 12:00 EDT May 16, 2018. > > Only current JDK Reviewers [2] 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 [3]. > > Kim Barrett > > [1] http://hg.openjdk.java.net/jdk/jdk/search/?rev=%28keyword%28%22erik.osterlund%40oracle.com%22%29%20or%20keyword%28%22erik.osterlund%40lnu.se%22%29%20or%20author%28eosterlund%29%29&revcount=100 > [2] http://openjdk.java.net/census > [3] http://openjdk.java.net/projects/#reviewer-vote > From ebourg at apache.org Tue May 15 21:41:27 2018 From: ebourg at apache.org (Emmanuel Bourg) Date: Tue, 15 May 2018 23:41:27 +0200 Subject: Proposed implementation of JEP 182 in JDK 11: drop javac support for -source/-target/--release 6 In-Reply-To: <1cf311f2-f915-f458-3f04-389a892b5977@oracle.com> References: <1cf311f2-f915-f458-3f04-389a892b5977@oracle.com> Message-ID: <2f720322-338c-d9fb-41e5-cf8906dfe158@apache.org> Le 14/05/2018 ? 15:51, Alan Bateman a ?crit?: > Do the upstream projects have maintainers and are there bugs submitted > to the issue trackers of the upstream projects? Yes we do forward the fixes when the upstream projects are still alive, but many are no longer actively maintained unfortunately. And for Linux distributions rebuilding everything from sources, changes like stricter Javadoc rules, javac source/target modifications, tools removal and API deprecations hit us hard. > Just curious as it seems > that many of the issues are you wrestling with won't be solved by > extending the support for `--release 6` to yet another release. Instead > it seems, at least based on a quick browse of the bug report logs, that > many of the issues relate to things were deprecated and eventually > removed (javah, extensions mechanism, the legacy doclet API, ....) and > it makes me wonder if some of these "packages" are actively maintained > or not. Yes they are, but we lack the manpower to actively fix mere build warnings that might break in the future. Packages are usually updated when a new version is available, to address security issues or fix build failures caused by toolchain changes. But we don't update packages just for replacing javah until it actually breaks. Emmanuel Bourg From joe.darcy at oracle.com Tue May 15 23:51:19 2018 From: joe.darcy at oracle.com (Joseph D. Darcy) Date: Tue, 15 May 2018 16:51:19 -0700 Subject: Proposed implementation of JEP 182 in JDK 11: drop javac support for -source/-target/--release 6 In-Reply-To: References: Message-ID: <5AFB7277.2030709@oracle.com> Hello, Based on the feedback on this thread and elsewhere, I've targeted JDK-8028563: Remove javac support for 6/1.6 source and target values JDK-8173606: Deprecate constructors of 7-era visitors to JDK 12. Thanks, -Joe On 5/10/2018 10:56 AM, joe darcy wrote: > Hello, > > As background, JEP 182 "Policy for Retiring javac -source and -target > Options" (http://openjdk.java.net/jeps/182) puts forth a "one plus > three back" policy for the supported range of -source and -target > arguments to javac. (As of JDK 9, a matching range of arguments is > supported for the --release option.) > > This policy was formulated under the old release model before the six > month release cadence. > > Under this policy, support for the 5/1.5 argument was removed in JDK > 9. JDK 10 added support for a 10 argument and retained all the older > values that were supported under JDK 9. > > JDK 6 first shipped at the end of 2006, which will be nearly 12 years > before the planned JDK 11 GA date. JDK 7 first shipped in 2011. > > Given the age of JDK 6, I think it is reasonable in 2018 for JDK 11 to > drop support for -source/-target/--release 1.6/6, leaving support for > 7, 8, 9, 10, and 11. This provides support for four rather than three > older versions in JDK 11, but better matches the time span of releases > discussed in the JEP. > > Future code reviews of the implementation of this removal and related > work > > JDK-8028563: Remove javac support for 6/1.6 source and target values > JDK-8173606: Deprecate constructors of 7-era visitors > > would take place on compiler-dev. > > Comments? > > Cheers, > > -Joe > From forax at univ-mlv.fr Wed May 16 05:28:25 2018 From: forax at univ-mlv.fr (Remi Forax) Date: Wed, 16 May 2018 05:28:25 +0000 Subject: Proposed implementation of JEP 182 in JDK 11: drop javac support for -source/-target/--release 6 In-Reply-To: <5AFB7277.2030709@oracle.com> References: <5AFB7277.2030709@oracle.com> Message-ID: <0DE243E9-2B52-4974-9C0A-359FC84908AD@univ-mlv.fr> Many thanks Joe to have taken our feedback into account. Remi On May 15, 2018 11:51:19 PM UTC, "Joseph D. Darcy" wrote: >Hello, > >Based on the feedback on this thread and elsewhere, I've targeted > > JDK-8028563: Remove javac support for 6/1.6 source and target values > JDK-8173606: Deprecate constructors of 7-era visitors > >to JDK 12. > >Thanks, > >-Joe > >On 5/10/2018 10:56 AM, joe darcy wrote: >> Hello, >> >> As background, JEP 182 "Policy for Retiring javac -source and -target > >> Options" (http://openjdk.java.net/jeps/182) puts forth a "one plus >> three back" policy for the supported range of -source and -target >> arguments to javac. (As of JDK 9, a matching range of arguments is >> supported for the --release option.) >> >> This policy was formulated under the old release model before the six > >> month release cadence. >> >> Under this policy, support for the 5/1.5 argument was removed in JDK >> 9. JDK 10 added support for a 10 argument and retained all the older >> values that were supported under JDK 9. >> >> JDK 6 first shipped at the end of 2006, which will be nearly 12 years > >> before the planned JDK 11 GA date. JDK 7 first shipped in 2011. >> >> Given the age of JDK 6, I think it is reasonable in 2018 for JDK 11 >to >> drop support for -source/-target/--release 1.6/6, leaving support for > >> 7, 8, 9, 10, and 11. This provides support for four rather than three > >> older versions in JDK 11, but better matches the time span of >releases >> discussed in the JEP. >> >> Future code reviews of the implementation of this removal and related > >> work >> >> JDK-8028563: Remove javac support for 6/1.6 source and target >values >> JDK-8173606: Deprecate constructors of 7-era visitors >> >> would take place on compiler-dev. >> >> Comments? >> >> Cheers, >> >> -Joe >> -- Sent from my Android device with K-9 Mail. Please excuse my brevity. From scolebourne at joda.org Wed May 16 07:24:13 2018 From: scolebourne at joda.org (Stephen Colebourne) Date: Wed, 16 May 2018 08:24:13 +0100 Subject: Proposed implementation of JEP 182 in JDK 11: drop javac support for -source/-target/--release 6 In-Reply-To: <5AFB7277.2030709@oracle.com> References: <5AFB7277.2030709@oracle.com> Message-ID: Thanks, it makes a big difference to have an LTS release with modules and JDK 6 support thanks Stephen On 16 May 2018 at 00:51, Joseph D. Darcy wrote: > Hello, > > Based on the feedback on this thread and elsewhere, I've targeted > > JDK-8028563: Remove javac support for 6/1.6 source and target values > JDK-8173606: Deprecate constructors of 7-era visitors > > to JDK 12. > > Thanks, > > -Joe > > > On 5/10/2018 10:56 AM, joe darcy wrote: >> >> Hello, >> >> As background, JEP 182 "Policy for Retiring javac -source and -target >> Options" (http://openjdk.java.net/jeps/182) puts forth a "one plus three >> back" policy for the supported range of -source and -target arguments to >> javac. (As of JDK 9, a matching range of arguments is supported for the >> --release option.) >> >> This policy was formulated under the old release model before the six >> month release cadence. >> >> Under this policy, support for the 5/1.5 argument was removed in JDK 9. >> JDK 10 added support for a 10 argument and retained all the older values >> that were supported under JDK 9. >> >> JDK 6 first shipped at the end of 2006, which will be nearly 12 years >> before the planned JDK 11 GA date. JDK 7 first shipped in 2011. >> >> Given the age of JDK 6, I think it is reasonable in 2018 for JDK 11 to >> drop support for -source/-target/--release 1.6/6, leaving support for 7, 8, >> 9, 10, and 11. This provides support for four rather than three older >> versions in JDK 11, but better matches the time span of releases discussed >> in the JEP. >> >> Future code reviews of the implementation of this removal and related work >> >> JDK-8028563: Remove javac support for 6/1.6 source and target values >> JDK-8173606: Deprecate constructors of 7-era visitors >> >> would take place on compiler-dev. >> >> Comments? >> >> Cheers, >> >> -Joe >> > From nils.eliasson at oracle.com Wed May 16 08:15:10 2018 From: nils.eliasson at oracle.com (Nils Eliasson) Date: Wed, 16 May 2018 10:15:10 +0200 Subject: =?UTF-8?Q?Re:_CFV:_New_JDK_Reviewer:_Erik_=c3=96sterlund?= In-Reply-To: <0BC4E9D8-6C68-43D2-9006-1A04C341D841@oracle.com> References: <0BC4E9D8-6C68-43D2-9006-1A04C341D841@oracle.com> Message-ID: <03b43f98-0f62-b409-e516-cea987c6463f@oracle.com> Vote: yes / Nils On 2018-05-02 04:56, Kim Barrett wrote: > I hearby nominate Erik ?sterlund (eosterlund) to JDK Project Reviewer. > > Erik is a JDK Project Committer and has contributed 54 changesets[1] > to the OpenJDK project. This includes substantial revisions to core > components such as Atomic and OrderAccess, and leading the effort to > provide a better interface between the GC and other VM components, > e.g. the Access API and various refactorings around BarrierSet. He has > also contributed to the ZGC project, particularly the SPARC port. > > Votes are due by 12:00 EDT May 16, 2018. > > Only current JDK Reviewers [2] 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 [3]. > > Kim Barrett > > [1] http://hg.openjdk.java.net/jdk/jdk/search/?rev=%28keyword%28%22erik.osterlund%40oracle.com%22%29%20or%20keyword%28%22erik.osterlund%40lnu.se%22%29%20or%20author%28eosterlund%29%29&revcount=100 > [2] http://openjdk.java.net/census > [3] http://openjdk.java.net/projects/#reviewer-vote > From kim.barrett at oracle.com Wed May 16 20:44:27 2018 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 16 May 2018 16:44:27 -0400 Subject: =?utf-8?Q?Result=3A_New_JDK_Reviewer=3A_Erik_=C3=96sterlund?= Message-ID: <948D04F8-8235-4287-81FF-CA75D83D2160@oracle.com> Voting for Erik ?sterlund [1] is now closed. Yes: 32 Veto: 0 Abstain: 0 According to the Bylaws definition of Three-Vote Consensus, this is sufficient to approve the nomination. Kim Barrett [1] http://mail.openjdk.java.net/pipermail/jdk-dev/2018-May/001119.html From rachmato at redhat.com Wed May 16 21:30:39 2018 From: rachmato at redhat.com (Richard Achmatowicz) Date: Wed, 16 May 2018 17:30:39 -0400 Subject: Enabling use of hugepages with java In-Reply-To: <5b5c7e1d-a6aa-a468-590e-9cbea17314be@oracle.com> References: <9e71448b-2d3d-acb6-79e8-47d1d0987da3@oracle.com> <5b5c7e1d-a6aa-a468-590e-9cbea17314be@oracle.com> Message-ID: <0cd776a9-ff79-4b5e-4e33-5ef30477abf4@redhat.com> Hi Stefan Thanks very much for your reply. I wish I had seen it before wading through the JDK sources (virtualspace.cpp, os_linux.cpp) :-) Through running some tests, I have found that when using the option -XX:+UseSHM, in addition to raising shmmax, the process requesting the large pages also needs to be a member of the group vm.hugetlb_shm_group: // Running as me (who is not in group 0) [nrla at localhost hugepages]$ sysctl -a | grep shm kernel.shm_next_id = -1 kernel.shm_rmid_forced = 0 kernel.shmall = 18446744073692774399 kernel.shmmax = 18446744073692774399 kernel.shmmni = 4096 vm.hugetlb_shm_group = 0 [nrla at localhost hugepages]$ java -Xmx7G -XX:+UseLargePages -XX:+UseSHM HugePagesTest Java HotSpot(TM) 64-Bit Server VM warning: Failed to reserve shared memory. (error = 1) Java HotSpot(TM) 64-Bit Server VM warning: Failed to reserve shared memory. (error = 1) Allocating (int) array of 4294967296 bytes (4.0 Gb). Allocated (int) array successfully. Press "ENTER" to continue... Shutting down. // Running as root (who is in group 0) [root at localhost hugepages]# java -Xmx7G -XX:+UseLargePages -XX:+UseSHM HugePagesTest Allocating (int) array of 4294967296 bytes (4.0 Gb). Allocated (int) array successfully. Press "ENTER" to continue... Shutting down. The large memory usage, after successful allocation and then after termination: [nrla at localhost ~]$ cat /proc/meminfo | grep Huge AnonHugePages:???????? 0 kB ShmemHugePages:??????? 0 kB HugePages_Total:??? 4096 HugePages_Free:???? 2045 HugePages_Rsvd:???? 1645 HugePages_Surp:??????? 0 Hugepagesize:?????? 2048 kB [nrla at localhost ~]$ cat /proc/meminfo | grep Huge AnonHugePages:???????? 0 kB ShmemHugePages:??????? 0 kB HugePages_Total:??? 4096 HugePages_Free:???? 4096 HugePages_Rsvd:??????? 0 HugePages_Surp:??????? 0 Hugepagesize:?????? 2048 kB Richard On 03/06/2018 03:30 AM, Stefan Karlsson wrote: > Hi Richard, > > On 2018-02-28 23:04, David Holmes wrote: >> Hi Richard, >> >> Moving to hotspot-dev as the appropriate list. >> >> David >> >> On 1/03/2018 1:20 AM, Richard Achmatowicz wrote: >>> Hi >>> >>> I hope that I am directing this question to the correct mailing list. >>> >>> I have a question concerning the OS setup on Linux required for >>> correct use of the java option -XX:+UseLargePages in JDK 8. >>> >>> Official Oracle documentation >>> (http://www.oracle.com/technetwork/java/javase/tech/largememory-jsp-137182.html) >>> suggests that in order to make use of large memory pages, in >>> addition to setting the flag -XX:+UseLargePages, an OS option shmmax >>> needs to be tuned to be larger than the java heap size. >>> >>> ?From looking at the java documentation, there are various ways of >>> enabling the use of huge pages: -XX:+UseHugeTLBFS, >>> -XX:+UseTransparentHugePages, -XX:+UseSHM and, if I understand >>> correctly, these correspond in part to making use of different >>> OS-level APIs for accessing huge pages (via shared memory, >>> hugetlbfs, and other means). >>> >>> My question is this: is setting the shmmax OS value only relevant if >>> we are using -XX:+UseSHM? In other words, if we are using >>> -XX:+UseHugeTLBFS to enable use of hugepages by the JVM, is it the >>> case that setting the shmmax OS setting has no effect on the use of >>> hugepages by the JVM? > > Yes, your understanding is correct. > > The document you link to seems to be from a time before > -XX:+UseHugeTLBFS was added. > > This document clarifies this a bit more: > ?https://docs.oracle.com/javase/8/docs/technotes/tools/unix/java.html#large_pages > > > ?"If you are using the option -XX:+UseSHM (instead of > -XX:+UseHugeTLBFS), then increase the SHMMAX value." > > Cheers, > StefanK > >>> >>> Thanks in advance >>> >>> Richard >>> > From sean.coffey at oracle.com Thu May 17 08:02:22 2018 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Thu, 17 May 2018 01:02:22 -0700 (PDT) Subject: Result: New JDK Committer : Bhanu Prakash Gopularam Message-ID: <7260ef73-2eb6-418b-5fea-5724a55acb4b@oracle.com> Voting for Bhanu Prakash Gopularam [1] is now closed. Yes: 19 Veto: 0 Abstain: 0 According to the Bylaws definition of Lazy Consensus, this is sufficient to approve the nomination. regards, Sean. [1] http://mail.openjdk.java.net/pipermail/jdk-dev/2018-May/001127.html From ebourg at apache.org Thu May 17 08:21:31 2018 From: ebourg at apache.org (Emmanuel Bourg) Date: Thu, 17 May 2018 10:21:31 +0200 Subject: Proposed implementation of JEP 182 in JDK 11: drop javac support for -source/-target/--release 6 In-Reply-To: <5AFB7277.2030709@oracle.com> References: <5AFB7277.2030709@oracle.com> Message-ID: <6908abe3-d5a2-9ee4-1be6-e0cbb5dc46da@apache.org> Thank you, this will really smooth the already shaky Java 8->11 transition. Emmanuel Bourg Le 16/05/2018 ? 01:51, Joseph D. Darcy a ?crit?: > Hello, > > Based on the feedback on this thread and elsewhere, I've targeted > > ??? JDK-8028563: Remove javac support for 6/1.6 source and target values > ??? JDK-8173606: Deprecate constructors of 7-era visitors > > to JDK 12. > > Thanks, > > -Joe From fridrich.strba at suse.com Thu May 17 11:57:47 2018 From: fridrich.strba at suse.com (Fridrich Strba) Date: Thu, 17 May 2018 13:57:47 +0200 Subject: Proposed implementation of JEP 182 in JDK 11: drop javac support for -source/-target/--release 6 In-Reply-To: <5AFB7277.2030709@oracle.com> References: <5AFB7277.2030709@oracle.com> Message-ID: <408fae33-5728-3494-bbe1-a342948f2751@suse.com> Thanks a lot. You made my life much easier and I will remember in a due time :) F. On 16/05/18 01:51, Joseph D. Darcy wrote: > Based on the feedback on this thread and elsewhere, I've targeted > > ??? JDK-8028563: Remove javac support for 6/1.6 source and target values > ??? JDK-8173606: Deprecate constructors of 7-era visitors > > to JDK 12. From mark.reinhold at oracle.com Thu May 17 20:12:03 2018 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Thu, 17 May 2018 13:12:03 -0700 (PDT) Subject: JEP proposed to target JDK 11: 329: ChaCha20 and Poly1305 Cryptographic Algorithms Message-ID: <20180517201203.DE4B31BC51B@eggemoggin.niobe.net> The following JEP is proposed to target JDK 11: 329: ChaCha20 and Poly1305 Cryptographic Algorithms http://openjdk.java.net/jeps/329 Feedback on this proposal is more than welcome, as are reasoned objections. If no such objections are raised by 23:00 UTC on Thursday, 24 May, or if they're raised and then satisfactorily answered, then per the JEP 2.0 process proposal [1] I'll target this JEP to JDK 11. - Mark [1] http://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html From mark.reinhold at oracle.com Thu May 17 20:12:04 2018 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Thu, 17 May 2018 13:12:04 -0700 (PDT) Subject: JEP proposed to target JDK 11: 330: Launch Single-File Source-Code Programs Message-ID: <20180517201204.EAA4F1BC51D@eggemoggin.niobe.net> The following JEP is proposed to target JDK 11: 330: Launch Single-File Source-Code Programs http://openjdk.java.net/jeps/330 Feedback on this proposal is more than welcome, as are reasoned objections. If no such objections are raised by 23:00 UTC on Thursday, 24 May, or if they're raised and then satisfactorily answered, then per the JEP 2.0 process proposal [1] I'll target this JEP to JDK 11. - Mark [1] http://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html From roman at kennke.org Thu May 17 20:50:44 2018 From: roman at kennke.org (Roman Kennke) Date: Thu, 17 May 2018 22:50:44 +0200 Subject: JEP proposed to target JDK 11: 330: Launch Single-File Source-Code Programs In-Reply-To: <20180517201204.EAA4F1BC51D@eggemoggin.niobe.net> References: <20180517201204.EAA4F1BC51D@eggemoggin.niobe.net> Message-ID: Am 17.05.2018 um 22:12 schrieb mark.reinhold at oracle.com: > The following JEP is proposed to target JDK 11: > > 330: Launch Single-File Source-Code Programs > http://openjdk.java.net/jeps/330 > > Feedback on this proposal is more than welcome, as are reasoned > objections. If no such objections are raised by 23:00 UTC on Thursday, > 24 May, or if they're raised and then satisfactorily answered, then > per the JEP 2.0 process proposal [1] I'll target this JEP to JDK 11. > > - Mark > > > [1] http://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html > I like this proposal. I have a question about the shebang support though. If I write a sourcefile Test.java like this: #!/usr/bin/java public class Test { public static void main(String[] args) { System.out.println("Hello"); } } ... then it's not a valid Java source file anymore, and (currently) rejected by javac. I see that it is not relevant for the intended use because the java launcher would strip the first line (except for the newline). I still find it odd. In particular, it may end up confusing for the growing experience: - people who start learning Java using this single-source feature will find that shebang 'Java scripts' don't actually compile when passed to the Java compiler - the little Java script turns out to be 'too slow', hey, let's compile it. Oops, doesn't work. - the little Java scipt has grown to complicated and needs additional classes, but doesn't compile. - editors/IDEs might (rightly) flag it as errors etc I wonder if it might be reasonable to extend the JLS to allow for shebang support too? Or maybe even don't extend the JLS but make compilers behave nicely anyway? At the very least, there should be some language in the JEP that mentions this issue. It is a complication that seems more important than the mentioned "HelloWorld"-package with "java" classname. Best regards, Roman From benjamin.john.evans at gmail.com Thu May 17 20:55:45 2018 From: benjamin.john.evans at gmail.com (Ben Evans) Date: Thu, 17 May 2018 21:55:45 +0100 Subject: JEP proposed to target JDK 11: 330: Launch Single-File Source-Code Programs In-Reply-To: References: <20180517201204.EAA4F1BC51D@eggemoggin.niobe.net> Message-ID: What about special-casing javac to interpret #! as a single-line comment marker (synonym for //), for the first line of an input file, and nowhere else? Thanks, Ben On Thu, May 17, 2018 at 9:50 PM, Roman Kennke wrote: > Am 17.05.2018 um 22:12 schrieb mark.reinhold at oracle.com: >> The following JEP is proposed to target JDK 11: >> >> 330: Launch Single-File Source-Code Programs >> http://openjdk.java.net/jeps/330 >> >> Feedback on this proposal is more than welcome, as are reasoned >> objections. If no such objections are raised by 23:00 UTC on Thursday, >> 24 May, or if they're raised and then satisfactorily answered, then >> per the JEP 2.0 process proposal [1] I'll target this JEP to JDK 11. >> >> - Mark >> >> >> [1] http://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html >> > > I like this proposal. > > I have a question about the shebang support though. If I write a > sourcefile Test.java like this: > > #!/usr/bin/java > > public class Test { > public static void main(String[] args) { > System.out.println("Hello"); > } > } > > ... then it's not a valid Java source file anymore, and (currently) > rejected by javac. I see that it is not relevant for the intended use > because the java launcher would strip the first line (except for the > newline). I still find it odd. > > In particular, it may end up confusing for the growing experience: > - people who start learning Java using this single-source feature will > find that shebang 'Java scripts' don't actually compile when passed to > the Java compiler > - the little Java script turns out to be 'too slow', hey, let's compile > it. Oops, doesn't work. > - the little Java scipt has grown to complicated and needs additional > classes, but doesn't compile. > - editors/IDEs might (rightly) flag it as errors > > etc > > I wonder if it might be reasonable to extend the JLS to allow for > shebang support too? Or maybe even don't extend the JLS but make > compilers behave nicely anyway? At the very least, there should be some > language in the JEP that mentions this issue. It is a complication that > seems more important than the mentioned "HelloWorld"-package with "java" > classname. > > Best regards, Roman > From roman at kennke.org Thu May 17 21:19:00 2018 From: roman at kennke.org (Roman Kennke) Date: Thu, 17 May 2018 23:19:00 +0200 Subject: JEP proposed to target JDK 11: 330: Launch Single-File Source-Code Programs In-Reply-To: References: <20180517201204.EAA4F1BC51D@eggemoggin.niobe.net> Message-ID: Yes, something like this. A little bit more broadly speaking, in order to make it consistent, make javac: - accept and ignore #! in the first line - don't enforce source filename convention as usual - expect main method, etc, as outlined in the JEP in other words: don't do the trickery of filtering etc in the launcher, but in the compiler itself. Roman > What about special-casing javac to interpret #! as a single-line > comment marker (synonym for //), for the first line of an input file, > and nowhere else? > > Thanks, > > Ben > > On Thu, May 17, 2018 at 9:50 PM, Roman Kennke wrote: >> Am 17.05.2018 um 22:12 schrieb mark.reinhold at oracle.com: >>> The following JEP is proposed to target JDK 11: >>> >>> 330: Launch Single-File Source-Code Programs >>> http://openjdk.java.net/jeps/330 >>> >>> Feedback on this proposal is more than welcome, as are reasoned >>> objections. If no such objections are raised by 23:00 UTC on Thursday, >>> 24 May, or if they're raised and then satisfactorily answered, then >>> per the JEP 2.0 process proposal [1] I'll target this JEP to JDK 11. >>> >>> - Mark >>> >>> >>> [1] http://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html >>> >> >> I like this proposal. >> >> I have a question about the shebang support though. If I write a >> sourcefile Test.java like this: >> >> #!/usr/bin/java >> >> public class Test { >> public static void main(String[] args) { >> System.out.println("Hello"); >> } >> } >> >> ... then it's not a valid Java source file anymore, and (currently) >> rejected by javac. I see that it is not relevant for the intended use >> because the java launcher would strip the first line (except for the >> newline). I still find it odd. >> >> In particular, it may end up confusing for the growing experience: >> - people who start learning Java using this single-source feature will >> find that shebang 'Java scripts' don't actually compile when passed to >> the Java compiler >> - the little Java script turns out to be 'too slow', hey, let's compile >> it. Oops, doesn't work. >> - the little Java scipt has grown to complicated and needs additional >> classes, but doesn't compile. >> - editors/IDEs might (rightly) flag it as errors >> >> etc >> >> I wonder if it might be reasonable to extend the JLS to allow for >> shebang support too? Or maybe even don't extend the JLS but make >> compilers behave nicely anyway? At the very least, there should be some >> language in the JEP that mentions this issue. It is a complication that >> seems more important than the mentioned "HelloWorld"-package with "java" >> classname. >> >> Best regards, Roman >> > From Peter.B.Kessler at Oracle.COM Thu May 17 22:00:20 2018 From: Peter.B.Kessler at Oracle.COM (Peter B. Kessler) Date: Thu, 17 May 2018 15:00:20 -0700 Subject: JEP proposed to target JDK 11: 330: Launch Single-File Source-Code Programs In-Reply-To: <20180517201204.EAA4F1BC51D@eggemoggin.niobe.net> References: <20180517201204.EAA4F1BC51D@eggemoggin.niobe.net> Message-ID: <03333111-faad-4b77-b18d-e5fc7632bb4c@Oracle.COM> Why are single-file source-code programs limited to being in files? Why not allow them to be in shell "here documents", or be read from pipelines, etc.? E.g., $ java - << '-EOF-' public class HelloWorld { public static void main(String[] arg) { System.out.println("Hello world!"); } } -EOF- or $ myJavaGenerator | java - or even $ java 'public class HelloWorld { public static void main(String[] arg) { System.out.println("Hello world!"); } }' JEP-330 mentions source files "compiled into memory", eliminating the class file. Why not eliminate the source file, too? It might be only a small matter of programming to write a "java-like" wrapper that would read a Java program from a non-file source, put it in a file, compile it, and execute it (except for the awkward correspondence between the class name the and source file name, sigh). But this JEP is all about not having wrappers. ... peter On 05/17/18 01:12 PM, mark.reinhold at oracle.com wrote: > The following JEP is proposed to target JDK 11: > > 330: Launch Single-File Source-Code Programs > http://openjdk.java.net/jeps/330 > > Feedback on this proposal is more than welcome, as are reasoned > objections. If no such objections are raised by 23:00 UTC on Thursday, > 24 May, or if they're raised and then satisfactorily answered, then > per the JEP 2.0 process proposal [1] I'll target this JEP to JDK 11. > > - Mark > > > [1] http://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html From volker.simonis at gmail.com Fri May 18 06:05:01 2018 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 18 May 2018 08:05:01 +0200 Subject: JEP proposed to target JDK 11: 330: Launch Single-File Source-Code Programs In-Reply-To: References: <20180517201204.EAA4F1BC51D@eggemoggin.niobe.net> Message-ID: Hi, I fully assist Roman and his proposal. I actually proposed this myself during the initial proposal of the JEP [1] but my request was rejected by Brian because they don't seem to want to change the JLS for this feature. To cite him: "Its simpler than that. There are NO changes to the JLS, nor even any (IIRC) changes to the compiler. This is all in the command-line launcher. This is not a Java language feature. The scope is JDK, not SE." I'm still unhappy about that decision (because of the obvious arguments mentioned by Roman) but if the community finally decides to implement this feature without changing the JLS the JEP should at least mention that explicitly in a "Non-Goals" section (e.g. something like "It is out of scope of this JEP to maintain compatibility between a Java source file as specified by the JLS and a source files which are intended to be executed by the single file source code launcher"). Also notice that the shebang problem is not the only source of incompatibility, but also the proposal that "the compiler does not enforce the optional restriction defined at the end of JLS ?7.6, that a type in a named package should exist in a file whose name is composed from the type name followed by the .java extension". The restriction is "optional", but to my knowledge still widely adapted (and I'm not sure, but this may still require a change to the current compiler in contrast to what Brian mentioned in the earlier conversation). Thank you and best regards, Volker [1] http://mail.openjdk.java.net/pipermail/jdk-dev/2018-February/thread.html#718 On Thu, May 17, 2018 at 11:19 PM, Roman Kennke wrote: > Yes, something like this. > > A little bit more broadly speaking, in order to make it consistent, make > javac: > - accept and ignore #! in the first line > - don't enforce source filename convention as usual > - expect main method, etc, as outlined in the JEP > > in other words: don't do the trickery of filtering etc in the launcher, > but in the compiler itself. > > Roman > >> What about special-casing javac to interpret #! as a single-line >> comment marker (synonym for //), for the first line of an input file, >> and nowhere else? >> >> Thanks, >> >> Ben >> >> On Thu, May 17, 2018 at 9:50 PM, Roman Kennke wrote: >>> Am 17.05.2018 um 22:12 schrieb mark.reinhold at oracle.com: >>>> The following JEP is proposed to target JDK 11: >>>> >>>> 330: Launch Single-File Source-Code Programs >>>> http://openjdk.java.net/jeps/330 >>>> >>>> Feedback on this proposal is more than welcome, as are reasoned >>>> objections. If no such objections are raised by 23:00 UTC on Thursday, >>>> 24 May, or if they're raised and then satisfactorily answered, then >>>> per the JEP 2.0 process proposal [1] I'll target this JEP to JDK 11. >>>> >>>> - Mark >>>> >>>> >>>> [1] http://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html >>>> >>> >>> I like this proposal. >>> >>> I have a question about the shebang support though. If I write a >>> sourcefile Test.java like this: >>> >>> #!/usr/bin/java >>> >>> public class Test { >>> public static void main(String[] args) { >>> System.out.println("Hello"); >>> } >>> } >>> >>> ... then it's not a valid Java source file anymore, and (currently) >>> rejected by javac. I see that it is not relevant for the intended use >>> because the java launcher would strip the first line (except for the >>> newline). I still find it odd. >>> >>> In particular, it may end up confusing for the growing experience: >>> - people who start learning Java using this single-source feature will >>> find that shebang 'Java scripts' don't actually compile when passed to >>> the Java compiler >>> - the little Java script turns out to be 'too slow', hey, let's compile >>> it. Oops, doesn't work. >>> - the little Java scipt has grown to complicated and needs additional >>> classes, but doesn't compile. >>> - editors/IDEs might (rightly) flag it as errors >>> >>> etc >>> >>> I wonder if it might be reasonable to extend the JLS to allow for >>> shebang support too? Or maybe even don't extend the JLS but make >>> compilers behave nicely anyway? At the very least, there should be some >>> language in the JEP that mentions this issue. It is a complication that >>> seems more important than the mentioned "HelloWorld"-package with "java" >>> classname. >>> >>> Best regards, Roman >>> >> > > From yingqi.lu at intel.com Fri May 18 17:42:45 2018 From: yingqi.lu at intel.com (Lu, Yingqi) Date: Fri, 18 May 2018 17:42:45 +0000 Subject: Draft JEP: Socket API for Remote Direct Memory Access (RDMA) Message-ID: <9ACD5B67AAC5594CB6268234CF29CF9AD1409855@ORSMSX113.amr.corp.intel.com> Hi All, Attached JEP draft is for bug 8195160 https://bugs.openjdk.java.net/browse/JDK-8195160. Please review it and let us know your feedback. This effort is to enhance the Java Socket API to support Remote Direct Memory Access (RDMA) using the rsocket protocol on the Linux-based platforms. Thank you for your help! Lucy From yingqi.lu at intel.com Fri May 18 18:21:54 2018 From: yingqi.lu at intel.com (Lu, Yingqi) Date: Fri, 18 May 2018 18:21:54 +0000 Subject: Draft JEP: Socket API for Remote Direct Memory Access (RDMA) Message-ID: <9ACD5B67AAC5594CB6268234CF29CF9AD1409AF5@ORSMSX113.amr.corp.intel.com> Hi All, We just submitted a JEP draft https://bugs.openjdk.java.net/browse/JDK-8203434. The proposal is to enhance the Java Socket API to support Remote Direct Memory Access (RDMA) using the rsocket protocol on the Linux-based platforms. Please review it and let us know your feedback. Thank you very much for your help! Thanks, Lucy From: Lu, Yingqi Sent: Friday, May 18, 2018 10:43 AM To: 'jdk-dev at openjdk.java.net' Cc: nio-dev at openjdk.java.net; Lu, Yingqi (yingqi.lu at intel.com) ; Kaczmarek, Eric ; Aundhe, Shirish ; Viswanathan, Sandhya ; 'Alan Bateman' ; 'Paul Sandoz' Subject: Draft JEP: Socket API for Remote Direct Memory Access (RDMA) Hi All, Attached JEP draft is for bug 8195160 https://bugs.openjdk.java.net/browse/JDK-8195160. Please review it and let us know your feedback. This effort is to enhance the Java Socket API to support Remote Direct Memory Access (RDMA) using the rsocket protocol on the Linux-based platforms. Thank you for your help! Lucy From vladimir.x.ivanov at oracle.com Fri May 18 18:24:41 2018 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Fri, 18 May 2018 11:24:41 -0700 Subject: Draft JEP: Socket API for Remote Direct Memory Access (RDMA) In-Reply-To: <9ACD5B67AAC5594CB6268234CF29CF9AD1409855@ORSMSX113.amr.corp.intel.com> References: <9ACD5B67AAC5594CB6268234CF29CF9AD1409855@ORSMSX113.amr.corp.intel.com> Message-ID: Unfortunately, the attachment was stripped. I guess you are talking about the following: https://bugs.openjdk.java.net/browse/JDK-8203434 Best regards, Vladimir Ivanov On 5/18/18 10:42, Lu, Yingqi wrote: > Hi All, > > Attached JEP draft is for bug 8195160 https://bugs.openjdk.java.net/browse/JDK-8195160. Please review it and let us know your feedback. This effort is to enhance the Java Socket API to support Remote Direct Memory Access (RDMA) using the rsocket protocol on the Linux-based platforms. > > Thank you for your help! > Lucy > > From yingqi.lu at intel.com Fri May 18 18:28:14 2018 From: yingqi.lu at intel.com (Lu, Yingqi) Date: Fri, 18 May 2018 18:28:14 +0000 Subject: Draft JEP: Socket API for Remote Direct Memory Access (RDMA) In-Reply-To: References: <9ACD5B67AAC5594CB6268234CF29CF9AD1409855@ORSMSX113.amr.corp.intel.com> Message-ID: <9ACD5B67AAC5594CB6268234CF29CF9AD1409BF2@ORSMSX113.amr.corp.intel.com> Yes, you are right. Thank you for pointing it out! I found out the attachment cannot be posted on the mailing list, then I sent a follow-up email with the link just seconds ago. I am new to this list :-) Thanks, Lucy >-----Original Message----- >From: Vladimir Ivanov [mailto:vladimir.x.ivanov at oracle.com] >Sent: Friday, May 18, 2018 11:25 AM >To: Lu, Yingqi ; jdk-dev at openjdk.java.net >Cc: Aundhe, Shirish ; nio-dev at openjdk.java.net; >Kaczmarek, Eric >Subject: Re: Draft JEP: Socket API for Remote Direct Memory Access (RDMA) > >Unfortunately, the attachment was stripped. > >I guess you are talking about the following: > https://bugs.openjdk.java.net/browse/JDK-8203434 > >Best regards, >Vladimir Ivanov > >On 5/18/18 10:42, Lu, Yingqi wrote: >> Hi All, >> >> Attached JEP draft is for bug 8195160 >https://bugs.openjdk.java.net/browse/JDK-8195160. Please review it and let >us know your feedback. This effort is to enhance the Java Socket API to >support Remote Direct Memory Access (RDMA) using the rsocket protocol on >the Linux-based platforms. >> >> Thank you for your help! >> Lucy >> >> From thomas.stuefe at gmail.com Sun May 20 04:49:56 2018 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Sun, 20 May 2018 06:49:56 +0200 Subject: Is jdk-submit down again? Message-ID: Hi all, is jdk-submit down again? I do not get any results since last tuesday. I would have expected results from these changes: changeset: 50389:7f48dcf2e287 branch: JDK-8176808-final tag: tip user: stuefe date: Fri May 11 08:11:54 2018 +0200 summary: metaspace-split changeset: 50357:4021e3e261b3 branch: JDK-8203343-2 parent: 50354:8e4fcfb4cfe4 user: stuefe date: Fri May 11 08:11:54 2018 +0200 summary: 8176808-split-metaspace-cpp + 8203219-VM.metaspace-show-loaded-classes + 8203343-VM.metaspace-show-reflection-invocation-targets changeset: 50356:e9a4f60b73c0 branch: JDK-8203219 parent: 50354:8e4fcfb4cfe4 user: stuefe date: Fri May 11 08:11:54 2018 +0200 summary: 8176808-split-metaspace-cpp + 8203219-VM.metaspace-show-loaded-classes Could someone at Oracle have a look please? Thanks, Thomas From chris.plummer at oracle.com Sun May 20 05:10:28 2018 From: chris.plummer at oracle.com (Chris Plummer) Date: Sat, 19 May 2018 22:10:28 -0700 Subject: Is jdk-submit down again? In-Reply-To: References: Message-ID: Hi Thomas, I see 10 jobs that completed between 3 and 5 days ago. None since then. Just before that you had 3 jobs completed. Did you get results for these? JDK-8203014??? 5 days??? 2018-05-15 06:14 JDK-8203032??? 6 days??? 2018-05-14 08:19 JDK-8176808??? 6 days??? 2018-05-14 06:50 Also the following even longer before that: JDK-8176808??? ?? 10 days??? 2018-05-10 07:39 JDK-8176808?????? 11 days??? 2018-05-09 07:02 JDK-8176808???? ? 11 days??? 2018-05-09 04:26 These seem to predate the 3 jobs you mentioned that you did not get results for. If you got results for all of the above, then I think there was probably just an issue when you submitted the jobs below. I'd suggest just resubmitting them. ...And I'm not an infra person, so if something is broken, I have no idea how to fix it. I'm just pointing out what I see in the jobs history for the submit repo. Ping me when you submit again and I'll see if they are showing up as executing. Chris On 5/19/18 9:49 PM, Thomas St?fe wrote: > Hi all, > > is jdk-submit down again? > > I do not get any results since last tuesday. I would have expected > results from these changes: > > changeset: 50389:7f48dcf2e287 > branch: JDK-8176808-final > tag: tip > user: stuefe > date: Fri May 11 08:11:54 2018 +0200 > summary: metaspace-split > > changeset: 50357:4021e3e261b3 > branch: JDK-8203343-2 > parent: 50354:8e4fcfb4cfe4 > user: stuefe > date: Fri May 11 08:11:54 2018 +0200 > summary: 8176808-split-metaspace-cpp + > 8203219-VM.metaspace-show-loaded-classes + > 8203343-VM.metaspace-show-reflection-invocation-targets > > changeset: 50356:e9a4f60b73c0 > branch: JDK-8203219 > parent: 50354:8e4fcfb4cfe4 > user: stuefe > date: Fri May 11 08:11:54 2018 +0200 > summary: 8176808-split-metaspace-cpp + > 8203219-VM.metaspace-show-loaded-classes > > Could someone at Oracle have a look please? > > Thanks, Thomas From thomas.stuefe at gmail.com Sun May 20 05:28:59 2018 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Sun, 20 May 2018 07:28:59 +0200 Subject: Is jdk-submit down again? In-Reply-To: References: Message-ID: HI Chris, On Sun, May 20, 2018 at 7:10 AM, Chris Plummer wrote: > Hi Thomas, > > I see 10 jobs that completed between 3 and 5 days ago. None since then. Just > before that you had 3 jobs completed. Did you get results for these? > >From the ones you see I miss results for one job: > JDK-8203014 5 days 2018-05-15 06:14 > JDK-8203032 6 days 2018-05-14 08:19 > JDK-8176808 6 days 2018-05-14 06:50 << missing > > Also the following even longer before that: > > JDK-8176808 10 days 2018-05-10 07:39 > JDK-8176808 11 days 2018-05-09 07:02 > JDK-8176808 11 days 2018-05-09 04:26 > > These seem to predate the 3 jobs you mentioned that you did not get results > for. If you got results for all of the above, then I think there was > probably just an issue when you submitted the jobs below. I'd suggest just > resubmitting them. I'll do that, until someone has a better idea. > > ...And I'm not an infra person, so if something is broken, I have no idea > how to fix it. I'm just pointing out what I see in the jobs history for the > submit repo. Ping me when you submit again and I'll see if they are showing > up as executing. Thank you, much appreciated! I resubmitted the most pressing one, JDK-8176808-final, Change id c9f52f88bd7e. Don't spend your weekend on it though, unless you really want to help. I can also wait until next week for the ops people. Thanks, Thomas > > Chris > > > On 5/19/18 9:49 PM, Thomas St?fe wrote: >> >> Hi all, >> >> is jdk-submit down again? >> >> I do not get any results since last tuesday. I would have expected >> results from these changes: >> >> changeset: 50389:7f48dcf2e287 >> branch: JDK-8176808-final >> tag: tip >> user: stuefe >> date: Fri May 11 08:11:54 2018 +0200 >> summary: metaspace-split >> >> changeset: 50357:4021e3e261b3 >> branch: JDK-8203343-2 >> parent: 50354:8e4fcfb4cfe4 >> user: stuefe >> date: Fri May 11 08:11:54 2018 +0200 >> summary: 8176808-split-metaspace-cpp + >> 8203219-VM.metaspace-show-loaded-classes + >> 8203343-VM.metaspace-show-reflection-invocation-targets >> >> changeset: 50356:e9a4f60b73c0 >> branch: JDK-8203219 >> parent: 50354:8e4fcfb4cfe4 >> user: stuefe >> date: Fri May 11 08:11:54 2018 +0200 >> summary: 8176808-split-metaspace-cpp + >> 8203219-VM.metaspace-show-loaded-classes >> >> Could someone at Oracle have a look please? >> >> Thanks, Thomas > > > > From chris.plummer at oracle.com Sun May 20 06:50:24 2018 From: chris.plummer at oracle.com (Chris Plummer) Date: Sat, 19 May 2018 23:50:24 -0700 Subject: Is jdk-submit down again? In-Reply-To: References: Message-ID: <941e696c-e39d-10ba-6ff5-c76ccb64bf62@oracle.com> On 5/19/18 10:28 PM, Thomas St?fe wrote: > HI Chris, > > On Sun, May 20, 2018 at 7:10 AM, Chris Plummer wrote: >> Hi Thomas, >> >> I see 10 jobs that completed between 3 and 5 days ago. None since then. Just >> before that you had 3 jobs completed. Did you get results for these? >> > From the ones you see I miss results for one job: > >> JDK-8203014 5 days 2018-05-15 06:14 >> JDK-8203032 6 days 2018-05-14 08:19 >> JDK-8176808 6 days 2018-05-14 06:50 << missing Actually I made a copy-n-paste mistake in that list. This is the correct one for the most recent 3 jobs JDK-8203043? ? ? 5 days??? 2018-05-15 06:14 JDK-8203014?? ?? 6 days??? 2018-05-14 08:19 JDK-8203032? ??? 6 days??? 2018-05-14 06:50 >> >> Also the following even longer before that: >> >> JDK-8176808 10 days 2018-05-10 07:39 >> JDK-8176808 11 days 2018-05-09 07:02 >> JDK-8176808 11 days 2018-05-09 04:26 >> >> These seem to predate the 3 jobs you mentioned that you did not get results >> for. If you got results for all of the above, then I think there was >> probably just an issue when you submitted the jobs below. I'd suggest just >> resubmitting them. > I'll do that, until someone has a better idea. > >> ...And I'm not an infra person, so if something is broken, I have no idea >> how to fix it. I'm just pointing out what I see in the jobs history for the >> submit repo. Ping me when you submit again and I'll see if they are showing >> up as executing. > Thank you, much appreciated! I resubmitted the most pressing one, > JDK-8176808-final, Change id c9f52f88bd7e. I don't see any indication that a new build-and-test job started, so looks like whatever mechanism starts submit repo jobs is not working. > > Don't spend your weekend on it though, unless you really want to help. > I can also wait until next week for the ops people. No worries. Hopefully it's resolved soon. Chris > > Thanks, Thomas > >> Chris >> >> >> On 5/19/18 9:49 PM, Thomas St?fe wrote: >>> Hi all, >>> >>> is jdk-submit down again? >>> >>> I do not get any results since last tuesday. I would have expected >>> results from these changes: >>> >>> changeset: 50389:7f48dcf2e287 >>> branch: JDK-8176808-final >>> tag: tip >>> user: stuefe >>> date: Fri May 11 08:11:54 2018 +0200 >>> summary: metaspace-split >>> >>> changeset: 50357:4021e3e261b3 >>> branch: JDK-8203343-2 >>> parent: 50354:8e4fcfb4cfe4 >>> user: stuefe >>> date: Fri May 11 08:11:54 2018 +0200 >>> summary: 8176808-split-metaspace-cpp + >>> 8203219-VM.metaspace-show-loaded-classes + >>> 8203343-VM.metaspace-show-reflection-invocation-targets >>> >>> changeset: 50356:e9a4f60b73c0 >>> branch: JDK-8203219 >>> parent: 50354:8e4fcfb4cfe4 >>> user: stuefe >>> date: Fri May 11 08:11:54 2018 +0200 >>> summary: 8176808-split-metaspace-cpp + >>> 8203219-VM.metaspace-show-loaded-classes >>> >>> Could someone at Oracle have a look please? >>> >>> Thanks, Thomas >> >> >> From thomas.stuefe at gmail.com Sun May 20 06:52:08 2018 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Sun, 20 May 2018 08:52:08 +0200 Subject: Is jdk-submit down again? In-Reply-To: <941e696c-e39d-10ba-6ff5-c76ccb64bf62@oracle.com> References: <941e696c-e39d-10ba-6ff5-c76ccb64bf62@oracle.com> Message-ID: Thank you! ..Thomas On Sun, May 20, 2018 at 8:50 AM, Chris Plummer wrote: > On 5/19/18 10:28 PM, Thomas St?fe wrote: >> >> HI Chris, >> >> On Sun, May 20, 2018 at 7:10 AM, Chris Plummer >> wrote: >>> >>> Hi Thomas, >>> >>> I see 10 jobs that completed between 3 and 5 days ago. None since then. >>> Just >>> before that you had 3 jobs completed. Did you get results for these? >>> >> From the ones you see I miss results for one job: >> >>> JDK-8203014 5 days 2018-05-15 06:14 >>> JDK-8203032 6 days 2018-05-14 08:19 >>> JDK-8176808 6 days 2018-05-14 06:50 << missing > > Actually I made a copy-n-paste mistake in that list. This is the correct one > for the most recent 3 jobs > > JDK-8203043 5 days 2018-05-15 06:14 > JDK-8203014 6 days 2018-05-14 08:19 > JDK-8203032 6 days 2018-05-14 06:50 >>> >>> >>> Also the following even longer before that: >>> >>> JDK-8176808 10 days 2018-05-10 07:39 >>> JDK-8176808 11 days 2018-05-09 07:02 >>> JDK-8176808 11 days 2018-05-09 04:26 >>> >>> These seem to predate the 3 jobs you mentioned that you did not get >>> results >>> for. If you got results for all of the above, then I think there was >>> probably just an issue when you submitted the jobs below. I'd suggest >>> just >>> resubmitting them. >> >> I'll do that, until someone has a better idea. >> >>> ...And I'm not an infra person, so if something is broken, I have no idea >>> how to fix it. I'm just pointing out what I see in the jobs history for >>> the >>> submit repo. Ping me when you submit again and I'll see if they are >>> showing >>> up as executing. >> >> Thank you, much appreciated! I resubmitted the most pressing one, >> JDK-8176808-final, Change id c9f52f88bd7e. > > I don't see any indication that a new build-and-test job started, so looks > like whatever mechanism starts submit repo jobs is not working. >> >> >> Don't spend your weekend on it though, unless you really want to help. >> I can also wait until next week for the ops people. > > No worries. Hopefully it's resolved soon. > > Chris > >> >> Thanks, Thomas >> >>> Chris >>> >>> >>> On 5/19/18 9:49 PM, Thomas St?fe wrote: >>>> >>>> Hi all, >>>> >>>> is jdk-submit down again? >>>> >>>> I do not get any results since last tuesday. I would have expected >>>> results from these changes: >>>> >>>> changeset: 50389:7f48dcf2e287 >>>> branch: JDK-8176808-final >>>> tag: tip >>>> user: stuefe >>>> date: Fri May 11 08:11:54 2018 +0200 >>>> summary: metaspace-split >>>> >>>> changeset: 50357:4021e3e261b3 >>>> branch: JDK-8203343-2 >>>> parent: 50354:8e4fcfb4cfe4 >>>> user: stuefe >>>> date: Fri May 11 08:11:54 2018 +0200 >>>> summary: 8176808-split-metaspace-cpp + >>>> 8203219-VM.metaspace-show-loaded-classes + >>>> 8203343-VM.metaspace-show-reflection-invocation-targets >>>> >>>> changeset: 50356:e9a4f60b73c0 >>>> branch: JDK-8203219 >>>> parent: 50354:8e4fcfb4cfe4 >>>> user: stuefe >>>> date: Fri May 11 08:11:54 2018 +0200 >>>> summary: 8176808-split-metaspace-cpp + >>>> 8203219-VM.metaspace-show-loaded-classes >>>> >>>> Could someone at Oracle have a look please? >>>> >>>> Thanks, Thomas >>> >>> >>> >>> > > From stanislav.smirnov at oracle.com Mon May 21 07:42:51 2018 From: stanislav.smirnov at oracle.com (Stanislav Smirnov) Date: Mon, 21 May 2018 13:12:51 +0530 Subject: Is jdk-submit down again? In-Reply-To: References: <941e696c-e39d-10ba-6ff5-c76ccb64bf62@oracle.com> Message-ID: Hello, thanks Thomas for reporting this and thanks Chris for taking a look. I checked our system and I noticed an issue there. It is resolved now and I triggered a build for your JDK-8176808-final branch, it is currently in progress. Thanks again for letting us know and sorry for the inconvenience. Best regards, Stanislav Smirnov > On May 20, 2018, at 12:22 PM, Thomas St?fe wrote: > > Thank you! > > ..Thomas > > On Sun, May 20, 2018 at 8:50 AM, Chris Plummer wrote: >> On 5/19/18 10:28 PM, Thomas St?fe wrote: >>> >>> HI Chris, >>> >>> On Sun, May 20, 2018 at 7:10 AM, Chris Plummer >>> wrote: >>>> >>>> Hi Thomas, >>>> >>>> I see 10 jobs that completed between 3 and 5 days ago. None since then. >>>> Just >>>> before that you had 3 jobs completed. Did you get results for these? >>>> >>> From the ones you see I miss results for one job: >>> >>>> JDK-8203014 5 days 2018-05-15 06:14 >>>> JDK-8203032 6 days 2018-05-14 08:19 >>>> JDK-8176808 6 days 2018-05-14 06:50 << missing >> >> Actually I made a copy-n-paste mistake in that list. This is the correct one >> for the most recent 3 jobs >> >> JDK-8203043 5 days 2018-05-15 06:14 >> JDK-8203014 6 days 2018-05-14 08:19 >> JDK-8203032 6 days 2018-05-14 06:50 >>>> >>>> >>>> Also the following even longer before that: >>>> >>>> JDK-8176808 10 days 2018-05-10 07:39 >>>> JDK-8176808 11 days 2018-05-09 07:02 >>>> JDK-8176808 11 days 2018-05-09 04:26 >>>> >>>> These seem to predate the 3 jobs you mentioned that you did not get >>>> results >>>> for. If you got results for all of the above, then I think there was >>>> probably just an issue when you submitted the jobs below. I'd suggest >>>> just >>>> resubmitting them. >>> >>> I'll do that, until someone has a better idea. >>> >>>> ...And I'm not an infra person, so if something is broken, I have no idea >>>> how to fix it. I'm just pointing out what I see in the jobs history for >>>> the >>>> submit repo. Ping me when you submit again and I'll see if they are >>>> showing >>>> up as executing. >>> >>> Thank you, much appreciated! I resubmitted the most pressing one, >>> JDK-8176808-final, Change id c9f52f88bd7e. >> >> I don't see any indication that a new build-and-test job started, so looks >> like whatever mechanism starts submit repo jobs is not working. >>> >>> >>> Don't spend your weekend on it though, unless you really want to help. >>> I can also wait until next week for the ops people. >> >> No worries. Hopefully it's resolved soon. >> >> Chris >> >>> >>> Thanks, Thomas >>> >>>> Chris >>>> >>>> >>>> On 5/19/18 9:49 PM, Thomas St?fe wrote: >>>>> >>>>> Hi all, >>>>> >>>>> is jdk-submit down again? >>>>> >>>>> I do not get any results since last tuesday. I would have expected >>>>> results from these changes: >>>>> >>>>> changeset: 50389:7f48dcf2e287 >>>>> branch: JDK-8176808-final >>>>> tag: tip >>>>> user: stuefe >>>>> date: Fri May 11 08:11:54 2018 +0200 >>>>> summary: metaspace-split >>>>> >>>>> changeset: 50357:4021e3e261b3 >>>>> branch: JDK-8203343-2 >>>>> parent: 50354:8e4fcfb4cfe4 >>>>> user: stuefe >>>>> date: Fri May 11 08:11:54 2018 +0200 >>>>> summary: 8176808-split-metaspace-cpp + >>>>> 8203219-VM.metaspace-show-loaded-classes + >>>>> 8203343-VM.metaspace-show-reflection-invocation-targets >>>>> >>>>> changeset: 50356:e9a4f60b73c0 >>>>> branch: JDK-8203219 >>>>> parent: 50354:8e4fcfb4cfe4 >>>>> user: stuefe >>>>> date: Fri May 11 08:11:54 2018 +0200 >>>>> summary: 8176808-split-metaspace-cpp + >>>>> 8203219-VM.metaspace-show-loaded-classes >>>>> >>>>> Could someone at Oracle have a look please? >>>>> >>>>> Thanks, Thomas >>>> >>>> >>>> >>>> >> >> From thomas.stuefe at gmail.com Mon May 21 07:45:17 2018 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Mon, 21 May 2018 09:45:17 +0200 Subject: Is jdk-submit down again? In-Reply-To: References: <941e696c-e39d-10ba-6ff5-c76ccb64bf62@oracle.com> Message-ID: Great, thank you! On Mon, May 21, 2018 at 9:42 AM, Stanislav Smirnov wrote: > Hello, > > thanks Thomas for reporting this and thanks Chris for taking a look. > I checked our system and I noticed an issue there. It is resolved now and I > triggered a build for your JDK-8176808-final branch, it is currently in > progress. > Thanks again for letting us know and sorry for the inconvenience. > > Best regards, > Stanislav Smirnov > > On May 20, 2018, at 12:22 PM, Thomas St?fe wrote: > > Thank you! > > ..Thomas > > On Sun, May 20, 2018 at 8:50 AM, Chris Plummer > wrote: > > On 5/19/18 10:28 PM, Thomas St?fe wrote: > > > HI Chris, > > On Sun, May 20, 2018 at 7:10 AM, Chris Plummer > wrote: > > > Hi Thomas, > > I see 10 jobs that completed between 3 and 5 days ago. None since then. > Just > before that you had 3 jobs completed. Did you get results for these? > > From the ones you see I miss results for one job: > > JDK-8203014 5 days 2018-05-15 06:14 > JDK-8203032 6 days 2018-05-14 08:19 > JDK-8176808 6 days 2018-05-14 06:50 << missing > > > Actually I made a copy-n-paste mistake in that list. This is the correct one > for the most recent 3 jobs > > JDK-8203043 5 days 2018-05-15 06:14 > JDK-8203014 6 days 2018-05-14 08:19 > JDK-8203032 6 days 2018-05-14 06:50 > > > > Also the following even longer before that: > > JDK-8176808 10 days 2018-05-10 07:39 > JDK-8176808 11 days 2018-05-09 07:02 > JDK-8176808 11 days 2018-05-09 04:26 > > These seem to predate the 3 jobs you mentioned that you did not get > results > for. If you got results for all of the above, then I think there was > probably just an issue when you submitted the jobs below. I'd suggest > just > resubmitting them. > > > I'll do that, until someone has a better idea. > > ...And I'm not an infra person, so if something is broken, I have no idea > how to fix it. I'm just pointing out what I see in the jobs history for > the > submit repo. Ping me when you submit again and I'll see if they are > showing > up as executing. > > > Thank you, much appreciated! I resubmitted the most pressing one, > JDK-8176808-final, Change id c9f52f88bd7e. > > > I don't see any indication that a new build-and-test job started, so looks > like whatever mechanism starts submit repo jobs is not working. > > > > Don't spend your weekend on it though, unless you really want to help. > I can also wait until next week for the ops people. > > > No worries. Hopefully it's resolved soon. > > Chris > > > Thanks, Thomas > > Chris > > > On 5/19/18 9:49 PM, Thomas St?fe wrote: > > > Hi all, > > is jdk-submit down again? > > I do not get any results since last tuesday. I would have expected > results from these changes: > > changeset: 50389:7f48dcf2e287 > branch: JDK-8176808-final > tag: tip > user: stuefe > date: Fri May 11 08:11:54 2018 +0200 > summary: metaspace-split > > changeset: 50357:4021e3e261b3 > branch: JDK-8203343-2 > parent: 50354:8e4fcfb4cfe4 > user: stuefe > date: Fri May 11 08:11:54 2018 +0200 > summary: 8176808-split-metaspace-cpp + > 8203219-VM.metaspace-show-loaded-classes + > 8203343-VM.metaspace-show-reflection-invocation-targets > > changeset: 50356:e9a4f60b73c0 > branch: JDK-8203219 > parent: 50354:8e4fcfb4cfe4 > user: stuefe > date: Fri May 11 08:11:54 2018 +0200 > summary: 8176808-split-metaspace-cpp + > 8203219-VM.metaspace-show-loaded-classes > > Could someone at Oracle have a look please? > > Thanks, Thomas > > > > > > > > From chris.hegarty at oracle.com Mon May 21 10:41:31 2018 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 21 May 2018 11:41:31 +0100 Subject: Draft JEP: Socket API for Remote Direct Memory Access (RDMA) In-Reply-To: <9ACD5B67AAC5594CB6268234CF29CF9AD1409AF5@ORSMSX113.amr.corp.intel.com> References: <9ACD5B67AAC5594CB6268234CF29CF9AD1409AF5@ORSMSX113.amr.corp.intel.com> Message-ID: Hi Lucy, On 18/05/18 19:21, Lu, Yingqi wrote: > Hi All, > > We just submitted a JEP draft > https://bugs.openjdk.java.net/browse/JDK-8203434. ?The proposal is to > enhance the Java Socket API to support Remote Direct Memory Access > (RDMA) using the rsocket protocol on the Linux-based platforms. This latest version looks very good. Just a few minor minor comments that I did not noticed before. 1) What is the behavior on platforms that do not support RDMA? For example, will jdk.net.Sockets::openRdmaSocketChannel throw UnsupportedOperationException? If so, then maybe make that clear in the API sketch in the description. 2) Links to external references seem to have been inadvertently dropped. Prefer markdown links, e.g. ... form [Wikipedia][wikirdma] ... [wikirdma]: https://en.wikipedia.org/wiki/Remote_direct_memory_access -Chris. From yingqi.lu at intel.com Mon May 21 15:36:40 2018 From: yingqi.lu at intel.com (Lu, Yingqi) Date: Mon, 21 May 2018 15:36:40 +0000 Subject: Draft JEP: Socket API for Remote Direct Memory Access (RDMA) In-Reply-To: References: <9ACD5B67AAC5594CB6268234CF29CF9AD1409AF5@ORSMSX113.amr.corp.intel.com> Message-ID: <9ACD5B67AAC5594CB6268234CF29CF9AD140CE19@ORSMSX113.amr.corp.intel.com> Hi Chris, Thank you for the feedback. Yes, on the platform that does not support rsocket, UOE is thrown. I will make it clear in the document. I will modify the reference links too. Thanks, Lucy >-----Original Message----- >From: Chris Hegarty [mailto:chris.hegarty at oracle.com] >Sent: Monday, May 21, 2018 3:42 AM >To: Lu, Yingqi ; jdk-dev at openjdk.java.net >Cc: Viswanathan, Sandhya ; Aundhe, >Shirish ; nio-dev at openjdk.java.net; Kaczmarek, >Eric >Subject: Re: Draft JEP: Socket API for Remote Direct Memory Access (RDMA) > >Hi Lucy, > >On 18/05/18 19:21, Lu, Yingqi wrote: >> Hi All, >> >> We just submitted a JEP draft >> https://bugs.openjdk.java.net/browse/JDK-8203434. ?The proposal is to >> enhance the Java Socket API to support Remote Direct Memory Access >> (RDMA) using the rsocket protocol on the Linux-based platforms. > >This latest version looks very good. Just a few minor minor comments that I >did not noticed before. > >1) What is the behavior on platforms that do not support RDMA? > For example, will jdk.net.Sockets::openRdmaSocketChannel > throw UnsupportedOperationException? If so, then maybe make > that clear in the API sketch in the description. > >2) Links to external references seem to have been inadvertently > dropped. Prefer markdown links, e.g. > > ... form [Wikipedia][wikirdma] ... > > [wikirdma]: https://en.wikipedia.org/wiki/Remote_direct_memory_access > >-Chris. From brian.goetz at oracle.com Mon May 21 15:39:12 2018 From: brian.goetz at oracle.com (Brian Goetz) Date: Mon, 21 May 2018 11:39:12 -0400 Subject: JEP proposed to target JDK 11: 330: Launch Single-File Source-Code Programs In-Reply-To: References: <20180517201204.EAA4F1BC51D@eggemoggin.niobe.net> Message-ID: <9c4cbfb2-849f-b5e5-1730-b61b243e6f80@oracle.com> Then javac would not be a compiler for the Java Language.? You don't get to sidestep the question by saying "just hack the compiler"; either this is part of the language -- which is defined by the specification -- or it's not. On 5/17/2018 4:55 PM, Ben Evans wrote: > What about special-casing javac to interpret #! as a single-line > comment marker (synonym for //), for the first line of an input file, > and nowhere else? > > Thanks, > > Ben > > On Thu, May 17, 2018 at 9:50 PM, Roman Kennke wrote: >> Am 17.05.2018 um 22:12 schrieb mark.reinhold at oracle.com: >>> The following JEP is proposed to target JDK 11: >>> >>> 330: Launch Single-File Source-Code Programs >>> http://openjdk.java.net/jeps/330 >>> >>> Feedback on this proposal is more than welcome, as are reasoned >>> objections. If no such objections are raised by 23:00 UTC on Thursday, >>> 24 May, or if they're raised and then satisfactorily answered, then >>> per the JEP 2.0 process proposal [1] I'll target this JEP to JDK 11. >>> >>> - Mark >>> >>> >>> [1] http://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html >>> >> I like this proposal. >> >> I have a question about the shebang support though. If I write a >> sourcefile Test.java like this: >> >> #!/usr/bin/java >> >> public class Test { >> public static void main(String[] args) { >> System.out.println("Hello"); >> } >> } >> >> ... then it's not a valid Java source file anymore, and (currently) >> rejected by javac. I see that it is not relevant for the intended use >> because the java launcher would strip the first line (except for the >> newline). I still find it odd. >> >> In particular, it may end up confusing for the growing experience: >> - people who start learning Java using this single-source feature will >> find that shebang 'Java scripts' don't actually compile when passed to >> the Java compiler >> - the little Java script turns out to be 'too slow', hey, let's compile >> it. Oops, doesn't work. >> - the little Java scipt has grown to complicated and needs additional >> classes, but doesn't compile. >> - editors/IDEs might (rightly) flag it as errors >> >> etc >> >> I wonder if it might be reasonable to extend the JLS to allow for >> shebang support too? Or maybe even don't extend the JLS but make >> compilers behave nicely anyway? At the very least, there should be some >> language in the JEP that mentions this issue. It is a complication that >> seems more important than the mentioned "HelloWorld"-package with "java" >> classname. >> >> Best regards, Roman >> From brian.goetz at oracle.com Mon May 21 15:41:33 2018 From: brian.goetz at oracle.com (Brian Goetz) Date: Mon, 21 May 2018 11:41:33 -0400 Subject: JEP proposed to target JDK 11: 330: Launch Single-File Source-Code Programs In-Reply-To: References: <20180517201204.EAA4F1BC51D@eggemoggin.niobe.net> Message-ID: I think this is mostly a "glass 5% empty" argument.? Let's retrace our steps. The primary purpose is providing a reduced-ceremony path for developing and running simple programs.? This streamlines learning (no need to learn about compilers before you can run your first Hello World), prototyping (the edit-run cycle is streamlined), and distribution (simple programs can be distributed and without additional packaging or tooling.)? And all of this is accomplished without shebang support. Shebang support is an additional feature provided for deploying script-like programs -- which is necessarily _at the end of their development phase_.? This allows you to drop a Java source in the file system, as part of the package installation process, as an executable.? That's great, but at this point, the program is now a deployment artifact, not a development artifact.? Adding the shebang line is the "packaging" step.? But shebang is surely secondary to the main goals of this feature. I agree than in an alternate world, we could have made different choices around the goals, but I see no new evidence that we chose the wrong design center.? If pressed, I'd be more inclined towards _dropping shebang completely_ than infecting the language with it, but I think the present position is a more pragmatic compromise. I am happy to take Volker's suggestion and add an explicit non-goal to characterize the intended limits of shebang support. On 5/17/2018 4:50 PM, Roman Kennke wrote: > Am 17.05.2018 um 22:12 schrieb mark.reinhold at oracle.com: >> The following JEP is proposed to target JDK 11: >> >> 330: Launch Single-File Source-Code Programs >> http://openjdk.java.net/jeps/330 >> >> Feedback on this proposal is more than welcome, as are reasoned >> objections. If no such objections are raised by 23:00 UTC on Thursday, >> 24 May, or if they're raised and then satisfactorily answered, then >> per the JEP 2.0 process proposal [1] I'll target this JEP to JDK 11. >> >> - Mark >> >> >> [1] http://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html >> > I like this proposal. > > I have a question about the shebang support though. If I write a > sourcefile Test.java like this: > > #!/usr/bin/java > > public class Test { > public static void main(String[] args) { > System.out.println("Hello"); > } > } > > ... then it's not a valid Java source file anymore, and (currently) > rejected by javac. I see that it is not relevant for the intended use > because the java launcher would strip the first line (except for the > newline). I still find it odd. > > In particular, it may end up confusing for the growing experience: > - people who start learning Java using this single-source feature will > find that shebang 'Java scripts' don't actually compile when passed to > the Java compiler > - the little Java script turns out to be 'too slow', hey, let's compile > it. Oops, doesn't work. > - the little Java scipt has grown to complicated and needs additional > classes, but doesn't compile. > - editors/IDEs might (rightly) flag it as errors > > etc > > I wonder if it might be reasonable to extend the JLS to allow for > shebang support too? Or maybe even don't extend the JLS but make > compilers behave nicely anyway? At the very least, there should be some > language in the JEP that mentions this issue. It is a complication that > seems more important than the mentioned "HelloWorld"-package with "java" > classname. > > Best regards, Roman > From kishor.kharbas at intel.com Mon May 21 22:30:37 2018 From: kishor.kharbas at intel.com (Kharbas, Kishor) Date: Mon, 21 May 2018 22:30:37 +0000 Subject: Draft JEP: Allocation of Old Generation of Java Heap on alternate memory devices Message-ID: Hi! I have proposed a JEP to add an experimental feature to allocate Old generation of Java Heap on alternate memory devices such as NV-DIMM memory. The link to the JEP is: https://bugs.openjdk.java.net/browse/JDK-8202286 Best regards, Kishor From peter.levart at gmail.com Tue May 22 11:44:19 2018 From: peter.levart at gmail.com (Peter Levart) Date: Tue, 22 May 2018 13:44:19 +0200 Subject: JEP proposed to target JDK 11: 330: Launch Single-File Source-Code Programs In-Reply-To: References: <20180517201204.EAA4F1BC51D@eggemoggin.niobe.net> Message-ID: <41f8d4fd-10c3-30d5-c01c-f3df941e6ac1@gmail.com> Perhaps Linux (and other Unixes) could be modified to accept la-la-bang: //! in addition to shebang: #! No, I'm not kidding (mostly). Most "scripting" languages have "#" as comment-introducing character. Supporting la-la-bang could open doors for executable files written in other C++-like languages that choose "//" as comment-introducing characters... Regards, Peter On 05/18/2018 08:05 AM, Volker Simonis wrote: > Hi, > > I fully assist Roman and his proposal. I actually proposed this myself > during the initial proposal of the JEP [1] but my request was rejected > by Brian because they don't seem to want to change the JLS for this > feature. To cite him: > > "Its simpler than that. There are NO changes to the JLS, nor even any > (IIRC) changes to the compiler. This is all in the command-line > launcher. This is not a Java language feature. The scope is JDK, not > SE." > > I'm still unhappy about that decision (because of the obvious > arguments mentioned by Roman) but if the community finally decides to > implement this feature without changing the JLS the JEP should at > least mention that explicitly in a "Non-Goals" section (e.g. something > like "It is out of scope of this JEP to maintain compatibility between > a Java source file as specified by the JLS and a source files which > are intended to be executed by the single file source code launcher"). > > Also notice that the shebang problem is not the only source of > incompatibility, but also the proposal that "the compiler does not > enforce the optional restriction defined at the end of JLS ?7.6, that > a type in a named package should exist in a file whose name is > composed from the type name followed by the .java extension". The > restriction is "optional", but to my knowledge still widely adapted > (and I'm not sure, but this may still require a change to the current > compiler in contrast to what Brian mentioned in the earlier > conversation). > > Thank you and best regards, > Volker > > [1] http://mail.openjdk.java.net/pipermail/jdk-dev/2018-February/thread.html#718 > > On Thu, May 17, 2018 at 11:19 PM, Roman Kennke wrote: >> Yes, something like this. >> >> A little bit more broadly speaking, in order to make it consistent, make >> javac: >> - accept and ignore #! in the first line >> - don't enforce source filename convention as usual >> - expect main method, etc, as outlined in the JEP >> >> in other words: don't do the trickery of filtering etc in the launcher, >> but in the compiler itself. >> >> Roman >> >>> What about special-casing javac to interpret #! as a single-line >>> comment marker (synonym for //), for the first line of an input file, >>> and nowhere else? >>> >>> Thanks, >>> >>> Ben >>> >>> On Thu, May 17, 2018 at 9:50 PM, Roman Kennke wrote: >>>> Am 17.05.2018 um 22:12 schrieb mark.reinhold at oracle.com: >>>>> The following JEP is proposed to target JDK 11: >>>>> >>>>> 330: Launch Single-File Source-Code Programs >>>>> http://openjdk.java.net/jeps/330 >>>>> >>>>> Feedback on this proposal is more than welcome, as are reasoned >>>>> objections. If no such objections are raised by 23:00 UTC on Thursday, >>>>> 24 May, or if they're raised and then satisfactorily answered, then >>>>> per the JEP 2.0 process proposal [1] I'll target this JEP to JDK 11. >>>>> >>>>> - Mark >>>>> >>>>> >>>>> [1] http://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html >>>>> >>>> I like this proposal. >>>> >>>> I have a question about the shebang support though. If I write a >>>> sourcefile Test.java like this: >>>> >>>> #!/usr/bin/java >>>> >>>> public class Test { >>>> public static void main(String[] args) { >>>> System.out.println("Hello"); >>>> } >>>> } >>>> >>>> ... then it's not a valid Java source file anymore, and (currently) >>>> rejected by javac. I see that it is not relevant for the intended use >>>> because the java launcher would strip the first line (except for the >>>> newline). I still find it odd. >>>> >>>> In particular, it may end up confusing for the growing experience: >>>> - people who start learning Java using this single-source feature will >>>> find that shebang 'Java scripts' don't actually compile when passed to >>>> the Java compiler >>>> - the little Java script turns out to be 'too slow', hey, let's compile >>>> it. Oops, doesn't work. >>>> - the little Java scipt has grown to complicated and needs additional >>>> classes, but doesn't compile. >>>> - editors/IDEs might (rightly) flag it as errors >>>> >>>> etc >>>> >>>> I wonder if it might be reasonable to extend the JLS to allow for >>>> shebang support too? Or maybe even don't extend the JLS but make >>>> compilers behave nicely anyway? At the very least, there should be some >>>> language in the JEP that mentions this issue. It is a complication that >>>> seems more important than the mentioned "HelloWorld"-package with "java" >>>> classname. >>>> >>>> Best regards, Roman >>>> >> From neugens at redhat.com Tue May 22 12:11:57 2018 From: neugens at redhat.com (Mario Torre) Date: Tue, 22 May 2018 14:11:57 +0200 Subject: JEP proposed to target JDK 11: 330: Launch Single-File Source-Code Programs In-Reply-To: References: <20180517201204.EAA4F1BC51D@eggemoggin.niobe.net> Message-ID: On Mon, May 21, 2018 at 5:41 PM, Brian Goetz wrote: > Shebang support is an additional feature provided for deploying script-like > programs -- which is necessarily _at the end of their development phase_. I respectfully disagree, Roman's point that beginning a Java file #! makes it not Java is sound. Also, we can't control how people will write their code, so "_at the end of their development phase_" may be a very wild assumption that most people may or may not follow. I suspect in fact that it may be quite the opposite, as it's a much faster way to write python styled tools and applications in Java, people my start using it expensively, especially given the rise of all the current features like var and lambdas etc... It seems rather odd that we are allowing a feature that enables writing invalid Java code that a specific implementation of Java can run but that the JLS specifically forbid. It would be most sensible to amend the specification so that the first two bytes can be 0x23 0x21 to identify a java file that is also a script.. Volker's suggestion may clarify the issues but it won't bypass them, I would rather prefer not to have the confusion in the first place. Cheers, Mario -- Mario Torre Associate Manager, Software Engineering Red Hat GmbH 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From adinn at redhat.com Tue May 22 13:42:24 2018 From: adinn at redhat.com (Andrew Dinn) Date: Tue, 22 May 2018 14:42:24 +0100 Subject: JEP proposed to target JDK 11: 330: Launch Single-File Source-Code Programs In-Reply-To: References: <20180517201204.EAA4F1BC51D@eggemoggin.niobe.net> Message-ID: <59cb2230-333c-0b8e-5915-b0940ce6e076@redhat.com> On 21/05/18 16:41, Brian Goetz wrote: > I think this is mostly a "glass 5% empty" argument.? Let's retrace our > steps. Before we 'retrace' may I ask: was that meant to be 5% or 50%? > The primary purpose is providing a reduced-ceremony path for developing > and running simple programs.? This streamlines learning (no need to > learn about compilers before you can run your first Hello World), > prototyping (the edit-run cycle is streamlined), and distribution > (simple programs can be distributed and without additional packaging or > tooling.)? And all of this is accomplished without shebang support. Is that comment offered as specification by diktat or does it reflect something that was previously discussed and justifiably concluded in the drawing up of this specification? I ask because, unfortunately, it comes across -- to me at least -- as the former. It certainly is not what I was expecting and hoping to hear given your use of the word 'retrace'. Of course, whatever answer you give to that last question I would also suggest that the specification process is not really over until the JEP has been fully discussed by members of the project, that being what is happening in this thread, I believe. > Shebang support is an additional feature provided for deploying > script-like programs -- which is necessarily _at the end of their > development phase_.? This allows you to drop a Java source in the file > system, as part of the package installation process, as an executable.? > That's great, but at this point, the program is now a deployment > artifact, not a development artifact.? Adding the shebang line is the > "packaging" step.? But shebang is surely secondary to the main goals of > this feature. Once again, this comes across more as the necessity of /your/ diktat than one driven by actual logic. Logically, you cannot legitimately dismiss the concerns of those who disagree with you simply by stating that it's a necessity -- or even a well-known fact -- that your perception of things is valid and theirs is invalid. Tautology or contingent truth really need to be backed with reason and/or evidence. Indeed, when it comes to your specific assumption here it seems to me a fairly routine matter to observe that much -- perhaps most -- software does not manifest a clear, one-off lifecycle change from development to deployment. Could you provide a reasoned justification as to why the assumption behind this JEP is that this is how users will actually employ the proposed capability? > I agree than in an alternate world, we could have made different choices > around the goals, but I see no new evidence that we chose the wrong > design center.? If pressed, I'd be more inclined towards _dropping > shebang completely_ than infecting the language with it, but I think the > present position is a more pragmatic compromise. I am afraid that adopting pejorative terms like 'infecting' doesn't really make your case stronger. If anything it looks like rhetoric picked precisely to mask weak or non-existent argument. As, indeed, does emphasising that from this point over here -- where you happen to stand -- the view looks rosy when in fact the issue in question is whether there are grounds for adopting a different perspective. > I am happy to take Volker's suggestion and add an explicit non-goal to > characterize the intended limits of shebang support. Well, yes, clearly you are happy to formalize your own conclusion. However, I recall Volker himself was not actually so, having offered this option as a last resort in face of your unwillingness to consider his preferred alternatives (I don't remember a lot of reasoned justification that time round either, but I acknowledge that may just be my bad recall). Clearly, given this thread, neither are some others happy with this conclusion. Your statement above, magnanimously conceding what amounts to little or nothing, looks yet again more like a rhetorical dodge than a legitimate justification for your position. Could you please retrace your steps as initially promised and refer those reading this thread to whatever prior discussion and/or reasoning justifies your conclusion and invalidates that of those who oppose it? n.b. Just to clarify why I am asking: I'm not particularly committed to having shebang support or otherwise. However, I am very strongly committed to having a clear and fair discussion of why it might or might not be supported. 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 peter.levart at gmail.com Tue May 22 14:43:46 2018 From: peter.levart at gmail.com (Peter Levart) Date: Tue, 22 May 2018 16:43:46 +0200 Subject: JEP proposed to target JDK 11: 330: Launch Single-File Source-Code Programs In-Reply-To: References: <20180517201204.EAA4F1BC51D@eggemoggin.niobe.net> Message-ID: Hi, If this JEP added a feature that specifying source file name as "-" would read STDIN as the Java source file, one could write executable scripts in the following "hybrid" way: #!/bin/bash exec /path/to/java - $* < exec $JAVA_HOME/bin/java $0 $* public class Hello { ??? public static void main(String[] args) { ??????? System.out.println("Hello world"); ??? } } ..but this still needs shebang support and script author is forced to use a special prefix in each line of bash script prefixing the java source: //bin/true; ... //bin/true; .... //bin/true; ... Support for "-" STDIN source in java launcher does have one drawback. Scripts written this way can not process STDIN passed to the script as STDIN of java launcher is redirected to obtain Java source. Regards, Peter From claudiovaliense at gmail.com Wed May 23 04:36:08 2018 From: claudiovaliense at gmail.com (=?UTF-8?Q?Cl=C3=A1udio_Valiense?=) Date: Wed, 23 May 2018 01:36:08 -0300 Subject: Contribute to the community Message-ID: Good evening, How can I contribute to the community? I use java for a long time, I want to contribute. -- *Atenciosamente,* *Cl?udio Mois?s Valiense de Andrade* *Mestrando em Computa??o Aplicada - Universidade Estadual de Feira de Santana* *Bacharel em Ci?ncia da Computa??o - Universidade Estadual de Santa Cruz* www.claudiovaliense.com *A imagina??o ? mais importante que o conhecimento.* *Albert Einsten* From xuelei.fan at oracle.com Wed May 23 04:42:08 2018 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 22 May 2018 21:42:08 -0700 Subject: Contribute to the community In-Reply-To: References: Message-ID: Hi, The "How to contribute" documentation could be the start. http://openjdk.java.net/contribute/ Regards, Xuelei On 5/22/2018 9:36 PM, Cl?udio Valiense wrote: > Good evening, How can I contribute to the community? I use java for a long > time, I want to contribute. > From jonathan.gibbons at oracle.com Wed May 23 21:01:48 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 23 May 2018 14:01:48 -0700 Subject: JEP proposed to target JDK 11: 330: Launch Single-File Source-Code Programs In-Reply-To: <20180517201204.EAA4F1BC51D@eggemoggin.niobe.net> References: <20180517201204.EAA4F1BC51D@eggemoggin.niobe.net> Message-ID: <0a0ea067-d8e8-ce70-9514-4b80c241215d@oracle.com> On 5/17/18 1:12 PM, mark.reinhold at oracle.com wrote: > The following JEP is proposed to target JDK 11: > > 330: Launch Single-File Source-Code Programs > http://openjdk.java.net/jeps/330 > > Feedback on this proposal is more than welcome, as are reasoned > objections. If no such objections are raised by 23:00 UTC on Thursday, > 24 May, or if they're raised and then satisfactorily answered, then > per the JEP 2.0 process proposal [1] I'll target this JEP to JDK 11. > > - Mark > > > [1] http://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html A number of points have been raised, regarding the interaction with javac and shebang scripts. It was never a goal to modify javac to support shebang-java scripts. This can be seen indirectly in the JEP in the description of how the first line may be removed before passing the rest of the file as a normal CompilationUnit to the compiler. With hindsight, this deserves to be stated as an explicit Non-Goal. There are various reasons to not want to change JLS or javac: 1. Changing JLS is a Big Deal, and comes with its own costs and constraints. Further, shebang files are a platform-specific feature, and are not even defined in the POSIX standard. The feature does not warrant changing a JCP-controlled specification. 2. Changing javac to accept shebang-java files is also a Big Deal. Modifying the command-line options to accept files that do not follow the standard naming conventions would introduce complexity and potential ambiguity. 3. There is no compelling need to change JLS or javac.? As demonstrated by the proposed implementation, no change to JLS or javac is actually necessary in order to implement the feature. It is therefore at most a convenience if javac were to be adapted to ignore shebang lines. Shebang scripts are an executable format defined on some, but not all, platforms. Creating a shebang script is typically more than just adding an initial first line to a file; it typically involves a number of steps: a. Add an initial shebang line to the file b. Rename the file to a "command-friendly" name c. Make the file executable d. Install the file in some standard location While renaming the file to a command-friendly name is optional, it is also expected to be common practice. For example, a source file named `HelloWorld.java` might be installed as `helloworld`. And, while the JEP describes use cases for executing a small single-file program with `java HelloWorld.java` or executing it as a platform-specific shebang script with just `helloworld`, it does not seem like there is a common use case to execute `HelloWorld.java`. So, if the shebang script is typically renamed to a command-friendly name, it will not be possible to compile it directly, with "javac helloworld", because that is not a valid command line for javac. This reduces any potential convenience of having javac ignore shebang lines. Since Java source files are different artifacts to platform-specific executable scripts, it makes sense to treat them differently, and since we do not want to change the Java language to support shebang lines, the suggestion is to amend the JEP and implementation so that shebang lines are never stripped from Java source files, i.e. files ending in `.java`. This avoids the problem of having the ecosystem of tools handling Java source files having to deal with arbitrary artifacts like shebang lines.? The change would still permit the direct execution of Java source files, such as `java HelloWorld.java`, and the execution of shebang scripts, such as `helloworld`. ?-- Jon From jonathan.gibbons at oracle.com Wed May 23 21:16:16 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 23 May 2018 14:16:16 -0700 Subject: JEP proposed to target JDK 11: 330: Launch Single-File Source-Code Programs In-Reply-To: References: <20180517201204.EAA4F1BC51D@eggemoggin.niobe.net> Message-ID: On 5/17/18 11:05 PM, Volker Simonis wrote: > ... > > Also notice that the shebang problem is not the only source of > incompatibility, but also the proposal that "the compiler does not > enforce the optional restriction defined at the end of JLS ?7.6, that > a type in a named package should exist in a file whose name is > composed from the type name followed by the .java extension". The > restriction is "optional", but to my knowledge still widely adapted > (and I'm not sure, but this may still require a change to the current > compiler in contrast to what Brian mentioned in the earlier > conversation). > > Thank you and best regards, > Volker > > [1] http://mail.openjdk.java.net/pipermail/jdk-dev/2018-February/thread.html#718 > Volker, With regard to this specific issue, you are correct to say that this convention is widely adopted, and enforced by existing use of javac. The reason for the convention is to help compilers, including javac, locate the definition of classes on the source path should that be necessary. JEP 330 only proposes to relax the constraint for the specific case in question: when compiling a single-file program for invocation by the proposed single-file source-code launcher.? The reason that this is acceptable is that by construction, no other source file will be looking for the file in question on the source path. It may be worth noting that if we had chosen to support reading additional source files from the source path, we would have enforced the standard naming convention for those files: the relaxed rule only applies to the file being executed. Finally, Brian was, and is, correct to say that there has been no change to javac in the implementation of this feature. The change in behavior for the source naming rule was accomplished by suitable configuration of the file objects being passed to the compiler via the Compiler API in the javax.tools package. -- Jon From serguei.spitsyn at oracle.com Thu May 24 00:00:23 2018 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 23 May 2018 17:00:23 -0700 Subject: CFV: New JDK Reviewer: Chris Plummer Message-ID: <4d4a97d1-882c-aa73-fb3d-ac55bf2f1f6c@oracle.com> I hearby nominate Chris Plummer (cjplummer) to JDK Project Reviewer. Chris is a JDK Project Committer has contributed 67 changesets[1]. Chris has contributed significant changes into various areas over the past 4 years: JVM TI, Attach API, DCMD's, NMT, CDS, VM Runtime including footprint reduction, stack sizing, stack walking, etc., and stabilization of serviceability tests (most of which were closed, but are/will be open now). Votes are due by June 6, 2018. Only current JDK Reviewers [2] 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 [3]. Serguei [1] http://hg.openjdk.java.net/jdk/jdk/search/?rev=(!keyword(%22merge%22)%20and%20author(cjplummer))&revcount=100 [2] http://openjdk.java.net/census [3] http://openjdk.java.net/projects/#reviewer-vote From david.holmes at oracle.com Thu May 24 00:13:53 2018 From: david.holmes at oracle.com (David Holmes) Date: Thu, 24 May 2018 10:13:53 +1000 Subject: CFV: New JDK Reviewer: Chris Plummer In-Reply-To: <4d4a97d1-882c-aa73-fb3d-ac55bf2f1f6c@oracle.com> References: <4d4a97d1-882c-aa73-fb3d-ac55bf2f1f6c@oracle.com> Message-ID: <970c952a-6680-188c-7695-33e1ea2b72c1@oracle.com> Vote: yes David On 24/05/2018 10:00 AM, serguei.spitsyn at oracle.com wrote: > I hearby nominate Chris Plummer (cjplummer) to JDK Project Reviewer. > > Chris is a JDK Project Committer has contributed 67 changesets[1]. > > Chris has contributed significant changes into various areas over the > past 4 years: > JVM TI, Attach API, DCMD's, NMT, CDS, VM Runtime including footprint > reduction, > stack sizing, stack walking, etc., and stabilization of serviceability > tests > (most of which were closed, but are/will be open now). > > Votes are due by June 6, 2018. > > Only current JDK Reviewers [2] 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 [3]. > > Serguei > > [1] > http://hg.openjdk.java.net/jdk/jdk/search/?rev=(!keyword(%22merge%22)%20and%20author(cjplummer))&revcount=100 > > > [2] http://openjdk.java.net/census > [3] http://openjdk.java.net/projects/#reviewer-vote > From brian.goetz at oracle.com Thu May 24 00:41:20 2018 From: brian.goetz at oracle.com (Brian Goetz) Date: Wed, 23 May 2018 20:41:20 -0400 Subject: JEP proposed to target JDK 11: 330: Launch Single-File Source-Code Programs In-Reply-To: <59cb2230-333c-0b8e-5915-b0940ce6e076@redhat.com> References: <20180517201204.EAA4F1BC51D@eggemoggin.niobe.net> <59cb2230-333c-0b8e-5915-b0940ce6e076@redhat.com> Message-ID: > On 21/05/18 16:41, Brian Goetz wrote: >> I think this is mostly a "glass 5% empty" argument.? Let's retrace our >> steps. > Before we 'retrace' may I ask: was that meant to be 5% or 50%? I did mean 5%.? The small number was not intended to minimize Roman's concern, but to minimize the place of the shebang feature in this JEP itself.? In setting our goals for the project, shebang support was always a pretty small, and entirely optional, part of the picture (a "stretch goal").? So if a small part of the whole is somewhat smaller than some might prefer, the difference is, necessarily, pretty small.? (If we hadn't found a reasonably stable place to draw the line (I think we were kind of lucky to have done so), we would have been perfectly fine to have no shebang support, but I do think the status quo is much better than that.) > It certainly is not what I > was expecting and hoping to hear given your use of the word 'retrace'. OK, let me explain the sense of "retrace" here.? As one of the instigators for this project, I am in a position to speak authoritatively to motivation, intentions, and goals.? While we of course attempt to lay these out in the JEP and in related communications, the reality is that one will never capture all the possible tradeoffs and interpretations in a short document.? So, when someone comes along with a different idea of what the goals of the project could have been, the sensible first step is to go back to our motivation, and clarify, in the context of the current relevant question.? (This isn't necessarily a failing of the expression of the JEP; no one would be served by a 200 page JEP that tries to anticipate every possible interaction and interpretation, and the cost of producing such a document would be way out of line with its value.)? So by retrace, I mean "let's go back to the inception of the project, which is necessarily uncaptured, and look at the thoughts that were in our heads at that time that might shed light on how we ended up where we did." Since my first attempt seems to have missed the mark, let me retrace in slightly more detail. We have spent countless hours listening to people's concerns about Java; these come from a wide range of sources, including developers, students, teachers, etc.? A general theme that people have expressed concern over is "activation energy"; that doing simple things in Java requires too much fixed work.? Examples include: ?- you have to download/install a JDK and IDE before you can write Hello World ?- "public static void main" ?- You have to compile HelloWorld.java before you run it. ?- Many libraries have a large fixed setup cost before you can do anything. ?- the list goes on Obviously, even a small amount of brainstorming along these lines could generate hundreds of man-years of project work, so we can't do all of them.? So we made subjective choices about which had the best impact, and we consider both the cost (in multiple dimensions) and benefit (or our subjective estimates of the benefits) when making these choices. One example of a project aimed, at least in part, at this problem was JShell.? I think this was very successful (but it was surely expensive.)? JEP 330 has both a smaller cost and a smaller benefit, but the balance seemed in line, and the cost was in budget.? So the goal here was to simplify approachability and streamline simple tasks that are perceived to have a high subjective activation energy.? That's the backdrop behind why we undertook this in the first place -- it provides some relief in the activation energy department, as long as it has a reasonable balance of cost and benefit. Actually, the step-retracing goes much farther back than this.? When we did jshell, we considered whether jshell should also serve as a "batch script runner", and this issue has been brought up plenty of times since.? But from the very beginning of the jshell project, we felt strongly that this would be asking jshell to serve two masters; jshell is intended as an interactive tool, and many decisions were made in favor of a better interactive experience.? If people want to just run a single Java file in source form, a more principled approach would be to teach the launchers about source files -- which was entirely practical, and a much better fit for "I just want to run a 'script' file that is written in Java."? So the seeds of this project were sown several years ago, and over those years, there have been many discussions (in many places) about how to address this particular use case. When we first started discussing this feature, we were thinking mostly in terms of a more streamlined means of execution, but it didn't take long to ask the question about packaging.? If people want to write "scripty" programs in Java, once developed, they're going to want to package and install them, and this is also a high-activation-energy aspect of Java (JARs, build scripts, etc). Shebang is a very low-overhead form of packaging, and -- as long as it didn't perturb the main goal or drive the cost or complexity over budget -- seemed to offer pretty reasonable incremental benefit for a not-terrible incremental cost. But, one can go too far, and turning this into a language feature would have been taking it too far.? The Java Language and VM try very hard to be platform-neutral; shebang is definitively not platform-neutral.? And, anything having to do with the language spec incurs greater costs (I'm not just talking development costs) and complexity.? So, this isn't a language feature, it's a platform integration feature.? Which is why the launcher is the right vehicle here -- this is where the Java platform meets the underlying platform. Volker raised this question early on.? We had already thought about the implications of this (we generally think pretty deeply about the many possible roads one could take before we propose a project), and we didn't like them -- because, as mentioned above, this is a platform integration issue, not a language issue.? I don't deny that it would be nice in certain situations if we made no distinction between "Java source file" and "scripts that happen to contain Java source code" -- and that might be a perfectly reasonable choice for some other languages -- but the goal was never "Java as a scripting language".?? So, while "why not go all the way with shebang" is a reasonable question to ask, it seemed (and still seems) the wrong match for Java.? When the question came up again (as they always do in a large community), no new information had come to light to cause us to come to a different conclusion. Jon's distinction here between "Java source file", and a separate notion of "script that contains Java code" or "platform-specific executable script", is a good one; we'd implicitly been thinking of these as two different things, but its clear that this is confusing to people, and making the distinction explicit should dispel some of that confusion.? Sure, they _could_ be merged, but highlighting this distinction seems much more in keeping with the spirit of the platform than blurring the distinction (though that might be a fine choice for other languages.)? So, +1 to Jon's suggestion. So, what can be done here?? We could: ?- move forward with the feature, as is. ?- clarify the distinction between "Java source file" and "script containing Java", and tweak accordingly, as Jon suggests. ?- drop the JEP entirely. ?- drop the shebang support and keep the rest. What does not seem like a reasonable choice is to turn the Java Language into a platform-dependent thing, for all the reasons Jon mentioned, and more. > I am afraid that adopting pejorative terms like 'infecting' doesn't > really make your case stronger. I'm sorry if you were offended by my use of this term.? I take the Java Language very seriously, and defend its boundaries vigorously! Cheers, -Brian From vladimir.kozlov at oracle.com Thu May 24 01:32:59 2018 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 23 May 2018 18:32:59 -0700 Subject: CFV: New JDK Reviewer: Chris Plummer In-Reply-To: <4d4a97d1-882c-aa73-fb3d-ac55bf2f1f6c@oracle.com> References: <4d4a97d1-882c-aa73-fb3d-ac55bf2f1f6c@oracle.com> Message-ID: <8bb5bce6-4c97-6f84-1c40-5c89521670ae@oracle.com> Vote: yes On 5/23/18 5:00 PM, serguei.spitsyn at oracle.com wrote: > I hearby nominate Chris Plummer (cjplummer) to JDK Project Reviewer. > > Chris is a JDK Project Committer has contributed 67 changesets[1]. > > Chris has contributed significant changes into various areas over the > past 4 years: > JVM TI, Attach API, DCMD's, NMT, CDS, VM Runtime including footprint > reduction, > stack sizing, stack walking, etc., and stabilization of serviceability > tests > (most of which were closed, but are/will be open now). > > Votes are due by June 6, 2018. > > Only current JDK Reviewers [2] 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 [3]. > > Serguei > > [1] > http://hg.openjdk.java.net/jdk/jdk/search/?rev=(!keyword(%22merge%22)%20and%20author(cjplummer))&revcount=100 > > > [2] http://openjdk.java.net/census > [3] http://openjdk.java.net/projects/#reviewer-vote > From jiangli.zhou at oracle.com Thu May 24 01:43:11 2018 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Wed, 23 May 2018 18:43:11 -0700 Subject: CFV: New JDK Reviewer: Chris Plummer In-Reply-To: <4d4a97d1-882c-aa73-fb3d-ac55bf2f1f6c@oracle.com> References: <4d4a97d1-882c-aa73-fb3d-ac55bf2f1f6c@oracle.com> Message-ID: Vote: yes Thanks, Jiangli > On May 23, 2018, at 5:00 PM, "serguei.spitsyn at oracle.com" wrote: > > I hearby nominate Chris Plummer (cjplummer) to JDK Project Reviewer. > > Chris is a JDK Project Committer has contributed 67 changesets[1]. > > Chris has contributed significant changes into various areas over the past 4 years: > JVM TI, Attach API, DCMD's, NMT, CDS, VM Runtime including footprint reduction, > stack sizing, stack walking, etc., and stabilization of serviceability tests > (most of which were closed, but are/will be open now). > > Votes are due by June 6, 2018. > > Only current JDK Reviewers [2] 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 [3]. > > Serguei > > [1] http://hg.openjdk.java.net/jdk/jdk/search/?rev=(!keyword(%22merge%22)%20and%20author(cjplummer))&revcount=100 > > [2] http://openjdk.java.net/census > [3] http://openjdk.java.net/projects/#reviewer-vote > From dean.long at oracle.com Thu May 24 02:47:13 2018 From: dean.long at oracle.com (dean.long at oracle.com) Date: Wed, 23 May 2018 19:47:13 -0700 Subject: CFV: New JDK Reviewer: Chris Plummer In-Reply-To: <4d4a97d1-882c-aa73-fb3d-ac55bf2f1f6c@oracle.com> References: <4d4a97d1-882c-aa73-fb3d-ac55bf2f1f6c@oracle.com> Message-ID: Vote: yes On 5/23/18 5:00 PM, serguei.spitsyn at oracle.com wrote: > I hearby nominate Chris Plummer (cjplummer) to JDK Project Reviewer. > > Chris is a JDK Project Committer has contributed 67 changesets[1]. > > Chris has contributed significant changes into various areas over the > past 4 years: > JVM TI, Attach API, DCMD's, NMT, CDS, VM Runtime including footprint > reduction, > stack sizing, stack walking, etc., and stabilization of serviceability > tests > (most of which were closed, but are/will be open now). > > Votes are due by June 6, 2018. > > Only current JDK Reviewers [2] 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 [3]. > > Serguei > > [1] > http://hg.openjdk.java.net/jdk/jdk/search/?rev=(!keyword(%22merge%22)%20and%20author(cjplummer))&revcount=100 > > [2] http://openjdk.java.net/census > [3] http://openjdk.java.net/projects/#reviewer-vote > From yasuenag at gmail.com Thu May 24 03:00:17 2018 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Thu, 24 May 2018 12:00:17 +0900 Subject: CFV: New JDK Reviewer: Chris Plummer In-Reply-To: <4d4a97d1-882c-aa73-fb3d-ac55bf2f1f6c@oracle.com> References: <4d4a97d1-882c-aa73-fb3d-ac55bf2f1f6c@oracle.com> Message-ID: vote: yes Yasumasa 2018-05-24 9:00 GMT+09:00 serguei.spitsyn at oracle.com : > I hearby nominate Chris Plummer (cjplummer) to JDK Project Reviewer. > > Chris is a JDK Project Committer has contributed 67 changesets[1]. > > Chris has contributed significant changes into various areas over the past 4 > years: > JVM TI, Attach API, DCMD's, NMT, CDS, VM Runtime including footprint > reduction, > stack sizing, stack walking, etc., and stabilization of serviceability tests > (most of which were closed, but are/will be open now). > > Votes are due by June 6, 2018. > > Only current JDK Reviewers [2] 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 [3]. > > Serguei > > [1] > http://hg.openjdk.java.net/jdk/jdk/search/?rev=(!keyword(%22merge%22)%20and%20author(cjplummer))&revcount=100 > > [2] http://openjdk.java.net/census > [3] http://openjdk.java.net/projects/#reviewer-vote > From tim.bell at oracle.com Thu May 24 03:55:15 2018 From: tim.bell at oracle.com (Tim Bell) Date: Wed, 23 May 2018 20:55:15 -0700 Subject: CFV: New JDK Reviewer: Chris Plummer In-Reply-To: <4d4a97d1-882c-aa73-fb3d-ac55bf2f1f6c@oracle.com> References: <4d4a97d1-882c-aa73-fb3d-ac55bf2f1f6c@oracle.com> Message-ID: <5B0637A3.9050008@oracle.com> Vote: yes On 05/23/18 17:00, serguei.spitsyn at oracle.com wrote: > I hearby nominate Chris Plummer (cjplummer) to JDK Project Reviewer. Tim From thomas.stuefe at gmail.com Thu May 24 04:36:57 2018 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 24 May 2018 06:36:57 +0200 Subject: CFV: New JDK Reviewer: Chris Plummer In-Reply-To: <4d4a97d1-882c-aa73-fb3d-ac55bf2f1f6c@oracle.com> References: <4d4a97d1-882c-aa73-fb3d-ac55bf2f1f6c@oracle.com> Message-ID: Vote: yes On Thu, May 24, 2018 at 2:00 AM, serguei.spitsyn at oracle.com wrote: > I hearby nominate Chris Plummer (cjplummer) to JDK Project Reviewer. > > Chris is a JDK Project Committer has contributed 67 changesets[1]. > > Chris has contributed significant changes into various areas over the past 4 > years: > JVM TI, Attach API, DCMD's, NMT, CDS, VM Runtime including footprint > reduction, > stack sizing, stack walking, etc., and stabilization of serviceability tests > (most of which were closed, but are/will be open now). > > Votes are due by June 6, 2018. > > Only current JDK Reviewers [2] 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 [3]. > > Serguei > > [1] > http://hg.openjdk.java.net/jdk/jdk/search/?rev=(!keyword(%22merge%22)%20and%20author(cjplummer))&revcount=100 > > [2] http://openjdk.java.net/census > [3] http://openjdk.java.net/projects/#reviewer-vote > From igor.ignatyev at oracle.com Thu May 24 04:58:01 2018 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Wed, 23 May 2018 21:58:01 -0700 Subject: CFV: New JDK Reviewer: Chris Plummer In-Reply-To: <4d4a97d1-882c-aa73-fb3d-ac55bf2f1f6c@oracle.com> References: <4d4a97d1-882c-aa73-fb3d-ac55bf2f1f6c@oracle.com> Message-ID: Vote: yes -- Igor > On May 23, 2018, at 5:00 PM, serguei.spitsyn at oracle.com wrote: > > I hearby nominate Chris Plummer (cjplummer) to JDK Project Reviewer. From stuart.marks at oracle.com Thu May 24 05:08:03 2018 From: stuart.marks at oracle.com (Stuart Marks) Date: Wed, 23 May 2018 22:08:03 -0700 Subject: JEP proposed to target JDK 11: 330: Launch Single-File Source-Code Programs In-Reply-To: References: <20180517201204.EAA4F1BC51D@eggemoggin.niobe.net> Message-ID: <7504603c-7b55-7b76-1268-9b5975a49022@oracle.com> On 5/22/18 7:43 AM, Peter Levart wrote: > If this JEP added a feature that specifying source file name as "-" would read > STDIN as the Java source file, one could write executable scripts in the > following "hybrid" way: > > #!/bin/bash > exec /path/to/java - $* < public class Hello { > ??? public static void main(String[] args) { > ??? ??? System.out.println("Hello world"); > ??? } > } > EOF > > Notice that this does not need shebang support from java launcher. The benefit > of this approach would also be that /path/to/java could be computed by the bash > script prefixing the Java source. Java typically does not have a standard > installation "place" like bash, so shebang scripts with hard-coded java path > would be less portable as bash scripts. > Support for "-" STDIN source in java launcher does have one drawback. Scripts > written this way can not process STDIN passed to the script as STDIN of java > launcher is redirected to obtain Java source. Hi Peter, This is an excellent point: one can use a shell script "wrapper" to do all kinds of interesting things in addition to computing the path to java, such as supplying additional arguments based on other logic, etc. I'll note that while "-" as a filename is a fairly strong convention, it isn't strictly necessary; /dev/stdin can be used on many systems as a filename that represents stdin. As you note this prevents the script's stdin from being read by the Java program. Instead, one can use a here-document with a file descriptor and then use /dev/fd/n as the "source file" to be compiled and run. This is system-specific, of course, but these facilities should be widely available. I tested this on a Mac using Jon's patch from a couple weeks ago, [1] and it works fine. I'm sure Linux has the /dev/fd stuff as well. Also, the --source option must be used to coax the launcher to compile a file that doesn't end in ".java". This is a little clunky, but it's no worse than the bits of magic you'd have to put at the top of a perl script in order to run it as a shell script. Here's an example: ------- #!/bin/bash exec java --source 11 /dev/fd/3 "$@" 3< References: <4d4a97d1-882c-aa73-fb3d-ac55bf2f1f6c@oracle.com> Message-ID: <5bfb565b-8769-3abf-4620-c0787d7da5b3@oracle.com> Vote: yes StefanK On 2018-05-24 02:00, serguei.spitsyn at oracle.com wrote: > I hearby nominate Chris Plummer (cjplummer) to JDK Project Reviewer. > > Chris is a JDK Project Committer has contributed 67 changesets[1]. > > Chris has contributed significant changes into various areas over the > past 4 years: > JVM TI, Attach API, DCMD's, NMT, CDS, VM Runtime including footprint > reduction, > stack sizing, stack walking, etc., and stabilization of serviceability > tests > (most of which were closed, but are/will be open now). > > Votes are due by June 6, 2018. > > Only current JDK Reviewers [2] 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 [3]. > > Serguei > > [1] > http://hg.openjdk.java.net/jdk/jdk/search/?rev=(!keyword(%22merge%22)%20and%20author(cjplummer))&revcount=100 > > > [2] http://openjdk.java.net/census > [3] http://openjdk.java.net/projects/#reviewer-vote > From robert.zenz at sibvisions.com Thu May 24 07:23:23 2018 From: robert.zenz at sibvisions.com (Robert Zenz) Date: Thu, 24 May 2018 07:23:23 +0000 Subject: JEP proposed to target JDK 11: 330: Launch Single-File Source-Code Programs In-Reply-To: <0a0ea067-d8e8-ce70-9514-4b80c241215d@oracle.com> References: <20180517201204.EAA4F1BC51D@eggemoggin.niobe.net> <0a0ea067-d8e8-ce70-9514-4b80c241215d@oracle.com> Message-ID: <5B06686A.6050302@sibvisions.com> I'm sorry, I still don't get why the shebang line is required at all for this proposal. I might argue that shebang lines are system dependent features and are typically only used with languages which treat `#` as a comment which is not the case in Java. Additionally, we can already "emulate" shebangs in Java (or any C like language) source files using a polyglot. Which is fore sure not that easy to understand, but it still gets the job done. I know what you're trying to do, but I fail to see how the achieved goal (of easily executing a Java source file by doing `./HelloWorld.java` versus `java HelloWorld.java`) validates the added special case just to support the shebang line (including possible confusion of newcomers why the first line is allowed to start with `#` but everywhere else is a syntax error). On 23.05.2018 23:01, Jonathan Gibbons wrote: > On 5/17/18 1:12 PM, mark.reinhold at oracle.com wrote: > >> The following JEP is proposed to target JDK 11: >> >> 330: Launch Single-File Source-Code Programs >> http://openjdk.java.net/jeps/330 >> >> Feedback on this proposal is more than welcome, as are reasoned >> objections. If no such objections are raised by 23:00 UTC on Thursday, >> 24 May, or if they're raised and then satisfactorily answered, then >> per the JEP 2.0 process proposal [1] I'll target this JEP to JDK 11. >> >> - Mark >> >> >> [1] http://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html > A number of points have been raised, regarding the interaction with javac and > shebang scripts. > > It was never a goal to modify javac to support shebang-java scripts. This can be > seen indirectly in the JEP in the description of how the first line may be > removed before passing the rest of the file as a normal CompilationUnit to the > compiler. With hindsight, this deserves to be stated as an explicit Non-Goal. > > There are various reasons to not want to change JLS or javac: > > 1. Changing JLS is a Big Deal, and comes with its own costs and constraints. > Further, shebang files are a platform-specific feature, and are not even defined > in the POSIX standard. The feature does not warrant changing a JCP-controlled > specification. > > 2. Changing javac to accept shebang-java files is also a Big Deal. Modifying the > command-line options to accept files that do not follow the standard naming > conventions would introduce complexity and potential ambiguity. > > 3. There is no compelling need to change JLS or javac. As demonstrated by the > proposed implementation, no change to JLS or javac is actually necessary in > order to implement the feature. It is therefore at most a convenience if javac > were to be adapted to ignore shebang lines. > > Shebang scripts are an executable format defined on some, but not all, > platforms. Creating a shebang script is typically more than just adding an > initial first line to a file; it typically involves a number of steps: > > a. Add an initial shebang line to the file > b. Rename the file to a "command-friendly" name > c. Make the file executable > d. Install the file in some standard location > > While renaming the file to a command-friendly name is optional, it is also > expected to be common practice. For example, a source file named > `HelloWorld.java` might be installed as `helloworld`. And, while the JEP > describes use cases for executing a small single-file program with `java > HelloWorld.java` or executing it as a platform-specific shebang script with just > `helloworld`, it does not seem like there is a common use case to execute > `HelloWorld.java`. So, if the shebang script is typically renamed to a > command-friendly name, it will not be possible to compile it directly, with > "javac helloworld", because that is not a valid command line for javac. This > reduces any potential convenience of having javac ignore shebang lines. > > Since Java source files are different artifacts to platform-specific executable > scripts, it makes sense to treat them differently, and since we do not want to > change the Java language to support shebang lines, the suggestion is to amend > the JEP and implementation so that shebang lines are never stripped from Java > source files, i.e. files ending in `.java`. This avoids the problem of having > the ecosystem of tools handling Java source files having to deal with arbitrary > artifacts like shebang lines. The change would still permit the direct > execution of Java source files, such as `java HelloWorld.java`, and the > execution of shebang scripts, such as `helloworld`. > > -- Jon From adinn at redhat.com Thu May 24 07:24:19 2018 From: adinn at redhat.com (Andrew Dinn) Date: Thu, 24 May 2018 08:24:19 +0100 Subject: JEP proposed to target JDK 11: 330: Launch Single-File Source-Code Programs In-Reply-To: References: <20180517201204.EAA4F1BC51D@eggemoggin.niobe.net> <59cb2230-333c-0b8e-5915-b0940ce6e076@redhat.com> Message-ID: On 24/05/18 01:41, Brian Goetz wrote: >> Before we 'retrace' may I ask: was that meant to be 5% or 50%? > > I did mean 5%.? The small number was not intended to minimize Roman's > concern, but to minimize the place of the shebang feature in this JEP > itself. Ah, ok, got it now. I agree this issue is small beer (not to say I would be happy if 5% was omitted from my pint :-). > OK, let me explain the sense of "retrace" here. > . . . Thank you for a clear and full exposition. Also thanks to Jon for his input. > So, what can be done here?? We could: > ?- move forward with the feature, as is. > ?- clarify the distinction between "Java source file" and "script > containing Java", and tweak accordingly, as Jon suggests. > ?- drop the JEP entirely. > ?- drop the shebang support and keep the rest. I like Jon's suggestion but I am happy to leave others to make a more informed decision than I believe I can offer. > What does not seem like a reasonable choice is to turn the Java Language > into a platform-dependent thing, for all the reasons Jon mentioned, and > more. I'm absolutely in agreement with that sentiment. >> I am afraid that adopting pejorative terms like 'infecting' doesn't >> really make your case stronger. > > I'm sorry if you were offended by my use of this term.? I take the Java > Language very seriously, and defend its boundaries vigorously! No offence was taken. I was merely concerned that this choice of words was reducing rather than increasing the impact of your case. Your reply has resolved that concern. 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 Alan.Bateman at oracle.com Thu May 24 07:49:59 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 24 May 2018 08:49:59 +0100 Subject: CFV: New JDK Reviewer: Chris Plummer In-Reply-To: <4d4a97d1-882c-aa73-fb3d-ac55bf2f1f6c@oracle.com> References: <4d4a97d1-882c-aa73-fb3d-ac55bf2f1f6c@oracle.com> Message-ID: Vote: yes From volker.simonis at gmail.com Thu May 24 08:23:18 2018 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 24 May 2018 10:23:18 +0200 Subject: CFV: New JDK Reviewer: Chris Plummer In-Reply-To: <4d4a97d1-882c-aa73-fb3d-ac55bf2f1f6c@oracle.com> References: <4d4a97d1-882c-aa73-fb3d-ac55bf2f1f6c@oracle.com> Message-ID: Vote: yes On Thu, May 24, 2018 at 2:00 AM, serguei.spitsyn at oracle.com wrote: > I hearby nominate Chris Plummer (cjplummer) to JDK Project Reviewer. > > Chris is a JDK Project Committer has contributed 67 changesets[1]. > > Chris has contributed significant changes into various areas over the past 4 > years: > JVM TI, Attach API, DCMD's, NMT, CDS, VM Runtime including footprint > reduction, > stack sizing, stack walking, etc., and stabilization of serviceability tests > (most of which were closed, but are/will be open now). > > Votes are due by June 6, 2018. > > Only current JDK Reviewers [2] 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 [3]. > > Serguei > > [1] > http://hg.openjdk.java.net/jdk/jdk/search/?rev=(!keyword(%22merge%22)%20and%20author(cjplummer))&revcount=100 > > [2] http://openjdk.java.net/census > [3] http://openjdk.java.net/projects/#reviewer-vote > From neugens at redhat.com Thu May 24 09:02:29 2018 From: neugens at redhat.com (Mario Torre) Date: Thu, 24 May 2018 11:02:29 +0200 Subject: JEP proposed to target JDK 11: 330: Launch Single-File Source-Code Programs In-Reply-To: <0a0ea067-d8e8-ce70-9514-4b80c241215d@oracle.com> References: <20180517201204.EAA4F1BC51D@eggemoggin.niobe.net> <0a0ea067-d8e8-ce70-9514-4b80c241215d@oracle.com> Message-ID: I hear those concern, and I agree with you, but this shows why this is an unwanted feature if any. I find this JEP dangerous to some extent (ok, that may be perhaps a strong wording) because it turns Java into a scripting language without full support from the JLS. Now, the controversial point is clearly the shebang support, the rest seems fine and reasonable, and like others have said if we allow to read files from stdin we should have full equivalence of shell scripting without all the unwanted side effects: #!/bin/bash exec java --source 11 /dev/fd/3 "$@" 3< wrote: > On 5/17/18 1:12 PM, mark.reinhold at oracle.com wrote: > >> The following JEP is proposed to target JDK 11: >> >> 330: Launch Single-File Source-Code Programs >> http://openjdk.java.net/jeps/330 >> >> Feedback on this proposal is more than welcome, as are reasoned >> objections. If no such objections are raised by 23:00 UTC on Thursday, >> 24 May, or if they're raised and then satisfactorily answered, then >> per the JEP 2.0 process proposal [1] I'll target this JEP to JDK 11. >> >> - Mark >> >> >> [1] http://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html > > A number of points have been raised, regarding the interaction with javac > and shebang scripts. > > It was never a goal to modify javac to support shebang-java scripts. This > can be seen indirectly in the JEP in the description of how the first line > may be removed before passing the rest of the file as a normal > CompilationUnit to the compiler. With hindsight, this deserves to be stated > as an explicit Non-Goal. > > There are various reasons to not want to change JLS or javac: > > 1. Changing JLS is a Big Deal, and comes with its own costs and constraints. > Further, shebang files are a platform-specific feature, and are not even > defined in the POSIX standard. The feature does not warrant changing a > JCP-controlled specification. > > 2. Changing javac to accept shebang-java files is also a Big Deal. Modifying > the command-line options to accept files that do not follow the standard > naming conventions would introduce complexity and potential ambiguity. > > 3. There is no compelling need to change JLS or javac. As demonstrated by > the proposed implementation, no change to JLS or javac is actually necessary > in order to implement the feature. It is therefore at most a convenience if > javac were to be adapted to ignore shebang lines. > > Shebang scripts are an executable format defined on some, but not all, > platforms. Creating a shebang script is typically more than just adding an > initial first line to a file; it typically involves a number of steps: > > a. Add an initial shebang line to the file > b. Rename the file to a "command-friendly" name > c. Make the file executable > d. Install the file in some standard location > > While renaming the file to a command-friendly name is optional, it is also > expected to be common practice. For example, a source file named > `HelloWorld.java` might be installed as `helloworld`. And, while the JEP > describes use cases for executing a small single-file program with `java > HelloWorld.java` or executing it as a platform-specific shebang script with > just `helloworld`, it does not seem like there is a common use case to > execute `HelloWorld.java`. So, if the shebang script is typically renamed to > a command-friendly name, it will not be possible to compile it directly, > with "javac helloworld", because that is not a valid command line for javac. > This reduces any potential convenience of having javac ignore shebang lines. > > Since Java source files are different artifacts to platform-specific > executable scripts, it makes sense to treat them differently, and since we > do not want to change the Java language to support shebang lines, the > suggestion is to amend the JEP and implementation so that shebang lines are > never stripped from Java source files, i.e. files ending in `.java`. This > avoids the problem of having the ecosystem of tools handling Java source > files having to deal with arbitrary artifacts like shebang lines. The > change would still permit the direct execution of Java source files, such as > `java HelloWorld.java`, and the execution of shebang scripts, such as > `helloworld`. > > -- Jon -- Mario Torre Associate Manager, Software Engineering Red Hat GmbH 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From jesper.wilhelmsson at oracle.com Thu May 24 09:40:27 2018 From: jesper.wilhelmsson at oracle.com (jesper.wilhelmsson at oracle.com) Date: Thu, 24 May 2018 11:40:27 +0200 Subject: CFV: New JDK Reviewer: Chris Plummer In-Reply-To: <4d4a97d1-882c-aa73-fb3d-ac55bf2f1f6c@oracle.com> References: <4d4a97d1-882c-aa73-fb3d-ac55bf2f1f6c@oracle.com> Message-ID: <5F751618-31F7-4423-8842-37FE410DCE56@oracle.com> Vote: Yes /Jesper > On 24 May 2018, at 02:00, serguei.spitsyn at oracle.com wrote: > > I hearby nominate Chris Plummer (cjplummer) to JDK Project Reviewer. > > Chris is a JDK Project Committer has contributed 67 changesets[1]. > > Chris has contributed significant changes into various areas over the past 4 years: > JVM TI, Attach API, DCMD's, NMT, CDS, VM Runtime including footprint reduction, > stack sizing, stack walking, etc., and stabilization of serviceability tests > (most of which were closed, but are/will be open now). > > Votes are due by June 6, 2018. > > Only current JDK Reviewers [2] 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 [3]. > > Serguei > > [1] http://hg.openjdk.java.net/jdk/jdk/search/?rev=(!keyword(%22merge%22)%20and%20author(cjplummer))&revcount=100 > > [2] http://openjdk.java.net/census > [3] http://openjdk.java.net/projects/#reviewer-vote > From roman at kennke.org Thu May 24 09:45:41 2018 From: roman at kennke.org (Roman Kennke) Date: Thu, 24 May 2018 11:45:41 +0200 Subject: JEP proposed to target JDK 11: 330: Launch Single-File Source-Code Programs In-Reply-To: References: <20180517201204.EAA4F1BC51D@eggemoggin.niobe.net> <59cb2230-333c-0b8e-5915-b0940ce6e076@redhat.com> Message-ID: <193C4CD5-86DD-4D3E-830E-8945451B68E7@kennke.org> Thanks Brian and Jon for clarification. I'd be happy with a short version of this in the non-goals section of the JEP. Also, //! sounds like a cool idea. Indeed I seem to remember that some version of Unix already does this (was it some BSD variant to support csh scripts? don't remember...) Cheers, Roman (/me goes back to the beach...) Am 24. Mai 2018 02:41:20 MESZ schrieb Brian Goetz : > > >> On 21/05/18 16:41, Brian Goetz wrote: >>> I think this is mostly a "glass 5% empty" argument.? Let's retrace >our >>> steps. >> Before we 'retrace' may I ask: was that meant to be 5% or 50%? > >I did mean 5%.? The small number was not intended to minimize Roman's >concern, but to minimize the place of the shebang feature in this JEP >itself.? In setting our goals for the project, shebang support was >always a pretty small, and entirely optional, part of the picture (a >"stretch goal").? So if a small part of the whole is somewhat smaller >than some might prefer, the difference is, necessarily, pretty small.? >(If we hadn't found a reasonably stable place to draw the line (I think > >we were kind of lucky to have done so), we would have been perfectly >fine to have no shebang support, but I do think the status quo is much >better than that.) > >> It certainly is not what I >> was expecting and hoping to hear given your use of the word >'retrace'. > >OK, let me explain the sense of "retrace" here.? As one of the >instigators for this project, I am in a position to speak >authoritatively to motivation, intentions, and goals.? While we of >course attempt to lay these out in the JEP and in related >communications, the reality is that one will never capture all the >possible tradeoffs and interpretations in a short document.? So, when >someone comes along with a different idea of what the goals of the >project could have been, the sensible first step is to go back to our >motivation, and clarify, in the context of the current relevant >question.? (This isn't necessarily a failing of the expression of the >JEP; no one would be served by a 200 page JEP that tries to anticipate >every possible interaction and interpretation, and the cost of >producing >such a document would be way out of line with its value.)? So by >retrace, I mean "let's go back to the inception of the project, which >is >necessarily uncaptured, and look at the thoughts that were in our heads > >at that time that might shed light on how we ended up where we did." > >Since my first attempt seems to have missed the mark, let me retrace in > >slightly more detail. > >We have spent countless hours listening to people's concerns about >Java; >these come from a wide range of sources, including developers, >students, >teachers, etc.? A general theme that people have expressed concern over > >is "activation energy"; that doing simple things in Java requires too >much fixed work.? Examples include: > ?- you have to download/install a JDK and IDE before you can write >Hello World > ?- "public static void main" > ?- You have to compile HelloWorld.java before you run it. >?- Many libraries have a large fixed setup cost before you can do >anything. > ?- the list goes on > >Obviously, even a small amount of brainstorming along these lines could > >generate hundreds of man-years of project work, so we can't do all of >them.? So we made subjective choices about which had the best impact, >and we consider both the cost (in multiple dimensions) and benefit (or >our subjective estimates of the benefits) when making these choices. > >One example of a project aimed, at least in part, at this problem was >JShell.? I think this was very successful (but it was surely >expensive.)? JEP 330 has both a smaller cost and a smaller benefit, but > >the balance seemed in line, and the cost was in budget.? So the goal >here was to simplify approachability and streamline simple tasks that >are perceived to have a high subjective activation energy.? That's the >backdrop behind why we undertook this in the first place -- it provides > >some relief in the activation energy department, as long as it has a >reasonable balance of cost and benefit. > >Actually, the step-retracing goes much farther back than this.? When we > >did jshell, we considered whether jshell should also serve as a "batch >script runner", and this issue has been brought up plenty of times >since.? But from the very beginning of the jshell project, we felt >strongly that this would be asking jshell to serve two masters; jshell >is intended as an interactive tool, and many decisions were made in >favor of a better interactive experience.? If people want to just run a > >single Java file in source form, a more principled approach would be to > >teach the launchers about source files -- which was entirely practical, > >and a much better fit for "I just want to run a 'script' file that is >written in Java."? So the seeds of this project were sown several years > >ago, and over those years, there have been many discussions (in many >places) about how to address this particular use case. > >When we first started discussing this feature, we were thinking mostly >in terms of a more streamlined means of execution, but it didn't take >long to ask the question about packaging.? If people want to write >"scripty" programs in Java, once developed, they're going to want to >package and install them, and this is also a high-activation-energy >aspect of Java (JARs, build scripts, etc). Shebang is a very >low-overhead form of packaging, and -- as long as it didn't perturb the > >main goal or drive the cost or complexity over budget -- seemed to >offer >pretty reasonable incremental benefit for a not-terrible incremental >cost. > >But, one can go too far, and turning this into a language feature would > >have been taking it too far.? The Java Language and VM try very hard to > >be platform-neutral; shebang is definitively not platform-neutral.? >And, >anything having to do with the language spec incurs greater costs (I'm >not just talking development costs) and complexity.? So, this isn't a >language feature, it's a platform integration feature.? Which is why >the >launcher is the right vehicle here -- this is where the Java platform >meets the underlying platform. > >Volker raised this question early on.? We had already thought about the > >implications of this (we generally think pretty deeply about the many >possible roads one could take before we propose a project), and we >didn't like them -- because, as mentioned above, this is a platform >integration issue, not a language issue.? I don't deny that it would be > >nice in certain situations if we made no distinction between "Java >source file" and "scripts that happen to contain Java source code" -- >and that might be a perfectly reasonable choice for some other >languages >-- but the goal was never "Java as a scripting language".?? So, while >"why not go all the way with shebang" is a reasonable question to ask, >it seemed (and still seems) the wrong match for Java.? When the >question >came up again (as they always do in a large community), no new >information had come to light to cause us to come to a different >conclusion. > >Jon's distinction here between "Java source file", and a separate >notion >of "script that contains Java code" or "platform-specific executable >script", is a good one; we'd implicitly been thinking of these as two >different things, but its clear that this is confusing to people, and >making the distinction explicit should dispel some of that confusion.? >Sure, they _could_ be merged, but highlighting this distinction seems >much more in keeping with the spirit of the platform than blurring the >distinction (though that might be a fine choice for other languages.)? >So, +1 to Jon's suggestion. > >So, what can be done here?? We could: > ?- move forward with the feature, as is. > ?- clarify the distinction between "Java source file" and "script >containing Java", and tweak accordingly, as Jon suggests. > ?- drop the JEP entirely. > ?- drop the shebang support and keep the rest. > >What does not seem like a reasonable choice is to turn the Java >Language >into a platform-dependent thing, for all the reasons Jon mentioned, and > >more. > >> I am afraid that adopting pejorative terms like 'infecting' doesn't >> really make your case stronger. > >I'm sorry if you were offended by my use of this term.? I take the Java > >Language very seriously, and defend its boundaries vigorously! > > >Cheers, >-Brian -- Diese Nachricht wurde von meinem Android-Ger?t mit K-9 Mail gesendet. From daniel.fuchs at oracle.com Thu May 24 10:17:08 2018 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Thu, 24 May 2018 11:17:08 +0100 Subject: CFV: New JDK Reviewer: Chris Plummer In-Reply-To: <4d4a97d1-882c-aa73-fb3d-ac55bf2f1f6c@oracle.com> References: <4d4a97d1-882c-aa73-fb3d-ac55bf2f1f6c@oracle.com> Message-ID: <3664abb2-246e-1046-28f9-cb002d8415e5@oracle.com> Vote: yes best regards, -- daniel On 24/05/2018 01:00, serguei.spitsyn at oracle.com wrote: > I hearby nominate Chris Plummer (cjplummer) to JDK Project Reviewer. From markus.gronlund at oracle.com Thu May 24 11:30:19 2018 From: markus.gronlund at oracle.com (Markus Gronlund) Date: Thu, 24 May 2018 04:30:19 -0700 (PDT) Subject: CFV: New JDK Reviewer: Chris Plummer In-Reply-To: <4d4a97d1-882c-aa73-fb3d-ac55bf2f1f6c@oracle.com> References: <4d4a97d1-882c-aa73-fb3d-ac55bf2f1f6c@oracle.com> Message-ID: <597e8b5e-498a-494d-af6c-b824901488d2@default> Vote: yes Thanks Markus -----Original Message----- From: Serguei Spitsyn Sent: den 24 maj 2018 02:00 To: jdk-dev Subject: CFV: New JDK Reviewer: Chris Plummer I hearby nominate Chris Plummer (cjplummer) to JDK Project Reviewer. Chris is a JDK Project Committer has contributed 67 changesets[1]. Chris has contributed significant changes into various areas over the past 4 years: JVM TI, Attach API, DCMD's, NMT, CDS, VM Runtime including footprint reduction, stack sizing, stack walking, etc., and stabilization of serviceability tests (most of which were closed, but are/will be open now). Votes are due by June 6, 2018. Only current JDK Reviewers [2] 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 [3]. Serguei [1] http://hg.openjdk.java.net/jdk/jdk/search/?rev=(!keyword(%22merge%22)%20and%20author(cjplummer))&revcount=100 [2] http://openjdk.java.net/census [3] http://openjdk.java.net/projects/#reviewer-vote From magnus.ihse.bursie at oracle.com Thu May 24 12:02:58 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 24 May 2018 14:02:58 +0200 Subject: CFV: New JDK Reviewer: Chris Plummer In-Reply-To: <4d4a97d1-882c-aa73-fb3d-ac55bf2f1f6c@oracle.com> References: <4d4a97d1-882c-aa73-fb3d-ac55bf2f1f6c@oracle.com> Message-ID: Vote: yes /Magnus On 2018-05-24 02:00, serguei.spitsyn at oracle.com wrote: > I hearby nominate Chris Plummer (cjplummer) to JDK Project Reviewer. > > Chris is a JDK Project Committer has contributed 67 changesets[1]. > > Chris has contributed significant changes into various areas over the > past 4 years: > JVM TI, Attach API, DCMD's, NMT, CDS, VM Runtime including footprint > reduction, > stack sizing, stack walking, etc., and stabilization of serviceability > tests > (most of which were closed, but are/will be open now). > > Votes are due by June 6, 2018. > > Only current JDK Reviewers [2] 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 [3]. > > Serguei > > [1] > http://hg.openjdk.java.net/jdk/jdk/search/?rev=(!keyword(%22merge%22)%20and%20author(cjplummer))&revcount=100 > > [2] http://openjdk.java.net/census > [3] http://openjdk.java.net/projects/#reviewer-vote > From james.laskey at oracle.com Thu May 24 12:08:21 2018 From: james.laskey at oracle.com (Jim Laskey) Date: Thu, 24 May 2018 09:08:21 -0300 Subject: CFV: New JDK Reviewer: Chris Plummer In-Reply-To: <4d4a97d1-882c-aa73-fb3d-ac55bf2f1f6c@oracle.com> References: <4d4a97d1-882c-aa73-fb3d-ac55bf2f1f6c@oracle.com> Message-ID: <8362E26D-0F97-48AE-9308-1683DDC0AD2B@oracle.com> vote: yes > On May 23, 2018, at 9:00 PM, serguei.spitsyn at oracle.com wrote: > > I hearby nominate Chris Plummer (cjplummer) to JDK Project Reviewer. > > Chris is a JDK Project Committer has contributed 67 changesets[1]. > > Chris has contributed significant changes into various areas over the past 4 years: > JVM TI, Attach API, DCMD's, NMT, CDS, VM Runtime including footprint reduction, > stack sizing, stack walking, etc., and stabilization of serviceability tests > (most of which were closed, but are/will be open now). > > Votes are due by June 6, 2018. > > Only current JDK Reviewers [2] 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 [3]. > > Serguei > > [1] http://hg.openjdk.java.net/jdk/jdk/search/?rev=(!keyword(%22merge%22)%20and%20author(cjplummer))&revcount=100 > > [2] http://openjdk.java.net/census > [3] http://openjdk.java.net/projects/#reviewer-vote > From zgu at redhat.com Thu May 24 12:08:45 2018 From: zgu at redhat.com (Zhengyu Gu) Date: Thu, 24 May 2018 08:08:45 -0400 Subject: CFV: New JDK Reviewer: Chris Plummer In-Reply-To: <4d4a97d1-882c-aa73-fb3d-ac55bf2f1f6c@oracle.com> References: <4d4a97d1-882c-aa73-fb3d-ac55bf2f1f6c@oracle.com> Message-ID: Vote: yes -Zhengyu On 05/23/2018 08:00 PM, serguei.spitsyn at oracle.com wrote: > I hearby nominate Chris Plummer (cjplummer) to JDK Project Reviewer. > > Chris is a JDK Project Committer has contributed 67 changesets[1]. > > Chris has contributed significant changes into various areas over the > past 4 years: > JVM TI, Attach API, DCMD's, NMT, CDS, VM Runtime including footprint > reduction, > stack sizing, stack walking, etc., and stabilization of serviceability > tests > (most of which were closed, but are/will be open now). > > Votes are due by June 6, 2018. > > Only current JDK Reviewers [2] 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 [3]. > > Serguei > > [1] > http://hg.openjdk.java.net/jdk/jdk/search/?rev=(!keyword(%22merge%22)%20and%20author(cjplummer))&revcount=100 > > > [2] http://openjdk.java.net/census > [3] http://openjdk.java.net/projects/#reviewer-vote > From kim.barrett at oracle.com Thu May 24 12:23:27 2018 From: kim.barrett at oracle.com (Kim Barrett) Date: Thu, 24 May 2018 14:23:27 +0200 Subject: CFV: New JDK Reviewer: Chris Plummer In-Reply-To: <4d4a97d1-882c-aa73-fb3d-ac55bf2f1f6c@oracle.com> References: <4d4a97d1-882c-aa73-fb3d-ac55bf2f1f6c@oracle.com> Message-ID: vote: yes > On May 24, 2018, at 2:00 AM, serguei.spitsyn at oracle.com wrote: > > I hearby nominate Chris Plummer (cjplummer) to JDK Project Reviewer. > > Chris is a JDK Project Committer has contributed 67 changesets[1]. > > Chris has contributed significant changes into various areas over the past 4 years: > JVM TI, Attach API, DCMD's, NMT, CDS, VM Runtime including footprint reduction, > stack sizing, stack walking, etc., and stabilization of serviceability tests > (most of which were closed, but are/will be open now). > > Votes are due by June 6, 2018. > > Only current JDK Reviewers [2] 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 [3]. > > Serguei > > [1] http://hg.openjdk.java.net/jdk/jdk/search/?rev=(!keyword(%22merge%22)%20and%20author(cjplummer))&revcount=100 > > [2] http://openjdk.java.net/census > [3] http://openjdk.java.net/projects/#reviewer-vote From Roger.Riggs at Oracle.com Thu May 24 13:19:34 2018 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Thu, 24 May 2018 09:19:34 -0400 Subject: CFV: New JDK Reviewer: Chris Plummer In-Reply-To: <4d4a97d1-882c-aa73-fb3d-ac55bf2f1f6c@oracle.com> References: <4d4a97d1-882c-aa73-fb3d-ac55bf2f1f6c@oracle.com> Message-ID: <19f4d67c-5a91-fd5d-327f-e772f9ae9621@Oracle.com> Vote: Yes On 5/23/2018 8:00 PM, serguei.spitsyn at oracle.com wrote: > I hearby nominate Chris Plummer (cjplummer) to JDK Project Reviewer. From lois.foltan at oracle.com Thu May 24 13:20:30 2018 From: lois.foltan at oracle.com (Lois Foltan) Date: Thu, 24 May 2018 09:20:30 -0400 Subject: CFV: New JDK Reviewer: Chris Plummer In-Reply-To: <4d4a97d1-882c-aa73-fb3d-ac55bf2f1f6c@oracle.com> References: <4d4a97d1-882c-aa73-fb3d-ac55bf2f1f6c@oracle.com> Message-ID: Vote: yes Lois On 5/23/2018 8:00 PM, serguei.spitsyn at oracle.com wrote: > I hearby nominate Chris Plummer (cjplummer) to JDK Project Reviewer. > > Chris is a JDK Project Committer has contributed 67 changesets[1]. > > Chris has contributed significant changes into various areas over the > past 4 years: > JVM TI, Attach API, DCMD's, NMT, CDS, VM Runtime including footprint > reduction, > stack sizing, stack walking, etc., and stabilization of serviceability > tests > (most of which were closed, but are/will be open now). > > Votes are due by June 6, 2018. > > Only current JDK Reviewers [2] 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 [3]. > > Serguei > > [1] > http://hg.openjdk.java.net/jdk/jdk/search/?rev=(!keyword(%22merge%22)%20and%20author(cjplummer))&revcount=100 > > [2] http://openjdk.java.net/census > [3] http://openjdk.java.net/projects/#reviewer-vote > From serguei.spitsyn at oracle.com Thu May 24 13:43:19 2018 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 24 May 2018 06:43:19 -0700 Subject: CFV: New JDK Reviewer: Chris Plummer In-Reply-To: <4d4a97d1-882c-aa73-fb3d-ac55bf2f1f6c@oracle.com> References: <4d4a97d1-882c-aa73-fb3d-ac55bf2f1f6c@oracle.com> Message-ID: <2059fa96-2a45-0dc1-6c58-491f4ed127f9@oracle.com> Vote: yes From stuart.monteith at linaro.org Thu May 24 13:56:24 2018 From: stuart.monteith at linaro.org (Stuart Monteith) Date: Thu, 24 May 2018 14:56:24 +0100 Subject: JEP proposed to target JDK 11: 330: Launch Single-File Source-Code Programs In-Reply-To: <5B06686A.6050302@sibvisions.com> References: <20180517201204.EAA4F1BC51D@eggemoggin.niobe.net> <0a0ea067-d8e8-ce70-9514-4b80c241215d@oracle.com> <5B06686A.6050302@sibvisions.com> Message-ID: While we are talking about platform specifics, I notice nobody has mentioned binfmt_misc. If you are running on a suitably configured Linux system you could just type: echo ":java:E::java::/bin/java:" >/proc/sys/fs/binfmt_misc/register That will allow you to run: $ ./HelloWorld.java without modify the source at all. Using binfmt_misc to handle "//! " at the beginning is possible with some magic bytes and a wrapper are also possible if you want to avoid needing the .java extension. Most Debian installations will have an entry for "jar" files already. While there probably isn't a scheme that would allow a single .java file to run from the command line (or icon) on every platform, there are perhaps platform specific means on most platforms. BR, Stuart On 24 May 2018 at 08:23, Robert Zenz wrote: > I'm sorry, I still don't get why the shebang line is required at all for this > proposal. I might argue that shebang lines are system dependent features and are > typically only used with languages which treat `#` as a comment which is not the > case in Java. Additionally, we can already "emulate" shebangs in Java (or any C > like language) source files using a polyglot. Which is fore sure not that easy > to understand, but it still gets the job done. > > I know what you're trying to do, but I fail to see how the achieved goal (of > easily executing a Java source file by doing `./HelloWorld.java` versus `java > HelloWorld.java`) validates the added special case just to support the shebang > line (including possible confusion of newcomers why the first line is allowed to > start with `#` but everywhere else is a syntax error). > > On 23.05.2018 23:01, Jonathan Gibbons wrote: >> On 5/17/18 1:12 PM, mark.reinhold at oracle.com wrote: >> >>> The following JEP is proposed to target JDK 11: >>> >>> 330: Launch Single-File Source-Code Programs >>> http://openjdk.java.net/jeps/330 >>> >>> Feedback on this proposal is more than welcome, as are reasoned >>> objections. If no such objections are raised by 23:00 UTC on Thursday, >>> 24 May, or if they're raised and then satisfactorily answered, then >>> per the JEP 2.0 process proposal [1] I'll target this JEP to JDK 11. >>> >>> - Mark >>> >>> >>> [1] http://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html >> A number of points have been raised, regarding the interaction with javac and >> shebang scripts. >> >> It was never a goal to modify javac to support shebang-java scripts. This can be >> seen indirectly in the JEP in the description of how the first line may be >> removed before passing the rest of the file as a normal CompilationUnit to the >> compiler. With hindsight, this deserves to be stated as an explicit Non-Goal. >> >> There are various reasons to not want to change JLS or javac: >> >> 1. Changing JLS is a Big Deal, and comes with its own costs and constraints. >> Further, shebang files are a platform-specific feature, and are not even defined >> in the POSIX standard. The feature does not warrant changing a JCP-controlled >> specification. >> >> 2. Changing javac to accept shebang-java files is also a Big Deal. Modifying the >> command-line options to accept files that do not follow the standard naming >> conventions would introduce complexity and potential ambiguity. >> >> 3. There is no compelling need to change JLS or javac. As demonstrated by the >> proposed implementation, no change to JLS or javac is actually necessary in >> order to implement the feature. It is therefore at most a convenience if javac >> were to be adapted to ignore shebang lines. >> >> Shebang scripts are an executable format defined on some, but not all, >> platforms. Creating a shebang script is typically more than just adding an >> initial first line to a file; it typically involves a number of steps: >> >> a. Add an initial shebang line to the file >> b. Rename the file to a "command-friendly" name >> c. Make the file executable >> d. Install the file in some standard location >> >> While renaming the file to a command-friendly name is optional, it is also >> expected to be common practice. For example, a source file named >> `HelloWorld.java` might be installed as `helloworld`. And, while the JEP >> describes use cases for executing a small single-file program with `java >> HelloWorld.java` or executing it as a platform-specific shebang script with just >> `helloworld`, it does not seem like there is a common use case to execute >> `HelloWorld.java`. So, if the shebang script is typically renamed to a >> command-friendly name, it will not be possible to compile it directly, with >> "javac helloworld", because that is not a valid command line for javac. This >> reduces any potential convenience of having javac ignore shebang lines. >> >> Since Java source files are different artifacts to platform-specific executable >> scripts, it makes sense to treat them differently, and since we do not want to >> change the Java language to support shebang lines, the suggestion is to amend >> the JEP and implementation so that shebang lines are never stripped from Java >> source files, i.e. files ending in `.java`. This avoids the problem of having >> the ecosystem of tools handling Java source files having to deal with arbitrary >> artifacts like shebang lines. The change would still permit the direct >> execution of Java source files, such as `java HelloWorld.java`, and the >> execution of shebang scripts, such as `helloworld`. >> >> -- Jon From harold.seigel at oracle.com Thu May 24 14:22:58 2018 From: harold.seigel at oracle.com (Harold David Seigel) Date: Thu, 24 May 2018 10:22:58 -0400 Subject: CFV: New JDK Reviewer: Chris Plummer In-Reply-To: <4d4a97d1-882c-aa73-fb3d-ac55bf2f1f6c@oracle.com> References: <4d4a97d1-882c-aa73-fb3d-ac55bf2f1f6c@oracle.com> Message-ID: <7ab8646d-9be9-e9c9-f3fc-31816356e817@oracle.com> Vote: yes Harold On 5/23/2018 8:00 PM, serguei.spitsyn at oracle.com wrote: > I hearby nominate Chris Plummer (cjplummer) to JDK Project Reviewer. > > Chris is a JDK Project Committer has contributed 67 changesets[1]. > > Chris has contributed significant changes into various areas over the > past 4 years: > JVM TI, Attach API, DCMD's, NMT, CDS, VM Runtime including footprint > reduction, > stack sizing, stack walking, etc., and stabilization of serviceability > tests > (most of which were closed, but are/will be open now). > > Votes are due by June 6, 2018. > > Only current JDK Reviewers [2] 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 [3]. > > Serguei > > [1] > http://hg.openjdk.java.net/jdk/jdk/search/?rev=(!keyword(%22merge%22)%20and%20author(cjplummer))&revcount=100 > > [2] http://openjdk.java.net/census > [3] http://openjdk.java.net/projects/#reviewer-vote > From mandy.chung at oracle.com Thu May 24 15:13:27 2018 From: mandy.chung at oracle.com (mandy chung) Date: Thu, 24 May 2018 08:13:27 -0700 Subject: CFV: New JDK Reviewer: Chris Plummer In-Reply-To: <4d4a97d1-882c-aa73-fb3d-ac55bf2f1f6c@oracle.com> References: <4d4a97d1-882c-aa73-fb3d-ac55bf2f1f6c@oracle.com> Message-ID: <356e1a71-e380-c788-644e-bc075503ecfd@oracle.com> Vote: yes Mandy On 5/23/18 5:00 PM, serguei.spitsyn at oracle.com wrote: > I hearby nominate Chris Plummer (cjplummer) to JDK Project Reviewer. > > Chris is a JDK Project Committer has contributed 67 changesets[1]. > > Chris has contributed significant changes into various areas over the > past 4 years: > JVM TI, Attach API, DCMD's, NMT, CDS, VM Runtime including footprint > reduction, > stack sizing, stack walking, etc., and stabilization of serviceability > tests > (most of which were closed, but are/will be open now). > > Votes are due by June 6, 2018. > > Only current JDK Reviewers [2] 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 [3]. > > Serguei > > [1] > http://hg.openjdk.java.net/jdk/jdk/search/?rev=(!keyword(%22merge%22)%20and%20author(cjplummer))&revcount=100 > > > [2] http://openjdk.java.net/census > [3] http://openjdk.java.net/projects/#reviewer-vote > From calvin.cheung at oracle.com Thu May 24 15:50:37 2018 From: calvin.cheung at oracle.com (Calvin Cheung) Date: Thu, 24 May 2018 08:50:37 -0700 Subject: CFV: New JDK Reviewer: Chris Plummer In-Reply-To: <4d4a97d1-882c-aa73-fb3d-ac55bf2f1f6c@oracle.com> References: <4d4a97d1-882c-aa73-fb3d-ac55bf2f1f6c@oracle.com> Message-ID: <5B06DF4D.7000302@oracle.com> Vote: yes On 5/23/18, 5:00 PM, serguei.spitsyn at oracle.com wrote: > I hearby nominate Chris Plummer (cjplummer) to JDK Project Reviewer. > > Chris is a JDK Project Committer has contributed 67 changesets[1]. > > Chris has contributed significant changes into various areas over the > past 4 years: > JVM TI, Attach API, DCMD's, NMT, CDS, VM Runtime including footprint > reduction, > stack sizing, stack walking, etc., and stabilization of serviceability > tests > (most of which were closed, but are/will be open now). > > Votes are due by June 6, 2018. > > Only current JDK Reviewers [2] 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 [3]. > > Serguei > > [1] > http://hg.openjdk.java.net/jdk/jdk/search/?rev=(!keyword(%22merge%22)%20and%20author(cjplummer))&revcount=100 > > [2] http://openjdk.java.net/census > [3] http://openjdk.java.net/projects/#reviewer-vote > From coleen.phillimore at oracle.com Thu May 24 15:55:47 2018 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Thu, 24 May 2018 11:55:47 -0400 Subject: CFV: New JDK Reviewer: Chris Plummer In-Reply-To: <4d4a97d1-882c-aa73-fb3d-ac55bf2f1f6c@oracle.com> References: <4d4a97d1-882c-aa73-fb3d-ac55bf2f1f6c@oracle.com> Message-ID: <938cbf22-b964-4a27-c6d5-1e72893916b1@oracle.com> Votes: yes On 5/23/18 8:00 PM, serguei.spitsyn at oracle.com wrote: > I hearby nominate Chris Plummer (cjplummer) to JDK Project Reviewer. > > Chris is a JDK Project Committer has contributed 67 changesets[1]. > > Chris has contributed significant changes into various areas over the > past 4 years: > JVM TI, Attach API, DCMD's, NMT, CDS, VM Runtime including footprint > reduction, > stack sizing, stack walking, etc., and stabilization of serviceability > tests > (most of which were closed, but are/will be open now). > > Votes are due by June 6, 2018. > > Only current JDK Reviewers [2] 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 [3]. > > Serguei > > [1] > http://hg.openjdk.java.net/jdk/jdk/search/?rev=(!keyword(%22merge%22)%20and%20author(cjplummer))&revcount=100 > > [2] http://openjdk.java.net/census > [3] http://openjdk.java.net/projects/#reviewer-vote > From karen.kinnear at oracle.com Thu May 24 18:44:55 2018 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Thu, 24 May 2018 14:44:55 -0400 Subject: CFV: New JDK Reviewer: Chris Plummer In-Reply-To: <4d4a97d1-882c-aa73-fb3d-ac55bf2f1f6c@oracle.com> References: <4d4a97d1-882c-aa73-fb3d-ac55bf2f1f6c@oracle.com> Message-ID: Vote: yes thanks, Karen > On May 23, 2018, at 8:00 PM, serguei.spitsyn at oracle.com wrote: > > I hearby nominate Chris Plummer (cjplummer) to JDK Project Reviewer. > > Chris is a JDK Project Committer has contributed 67 changesets[1]. > > Chris has contributed significant changes into various areas over the past 4 years: > JVM TI, Attach API, DCMD's, NMT, CDS, VM Runtime including footprint reduction, > stack sizing, stack walking, etc., and stabilization of serviceability tests > (most of which were closed, but are/will be open now). > > Votes are due by June 6, 2018. > > Only current JDK Reviewers [2] 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 [3]. > > Serguei > > [1] http://hg.openjdk.java.net/jdk/jdk/search/?rev=(!keyword(%22merge%22)%20and%20author(cjplummer))&revcount=100 > > [2] http://openjdk.java.net/census > [3] http://openjdk.java.net/projects/#reviewer-vote > From mark.reinhold at oracle.com Thu May 24 23:03:27 2018 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Thu, 24 May 2018 16:03:27 -0700 Subject: JEP proposed to target JDK 11: 329: ChaCha20 and Poly1305 Cryptographic Algorithms In-Reply-To: <20180517201203.DE4B31BC51B@eggemoggin.niobe.net> References: <20180517201203.DE4B31BC51B@eggemoggin.niobe.net> Message-ID: <20180524160327.387138197@eggemoggin.niobe.net> 2018/5/17 13:12:03 -0700, mark.reinhold at oracle.com: > The following JEP is proposed to target JDK 11: > > 329: ChaCha20 and Poly1305 Cryptographic Algorithms > http://openjdk.java.net/jeps/329 > > Feedback on this proposal is more than welcome, as are reasoned > objections. If no such objections are raised by 23:00 UTC on Thursday, > 24 May, or if they're raised and then satisfactorily answered, then > per the JEP 2.0 process proposal [1] I'll target this JEP to JDK 11. Hearing no objections, I?ve targeted this JEP to JDK 11. - Mark From mark.reinhold at oracle.com Thu May 24 23:05:24 2018 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Thu, 24 May 2018 16:05:24 -0700 Subject: JEP proposed to target JDK 11: 330: Launch Single-File Source-Code Programs In-Reply-To: <20180517201204.EAA4F1BC51D@eggemoggin.niobe.net> References: <20180517201204.EAA4F1BC51D@eggemoggin.niobe.net> Message-ID: <20180524160524.266587816@eggemoggin.niobe.net> 2018/5/17 13:12:04 -0700, mark.reinhold at oracle.com: > The following JEP is proposed to target JDK 11: > > 330: Launch Single-File Source-Code Programs > http://openjdk.java.net/jeps/330 > > Feedback on this proposal is more than welcome, as are reasoned > objections. If no such objections are raised by 23:00 UTC on Thursday, > 24 May, or if they're raised and then satisfactorily answered, then > per the JEP 2.0 process proposal [1] I'll target this JEP to JDK 11. Thanks to all who?ve contributed to the vigorous discussion of this JEP. Let?s extend the review period to 23:00 UTC on Thursday, 31 May, to make sure that all concerns are addressed. - Mark From jonathan.gibbons at oracle.com Thu May 24 23:23:28 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 24 May 2018 16:23:28 -0700 Subject: JEP proposed to target JDK 11: 330: Launch Single-File Source-Code Programs In-Reply-To: References: <20180517201204.EAA4F1BC51D@eggemoggin.niobe.net> <0a0ea067-d8e8-ce70-9514-4b80c241215d@oracle.com> Message-ID: <0d1f2b8a-a0cd-ae55-3092-f30bfa34c592@oracle.com> Mario, Your comments are well-taken, and the existence of other, arguably better, ways to invoke Java source code from a script lend credence to the argument that we should _not_ extend the Java language or javac to directly support shebang lines. Two suggestions have been made in this discussion, both of which can be the subject of further investigation, separate from this JEP. 1. Support for "//!" in Linux and other Unix-based systems as an alternative to "#!". Such a feature would totally remove the need for suppressing shebang lines in the source files under consideration. But, while we can advocate for such a solution, such would be an RFE for those systems to consider, and would be beyond the scope of any JEP. 2. The use of "here" documents, as suggested by you and others. The JEP as currently proposed should support such usage, albeit using the somewhat cryptic "/dev/fd3" as an input file. It would be a relatively minor change to the current work to support the commonly accepted use of "-" to represent stdin. There is nothing in the current work that would preclude that, and supporting "-" could be handled as a followup RFE. Regarding your specific proposal for using "here" documents, I do not follow your argument that your example is better for being "proper Java, with all the benefits like debugging, IDE support etc.". At least to a casual observer, the shebang line and the couple of lines to invoke java using a "here" document look very similar: in both cases, there is a cryptic header followed by some Java source code. In both cases the file can be seen as a script that contains Java source code, as compared to a Java source file that is a script. As to the possible ways forward: * Support for "//!" is attractive but requires a manual or automated update to the underlying system, which is beyond our control. * Support for using "here" documents as you suggest is possible: it is ultimately more flexible than shebang lines, and should be advertised in the JEP, but it requires a more advanced understanding of shell, when much of the current focus is about simplifying the on-ramp to Java. * The "shebang" line is attractive for its simplicity for all those cases where it is sufficient, even if the Java launcher has to go out of its way to remove the line before compiling the source code that follows. The general theme here is not to evolve Java into a scripting language, but to make tools like the Java launcher more friendly to supporting the use of Java source code in an executable text file, in order to reduce the ceremony of running simple programs. In conclusion, while I don?t think pulling the emergency brake cord on this feature is warranted, there are some simpler things we could do. I suggest that we should update the JEP to be more clear about the Non-Goals, and to cite additional alternative ways that Java source code can be used in executable text files (scripts.)? This is in addition to yesterday's suggestion [1] to draw a more distinct separation between Java source files (which end with a .java extension), and executable scripts (which do not use any such extension.) -- Jon [1] http://mail.openjdk.java.net/pipermail/jdk-dev/2018-May/001248.html On 5/24/18 2:02 AM, Mario Torre wrote: > I hear those concern, and I agree with you, but this shows why this is > an unwanted feature if any. I find this JEP dangerous to some extent > (ok, that may be perhaps a strong wording) because it turns Java into > a scripting language without full support from the JLS. Now, the > controversial point is clearly the shebang support, the rest seems > fine and reasonable, and like others have said if we allow to read > files from stdin we should have full equivalence of shell scripting > without all the unwanted side effects: > > #!/bin/bash > exec java --source 11 /dev/fd/3 "$@" 3< public class Hello { > public static void main(String[] args) { > String name = System.console().readLine("Please enter your name: "); > System.console().printf("Hello, %s!%n", name); > } > } > EOF > > Is functionally the same and almost as convenient as: > > #!/bin/java > public class Hello { > public static void main(String[] args) { > String name = System.console().readLine("Please enter your name: "); > System.console().printf("Hello, %s!%n", name); > } > } > > Except that is proper Java, with all the benefits like debugging, IDE > support etc.. in fact, the added benefit is that such utility is more > naturally projected toward a use "_at the end of their development > phase_", as it requires a developer to thing through the embedding, > but at the same time it keeps the option open, since this is instantly > compatible with any scripted java code you may have already around or > any actual compiled class, no need to touch anything to make it work > in the script, platform idiosyncrasies are where they belong, no > special casing. Yes, the difference is really a one liner but the > perception in how this is meant to be used is drastic. > > I think this should be part of the JEP and the controversial line > about Shebang removed instead. > > Cheers, > Mario > > > On Wed, May 23, 2018 at 11:01 PM, Jonathan Gibbons > wrote: >> On 5/17/18 1:12 PM, mark.reinhold at oracle.com wrote: >> >>> The following JEP is proposed to target JDK 11: >>> >>> 330: Launch Single-File Source-Code Programs >>> http://openjdk.java.net/jeps/330 >>> >>> Feedback on this proposal is more than welcome, as are reasoned >>> objections. If no such objections are raised by 23:00 UTC on Thursday, >>> 24 May, or if they're raised and then satisfactorily answered, then >>> per the JEP 2.0 process proposal [1] I'll target this JEP to JDK 11. >>> >>> - Mark >>> >>> >>> [1] http://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html >> A number of points have been raised, regarding the interaction with javac >> and shebang scripts. >> >> It was never a goal to modify javac to support shebang-java scripts. This >> can be seen indirectly in the JEP in the description of how the first line >> may be removed before passing the rest of the file as a normal >> CompilationUnit to the compiler. With hindsight, this deserves to be stated >> as an explicit Non-Goal. >> >> There are various reasons to not want to change JLS or javac: >> >> 1. Changing JLS is a Big Deal, and comes with its own costs and constraints. >> Further, shebang files are a platform-specific feature, and are not even >> defined in the POSIX standard. The feature does not warrant changing a >> JCP-controlled specification. >> >> 2. Changing javac to accept shebang-java files is also a Big Deal. Modifying >> the command-line options to accept files that do not follow the standard >> naming conventions would introduce complexity and potential ambiguity. >> >> 3. There is no compelling need to change JLS or javac. As demonstrated by >> the proposed implementation, no change to JLS or javac is actually necessary >> in order to implement the feature. It is therefore at most a convenience if >> javac were to be adapted to ignore shebang lines. >> >> Shebang scripts are an executable format defined on some, but not all, >> platforms. Creating a shebang script is typically more than just adding an >> initial first line to a file; it typically involves a number of steps: >> >> a. Add an initial shebang line to the file >> b. Rename the file to a "command-friendly" name >> c. Make the file executable >> d. Install the file in some standard location >> >> While renaming the file to a command-friendly name is optional, it is also >> expected to be common practice. For example, a source file named >> `HelloWorld.java` might be installed as `helloworld`. And, while the JEP >> describes use cases for executing a small single-file program with `java >> HelloWorld.java` or executing it as a platform-specific shebang script with >> just `helloworld`, it does not seem like there is a common use case to >> execute `HelloWorld.java`. So, if the shebang script is typically renamed to >> a command-friendly name, it will not be possible to compile it directly, >> with "javac helloworld", because that is not a valid command line for javac. >> This reduces any potential convenience of having javac ignore shebang lines. >> >> Since Java source files are different artifacts to platform-specific >> executable scripts, it makes sense to treat them differently, and since we >> do not want to change the Java language to support shebang lines, the >> suggestion is to amend the JEP and implementation so that shebang lines are >> never stripped from Java source files, i.e. files ending in `.java`. This >> avoids the problem of having the ecosystem of tools handling Java source >> files having to deal with arbitrary artifacts like shebang lines. The >> change would still permit the direct execution of Java source files, such as >> `java HelloWorld.java`, and the execution of shebang scripts, such as >> `helloworld`. >> >> -- Jon > > From neugens at redhat.com Fri May 25 10:18:23 2018 From: neugens at redhat.com (Mario Torre) Date: Fri, 25 May 2018 12:18:23 +0200 Subject: JEP proposed to target JDK 11: 330: Launch Single-File Source-Code Programs In-Reply-To: <0d1f2b8a-a0cd-ae55-3092-f30bfa34c592@oracle.com> References: <20180517201204.EAA4F1BC51D@eggemoggin.niobe.net> <0a0ea067-d8e8-ce70-9514-4b80c241215d@oracle.com> <0d1f2b8a-a0cd-ae55-3092-f30bfa34c592@oracle.com> Message-ID: On Fri, May 25, 2018 at 1:23 AM, Jonathan Gibbons wrote: > Mario, > Regarding your specific proposal for using "here" documents, I do not follow > your argument that your example is better for being "proper Java, with all > the benefits like debugging, IDE support etc.". At least to a casual > observer, the shebang line and the couple of lines to invoke java using a > "here" document look very similar: in both cases, there is a cryptic header > followed by some Java source code. In both cases the file can be seen as a > script that contains Java source code, as compared to a Java source file > that is a script. The difference is subtle, with the shebang the "#!" is part of the java file, with the here syntax it isn't, that means every single line you write is actually proper java. One is an invalid .java file unrecognized by IDE and compilers, the other is a shell script. The implication is that a developer that wants to embed it in a shell script is more forced to think about the embedding as part of the process of writing the utility, but can do so at a later stage with no modifications and without introducing an incompatible java artefact (which is great for reuse for instance). You are right there's not much difference from an IDE point of view though, except that again a .java class that is loaded in an IDE but contains the "#!"line won't be valid and will be unrecognized, while a shell script will be essentially seen as a shell script. I suspect that java code that is mean to be embedded like this will likely be small utilities, but there's nothing stopping someone from creating a full applications in the IDE and then just embed it in a script. The shebang in this case would be tying the two process too tightly, if we only support the here documents we are decoupling things which is better imho. > As to the possible ways forward: > > * Support for "//!" is attractive but requires a manual or automated update > to the underlying system, which is beyond our control. > > * Support for using "here" documents as you suggest is possible: it is > ultimately more flexible than shebang lines, and should be advertised in the > JEP, but it requires a more advanced understanding of shell, when much of > the current focus is about simplifying the on-ramp to Java. I would go with that and drop the shebang, I strongly suspect that shebang will create long term problems we are not carefully considering at this stage. Cheers, Mario -- Mario Torre Associate Manager, Software Engineering Red Hat GmbH 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From jonathan.gibbons at oracle.com Fri May 25 13:55:52 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Fri, 25 May 2018 06:55:52 -0700 Subject: JEP proposed to target JDK 11: 330: Launch Single-File Source-Code Programs In-Reply-To: References: <20180517201204.EAA4F1BC51D@eggemoggin.niobe.net> <0a0ea067-d8e8-ce70-9514-4b80c241215d@oracle.com> <0d1f2b8a-a0cd-ae55-3092-f30bfa34c592@oracle.com> Message-ID: <5a492211-f213-202d-b29f-56888a5c9c78@oracle.com> On 5/25/18 3:18 AM, Mario Torre wrote: > On Fri, May 25, 2018 at 1:23 AM, Jonathan Gibbons > wrote: >> Mario, >> Regarding your specific proposal for using "here" documents, I do not follow >> your argument that your example is better for being "proper Java, with all >> the benefits like debugging, IDE support etc.". At least to a casual >> observer, the shebang line and the couple of lines to invoke java using a >> "here" document look very similar: in both cases, there is a cryptic header >> followed by some Java source code. In both cases the file can be seen as a >> script that contains Java source code, as compared to a Java source file >> that is a script. > The difference is subtle, with the shebang the "#!" is part of the > java file, with the here syntax it isn't, that means every single line > you write is actually proper java. One is an invalid .java file > unrecognized by IDE and compilers, the other is a shell script. Mario, I agree with your general concern about polluting Java source files, which is why we have suggested modifying the feature to prohibit the use of shebang lines in Java source files, as identified by a filename ending in ".java". [1]?? With this proposed change, the source-file launcher will only remove shebang lines in files which are not identified as Java source files, thus drawing a clear distinction between files which are Java source files and those which are not.?? In particular, there will not be any invalid .java files, unrecognized by IDEs and compilers, to be worried about. -- Jon [1] http://mail.openjdk.java.net/pipermail/jdk-dev/2018-May/001248.html > > The implication is that a developer that wants to embed it in a shell > script is more forced to think about the embedding as part of the > process of writing the utility, but can do so at a later stage with no > modifications and without introducing an incompatible java artefact > (which is great for reuse for instance). > > You are right there's not much difference from an IDE point of view > though, except that again a .java class that is loaded in an IDE but > contains the "#!"line won't be valid and will be unrecognized, while a > shell script will be essentially seen as a shell script. I suspect > that java code that is mean to be embedded like this will likely be > small utilities, but there's nothing stopping someone from creating a > full applications in the IDE and then just embed it in a script. The > shebang in this case would be tying the two process too tightly, if we > only support the here documents we are decoupling things which is > better imho. > >> As to the possible ways forward: >> >> * Support for "//!" is attractive but requires a manual or automated update >> to the underlying system, which is beyond our control. >> >> * Support for using "here" documents as you suggest is possible: it is >> ultimately more flexible than shebang lines, and should be advertised in the >> JEP, but it requires a more advanced understanding of shell, when much of >> the current focus is about simplifying the on-ramp to Java. > I would go with that and drop the shebang, I strongly suspect that > shebang will create long term problems we are not carefully > considering at this stage. > > Cheers, > Mario From yumin.qi at gmail.com Fri May 25 17:00:17 2018 From: yumin.qi at gmail.com (yumin qi) Date: Fri, 25 May 2018 10:00:17 -0700 Subject: JEP: JWarmup precompile java hot methods at application startup Message-ID: Hi, Mark Proposed a draft of new JEP: https://bugs.openjdk.java.net/browse/JDK-8203832 We (Alibaba Group Inc) have an implementation of warmup performance solution and want to contribute to OpenJDK, wish it can help java developers to resolve the same problems we have encountered. Please take a look and wait for a discussion/evaluation on it. Thanks Yumin From mark.reinhold at oracle.com Fri May 25 20:22:51 2018 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Fri, 25 May 2018 13:22:51 -0700 Subject: JEP: JWarmup precompile java hot methods at application startup In-Reply-To: References: Message-ID: <20180525132251.552041504@eggemoggin.niobe.net> 2018/5/25 10:00:17 -0700, yumin.qi at gmail.com: > Hi, Mark > > Proposed a draft of new JEP: > https://bugs.openjdk.java.net/browse/JDK-8203832 > > We (Alibaba Group Inc) have an implementation of warmup performance > solution and want to contribute to OpenJDK, wish it can help java > developers to resolve the same problems we have encountered. > > Please take a look and wait for a discussion/evaluation on it. I suggest that you ask hotspot-dev for feedback. - Mark From per.liden at oracle.com Mon May 28 20:09:38 2018 From: per.liden at oracle.com (Per Liden) Date: Mon, 28 May 2018 22:09:38 +0200 Subject: CFV: New JDK Reviewer: Chris Plummer In-Reply-To: <4d4a97d1-882c-aa73-fb3d-ac55bf2f1f6c@oracle.com> References: <4d4a97d1-882c-aa73-fb3d-ac55bf2f1f6c@oracle.com> Message-ID: Vote: yes /Per On 2018-05-24 02:00, serguei.spitsyn at oracle.com wrote: > I hearby nominate Chris Plummer (cjplummer) to JDK Project Reviewer. > > Chris is a JDK Project Committer has contributed 67 changesets[1]. > > Chris has contributed significant changes into various areas over the > past 4 years: > JVM TI, Attach API, DCMD's, NMT, CDS, VM Runtime including footprint > reduction, > stack sizing, stack walking, etc., and stabilization of serviceability > tests > (most of which were closed, but are/will be open now). > > Votes are due by June 6, 2018. > > Only current JDK Reviewers [2] 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 [3]. > > Serguei > > [1] > http://hg.openjdk.java.net/jdk/jdk/search/?rev=(!keyword(%22merge%22)%20and%20author(cjplummer))&revcount=100 > > > [2] http://openjdk.java.net/census > [3] http://openjdk.java.net/projects/#reviewer-vote > From vladimir.x.ivanov at oracle.com Tue May 29 09:38:51 2018 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Tue, 29 May 2018 12:38:51 +0300 Subject: CFV: New JDK Reviewer: Chris Plummer In-Reply-To: <4d4a97d1-882c-aa73-fb3d-ac55bf2f1f6c@oracle.com> References: <4d4a97d1-882c-aa73-fb3d-ac55bf2f1f6c@oracle.com> Message-ID: Vote: yes Best regards, Vladimir Ivanov On 24/05/2018 03:00, serguei.spitsyn at oracle.com wrote: > I hearby nominate Chris Plummer (cjplummer) to JDK Project Reviewer. From christoph.langer at sap.com Tue May 29 09:55:40 2018 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 29 May 2018 09:55:40 +0000 Subject: New JDK Reviewer: Chris Plummer In-Reply-To: <4d4a97d1-882c-aa73-fb3d-ac55bf2f1f6c@oracle.com> References: <4d4a97d1-882c-aa73-fb3d-ac55bf2f1f6c@oracle.com> Message-ID: Vote: yes Best regards Christoph > -----Original Message----- > From: jdk-dev [mailto:jdk-dev-bounces at openjdk.java.net] On Behalf Of > serguei.spitsyn at oracle.com > Sent: Donnerstag, 24. Mai 2018 02:00 > To: jdk-dev > Subject: CFV: New JDK Reviewer: Chris Plummer > > I hearby nominate Chris Plummer (cjplummer) to JDK Project Reviewer. > > Chris is a JDK Project Committer has contributed 67 changesets[1]. > > Chris has contributed significant changes into various areas over the past 4 > years: > JVM TI, Attach API, DCMD's, NMT, CDS, VM Runtime including footprint > reduction, > stack sizing, stack walking, etc., and stabilization of serviceability tests > (most of which were closed, but are/will be open now). > > Votes are due by June 6, 2018. > > Only current JDK Reviewers [2] 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 [3]. > > Serguei > > [1] > http://hg.openjdk.java.net/jdk/jdk/search/?rev=(!keyword(%22merge%22) > %20and%20author(cjplummer))&revcount=100 > > [2] http://openjdk.java.net/census > [3] http://openjdk.java.net/projects/#reviewer-vote From robbin.ehn at oracle.com Tue May 29 12:51:16 2018 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Tue, 29 May 2018 14:51:16 +0200 Subject: CFV: New JDK Reviewer: Chris Plummer In-Reply-To: <4d4a97d1-882c-aa73-fb3d-ac55bf2f1f6c@oracle.com> References: <4d4a97d1-882c-aa73-fb3d-ac55bf2f1f6c@oracle.com> Message-ID: <83d9d026-1ba4-f4cd-9ebb-d343813f2ece@oracle.com> Vote: yes /Robbin On 05/24/2018 02:00 AM, serguei.spitsyn at oracle.com wrote: > I hearby nominate Chris Plummer (cjplummer) to JDK Project Reviewer. > > Chris is a JDK Project Committer has contributed 67 changesets[1]. > > Chris has contributed significant changes into various areas over the past 4 years: > JVM TI, Attach API, DCMD's, NMT, CDS, VM Runtime including footprint reduction, > stack sizing, stack walking, etc., and stabilization of serviceability tests > (most of which were closed, but are/will be open now). > > Votes are due by June 6, 2018. > > Only current JDK Reviewers [2] 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 [3]. > > Serguei > > [1] > http://hg.openjdk.java.net/jdk/jdk/search/?rev=(!keyword(%22merge%22)%20and%20author(cjplummer))&revcount=100 > > > [2] http://openjdk.java.net/census > [3] http://openjdk.java.net/projects/#reviewer-vote > From mark.reinhold at oracle.com Tue May 29 22:58:16 2018 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Tue, 29 May 2018 15:58:16 -0700 (PDT) Subject: JEP proposed to target JDK 11: 315: Improve Aarch64 Intrinsics Message-ID: <20180529225816.D41691DB3A7@eggemoggin.niobe.net> The following JEP is proposed to target JDK 11: 315: Improve Aarch64 Intrinsics http://openjdk.java.net/jeps/315 Feedback on this proposal is more than welcome, as are reasoned objections. If no such objections are raised by 23:00 UTC on Friday, 5 January, or if they're raised and then satisfactorily answered, then per the JEP 2.0 process proposal [1] I'll target this JEP to JDK 11. - Mark [1] http://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html From mark.reinhold at oracle.com Wed May 30 00:38:35 2018 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Tue, 29 May 2018 17:38:35 -0700 Subject: JEP proposed to target JDK 11: 315: Improve Aarch64 Intrinsics In-Reply-To: <20180529225816.D41691DB3A7@eggemoggin.niobe.net> References: <20180529225816.D41691DB3A7@eggemoggin.niobe.net> Message-ID: <20180529173835.249260702@eggemoggin.niobe.net> 2018/5/29 15:58:16 -0700, mark.reinhold at oracle.com: > The following JEP is proposed to target JDK 11: > > 315: Improve Aarch64 Intrinsics > http://openjdk.java.net/jeps/315 > > Feedback on this proposal is more than welcome, as are reasoned > objections. If no such objections are raised by 23:00 UTC on Friday, > 5 January, ... D?oh! I meant 23:00 UTC next Thursday, 5 June, of course. - Mark From mark.reinhold at oracle.com Wed May 30 22:49:18 2018 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Wed, 30 May 2018 15:49:18 -0700 (PDT) Subject: JEP proposed to target JDK 11: 333: ZGC: A Scalable Low-Latency Garbage Collector (Experimental) Message-ID: <20180530224918.6DA371DB5A0@eggemoggin.niobe.net> The following JEP is proposed to target JDK 11: 333: ZGC: A Scalable Low-Latency Garbage Collector (Experimental) http://openjdk.java.net/jeps/333 Feedback on this proposal is more than welcome, as are reasoned objections. If no such objections are raised by 23:00 UTC on Wednesday, 6 June, or if they're raised and then satisfactorily answered, then per the JEP 2.0 process proposal [1] I'll target this JEP to JDK 11. - Mark [1] http://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html From mark.reinhold at oracle.com Wed May 30 22:49:17 2018 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Wed, 30 May 2018 15:49:17 -0700 (PDT) Subject: JEP proposed to target JDK 11: 181: Nest-Based Access Control Message-ID: <20180530224917.507061DB59E@eggemoggin.niobe.net> The following JEP is proposed to target JDK 11: 181: Nest-Based Access Control http://openjdk.java.net/jeps/181 Feedback on this proposal is more than welcome, as are reasoned objections. If no such objections are raised by 23:00 UTC on Wednesday, 6 June, or if they're raised and then satisfactorily answered, then per the JEP 2.0 process proposal [1] I'll target this JEP to JDK 11. - Mark [1] http://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html From tibokruse at googlemail.com Thu May 31 13:01:29 2018 From: tibokruse at googlemail.com (Thibault Kruse) Date: Thu, 31 May 2018 22:01:29 +0900 Subject: JEP proposed to target JDK 11: 330: Launch Single-File, Source-Code Programs In-Reply-To: <20180517201204.EAA4F1BC51D@eggemoggin.niobe.net> References: <20180517201204.EAA4F1BC51D@eggemoggin.niobe.net> Message-ID: Hello, I have a few minor concerns. # Regarding the command structure The JEP330 (2018/05/30) states: "The source file should contain one or more top-level classes, the first of which is taken as the class to be executed. No other source files are found and compiled, as if the source path is set to an empty value." So why should the java command not continue to take a class name as a positional parameter, and get an additional optional parameter like "-sourcepath" taking one sourcefile (or later maybe more) to compile? As it is specified in the JEP, changing the order of top-level classes in the file could affect the outcome, something that seems very un-java-like. Also this prevents users from specifying classes to run, or running nested classes, etc. The effort of typing ??? java HelloWorld.java ??? vs. ??? java HelloWorld -sourcepath HelloWorld.java seems small enough to be suffered for this first day of learning java, in particular since a shell can easily run commands again from the history (the second day of learning java would start with installing an IDE). And that structure does not share the quirks of heuristically guessing what the user meant. Also this would more easily allow later addition of specifying multiple files or sourcefolders along with a main class to run. # Regarding the single-file restriction Why not allow users to modularize their first few classes in java and load them all to run a main method? Teaching them to put all classes in a single file does not seem java-like. A source-path option could well point to a folder or a list of folders to load sources from. # Regarding the source filename JEP330 (2018/05/30) currently also states: "The compiler does not enforce the optional restriction defined at the end of JLS ?7.6, [...] the type name followed by the .java extension. [...] If the file does not have the|.java|extension..." I see no significant benefit in allowing users to use a different filename (unless for the shebang line / scripting issue), and IDEs will again struggle to turn off compiler errors for such files. I believe it is better to keep the experience consistent. # Regarding jshell as alternative JEP330 (2018/05/30) currently states jshell "We could delegate the task of "one-off runs" to the|jshell|tool. While this may at first seem obvious, this was an explicit non-goal in the design of|jshell|. The|jshell|tool was designed to be an interactive shell, and many design decisions were made in favor of providing a better interactive experience. Burdening it with the additional constraints of being the batch runner would detract from the interactive experience." This seems insufficient justification. People are already using jshell for this purpose, e.g. see * https://stackoverflow.com/questions/44916618/how-to-execute-a-java-script-with-jshell * https://gist.github.com/ffissore/012d7e32a096fde5266f49038c93dcaf * https://dzone.com/articles/jdk9-execute-java-code-like-unix-shell-script Why burdening java with this feature for interactive programming sessions and not jshell seems quite mysterious to me. Several other programming languages also have a unified executable for running both interactive mode and individual files, so it's not generally considered counter-intuitive. I might be wrong, but jshell seems to be part of the JDK, which would also help compared to the java command being part of the JRE, which by itself would not be able to compile source files (I assume). # Regarding POSIX scripting support (shebang lines) This should be a JEP in it's own right, and may well also consider approaches like this: https://coderwall.com/p/ssuaxa/how-to-make-a-jar-file-linux-executable || From jonathan.gibbons at oracle.com Thu May 31 18:42:53 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 31 May 2018 11:42:53 -0700 Subject: JEP proposed to target JDK 11: 330: Launch Single-File, Source-Code Programs In-Reply-To: References: <20180517201204.EAA4F1BC51D@eggemoggin.niobe.net> Message-ID: <5B10422D.6080403@oracle.com> On 05/31/2018 06:01 AM, Thibault Kruse wrote: > Hello, I have a few minor concerns. > > # Regarding the command structure > > The JEP330 (2018/05/30) states: "The source file should contain one or > more top-level classes, the first of which is taken as the class to be > executed. > No other source files are found and compiled, as if the source path is > set to an empty value." > > So why should the java command not continue to take a class name as a > positional parameter, and get an additional optional parameter like > "-sourcepath" taking one sourcefile (or later maybe more) to compile? > As it is specified in the JEP, changing the order of top-level classes > in the file could affect the outcome, something that seems very > un-java-like. Also this prevents users from specifying classes to run, > or running nested classes, etc. > > The effort of typing > > java HelloWorld.java > vs. > java HelloWorld -sourcepath HelloWorld.java > > seems small enough to be suffered for this first day of learning java, > in particular since a shell can easily run commands again from the > history (the second day of learning java would start with installing > an IDE). > And that structure does not share the quirks of heuristically guessing > what the user meant. > Also this would more easily allow later addition of specifying > multiple files or sourcefolders along with a main class to run. This would be an incompatible change, since all parameters after the main class are specified to be passed as arguments to the main class. > > # Regarding the single-file restriction > > Why not allow users to modularize their first few classes in java and > load them all to run a main method? Teaching them to put all classes > in a single file does not seem java-like. A source-path option could > well point to a folder or a list of folders to load sources from. While we permit multiple top level classes in the file, I would not recommend it as a style. The use cases here are for beginners writing initial small programs, and for use of Java in scripts. Anything beyond those use cases is better addressed by existing tools for building programs composed of many source files. > > # Regarding the source filename > > JEP330 (2018/05/30) currently also states: "The compiler does not > enforce the optional restriction defined at the end of JLS ?7.6, [...] > the type name followed by the .java extension. [...] If the file does > not have the|.java|extension..." > I see no significant benefit in allowing users to use a different > filename (unless for the shebang line / scripting issue), and IDEs > will again struggle to turn off compiler errors for such files. I > believe it is better to keep the experience consistent. The desire to disable the file name check is specifically to support the shebang/scripting use case. > > # Regarding jshell as alternative > > JEP330 (2018/05/30) currently states jshell "We could delegate the > task of "one-off runs" to the|jshell|tool. While this may at first > seem obvious, this was an explicit non-goal in the design of|jshell|. > The|jshell|tool was designed to be an interactive shell, and many > design decisions were made in favor of providing a better interactive > experience. Burdening it with the additional constraints of being the > batch runner would detract from the interactive experience." > > This seems insufficient justification. People are already using jshell > for this purpose, e.g. see > * > https://stackoverflow.com/questions/44916618/how-to-execute-a-java-script-with-jshell > * https://gist.github.com/ffissore/012d7e32a096fde5266f49038c93dcaf > * > https://dzone.com/articles/jdk9-execute-java-code-like-unix-shell-script > Why burdening java with this feature for interactive programming > sessions and not jshell seems quite mysterious to me. Several other > programming languages also have a unified executable for running both > interactive mode and individual files, so it's not generally > considered counter-intuitive. > I might be wrong, but jshell seems to be part of the JDK, which would > also help compared to the java command being part of the JRE, which by > itself would not be able to compile source files (I assume). The reasons to prefer incorporating this feature into the launcher, and not into jshell, have already been discussed on this alias. > > # Regarding POSIX scripting support (shebang lines) > > This should be a JEP in it's own right, and may well also consider > approaches like this: > https://coderwall.com/p/ssuaxa/how-to-make-a-jar-file-linux-executable > || FWIW, shebang lines are not specified in POSIX. Making jar files executable is a wholly different topic to supporting the use of Java source code in scripts. -- Jon