From james.laskey at oracle.com Thu Apr 6 15:31:08 2017 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Thu, 6 Apr 2017 12:31:08 -0300 Subject: CFV: New Project: Project Duke In-Reply-To: <9CE42887-B17C-493A-A9B8-7BB963A83F39@oracle.com> References: <8650fd47-8738-42ef-b285-bc5284b0ee5b@default> <9CE42887-B17C-493A-A9B8-7BB963A83F39@oracle.com> Message-ID: <09DB9EB4-F8A0-437F-8763-597D7EBDAC26@oracle.com> Vote: Yes > On Apr 6, 2017, at 12:11 PM, Jeff Dinkins wrote: > > > I hereby propose the creation of Project Duke, with myself as the > Lead and the Core Libraries and Web groups as sponsoring groups. > > In accordance with the OpenJDK guidelines [1], this project will > provide a location for Duke graphics to reside. Duke is the Java > mascot, which was open sourced by Sun on November 13th 2006. > > About the Lead: Jeff Dinkins (OpenJDK username: jeff) is a JDK 9 > Committer, and has had experinece drawing Duke for 15+ years. > > The initial Committers will be: > > * James Gosling > ? Jasper Potts > * Jeff Dinkins > > The project will host at least the following mailing list: > > * duke-dev for developers & aspiring graphics artists > > The initial ?source" of this project will be based on a clone of the > existing (but soon to disappear) repo on Kenai [2]. > > Votes are due by April 21st, 2017. > > Only current OpenJDK Members [3] are eligible to vote on this motion. > Votes must be cast in the open on the discuss list. Replying to this > message is sufficient if your mail program honors the Reply-To header. > > For Lazy Consensus voting instructions, see [4]. > > > [1] http://openjdk.java.net/projects/#new-project > > [2] https://duke.kenai.com > > [3] http://openjdk.java.net/census#members > > [4] http://openjdk.java.net/projects/#new-project-vote > From neugens.limasoftware at gmail.com Thu Apr 6 15:38:30 2017 From: neugens.limasoftware at gmail.com (Mario Torre) Date: Thu, 6 Apr 2017 17:38:30 +0200 Subject: CFV: New Project: Project Duke In-Reply-To: <9CE42887-B17C-493A-A9B8-7BB963A83F39@oracle.com> References: <8650fd47-8738-42ef-b285-bc5284b0ee5b@default> <9CE42887-B17C-493A-A9B8-7BB963A83F39@oracle.com> Message-ID: Vote: Yes. > About the Lead: Jeff Dinkins (OpenJDK username: jeff) is a JDK 9 > Committer, and has had experinece drawing Duke for 15+ years. :) Cheers, Mario -- pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens Proud GNU Classpath developer: http://www.classpath.org/ OpenJDK: http://openjdk.java.net/projects/caciocavallo/ Please, support open standards: http://endsoftpatents.org/ From omajid at redhat.com Thu Apr 6 15:41:04 2017 From: omajid at redhat.com (Omair Majid) Date: Thu, 6 Apr 2017 11:41:04 -0400 Subject: CFV: New Project: Project Duke In-Reply-To: <9CE42887-B17C-493A-A9B8-7BB963A83F39@oracle.com> References: <8650fd47-8738-42ef-b285-bc5284b0ee5b@default> <9CE42887-B17C-493A-A9B8-7BB963A83F39@oracle.com> Message-ID: <20170406154103.GB14181@redhat.com> Vote: Yes * Jeff Dinkins [2017-04-06 11:26]: > I hereby propose the creation of Project Duke, with myself as the > Lead and the Core Libraries and Web groups as sponsoring groups. > > In accordance with the OpenJDK guidelines [1], this project will > provide a location for Duke graphics to reside. Duke is the Java > mascot, which was open sourced by Sun on November 13th 2006. Thanks, Omair -- PGP Key: 66484681 (http://pgp.mit.edu/) Fingerprint = F072 555B 0A17 3957 4E95 0056 F286 F14F 6648 4681 From mark.reinhold at oracle.com Thu Apr 6 15:50:59 2017 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Thu, 06 Apr 2017 08:50:59 -0700 Subject: CFV: New Project: Project Duke In-Reply-To: <9CE42887-B17C-493A-A9B8-7BB963A83F39@oracle.com> References: <8650fd47-8738-42ef-b285-bc5284b0ee5b@default> <9CE42887-B17C-493A-A9B8-7BB963A83F39@oracle.com> Message-ID: <20170406085059.778539489@eggemoggin.niobe.net> Vote: yes - Mark From daniel.daugherty at oracle.com Thu Apr 6 15:51:05 2017 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 6 Apr 2017 09:51:05 -0600 Subject: CFV: New Project: Project Duke In-Reply-To: <9CE42887-B17C-493A-A9B8-7BB963A83F39@oracle.com> References: <8650fd47-8738-42ef-b285-bc5284b0ee5b@default> <9CE42887-B17C-493A-A9B8-7BB963A83F39@oracle.com> Message-ID: <910521d0-9d4d-fdda-d99d-c6df61c1528b@oracle.com> Vote: yes Dan On 4/6/17 9:11 AM, Jeff Dinkins wrote: > I hereby propose the creation of Project Duke, with myself as the > Lead and the Core Libraries and Web groups as sponsoring groups. > > In accordance with the OpenJDK guidelines [1], this project will > provide a location for Duke graphics to reside. Duke is the Java > mascot, which was open sourced by Sun on November 13th 2006. > > About the Lead: Jeff Dinkins (OpenJDK username: jeff) is a JDK 9 > Committer, and has had experinece drawing Duke for 15+ years. > > The initial Committers will be: > > * James Gosling > ? Jasper Potts > * Jeff Dinkins > > The project will host at least the following mailing list: > > * duke-dev for developers & aspiring graphics artists > > The initial ?source" of this project will be based on a clone of the > existing (but soon to disappear) repo on Kenai [2]. > > Votes are due by April 21st, 2017. > > Only current OpenJDK Members [3] are eligible to vote on this motion. > Votes must be cast in the open on the discuss list. Replying to this > message is sufficient if your mail program honors the Reply-To header. > > For Lazy Consensus voting instructions, see [4]. > > > [1] http://openjdk.java.net/projects/#new-project > > [2] https://duke.kenai.com > > [3] http://openjdk.java.net/census#members > > [4] http://openjdk.java.net/projects/#new-project-vote > > From Roger.Riggs at Oracle.com Thu Apr 6 15:55:17 2017 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Thu, 6 Apr 2017 11:55:17 -0400 Subject: CFV: New Project: Project Duke In-Reply-To: <9CE42887-B17C-493A-A9B8-7BB963A83F39@oracle.com> References: <8650fd47-8738-42ef-b285-bc5284b0ee5b@default> <9CE42887-B17C-493A-A9B8-7BB963A83F39@oracle.com> Message-ID: <12427c89-6d48-8146-aac2-11efe5941f53@Oracle.com> Vote: Yes On 4/6/2017 11:11 AM, Jeff Dinkins wrote: > I hereby propose the creation of Project Duke, with myself as the > Lead and the Core Libraries and Web groups as sponsoring groups. > From Alan.Bateman at oracle.com Thu Apr 6 15:55:17 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 6 Apr 2017 16:55:17 +0100 Subject: CFV: New Project: Project Duke In-Reply-To: <9CE42887-B17C-493A-A9B8-7BB963A83F39@oracle.com> References: <8650fd47-8738-42ef-b285-bc5284b0ee5b@default> <9CE42887-B17C-493A-A9B8-7BB963A83F39@oracle.com> Message-ID: Vote: yes From joe.darcy at oracle.com Thu Apr 6 15:55:42 2017 From: joe.darcy at oracle.com (joe darcy) Date: Thu, 6 Apr 2017 08:55:42 -0700 Subject: CFV: New Project: Project Duke In-Reply-To: <9CE42887-B17C-493A-A9B8-7BB963A83F39@oracle.com> References: <8650fd47-8738-42ef-b285-bc5284b0ee5b@default> <9CE42887-B17C-493A-A9B8-7BB963A83F39@oracle.com> Message-ID: Vote: Yes! -Joe On 4/6/2017 8:11 AM, Jeff Dinkins wrote: > I hereby propose the creation of Project Duke, with myself as the > Lead and the Core Libraries and Web groups as sponsoring groups. > > In accordance with the OpenJDK guidelines [1], this project will > provide a location for Duke graphics to reside. Duke is the Java > mascot, which was open sourced by Sun on November 13th 2006. > > About the Lead: Jeff Dinkins (OpenJDK username: jeff) is a JDK 9 > Committer, and has had experinece drawing Duke for 15+ years. > > The initial Committers will be: > > * James Gosling > ? Jasper Potts > * Jeff Dinkins > > The project will host at least the following mailing list: > > * duke-dev for developers & aspiring graphics artists > > The initial ?source" of this project will be based on a clone of the > existing (but soon to disappear) repo on Kenai [2]. > > Votes are due by April 21st, 2017. > > Only current OpenJDK Members [3] are eligible to vote on this motion. > Votes must be cast in the open on the discuss list. Replying to this > message is sufficient if your mail program honors the Reply-To header. > > For Lazy Consensus voting instructions, see [4]. > > > [1] http://openjdk.java.net/projects/#new-project > > [2] https://duke.kenai.com > > [3] http://openjdk.java.net/census#members > > [4] http://openjdk.java.net/projects/#new-project-vote > From david.grieve at oracle.com Thu Apr 6 15:57:03 2017 From: david.grieve at oracle.com (David Grieve) Date: Thu, 6 Apr 2017 11:57:03 -0400 Subject: CFV: New Project: Project Duke In-Reply-To: References: <8650fd47-8738-42ef-b285-bc5284b0ee5b@default> <9CE42887-B17C-493A-A9B8-7BB963A83F39@oracle.com> Message-ID: <3a085929-4a40-f6e1-111e-4d1a2680b89d@oracle.com> |https://duke.kenai.com/ ?? | On 4/6/17 11:55 AM, joe darcy wrote: > Vote: Yes! > > -Joe > > > On 4/6/2017 8:11 AM, Jeff Dinkins wrote: >> I hereby propose the creation of Project Duke, with myself as the >> Lead and the Core Libraries and Web groups as sponsoring groups. >> >> In accordance with the OpenJDK guidelines [1], this project will >> provide a location for Duke graphics to reside. Duke is the Java >> mascot, which was open sourced by Sun on November 13th 2006. >> >> About the Lead: Jeff Dinkins (OpenJDK username: jeff) is a JDK 9 >> Committer, and has had experinece drawing Duke for 15+ years. >> >> The initial Committers will be: >> >> * James Gosling >> ? Jasper Potts >> * Jeff Dinkins >> >> The project will host at least the following mailing list: >> >> * duke-dev for developers & aspiring graphics artists >> >> The initial ?source" of this project will be based on a clone of the >> existing (but soon to disappear) repo on Kenai [2]. >> >> Votes are due by April 21st, 2017. >> >> Only current OpenJDK Members [3] are eligible to vote on this motion. >> Votes must be cast in the open on the discuss list. Replying to this >> message is sufficient if your mail program honors the Reply-To header. >> >> For Lazy Consensus voting instructions, see [4]. >> >> >> [1] http://openjdk.java.net/projects/#new-project >> >> [2] https://duke.kenai.com >> >> [3] http://openjdk.java.net/census#members >> >> [4] http://openjdk.java.net/projects/#new-project-vote >> > From naoto.sato at oracle.com Thu Apr 6 15:54:52 2017 From: naoto.sato at oracle.com (Naoto Sato) Date: Thu, 6 Apr 2017 08:54:52 -0700 Subject: CFV: New Project: Project Duke In-Reply-To: <9CE42887-B17C-493A-A9B8-7BB963A83F39@oracle.com> References: <8650fd47-8738-42ef-b285-bc5284b0ee5b@default> <9CE42887-B17C-493A-A9B8-7BB963A83F39@oracle.com> Message-ID: Vote: yes Naoto From daniel.fuchs at oracle.com Thu Apr 6 16:00:07 2017 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Thu, 6 Apr 2017 17:00:07 +0100 Subject: CFV: New Project: Project Duke In-Reply-To: <9CE42887-B17C-493A-A9B8-7BB963A83F39@oracle.com> References: <8650fd47-8738-42ef-b285-bc5284b0ee5b@default> <9CE42887-B17C-493A-A9B8-7BB963A83F39@oracle.com> Message-ID: <29b5c1fe-52da-599c-382b-bce8b5f7eb48@oracle.com> Vote: yes On 06/04/2017 16:11, Jeff Dinkins wrote: > > I hereby propose the creation of Project Duke, with myself as the > Lead and the Core Libraries and Web groups as sponsoring groups. From brent.christian at oracle.com Thu Apr 6 16:01:19 2017 From: brent.christian at oracle.com (Brent Christian) Date: Thu, 6 Apr 2017 09:01:19 -0700 Subject: CFV: New Project: Project Duke In-Reply-To: <9CE42887-B17C-493A-A9B8-7BB963A83F39@oracle.com> References: <8650fd47-8738-42ef-b285-bc5284b0ee5b@default> <9CE42887-B17C-493A-A9B8-7BB963A83F39@oracle.com> Message-ID: <177479fa-cca1-8ffe-0681-25f6caa47b8d@oracle.com> Vote: Yes On 4/6/17 8:11 AM, Jeff Dinkins wrote: > > I hereby propose the creation of Project Duke, with myself as the > Lead and the Core Libraries and Web groups as sponsoring groups. From jonathan.gibbons at oracle.com Thu Apr 6 16:50:09 2017 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 6 Apr 2017 09:50:09 -0700 Subject: CFV: New Project: Project Duke In-Reply-To: <9CE42887-B17C-493A-A9B8-7BB963A83F39@oracle.com> References: <8650fd47-8738-42ef-b285-bc5284b0ee5b@default> <9CE42887-B17C-493A-A9B8-7BB963A83F39@oracle.com> Message-ID: <96d8bbd7-8930-41f7-9671-20c507d66f73@oracle.com> Vote: yes On 4/6/17 8:11 AM, Jeff Dinkins wrote: > I hereby propose the creation of Project Duke, with myself as the > Lead and the Core Libraries and Web groups as sponsoring groups. > > In accordance with the OpenJDK guidelines [1], this project will > provide a location for Duke graphics to reside. Duke is the Java > mascot, which was open sourced by Sun on November 13th 2006. > > About the Lead: Jeff Dinkins (OpenJDK username: jeff) is a JDK 9 > Committer, and has had experinece drawing Duke for 15+ years. > > The initial Committers will be: > > * James Gosling > ? Jasper Potts > * Jeff Dinkins > > The project will host at least the following mailing list: > > * duke-dev for developers & aspiring graphics artists > > The initial ?source" of this project will be based on a clone of the > existing (but soon to disappear) repo on Kenai [2]. > > Votes are due by April 21st, 2017. > > Only current OpenJDK Members [3] are eligible to vote on this motion. > Votes must be cast in the open on the discuss list. Replying to this > message is sufficient if your mail program honors the Reply-To header. > > For Lazy Consensus voting instructions, see [4]. > > > [1] http://openjdk.java.net/projects/#new-project > > [2] https://duke.kenai.com > > [3] http://openjdk.java.net/census#members > > [4] http://openjdk.java.net/projects/#new-project-vote > From jesper.wilhelmsson at oracle.com Thu Apr 6 16:43:26 2017 From: jesper.wilhelmsson at oracle.com (jesper.wilhelmsson at oracle.com) Date: Thu, 6 Apr 2017 18:43:26 +0200 Subject: CFV: New Project: Project Duke In-Reply-To: <9CE42887-B17C-493A-A9B8-7BB963A83F39@oracle.com> References: <8650fd47-8738-42ef-b285-bc5284b0ee5b@default> <9CE42887-B17C-493A-A9B8-7BB963A83F39@oracle.com> Message-ID: <09EE52B9-2377-447C-AE5C-956B8F0D4CE2@oracle.com> Vote: Yes /Jesper > On 6 Apr 2017, at 17:11, Jeff Dinkins wrote: > > > I hereby propose the creation of Project Duke, with myself as the > Lead and the Core Libraries and Web groups as sponsoring groups. > > In accordance with the OpenJDK guidelines [1], this project will > provide a location for Duke graphics to reside. Duke is the Java > mascot, which was open sourced by Sun on November 13th 2006. > > About the Lead: Jeff Dinkins (OpenJDK username: jeff) is a JDK 9 > Committer, and has had experinece drawing Duke for 15+ years. > > The initial Committers will be: > > * James Gosling > ? Jasper Potts > * Jeff Dinkins > > The project will host at least the following mailing list: > > * duke-dev for developers & aspiring graphics artists > > The initial ?source" of this project will be based on a clone of the > existing (but soon to disappear) repo on Kenai [2]. > > Votes are due by April 21st, 2017. > > Only current OpenJDK Members [3] are eligible to vote on this motion. > Votes must be cast in the open on the discuss list. Replying to this > message is sufficient if your mail program honors the Reply-To header. > > For Lazy Consensus voting instructions, see [4]. > > > [1] http://openjdk.java.net/projects/#new-project > > [2] https://duke.kenai.com > > [3] http://openjdk.java.net/census#members > > [4] http://openjdk.java.net/projects/#new-project-vote > From tim.bell at oracle.com Thu Apr 6 17:04:58 2017 From: tim.bell at oracle.com (Tim Bell) Date: Thu, 6 Apr 2017 10:04:58 -0700 Subject: CFV: New Project: Project Duke In-Reply-To: <9CE42887-B17C-493A-A9B8-7BB963A83F39@oracle.com> References: <8650fd47-8738-42ef-b285-bc5284b0ee5b@default> <9CE42887-B17C-493A-A9B8-7BB963A83F39@oracle.com> Message-ID: <75ab71b0-cee7-8058-a10b-38fc368ca257@oracle.com> Vote: yes Tim On 04/06/17 08:11, Jeff Dinkins wrote: > I hereby propose the creation of Project Duke, with myself as the > Lead and the Core Libraries and Web groups as sponsoring groups. From Peter.B.Kessler at Oracle.COM Thu Apr 6 17:14:40 2017 From: Peter.B.Kessler at Oracle.COM (Peter B. Kessler) Date: Thu, 6 Apr 2017 10:14:40 -0700 Subject: CFV: New Project: Project Duke In-Reply-To: <9CE42887-B17C-493A-A9B8-7BB963A83F39@oracle.com> References: <8650fd47-8738-42ef-b285-bc5284b0ee5b@default> <9CE42887-B17C-493A-A9B8-7BB963A83F39@oracle.com> Message-ID: Vote: Yes. ... peter On 04/ 6/17 08:11 AM, Jeff Dinkins wrote: > > I hereby propose the creation of Project Duke, with myself as the > Lead and the Core Libraries and Web groups as sponsoring groups. > .... From Peter.B.Kessler at Oracle.COM Thu Apr 6 17:33:44 2017 From: Peter.B.Kessler at Oracle.COM (Peter B. Kessler) Date: Thu, 6 Apr 2017 10:33:44 -0700 Subject: CFV: New Project: Project Duke In-Reply-To: <9CE42887-B17C-493A-A9B8-7BB963A83F39@oracle.com> References: <8650fd47-8738-42ef-b285-bc5284b0ee5b@default> <9CE42887-B17C-493A-A9B8-7BB963A83F39@oracle.com> Message-ID: <5fa3bc15-2155-ebbe-3e03-0a82f143cfcc@Oracle.COM> It doesn't look like the kenai repository has the "Tumbling Duke" images. I have them (T1.gif through T17.gif, though I don't think all of them got used in the applet) if everyone else has misplaced their copies. I used them in some demo (to show GC pauses and their effect on animation?) Even better, I have an original Joe Palrang whiteboard drawing of Duke holding a time bomb. If memory serves, it was the countdown clock for the Moviewood demo, which got cancelled at day 34. Carla Schroer gave it to Lisa Friendly when she left Sun, and Lisa gave it to me when she left Sun. My contribution was to put a sheet of plexiglass over it so it didn't get erased accidentally. I have a photograph of it somewhere. It don't think the internets are capable of uploading physical objects. ... peter On 04/ 6/17 08:11 AM, Jeff Dinkins wrote: > > I hereby propose the creation of Project Duke, with myself as the > Lead and the Core Libraries and Web groups as sponsoring groups. > > In accordance with the OpenJDK guidelines [1], this project will > provide a location for Duke graphics to reside. Duke is the Java > mascot, which was open sourced by Sun on November 13th 2006. > > About the Lead: Jeff Dinkins (OpenJDK username: jeff) is a JDK 9 > Committer, and has had experinece drawing Duke for 15+ years. > > The initial Committers will be: > > * James Gosling > ? Jasper Potts > * Jeff Dinkins > > The project will host at least the following mailing list: > > * duke-dev for developers & aspiring graphics artists > > The initial ?source" of this project will be based on a clone of the > existing (but soon to disappear) repo on Kenai [2]. > > Votes are due by April 21st, 2017. > > Only current OpenJDK Members [3] are eligible to vote on this motion. > Votes must be cast in the open on the discuss list. Replying to this > message is sufficient if your mail program honors the Reply-To header. > > For Lazy Consensus voting instructions, see [4]. > > > [1] http://openjdk.java.net/projects/#new-project > > [2] https://duke.kenai.com > > [3] http://openjdk.java.net/census#members > > [4] http://openjdk.java.net/projects/#new-project-vote > From james.graham at oracle.com Thu Apr 6 19:13:11 2017 From: james.graham at oracle.com (Jim Graham) Date: Thu, 6 Apr 2017 12:13:11 -0700 Subject: CFV: New Project: Project Duke In-Reply-To: <9CE42887-B17C-493A-A9B8-7BB963A83F39@oracle.com> References: <8650fd47-8738-42ef-b285-bc5284b0ee5b@default> <9CE42887-B17C-493A-A9B8-7BB963A83F39@oracle.com> Message-ID: <8463bf73-8c9e-6002-1264-3ee95f481d63@oracle.com> Vote: Yes ...jim On 4/6/17 8:11 AM, Jeff Dinkins wrote: > > I hereby propose the creation of Project Duke, with myself as the > Lead and the Core Libraries and Web groups as sponsoring groups. From john.r.rose at oracle.com Thu Apr 6 20:28:56 2017 From: john.r.rose at oracle.com (John Rose) Date: Thu, 6 Apr 2017 13:28:56 -0700 Subject: CFV: New Project: Project Duke In-Reply-To: <9CE42887-B17C-493A-A9B8-7BB963A83F39@oracle.com> References: <8650fd47-8738-42ef-b285-bc5284b0ee5b@default> <9CE42887-B17C-493A-A9B8-7BB963A83F39@oracle.com> Message-ID: <6B0DDA1A-87AA-4CB8-A34C-CB7EC5873002@oracle.com> On Apr 6, 2017, at 8:11 AM, Jeff Dinkins wrote: > > I hereby propose the creation of Project Duke, with myself as the > Lead and the Core Libraries and Web groups as sponsoring groups. Vote: yes Comment: I offer whatever JVMLS graphic files we have as contributions. From stuart.marks at oracle.com Thu Apr 6 21:20:09 2017 From: stuart.marks at oracle.com (Stuart Marks) Date: Thu, 6 Apr 2017 14:20:09 -0700 Subject: CFV: New Project: Project Duke In-Reply-To: <9CE42887-B17C-493A-A9B8-7BB963A83F39@oracle.com> References: <8650fd47-8738-42ef-b285-bc5284b0ee5b@default> <9CE42887-B17C-493A-A9B8-7BB963A83F39@oracle.com> Message-ID: <814c4253-9c88-0ed1-5b21-8e18c270e92e@oracle.com> Vote: yes On 4/6/17 8:11 AM, Jeff Dinkins wrote: > > I hereby propose the creation of Project Duke, with myself as the > Lead and the Core Libraries and Web groups as sponsoring groups. > > In accordance with the OpenJDK guidelines [1], this project will > provide a location for Duke graphics to reside. Duke is the Java > mascot, which was open sourced by Sun on November 13th 2006. > > About the Lead: Jeff Dinkins (OpenJDK username: jeff) is a JDK 9 > Committer, and has had experinece drawing Duke for 15+ years. > > The initial Committers will be: > > * James Gosling > ? Jasper Potts > * Jeff Dinkins > > The project will host at least the following mailing list: > > * duke-dev for developers & aspiring graphics artists > > The initial ?source" of this project will be based on a clone of the > existing (but soon to disappear) repo on Kenai [2]. > > Votes are due by April 21st, 2017. > > Only current OpenJDK Members [3] are eligible to vote on this motion. > Votes must be cast in the open on the discuss list. Replying to this > message is sufficient if your mail program honors the Reply-To header. > > For Lazy Consensus voting instructions, see [4]. > > > [1] http://openjdk.java.net/projects/#new-project > > [2] https://duke.kenai.com > > [3] http://openjdk.java.net/census#members > > [4] http://openjdk.java.net/projects/#new-project-vote > From cthalinger at twitter.com Thu Apr 6 21:36:06 2017 From: cthalinger at twitter.com (Christian Thalinger) Date: Thu, 6 Apr 2017 11:36:06 -1000 Subject: CFV: New Project: Project Duke In-Reply-To: <9CE42887-B17C-493A-A9B8-7BB963A83F39@oracle.com> References: <8650fd47-8738-42ef-b285-bc5284b0ee5b@default> <9CE42887-B17C-493A-A9B8-7BB963A83F39@oracle.com> Message-ID: <579D32D2-097D-4BD6-A2B8-B40B692A63E6@twitter.com> Vote: yes > On Apr 6, 2017, at 5:11 AM, Jeff Dinkins wrote: > > > I hereby propose the creation of Project Duke, with myself as the > Lead and the Core Libraries and Web groups as sponsoring groups. > > In accordance with the OpenJDK guidelines [1], this project will > provide a location for Duke graphics to reside. Duke is the Java > mascot, which was open sourced by Sun on November 13th 2006. > > About the Lead: Jeff Dinkins (OpenJDK username: jeff) is a JDK 9 > Committer, and has had experinece drawing Duke for 15+ years. > > The initial Committers will be: > > * James Gosling > ? Jasper Potts > * Jeff Dinkins > > The project will host at least the following mailing list: > > * duke-dev for developers & aspiring graphics artists > > The initial ?source" of this project will be based on a clone of the > existing (but soon to disappear) repo on Kenai [2]. > > Votes are due by April 21st, 2017. > > Only current OpenJDK Members [3] are eligible to vote on this motion. > Votes must be cast in the open on the discuss list. Replying to this > message is sufficient if your mail program honors the Reply-To header. > > For Lazy Consensus voting instructions, see [4]. > > > [1] http://openjdk.java.net/projects/#new-project > > [2] https://duke.kenai.com > > [3] http://openjdk.java.net/census#members > > [4] http://openjdk.java.net/projects/#new-project-vote > From kellyohair at gmail.com Thu Apr 6 21:40:38 2017 From: kellyohair at gmail.com (Kelly O'Hair) Date: Thu, 6 Apr 2017 14:40:38 -0700 Subject: CFV: New Project: Project Duke In-Reply-To: <9CE42887-B17C-493A-A9B8-7BB963A83F39@oracle.com> References: <8650fd47-8738-42ef-b285-bc5284b0ee5b@default> <9CE42887-B17C-493A-A9B8-7BB963A83F39@oracle.com> Message-ID: <947940CB-D113-43B4-B542-1019F01B4F68@gmail.com> Vite: YES -kto > On Apr 6, 2017, at 8:11 AM, Jeff Dinkins wrote: > > > I hereby propose the creation of Project Duke, with myself as the > Lead and the Core Libraries and Web groups as sponsoring groups. > > In accordance with the OpenJDK guidelines [1], this project will > provide a location for Duke graphics to reside. Duke is the Java > mascot, which was open sourced by Sun on November 13th 2006. > > About the Lead: Jeff Dinkins (OpenJDK username: jeff) is a JDK 9 > Committer, and has had experinece drawing Duke for 15+ years. > > The initial Committers will be: > > * James Gosling > ? Jasper Potts > * Jeff Dinkins > > The project will host at least the following mailing list: > > * duke-dev for developers & aspiring graphics artists > > The initial ?source" of this project will be based on a clone of the > existing (but soon to disappear) repo on Kenai [2]. > > Votes are due by April 21st, 2017. > > Only current OpenJDK Members [3] are eligible to vote on this motion. > Votes must be cast in the open on the discuss list. Replying to this > message is sufficient if your mail program honors the Reply-To header. > > For Lazy Consensus voting instructions, see [4]. > > > [1] http://openjdk.java.net/projects/#new-project > > [2] https://duke.kenai.com > > [3] http://openjdk.java.net/census#members > > [4] http://openjdk.java.net/projects/#new-project-vote > From kellyohair at gmail.com Thu Apr 6 22:38:29 2017 From: kellyohair at gmail.com (Kelly O'Hair) Date: Thu, 6 Apr 2017 15:38:29 -0700 Subject: CFV: New Project: Project Duke In-Reply-To: <9CE42887-B17C-493A-A9B8-7BB963A83F39@oracle.com> References: <8650fd47-8738-42ef-b285-bc5284b0ee5b@default> <9CE42887-B17C-493A-A9B8-7BB963A83F39@oracle.com> Message-ID: Vote: YES -kto Been so long I forgot how to spell... :( > On Apr 6, 2017, at 8:11 AM, Jeff Dinkins wrote: > > > I hereby propose the creation of Project Duke, with myself as the > Lead and the Core Libraries and Web groups as sponsoring groups. > > In accordance with the OpenJDK guidelines [1], this project will > provide a location for Duke graphics to reside. Duke is the Java > mascot, which was open sourced by Sun on November 13th 2006. > > About the Lead: Jeff Dinkins (OpenJDK username: jeff) is a JDK 9 > Committer, and has had experinece drawing Duke for 15+ years. > > The initial Committers will be: > > * James Gosling > ? Jasper Potts > * Jeff Dinkins > > The project will host at least the following mailing list: > > * duke-dev for developers & aspiring graphics artists > > The initial ?source" of this project will be based on a clone of the > existing (but soon to disappear) repo on Kenai [2]. > > Votes are due by April 21st, 2017. > > Only current OpenJDK Members [3] are eligible to vote on this motion. > Votes must be cast in the open on the discuss list. Replying to this > message is sufficient if your mail program honors the Reply-To header. > > For Lazy Consensus voting instructions, see [4]. > > > [1] http://openjdk.java.net/projects/#new-project > > [2] https://duke.kenai.com > > [3] http://openjdk.java.net/census#members > > [4] http://openjdk.java.net/projects/#new-project-vote > From maurizio.cimadamore at oracle.com Fri Apr 7 00:02:22 2017 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Fri, 7 Apr 2017 01:02:22 +0100 Subject: CFV: New Project: Project Duke In-Reply-To: <9CE42887-B17C-493A-A9B8-7BB963A83F39@oracle.com> References: <8650fd47-8738-42ef-b285-bc5284b0ee5b@default> <9CE42887-B17C-493A-A9B8-7BB963A83F39@oracle.com> Message-ID: <0f88780e-03cc-3cbd-726b-0f84956060a9@oracle.com> Vote: yes! Maurizio On 06/04/17 16:11, Jeff Dinkins wrote: > I hereby propose the creation of Project Duke, with myself as the > Lead and the Core Libraries and Web groups as sponsoring groups. > > In accordance with the OpenJDK guidelines [1], this project will > provide a location for Duke graphics to reside. Duke is the Java > mascot, which was open sourced by Sun on November 13th 2006. > > About the Lead: Jeff Dinkins (OpenJDK username: jeff) is a JDK 9 > Committer, and has had experinece drawing Duke for 15+ years. > > The initial Committers will be: > > * James Gosling > ? Jasper Potts > * Jeff Dinkins > > The project will host at least the following mailing list: > > * duke-dev for developers & aspiring graphics artists > > The initial ?source" of this project will be based on a clone of the > existing (but soon to disappear) repo on Kenai [2]. > > Votes are due by April 21st, 2017. > > Only current OpenJDK Members [3] are eligible to vote on this motion. > Votes must be cast in the open on the discuss list. Replying to this > message is sufficient if your mail program honors the Reply-To header. > > For Lazy Consensus voting instructions, see [4]. > > > [1] http://openjdk.java.net/projects/#new-project > > [2] https://duke.kenai.com > > [3] http://openjdk.java.net/census#members > > [4] http://openjdk.java.net/projects/#new-project-vote > From ChrisPhi at LGonQn.Org Fri Apr 7 01:17:53 2017 From: ChrisPhi at LGonQn.Org ("Chris Phillips"@T O) Date: Thu, 6 Apr 2017 21:17:53 -0400 Subject: CFV: New Project: Project Duke In-Reply-To: <9CE42887-B17C-493A-A9B8-7BB963A83F39@oracle.com> References: <8650fd47-8738-42ef-b285-bc5284b0ee5b@default> <9CE42887-B17C-493A-A9B8-7BB963A83F39@oracle.com> Message-ID: <993184eb-bbab-f651-4513-14224a3e5c57@LGonQn.Org> Hi Vote: yes On 06/04/17 11:11 AM, Jeff Dinkins wrote: > I hereby propose the creation of Project Duke, with myself as the > Lead and the Core Libraries and Web groups as sponsoring groups. ChrisPhi From sean.mullan at oracle.com Fri Apr 7 14:56:16 2017 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 7 Apr 2017 10:56:16 -0400 Subject: CFV: New Project: Project Duke In-Reply-To: <9CE42887-B17C-493A-A9B8-7BB963A83F39@oracle.com> References: <8650fd47-8738-42ef-b285-bc5284b0ee5b@default> <9CE42887-B17C-493A-A9B8-7BB963A83F39@oracle.com> Message-ID: <8c61435a-b2cf-0adb-06cb-38a54298470e@oracle.com> Vote: yes From mandy.chung at oracle.com Fri Apr 7 15:41:24 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 7 Apr 2017 08:41:24 -0700 Subject: CFV: New Project: Project Duke In-Reply-To: <8c61435a-b2cf-0adb-06cb-38a54298470e@oracle.com> References: <8650fd47-8738-42ef-b285-bc5284b0ee5b@default> <9CE42887-B17C-493A-A9B8-7BB963A83F39@oracle.com> <8c61435a-b2cf-0adb-06cb-38a54298470e@oracle.com> Message-ID: Vote: yes Mandy From dalibor.topic at oracle.com Mon Apr 10 11:32:41 2017 From: dalibor.topic at oracle.com (dalibor topic) Date: Mon, 10 Apr 2017 13:32:41 +0200 Subject: CFV: New Project: Project Duke In-Reply-To: <9CE42887-B17C-493A-A9B8-7BB963A83F39@oracle.com> References: <8650fd47-8738-42ef-b285-bc5284b0ee5b@default> <9CE42887-B17C-493A-A9B8-7BB963A83F39@oracle.com> Message-ID: <7fb6ac84-d60e-740c-ae0c-fb5ec954e825@oracle.com> Vote: yes. -- Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile: +491737185961 ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher Oracle is committed to developing practices and products that help protect the environment From iris.clark at oracle.com Mon Apr 10 16:55:12 2017 From: iris.clark at oracle.com (Iris Clark) Date: Mon, 10 Apr 2017 09:55:12 -0700 (PDT) Subject: CFV: New Project: Project Duke In-Reply-To: <9CE42887-B17C-493A-A9B8-7BB963A83F39@oracle.com> References: <8650fd47-8738-42ef-b285-bc5284b0ee5b@default> <9CE42887-B17C-493A-A9B8-7BB963A83F39@oracle.com> Message-ID: <7d8fb08e-18da-4be1-9941-26c1b5027cdb@default> Vote: yes Iris From michael.x.mcmahon at oracle.com Mon Apr 10 17:49:31 2017 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Mon, 10 Apr 2017 18:49:31 +0100 Subject: CFV: New Project: Project Duke In-Reply-To: <9CE42887-B17C-493A-A9B8-7BB963A83F39@oracle.com> References: <8650fd47-8738-42ef-b285-bc5284b0ee5b@default> <9CE42887-B17C-493A-A9B8-7BB963A83F39@oracle.com> Message-ID: <58EBC5AB.60004@oracle.com> Vote: yes - Michael From chris.hegarty at oracle.com Mon Apr 10 18:08:59 2017 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 10 Apr 2017 19:08:59 +0100 Subject: CFV: New Project: Project Duke In-Reply-To: <58EBC5AB.60004@oracle.com> References: <8650fd47-8738-42ef-b285-bc5284b0ee5b@default> <9CE42887-B17C-493A-A9B8-7BB963A83F39@oracle.com> <58EBC5AB.60004@oracle.com> Message-ID: <85A2340C-E7FC-4490-AFED-55721E15C59C@oracle.com> Vote: YES -Chris. From bradford.wetmore at oracle.com Mon Apr 10 21:08:29 2017 From: bradford.wetmore at oracle.com (Brad R. Wetmore) Date: Mon, 10 Apr 2017 14:08:29 -0700 Subject: CFV: New Project: Project Duke In-Reply-To: <9CE42887-B17C-493A-A9B8-7BB963A83F39@oracle.com> References: <8650fd47-8738-42ef-b285-bc5284b0ee5b@default> <9CE42887-B17C-493A-A9B8-7BB963A83F39@oracle.com> Message-ID: Vote: Yes. Brad On 4/6/2017 8:11 AM, Jeff Dinkins wrote: > > I hereby propose the creation of Project Duke, with myself as the > Lead and the Core Libraries and Web groups as sponsoring groups. > > In accordance with the OpenJDK guidelines [1], this project will > provide a location for Duke graphics to reside. Duke is the Java > mascot, which was open sourced by Sun on November 13th 2006. > > About the Lead: Jeff Dinkins (OpenJDK username: jeff) is a JDK 9 > Committer, and has had experinece drawing Duke for 15+ years. > > The initial Committers will be: > > * James Gosling > ? Jasper Potts > * Jeff Dinkins > > The project will host at least the following mailing list: > > * duke-dev for developers & aspiring graphics artists > > The initial ?source" of this project will be based on a clone of the > existing (but soon to disappear) repo on Kenai [2]. > > Votes are due by April 21st, 2017. > > Only current OpenJDK Members [3] are eligible to vote on this motion. > Votes must be cast in the open on the discuss list. Replying to this > message is sufficient if your mail program honors the Reply-To header. > > For Lazy Consensus voting instructions, see [4]. > > > [1] http://openjdk.java.net/projects/#new-project > > [2] https://duke.kenai.com > > [3] http://openjdk.java.net/census#members > > [4] http://openjdk.java.net/projects/#new-project-vote > From weijun.wang at oracle.com Tue Apr 11 02:42:53 2017 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 11 Apr 2017 10:42:53 +0800 Subject: CFV: New Project: Project Duke In-Reply-To: <9CE42887-B17C-493A-A9B8-7BB963A83F39@oracle.com> References: <8650fd47-8738-42ef-b285-bc5284b0ee5b@default> <9CE42887-B17C-493A-A9B8-7BB963A83F39@oracle.com> Message-ID: <962b4599-3ba3-a08b-c475-7074089a42ba@oracle.com> Vote: yes --Weijun On 04/06/2017 11:11 PM, Jeff Dinkins wrote: > > I hereby propose the creation of Project Duke, with myself as the > Lead and the Core Libraries and Web groups as sponsoring groups. > From laurent.daynes at oracle.com Tue Apr 11 07:00:21 2017 From: laurent.daynes at oracle.com (Laurent Daynes) Date: Tue, 11 Apr 2017 09:00:21 +0200 Subject: CFV: New Project: Project Duke In-Reply-To: References: <8650fd47-8738-42ef-b285-bc5284b0ee5b@default> <9CE42887-B17C-493A-A9B8-7BB963A83F39@oracle.com> Message-ID: <58EC7F05.8000702@oracle.com> Vote:yes On 4/6/2017 8:11 AM, Jeff Dinkins wrote: I hereby propose the creation of Project Duke, with myself as the Lead and the Core Libraries and Web groups as sponsoring groups. From magnus.ihse.bursie at oracle.com Tue Apr 11 08:58:28 2017 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 11 Apr 2017 10:58:28 +0200 Subject: CFV: New Project: Project Duke In-Reply-To: <9CE42887-B17C-493A-A9B8-7BB963A83F39@oracle.com> References: <8650fd47-8738-42ef-b285-bc5284b0ee5b@default> <9CE42887-B17C-493A-A9B8-7BB963A83F39@oracle.com> Message-ID: <48b45eb0-9dec-b58d-478b-bd98748408d3@oracle.com> Vote: yes /Magnus On 2017-04-06 17:11, Jeff Dinkins wrote: > I hereby propose the creation of Project Duke, with myself as the > Lead and the Core Libraries and Web groups as sponsoring groups. > > In accordance with the OpenJDK guidelines [1], this project will > provide a location for Duke graphics to reside. Duke is the Java > mascot, which was open sourced by Sun on November 13th 2006. > > About the Lead: Jeff Dinkins (OpenJDK username: jeff) is a JDK 9 > Committer, and has had experinece drawing Duke for 15+ years. > > The initial Committers will be: > > * James Gosling > ? Jasper Potts > * Jeff Dinkins > > The project will host at least the following mailing list: > > * duke-dev for developers & aspiring graphics artists > > The initial ?source" of this project will be based on a clone of the > existing (but soon to disappear) repo on Kenai [2]. > > Votes are due by April 21st, 2017. > > Only current OpenJDK Members [3] are eligible to vote on this motion. > Votes must be cast in the open on the discuss list. Replying to this > message is sufficient if your mail program honors the Reply-To header. > > For Lazy Consensus voting instructions, see [4]. > > > [1] http://openjdk.java.net/projects/#new-project > > [2] https://duke.kenai.com > > [3] http://openjdk.java.net/census#members > > [4] http://openjdk.java.net/projects/#new-project-vote > From iris.clark at oracle.com Tue Apr 11 20:38:47 2017 From: iris.clark at oracle.com (Iris Clark) Date: Tue, 11 Apr 2017 13:38:47 -0700 (PDT) Subject: Client Libraries Group consolidation proposal Message-ID: Hi. Since no objections were raised when the affected Groups were consulted [0-3], I'd like to solicit final comments on the creation of the Client Libraries Group with Phil Race as the Lead. The Client Libraries Group is the consolidation of the members and interests of the existing AWT [4], 2D [5], Swing [6], and Sound [7] Groups. These individual Groups were created at the 2007 launch of OpenJDK partially following the organizational structure of Sun's existing development groups, which partially followed the separate nature of each of these areas. At least one Group (Sound), has always been too narrow an area to Attract sufficient interest to justify a Group but it became one since it didn't obviously belong to another Group. While individual Group members continue to focus in their specialization area, there has been an increasing overlap in code responsibilities and the individuals working on them. Some of this became apparent in the OSX port as AWT members operated as de facto members of Swing and so forth. Unifying these Groups will more realistically reflect the actual community and make it more apparent where sub-areas such as sound, beans, and accessibility should be discussed. The new Group will sponsor the OpenJFX [8], XRender Pipeline [9], and Harfbuzz [10] Projects. Over time the Group's mailing lists, static web pages, etc. will be coalesced at the discretion of the Lead. Phil is the OpenJDK Group Lead for the 2D and Sound Groups. He has been a member of the Java 2D graphics team on JDK since 1999 and has contributed hundreds, if not thousands, of changesets to client code over that period. Phil is the specification lead for JSR 15 Image I/O Framework Specification and JSR 6 Unified Printing API. The proposed set of initial Members is the union of the Members of the 2D, AWT, Swing, and Sound Groups. If there are no objections to this Group consolidation by Tuesday 18 April, the OpenJDK Lead will simultaneously ask the Governing Board to create the new Group and dissolve the AWT, 2D, Swing, and Sound Groups as described in the Bylaws [11]. The long-inactive Framebuffer Toolkit Project [12] will be dissolved by virtue of losing its sponsoring Group. Thanks, Iris [0]: http://mail.openjdk.java.net/pipermail/awt-dev/2015-February/008950.html [1]: http://mail.openjdk.java.net/pipermail/2d-dev/2015-February/005074.html [2]: http://mail.openjdk.java.net/pipermail/swing-dev/2015-February/004193.html [3]: http://mail.openjdk.java.net/pipermail/sound-dev/2015-February/000260.html [4]: http://openjdk.java.net/census#awt [5]: http://openjdk.java.net/census#2d [6]: http://openjdk.java.net/census#swing [7]: http://openjdk.java.net/census#sound [8]: http://openjdk.java.net/census#openjfx [9]: http://openjdk.java.net/census#xrender [10]: http://openjdk.java.net/census#harfbuzz [11]: http://openjdk.java.net/bylaws#_4 [12]: http://openjdk.java.net/census#fbtoolkit From zen at freedbms.net Thu Apr 13 13:26:51 2017 From: zen at freedbms.net (Zenaan Harkness) Date: Thu, 13 Apr 2017 23:26:51 +1000 Subject: CodePointCursor + CodePointParser (was Re: string indexing (was: Java needs an immutable byte array wrapper)) In-Reply-To: <20161113122148.GA5258@x220-a02> References: <1478970277.2649.3.camel@kennke.org> <20161113122148.GA5258@x220-a02> Message-ID: <20170413132651.GA18779@x220-a02> On Sun, Nov 13, 2016 at 11:21:48PM +1100, Zenaan Harkness wrote: > https://zenaan.github.io/zen/javadoc/zen/lang/string.html > (Note, this was pre-Java 9) > > Hopefully by Java 10, 11 or 12, we might see full grapheme support in > Java (as is the case in Swift), now that String is implemented with byte > array storage. Further: https://github.com/zenaan/zen https://github.com/zenaan/zen/blob/master/src/java/zen/lang/CodePointCursor.java https://github.com/zenaan/zen/blob/master/src/java/zen/lang/CodePointParser.java A small step for anyone who prefers to work with Unicode code points rather than Java String's "code units": * CodePointCursor.java: - complete and straightforward to use Unicode code point cursor (or "iterator") - resettable - and optionally reversable when reset (or at construction) - bidirectional - can move forwards and backwards - supports hops of >1 , in either direction - supports (default constructor) creation of default "null" cursor - provides methods for both inclusive and exclusive indexes - provides methods for both code point indexes, and underlying code unit indexes - supports traditional Java hasNext() and next() idiom - supports also peek(), advance(), curr() and prev() idioms - outputs a useful string representation of itself * CodePointParser.java: - limited parser exercising CodePointCursor - parses string and unsigned long - no overflow checking - supports optional literals escape char - traditional parsing model - pretty step-wise output messages/ parse analysis This parser is very simple as seen, but the two functions are well tested fwiw. Now the next layer above code points is graphemes, "grapheme clusters" as I think Swift calls them, or "code point clusters" or "codepoint clusters" as they ought rightfully be called. That looks like a big job, unlike a simple code point cursor and parser. Now ideally we would be starting with and building upon, UTF-8 strings, not 16-bit "code unit strings", but that's for another day... or year :/ Also have not yet checked out IBM's ICU4J yet... Any feedback, positive or negative, appreciated. Regards, Zenaan ---------- # Method signatures (CP = code point, CU = code unit) : public class CodePointCursor implements IDEBUG { public CodePointCursor () {} public CodePointCursor (String s) {this(s, false);} public CodePointCursor (String s, boolean reverse) public CodePointCursor reset (boolean reverse) public void setDebug (boolean debug) {this._debug = debug;} public int getCPLen () public int getCPIdxIn () public int getCPIdxEx () public int getCUIdxEx () public boolean hasNext () {return i != iend;} // | hasNext(1) public boolean hasNext (int n) public int peekIdx () throws IndexOutOfBoundsException public int peekIdx (int n) throws IndexOutOfBoundsException public int advance () throws IndexOutOfBoundsException public int advance (int n) throws IndexOutOfBoundsException public int peek () public int peek (int n) public int next () public int next (int n) public int curr () public int prev () public String toString () { public class CodePointParser implements IDEBUG { public CodePointParser (CodePointCursor i) {this.i = i;} public class CPParserException extends RuntimeException { public void setEscape (int escapecp) { public boolean hasEscape () {return lescape != 0;} public String toString () { public int parseString (StringBuilder result, int end_char) public int parseString (StringBuilder result, int end_char1, int end_char2) public static final int CURSOR_END = -1; public static final int ESCAPE_AT_END = -2; public int parseString (StringBuilder result, int end_char1, int end_char2, Messages m) public static class Messages { public String noDigit = " "; public String endChar = " "; public String atEnd = " "; public String escape = " "; public String literal = " "; public String pushBack = " "; public long parseULong (long defaultVal) public long parseULong (long defaultVal, int base, Messages m) From p.tommaso at gmail.com Thu Apr 20 23:11:11 2017 From: p.tommaso at gmail.com (Tommaso Pasini) Date: Fri, 21 Apr 2017 01:11:11 +0200 Subject: hi guys Message-ID: Hi guys, I'm Tommaso and I'm glad to be here. I'm a java user since 7 years by then, and so I thought it was the moment to start contributing in its development. I Would really like to actively partecipate in JDK-10 development and so I'd like to ask you if you have any suggestion and if you can explain how can I do (I mean, should I just clone mercurial repos and start looking around for something to fix or to improve or is there something else??) Thanks again and have a good day/night depending on your time zone Tommaso Pasini From martijnverburg at gmail.com Fri Apr 21 09:14:58 2017 From: martijnverburg at gmail.com (Martijn Verburg) Date: Fri, 21 Apr 2017 10:14:58 +0100 Subject: hi guys In-Reply-To: References: Message-ID: Hi Tommaso, Welcome to OpenJDK! Please see the Contribution Guide on how to get started and you can ask all of your "I'm new here" questions over at the Adoption Group and its subsequent mailing list . Cheers, Martijn On 21 April 2017 at 00:11, Tommaso Pasini wrote: > Hi guys, I'm Tommaso and I'm glad to be here. I'm a java user since 7 years > by then, and so I thought it was the moment to start contributing in its > development. I Would really like to actively partecipate in JDK-10 > development and so I'd like to ask you if you have any suggestion and if > you can explain how can I do (I mean, should I just clone mercurial repos > and start looking around for something to fix or to improve or is there > something else??) > > Thanks again and have a good day/night depending on your time zone > > Tommaso Pasini > From p.tommaso at gmail.com Fri Apr 21 09:36:14 2017 From: p.tommaso at gmail.com (Tommaso Pasini) Date: Fri, 21 Apr 2017 09:36:14 +0000 Subject: hi guys In-Reply-To: References: Message-ID: Great, thanks! Il giorno ven 21 apr 2017 alle 11:15 Martijn Verburg < martijnverburg at gmail.com> ha scritto: > Hi Tommaso, > > Welcome to OpenJDK! Please see the Contribution Guide > on how to get started and you can > ask all of your "I'm new here" questions over at the Adoption Group > and its subsequent mailing list > . > > Cheers, > Martijn > > On 21 April 2017 at 00:11, Tommaso Pasini wrote: > >> Hi guys, I'm Tommaso and I'm glad to be here. I'm a java user since 7 >> years >> by then, and so I thought it was the moment to start contributing in its >> development. I Would really like to actively partecipate in JDK-10 >> development and so I'd like to ask you if you have any suggestion and if >> you can explain how can I do (I mean, should I just clone mercurial repos >> and start looking around for something to fix or to improve or is there >> something else??) >> >> Thanks again and have a good day/night depending on your time zone >> >> Tommaso Pasini >> > > -- Tommaso Pasini, Ph.D. Dipartimento di Informatica Sapienza Universit? di Roma via Salaria 113, 00196 Rome, Italy Homepage: http://www.tommasopasini.altervista.org/ From karthik.ganesan at oracle.com Fri Apr 21 18:28:24 2017 From: karthik.ganesan at oracle.com (Karthik Ganesan) Date: Fri, 21 Apr 2017 13:28:24 -0500 Subject: CFV: Project Trinity Message-ID: <19997aa6-aad8-da42-bdf0-3dd5f39e7d48@oracle.com> Hi, I would like to propose the creation of a new Project: Project Trinity with myself as the Lead and the Core Libraries Group as the Sponsoring Group. This Project would explore enhanced execution of bulk aggregate calculations over Streams through offloading calculations to hardware accelerators. Streams allow developers to express calculations such that data parallelism can be efficiently exploited. Such calculations are prime candidates for leveraging enhanced data-oriented instructions on CPUs (such as SIMD instructions) or offloading to hardware accelerators (such as the SPARC Data Accelerator co-processor, further referred to as DAX [1]). To identify a path to improving performance and power efficiency, Project Trinity will explore how libraries like Streams can be enhanced to leverage data processing hardware features to execute Streams more efficiently [2]. Directions for exploration include: - Building a streams-like library optimized for offload to -- hardware accelerators (such as DAX), or -- a GPU, or -- SIMD instructions; - Optimizations in the Graal compiler to automatically transform suitable Streams pipelines, taking advantage of data processing hardware features; - Explorations with Project Valhalla to expand the range of effective acceleration to Streams of value types. Success will be evaluated based upon: (1) speedups and resource efficiency gains achieved for a broad range of representative streams calculations under offload, (2) ease of use of the hardware acceleration capability, and (3) ensuring that there is no time or space overhead for non-accelerated calculations. The project will host at least the following mailing list: - trinity-dev for development discussions and user feedback - trinity-design for design and specification discussions About the Lead: Karthik Ganesan works for Oracle in the Performance and Applications Engineering group with more than 5 years of experience in Java/Hotspot performance projects [3]. The initial Reviewers and Committers will be: * Ahmed Khawaja * Karthik Ganesan * Malcolm Kavalsky * Shrinivas Joshi Votes are due by May 4, 2017. Only current OpenJDK Members [4] are eligible to vote on this motion. Votes must be cast in the open on the discuss list. Replying to this message is sufficient if your mail program honors the Reply-To header. For Lazy Consensus voting instructions, see [5]. Karthik Ganesan [1] https://community.oracle.com/docs/DOC-994842 [2] https://bugs.openjdk.java.net/browse/JDK-8150304 [3] Karthik Ganesan, Yao-Min Chen and X Pan, ?Scaling Java Virtual Machine on a Many-core System? at 14th International Symposium on Integrated Circuits (ISIC 2014) [4] http://openjdk.java.net/census#members [5] http://openjdk.java.net/projects/#new-project-vote From paul.sandoz at oracle.com Fri Apr 21 20:19:02 2017 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 21 Apr 2017 13:19:02 -0700 Subject: CFV: Project Trinity In-Reply-To: <19997aa6-aad8-da42-bdf0-3dd5f39e7d48@oracle.com> References: <19997aa6-aad8-da42-bdf0-3dd5f39e7d48@oracle.com> Message-ID: Hi Karthik, Along with Valhalla i strongly encourage you to also consider explorations with Project Panama, especially with regards to Intel?s Vector API work (under the Panama remit) and how to surface that at a higher DSL-like level. Paul. > On 21 Apr 2017, at 11:28, Karthik Ganesan wrote: > > Hi, > > I would like to propose the creation of a new Project: > Project Trinity with myself as the Lead and the Core > Libraries Group as the Sponsoring Group. > > This Project would explore enhanced execution of bulk > aggregate calculations over Streams through offloading > calculations to hardware accelerators. > > Streams allow developers to express calculations such > that data parallelism can be efficiently exploited. Such > calculations are prime candidates for leveraging enhanced > data-oriented instructions on CPUs (such as SIMD > instructions) or offloading to hardware accelerators > (such as the SPARC Data Accelerator co-processor, further > referred to as DAX [1]). > > To identify a path to improving performance and power > efficiency, Project Trinity will explore how libraries > like Streams can be enhanced to leverage data processing > hardware features to execute Streams more efficiently [2]. > > Directions for exploration include: > - Building a streams-like library optimized for offload to > -- hardware accelerators (such as DAX), or > -- a GPU, or > -- SIMD instructions; > - Optimizations in the Graal compiler to automatically > transform suitable Streams pipelines, taking advantage > of data processing hardware features; > - Explorations with Project Valhalla to expand the > range of effective acceleration to Streams of value types. > > Success will be evaluated based upon: > (1) speedups and resource efficiency gains achieved for a > broad range of representative streams calculations under > offload, > (2) ease of use of the hardware acceleration capability, and > (3) ensuring that there is no time or space overhead for > non-accelerated calculations. > > The project will host at least the following mailing list: > - trinity-dev for development discussions and user feedback > - trinity-design for design and specification discussions > > About the Lead: > Karthik Ganesan works for Oracle in the Performance and > Applications Engineering group with more than 5 years of > experience in Java/Hotspot performance projects [3]. > > The initial Reviewers and Committers will be: > * Ahmed Khawaja > * Karthik Ganesan > * Malcolm Kavalsky > * Shrinivas Joshi > > Votes are due by May 4, 2017. > > Only current OpenJDK Members [4] are eligible to vote on this > motion. Votes must be cast in the open on the discuss list. > Replying to this message is sufficient if your mail program > honors the Reply-To header. > > For Lazy Consensus voting instructions, see [5]. > > Karthik Ganesan > > [1] https://community.oracle.com/docs/DOC-994842 > [2] https://bugs.openjdk.java.net/browse/JDK-8150304 > [3] Karthik Ganesan, Yao-Min Chen and X Pan, ?Scaling > Java Virtual Machine on a Many-core System? at 14th > International Symposium on Integrated Circuits (ISIC 2014) > [4] http://openjdk.java.net/census#members > [5] http://openjdk.java.net/projects/#new-project-vote > > From cthalinger at twitter.com Fri Apr 21 20:18:58 2017 From: cthalinger at twitter.com (Christian Thalinger) Date: Fri, 21 Apr 2017 10:18:58 -1000 Subject: CFV: Project Trinity In-Reply-To: <19997aa6-aad8-da42-bdf0-3dd5f39e7d48@oracle.com> References: <19997aa6-aad8-da42-bdf0-3dd5f39e7d48@oracle.com> Message-ID: <78B4997B-9889-4991-B1A6-D54455A90F33@twitter.com> Why can?t we use Project Sumatra[1] for this? [1] http://openjdk.java.net/projects/sumatra/ > On Apr 21, 2017, at 8:28 AM, Karthik Ganesan wrote: > > Hi, > > I would like to propose the creation of a new Project: > Project Trinity with myself as the Lead and the Core > Libraries Group as the Sponsoring Group. > > This Project would explore enhanced execution of bulk > aggregate calculations over Streams through offloading > calculations to hardware accelerators. > > Streams allow developers to express calculations such > that data parallelism can be efficiently exploited. Such > calculations are prime candidates for leveraging enhanced > data-oriented instructions on CPUs (such as SIMD > instructions) or offloading to hardware accelerators > (such as the SPARC Data Accelerator co-processor, further > referred to as DAX [1]). > > To identify a path to improving performance and power > efficiency, Project Trinity will explore how libraries > like Streams can be enhanced to leverage data processing > hardware features to execute Streams more efficiently [2]. > > Directions for exploration include: > - Building a streams-like library optimized for offload to > -- hardware accelerators (such as DAX), or > -- a GPU, or > -- SIMD instructions; > - Optimizations in the Graal compiler to automatically > transform suitable Streams pipelines, taking advantage > of data processing hardware features; > - Explorations with Project Valhalla to expand the > range of effective acceleration to Streams of value types. > > Success will be evaluated based upon: > (1) speedups and resource efficiency gains achieved for a > broad range of representative streams calculations under > offload, > (2) ease of use of the hardware acceleration capability, and > (3) ensuring that there is no time or space overhead for > non-accelerated calculations. > > The project will host at least the following mailing list: > - trinity-dev for development discussions and user feedback > - trinity-design for design and specification discussions > > About the Lead: > Karthik Ganesan works for Oracle in the Performance and > Applications Engineering group with more than 5 years of > experience in Java/Hotspot performance projects [3]. > > The initial Reviewers and Committers will be: > * Ahmed Khawaja > * Karthik Ganesan > * Malcolm Kavalsky > * Shrinivas Joshi > > Votes are due by May 4, 2017. > > Only current OpenJDK Members [4] are eligible to vote on this > motion. Votes must be cast in the open on the discuss list. > Replying to this message is sufficient if your mail program > honors the Reply-To header. > > For Lazy Consensus voting instructions, see [5]. > > Karthik Ganesan > > [1] https://community.oracle.com/docs/DOC-994842 > [2] https://bugs.openjdk.java.net/browse/JDK-8150304 > [3] Karthik Ganesan, Yao-Min Chen and X Pan, ?Scaling > Java Virtual Machine on a Many-core System? at 14th > International Symposium on Integrated Circuits (ISIC 2014) > [4] http://openjdk.java.net/census#members > [5] http://openjdk.java.net/projects/#new-project-vote > > From karthik.ganesan at oracle.com Fri Apr 21 21:41:28 2017 From: karthik.ganesan at oracle.com (Karthik Ganesan) Date: Fri, 21 Apr 2017 16:41:28 -0500 Subject: CFV: Project Trinity In-Reply-To: <78B4997B-9889-4991-B1A6-D54455A90F33@twitter.com> References: <19997aa6-aad8-da42-bdf0-3dd5f39e7d48@oracle.com> <78B4997B-9889-4991-B1A6-D54455A90F33@twitter.com> Message-ID: <81066cc5-0b0a-3345-4d63-87a9bc4a2909@oracle.com> Hi Christian, Thanks for your interest. This question was brought up previously in the discussion email thread for this project: Project Sumatra was aimed at translation of Java byte code to execute on GPU, which was an ambitious goal and a challenging task to take up. In this project, we aim to come up with APIs targeting the most common Analytics operations that can be readily offloaded to accelerators transparently. Most of the information needed for offload to the accelerator is expected to be readily provided by the API semantics and there by, simplifying the need to do tedious byte code analysis. Thanks, Karthik On 4/21/2017 3:18 PM, Christian Thalinger wrote: > Why can?t we use Project Sumatra[1] for this? > > [1] http://openjdk.java.net/projects/sumatra/ > >> On Apr 21, 2017, at 8:28 AM, Karthik Ganesan wrote: >> >> Hi, >> >> I would like to propose the creation of a new Project: >> Project Trinity with myself as the Lead and the Core >> Libraries Group as the Sponsoring Group. >> >> This Project would explore enhanced execution of bulk >> aggregate calculations over Streams through offloading >> calculations to hardware accelerators. >> >> Streams allow developers to express calculations such >> that data parallelism can be efficiently exploited. Such >> calculations are prime candidates for leveraging enhanced >> data-oriented instructions on CPUs (such as SIMD >> instructions) or offloading to hardware accelerators >> (such as the SPARC Data Accelerator co-processor, further >> referred to as DAX [1]). >> >> To identify a path to improving performance and power >> efficiency, Project Trinity will explore how libraries >> like Streams can be enhanced to leverage data processing >> hardware features to execute Streams more efficiently [2]. >> >> Directions for exploration include: >> - Building a streams-like library optimized for offload to >> -- hardware accelerators (such as DAX), or >> -- a GPU, or >> -- SIMD instructions; >> - Optimizations in the Graal compiler to automatically >> transform suitable Streams pipelines, taking advantage >> of data processing hardware features; >> - Explorations with Project Valhalla to expand the >> range of effective acceleration to Streams of value types. >> >> Success will be evaluated based upon: >> (1) speedups and resource efficiency gains achieved for a >> broad range of representative streams calculations under >> offload, >> (2) ease of use of the hardware acceleration capability, and >> (3) ensuring that there is no time or space overhead for >> non-accelerated calculations. >> >> The project will host at least the following mailing list: >> - trinity-dev for development discussions and user feedback >> - trinity-design for design and specification discussions >> >> About the Lead: >> Karthik Ganesan works for Oracle in the Performance and >> Applications Engineering group with more than 5 years of >> experience in Java/Hotspot performance projects [3]. >> >> The initial Reviewers and Committers will be: >> * Ahmed Khawaja >> * Karthik Ganesan >> * Malcolm Kavalsky >> * Shrinivas Joshi >> >> Votes are due by May 4, 2017. >> >> Only current OpenJDK Members [4] are eligible to vote on this >> motion. Votes must be cast in the open on the discuss list. >> Replying to this message is sufficient if your mail program >> honors the Reply-To header. >> >> For Lazy Consensus voting instructions, see [5]. >> >> Karthik Ganesan >> >> [1] https://community.oracle.com/docs/DOC-994842 >> [2] https://bugs.openjdk.java.net/browse/JDK-8150304 >> [3] Karthik Ganesan, Yao-Min Chen and X Pan, ?Scaling >> Java Virtual Machine on a Many-core System? at 14th >> International Symposium on Integrated Circuits (ISIC 2014) >> [4] http://openjdk.java.net/census#members >> [5] http://openjdk.java.net/projects/#new-project-vote >> >> From cthalinger at twitter.com Fri Apr 21 21:54:14 2017 From: cthalinger at twitter.com (Christian Thalinger) Date: Fri, 21 Apr 2017 11:54:14 -1000 Subject: CFV: Project Trinity In-Reply-To: <81066cc5-0b0a-3345-4d63-87a9bc4a2909@oracle.com> References: <19997aa6-aad8-da42-bdf0-3dd5f39e7d48@oracle.com> <78B4997B-9889-4991-B1A6-D54455A90F33@twitter.com> <81066cc5-0b0a-3345-4d63-87a9bc4a2909@oracle.com> Message-ID: > On Apr 21, 2017, at 11:41 AM, Karthik Ganesan wrote: > > Hi Christian, > > Thanks for your interest. This question was brought up previously in the discussion email thread for this project: > > Project Sumatra was aimed at translation of Java byte code to execute on > GPU, which was an ambitious goal and a challenging task to take up. In this > project, we aim to come up with APIs targeting the most common Analytics > operations that can be readily offloaded to accelerators transparently. Most > of the information needed for offload to the accelerator is expected to be > readily provided by the API semantics and there by, simplifying the need to > do tedious byte code analysis. I disagree. The first paragraph on the Sumatra project page says: "This primary goal of this project is to enable Java applications to take advantage of graphics processing units (GPUs) and accelerated processing units (APUs)--whether they are discrete devices or integrated with a CPU--to improve performance.? while you state: "This Project would explore enhanced execution of bulk aggregate calculations over Streams through offloading calculations to hardware accelerators.? It?s the same thing. I just don?t see the need to spin up yet-another OpenJDK project that aims at the same goal. > > Thanks, > Karthik > On 4/21/2017 3:18 PM, Christian Thalinger wrote: >> Why can?t we use Project Sumatra[1] for this? >> >> [1] http://openjdk.java.net/projects/sumatra/ >> >>> On Apr 21, 2017, at 8:28 AM, Karthik Ganesan wrote: >>> >>> Hi, >>> >>> I would like to propose the creation of a new Project: >>> Project Trinity with myself as the Lead and the Core >>> Libraries Group as the Sponsoring Group. >>> >>> This Project would explore enhanced execution of bulk >>> aggregate calculations over Streams through offloading >>> calculations to hardware accelerators. >>> >>> Streams allow developers to express calculations such >>> that data parallelism can be efficiently exploited. Such >>> calculations are prime candidates for leveraging enhanced >>> data-oriented instructions on CPUs (such as SIMD >>> instructions) or offloading to hardware accelerators >>> (such as the SPARC Data Accelerator co-processor, further >>> referred to as DAX [1]). >>> >>> To identify a path to improving performance and power >>> efficiency, Project Trinity will explore how libraries >>> like Streams can be enhanced to leverage data processing >>> hardware features to execute Streams more efficiently [2]. >>> >>> Directions for exploration include: >>> - Building a streams-like library optimized for offload to >>> -- hardware accelerators (such as DAX), or >>> -- a GPU, or >>> -- SIMD instructions; >>> - Optimizations in the Graal compiler to automatically >>> transform suitable Streams pipelines, taking advantage >>> of data processing hardware features; >>> - Explorations with Project Valhalla to expand the >>> range of effective acceleration to Streams of value types. >>> >>> Success will be evaluated based upon: >>> (1) speedups and resource efficiency gains achieved for a >>> broad range of representative streams calculations under >>> offload, >>> (2) ease of use of the hardware acceleration capability, and >>> (3) ensuring that there is no time or space overhead for >>> non-accelerated calculations. >>> >>> The project will host at least the following mailing list: >>> - trinity-dev for development discussions and user feedback >>> - trinity-design for design and specification discussions >>> >>> About the Lead: >>> Karthik Ganesan works for Oracle in the Performance and >>> Applications Engineering group with more than 5 years of >>> experience in Java/Hotspot performance projects [3]. >>> >>> The initial Reviewers and Committers will be: >>> * Ahmed Khawaja >>> * Karthik Ganesan >>> * Malcolm Kavalsky >>> * Shrinivas Joshi >>> >>> Votes are due by May 4, 2017. >>> >>> Only current OpenJDK Members [4] are eligible to vote on this >>> motion. Votes must be cast in the open on the discuss list. >>> Replying to this message is sufficient if your mail program >>> honors the Reply-To header. >>> >>> For Lazy Consensus voting instructions, see [5]. >>> >>> Karthik Ganesan >>> >>> [1] https://community.oracle.com/docs/DOC-994842 >>> [2] https://bugs.openjdk.java.net/browse/JDK-8150304 >>> [3] Karthik Ganesan, Yao-Min Chen and X Pan, ?Scaling >>> Java Virtual Machine on a Many-core System? at 14th >>> International Symposium on Integrated Circuits (ISIC 2014) >>> [4] http://openjdk.java.net/census#members >>> [5] http://openjdk.java.net/projects/#new-project-vote >>> >>> > From doug.simon at oracle.com Sun Apr 23 11:39:11 2017 From: doug.simon at oracle.com (Doug Simon) Date: Sun, 23 Apr 2017 13:39:11 +0200 Subject: CFV: Project Trinity In-Reply-To: References: <19997aa6-aad8-da42-bdf0-3dd5f39e7d48@oracle.com> <78B4997B-9889-4991-B1A6-D54455A90F33@twitter.com> <81066cc5-0b0a-3345-4d63-87a9bc4a2909@oracle.com> Message-ID: <0BEEDF0A-91F0-4640-8F95-D5513200B72F@oracle.com> > On 21 Apr 2017, at 23:54, Christian Thalinger wrote: > > >> On Apr 21, 2017, at 11:41 AM, Karthik Ganesan wrote: >> >> Hi Christian, >> >> Thanks for your interest. This question was brought up previously in the discussion email thread for this project: >> >> Project Sumatra was aimed at translation of Java byte code to execute on >> GPU, which was an ambitious goal and a challenging task to take up. In this >> project, we aim to come up with APIs targeting the most common Analytics >> operations that can be readily offloaded to accelerators transparently. Most >> of the information needed for offload to the accelerator is expected to be >> readily provided by the API semantics and there by, simplifying the need to >> do tedious byte code analysis. > > I disagree. The first paragraph on the Sumatra project page says: > > "This primary goal of this project is to enable Java applications to take advantage of graphics processing units (GPUs) and accelerated processing units (APUs)--whether they are discrete devices or integrated with a CPU--to improve performance.? > > while you state: > > "This Project would explore enhanced execution of bulk > aggregate calculations over Streams through offloading > calculations to hardware accelerators.? > > It?s the same thing. I just don?t see the need to spin up yet-another OpenJDK project that aims at the same goal. Maybe this is just a discrepancy between the officially stated aims. I understood Sumatra to be about *automatic* offloading work for existing APIs (such as the Streams API) to a GPU where as Trinity seems to be more about designing an explicit API for GPU offloading. -Doug From neugens.limasoftware at gmail.com Sun Apr 23 11:58:07 2017 From: neugens.limasoftware at gmail.com (Mario Torre) Date: Sun, 23 Apr 2017 11:58:07 +0000 Subject: CFV: Project Trinity In-Reply-To: <0BEEDF0A-91F0-4640-8F95-D5513200B72F@oracle.com> References: <19997aa6-aad8-da42-bdf0-3dd5f39e7d48@oracle.com> <78B4997B-9889-4991-B1A6-D54455A90F33@twitter.com> <81066cc5-0b0a-3345-4d63-87a9bc4a2909@oracle.com> <0BEEDF0A-91F0-4640-8F95-D5513200B72F@oracle.com> Message-ID: Ah, if that's the case it's interesting, and I would certainly vote for that. Cheers, Mario On Sun 23. Apr 2017 at 13:39, Doug Simon wrote: > > > On 21 Apr 2017, at 23:54, Christian Thalinger > wrote: > > > > > >> On Apr 21, 2017, at 11:41 AM, Karthik Ganesan < > karthik.ganesan at oracle.com> wrote: > >> > >> Hi Christian, > >> > >> Thanks for your interest. This question was brought up previously in > the discussion email thread for this project: > >> > >> Project Sumatra was aimed at translation of Java byte code to execute on > >> GPU, which was an ambitious goal and a challenging task to take up. In > this > >> project, we aim to come up with APIs targeting the most common Analytics > >> operations that can be readily offloaded to accelerators transparently. > Most > >> of the information needed for offload to the accelerator is expected to > be > >> readily provided by the API semantics and there by, simplifying the > need to > >> do tedious byte code analysis. > > > > I disagree. The first paragraph on the Sumatra project page says: > > > > "This primary goal of this project is to enable Java applications to > take advantage of graphics processing units (GPUs) and accelerated > processing units (APUs)--whether they are discrete devices or integrated > with a CPU--to improve performance.? > > > > while you state: > > > > "This Project would explore enhanced execution of bulk > > aggregate calculations over Streams through offloading > > calculations to hardware accelerators.? > > > > It?s the same thing. I just don?t see the need to spin up yet-another > OpenJDK project that aims at the same goal. > > Maybe this is just a discrepancy between the officially stated aims. I > understood Sumatra to be about *automatic* offloading work for existing > APIs (such as the Streams API) to a GPU where as Trinity seems to be more > about designing an explicit API for GPU offloading. > > -Doug From volker.simonis at gmail.com Mon Apr 24 08:50:45 2017 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 24 Apr 2017 10:50:45 +0200 Subject: CFV: Project Trinity In-Reply-To: <0BEEDF0A-91F0-4640-8F95-D5513200B72F@oracle.com> References: <19997aa6-aad8-da42-bdf0-3dd5f39e7d48@oracle.com> <78B4997B-9889-4991-B1A6-D54455A90F33@twitter.com> <81066cc5-0b0a-3345-4d63-87a9bc4a2909@oracle.com> <0BEEDF0A-91F0-4640-8F95-D5513200B72F@oracle.com> Message-ID: On Sun, Apr 23, 2017 at 1:39 PM, Doug Simon wrote: > >> On 21 Apr 2017, at 23:54, Christian Thalinger wrote: >> >> >>> On Apr 21, 2017, at 11:41 AM, Karthik Ganesan wrote: >>> >>> Hi Christian, >>> >>> Thanks for your interest. This question was brought up previously in the discussion email thread for this project: >>> >>> Project Sumatra was aimed at translation of Java byte code to execute on >>> GPU, which was an ambitious goal and a challenging task to take up. In this >>> project, we aim to come up with APIs targeting the most common Analytics >>> operations that can be readily offloaded to accelerators transparently. Most >>> of the information needed for offload to the accelerator is expected to be >>> readily provided by the API semantics and there by, simplifying the need to >>> do tedious byte code analysis. >> >> I disagree. The first paragraph on the Sumatra project page says: >> >> "This primary goal of this project is to enable Java applications to take advantage of graphics processing units (GPUs) and accelerated processing units (APUs)--whether they are discrete devices or integrated with a CPU--to improve performance.? >> >> while you state: >> >> "This Project would explore enhanced execution of bulk >> aggregate calculations over Streams through offloading >> calculations to hardware accelerators.? >> >> It?s the same thing. I just don?t see the need to spin up yet-another OpenJDK project that aims at the same goal. > > Maybe this is just a discrepancy between the officially stated aims. I understood Sumatra to be about *automatic* offloading work for existing APIs (such as the Streams API) to a GPU where as Trinity seems to be more about designing an explicit API for GPU offloading. > So if this is about a explicit API for GPU offloading, will this be a Java implementation/wrapper for already existing C/C++ APIs like CUDA/OpenCL. Designing a completely new, Java-specific API seems to be not very promising to me. > -Doug From doug.simon at oracle.com Mon Apr 24 09:09:27 2017 From: doug.simon at oracle.com (Doug Simon) Date: Mon, 24 Apr 2017 11:09:27 +0200 Subject: CFV: Project Trinity In-Reply-To: References: <19997aa6-aad8-da42-bdf0-3dd5f39e7d48@oracle.com> <78B4997B-9889-4991-B1A6-D54455A90F33@twitter.com> <81066cc5-0b0a-3345-4d63-87a9bc4a2909@oracle.com> <0BEEDF0A-91F0-4640-8F95-D5513200B72F@oracle.com> Message-ID: <38209C6C-567B-4500-ACCC-3F23A5BC5AE9@oracle.com> > On 24 Apr 2017, at 10:50, Volker Simonis wrote: > > On Sun, Apr 23, 2017 at 1:39 PM, Doug Simon wrote: >> >>> On 21 Apr 2017, at 23:54, Christian Thalinger wrote: >>> >>> >>>> On Apr 21, 2017, at 11:41 AM, Karthik Ganesan wrote: >>>> >>>> Hi Christian, >>>> >>>> Thanks for your interest. This question was brought up previously in the discussion email thread for this project: >>>> >>>> Project Sumatra was aimed at translation of Java byte code to execute on >>>> GPU, which was an ambitious goal and a challenging task to take up. In this >>>> project, we aim to come up with APIs targeting the most common Analytics >>>> operations that can be readily offloaded to accelerators transparently. Most >>>> of the information needed for offload to the accelerator is expected to be >>>> readily provided by the API semantics and there by, simplifying the need to >>>> do tedious byte code analysis. >>> >>> I disagree. The first paragraph on the Sumatra project page says: >>> >>> "This primary goal of this project is to enable Java applications to take advantage of graphics processing units (GPUs) and accelerated processing units (APUs)--whether they are discrete devices or integrated with a CPU--to improve performance.? >>> >>> while you state: >>> >>> "This Project would explore enhanced execution of bulk >>> aggregate calculations over Streams through offloading >>> calculations to hardware accelerators.? >>> >>> It?s the same thing. I just don?t see the need to spin up yet-another OpenJDK project that aims at the same goal. >> >> Maybe this is just a discrepancy between the officially stated aims. I understood Sumatra to be about *automatic* offloading work for existing APIs (such as the Streams API) to a GPU where as Trinity seems to be more about designing an explicit API for GPU offloading. >> > > So if this is about a explicit API for GPU offloading, will this be a > Java implementation/wrapper for already existing C/C++ APIs like > CUDA/OpenCL. Designing a completely new, Java-specific API seems to be > not very promising to me. I agree. Karthik, maybe you could discuss the differences/similarities between Trinity and the Arapapi project (https://github.com/aparapi/aparapi). -Doug From mark.reinhold at oracle.com Mon Apr 24 14:30:05 2017 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Mon, 24 Apr 2017 07:30:05 -0700 Subject: CFV: Project Trinity In-Reply-To: <19997aa6-aad8-da42-bdf0-3dd5f39e7d48@oracle.com> References: <19997aa6-aad8-da42-bdf0-3dd5f39e7d48@oracle.com> Message-ID: <20170424073005.445392201@eggemoggin.niobe.net> 2017/4/21 11:28:24 -0700, karthik.ganesan at oracle.com: > I would like to propose the creation of a new Project: > Project Trinity with myself as the Lead and the Core > Libraries Group as the Sponsoring Group. > > ... > > Votes are due by May 4, 2017. > > Only current OpenJDK Members [4] are eligible to vote on this > motion. Votes must be cast in the open on the discuss list. > Replying to this message is sufficient if your mail program > honors the Reply-To header. >From a strictly procedural perspective, this CFV is not valid. Calls for votes on the creation of a new Project must be sent to the announcement list, as described here: http://openjdk.java.net/projects/#new-project-propose At any rate it has provoked a useful discussion, so let's see how that turns out before you initiate an actual CFV. - Mark From karthik.ganesan at oracle.com Mon Apr 24 15:00:29 2017 From: karthik.ganesan at oracle.com (Karthik Ganesan) Date: Mon, 24 Apr 2017 10:00:29 -0500 Subject: CFV: Project Trinity In-Reply-To: <38209C6C-567B-4500-ACCC-3F23A5BC5AE9@oracle.com> References: <19997aa6-aad8-da42-bdf0-3dd5f39e7d48@oracle.com> <78B4997B-9889-4991-B1A6-D54455A90F33@twitter.com> <81066cc5-0b0a-3345-4d63-87a9bc4a2909@oracle.com> <0BEEDF0A-91F0-4640-8F95-D5513200B72F@oracle.com> <38209C6C-567B-4500-ACCC-3F23A5BC5AE9@oracle.com> Message-ID: <12a5acf4-cc8a-97c6-b611-0cfc25c54936@oracle.com> I would like to thank Paul Sandoz, Christian Thalinger, Doug Simon, Mario Torre and Volker Simonis for their support and the insightful questions. What we are proposing to do as part of this project is complementary to existing efforts that enable offload to GPUs like Sumatra, AparAPI etc. These existing projects provide implementations translating existing Java API via Bytecodes to GPU language. Trinity extends these efforts and takes it one step further by readily providing the building blocks for programmers to construct complex bulk data/stream based algorithms in Java that can be easily offloaded by these existing projects. While having a route to offload to hardware accelerators is useful, but making it easier for programmers to leverage will take it one step closer to adoption. Projects like Sumatra and AparAPI use the the Stream ForEach() method to show case offloads. Trinity will offer more such methods with richer functionality, making it easier for these existing projects to leverage and deliver hardware capabilities to be readily consumed by programmers. Unlike the existing Streams API, the library for this new API is envisioned to have a stronger focus on performance, a dedicated implementation that will be offload friendly and cover more functions that are relevant to this domain of programmers. Also, please note that Trinity casts a wider a net when it comes to accelerators, not just GPUs/APUs. These accelerators can include Analytics accelerators like DAX, SIMD units on general purpose cores, FPGA based accelerators for bulk aggregate operations, GPUs and whatever more the future holds in terms of heterogeneous computing for bulk data processing. Inspired by the existing Streams API that brings succinct functional programming to Java using lambdas, this project will try to retain such rich features, significantly simplifying programming in Java for the performance oriented developers focusing on bulk data processing. Regards, Karthik On 4/24/2017 4:09 AM, Doug Simon wrote: >> On 24 Apr 2017, at 10:50, Volker Simonis wrote: >> >> On Sun, Apr 23, 2017 at 1:39 PM, Doug Simon wrote: >>>> On 21 Apr 2017, at 23:54, Christian Thalinger wrote: >>>> >>>> >>>>> On Apr 21, 2017, at 11:41 AM, Karthik Ganesan wrote: >>>>> >>>>> Hi Christian, >>>>> >>>>> Thanks for your interest. This question was brought up previously in the discussion email thread for this project: >>>>> >>>>> Project Sumatra was aimed at translation of Java byte code to execute on >>>>> GPU, which was an ambitious goal and a challenging task to take up. In this >>>>> project, we aim to come up with APIs targeting the most common Analytics >>>>> operations that can be readily offloaded to accelerators transparently. Most >>>>> of the information needed for offload to the accelerator is expected to be >>>>> readily provided by the API semantics and there by, simplifying the need to >>>>> do tedious byte code analysis. >>>> I disagree. The first paragraph on the Sumatra project page says: >>>> >>>> "This primary goal of this project is to enable Java applications to take advantage of graphics processing units (GPUs) and accelerated processing units (APUs)--whether they are discrete devices or integrated with a CPU--to improve performance.? >>>> >>>> while you state: >>>> >>>> "This Project would explore enhanced execution of bulk >>>> aggregate calculations over Streams through offloading >>>> calculations to hardware accelerators.? >>>> >>>> It?s the same thing. I just don?t see the need to spin up yet-another OpenJDK project that aims at the same goal. >>> Maybe this is just a discrepancy between the officially stated aims. I understood Sumatra to be about *automatic* offloading work for existing APIs (such as the Streams API) to a GPU where as Trinity seems to be more about designing an explicit API for GPU offloading. >>> >> So if this is about a explicit API for GPU offloading, will this be a >> Java implementation/wrapper for already existing C/C++ APIs like >> CUDA/OpenCL. Designing a completely new, Java-specific API seems to be >> not very promising to me. > I agree. > > Karthik, maybe you could discuss the differences/similarities between Trinity and the Arapapi project (https://github.com/aparapi/aparapi). > > -Doug From neugens.limasoftware at gmail.com Mon Apr 24 16:35:11 2017 From: neugens.limasoftware at gmail.com (Mario Torre) Date: Mon, 24 Apr 2017 18:35:11 +0200 Subject: CFV: Project Trinity In-Reply-To: <12a5acf4-cc8a-97c6-b611-0cfc25c54936@oracle.com> References: <19997aa6-aad8-da42-bdf0-3dd5f39e7d48@oracle.com> <78B4997B-9889-4991-B1A6-D54455A90F33@twitter.com> <81066cc5-0b0a-3345-4d63-87a9bc4a2909@oracle.com> <0BEEDF0A-91F0-4640-8F95-D5513200B72F@oracle.com> <38209C6C-567B-4500-ACCC-3F23A5BC5AE9@oracle.com> <12a5acf4-cc8a-97c6-b611-0cfc25c54936@oracle.com> Message-ID: 2017-04-24 17:00 GMT+02:00 Karthik Ganesan : > SIMD I still have an old PS3 with Linux, I'm looking forward to try that out :) I think the project idea is interesting, I personally would not mind if it duplicated some efforts from the existing libraries, as long as the goal is to have a generic framework within the JDK. The challenge is that such framework should work even if no specialised hardware is available. Is "Trinity" going to be something akin the various providers based subsystems (like the Sound, the Filesystem, JavaScript, etc...), with multiple possible backends, maybe using one the already mentioned projects? I personally think that there is benefit in overcoming the inherent verbosity (and complexity) of APIs like CUDA or OpenCL (or Metal), but those framework are verbose for a reason (flexibility). Just wrapping them around (with little added extras) doesn't really add out much, and in fact, it just makes things look even more alien (I think about Jogl for example, does the job perfectly but it really looks like C wrapped in Java). If we go the extra length to make a project it should really be a nice, modern, well thought Java API. To that extent, do you already have some code? It would be very nice if we can look at something (including design and architecture documents) before getting a huge patch bomb hitting the repos a week after the project is approved. I'll still likely vote for that, I'm intrigued. Cheers, Mario -- pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens Proud GNU Classpath developer: http://www.classpath.org/ OpenJDK: http://openjdk.java.net/projects/caciocavallo/ Please, support open standards: http://endsoftpatents.org/ From volker.simonis at gmail.com Mon Apr 24 17:30:30 2017 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 24 Apr 2017 19:30:30 +0200 Subject: CFV: Project Trinity In-Reply-To: <12a5acf4-cc8a-97c6-b611-0cfc25c54936@oracle.com> References: <19997aa6-aad8-da42-bdf0-3dd5f39e7d48@oracle.com> <78B4997B-9889-4991-B1A6-D54455A90F33@twitter.com> <81066cc5-0b0a-3345-4d63-87a9bc4a2909@oracle.com> <0BEEDF0A-91F0-4640-8F95-D5513200B72F@oracle.com> <38209C6C-567B-4500-ACCC-3F23A5BC5AE9@oracle.com> <12a5acf4-cc8a-97c6-b611-0cfc25c54936@oracle.com> Message-ID: On Mon, Apr 24, 2017 at 5:00 PM, Karthik Ganesan wrote: > I would like to thank Paul Sandoz, Christian Thalinger, Doug Simon, Mario > Torre and Volker Simonis for their support and the insightful questions. > > What we are proposing to do as part of this project is complementary to > existing efforts that enable offload to GPUs like Sumatra, AparAPI etc. > These existing projects provide implementations translating existing Java > API via Bytecodes to GPU language. Trinity extends these efforts and takes > it one step further by readily providing the building blocks for programmers > to construct complex bulk data/stream based algorithms in Java that can be > easily offloaded by these existing projects. While having a route to offload > to hardware accelerators is useful, but making it easier for programmers to > leverage will take it one step closer to adoption. > > Projects like Sumatra and AparAPI use the the Stream ForEach() method to > show case offloads. Trinity will offer more such methods with richer > functionality, making it easier for these existing projects to leverage and > deliver hardware capabilities to be readily consumed by programmers. Unlike > the existing Streams API, the library for this new API is envisioned to have > a stronger focus on performance, a dedicated implementation that will be > offload friendly and cover more functions that are relevant to this domain > of programmers. > > Also, please note that Trinity casts a wider a net when it comes to > accelerators, not just GPUs/APUs. These accelerators can include Analytics > accelerators like DAX, SIMD units on general purpose cores, FPGA based > accelerators for bulk aggregate operations, GPUs and whatever more the > future holds in terms of heterogeneous computing for bulk data processing. > This certainly sounds very ambitious! I'm not an expert in this area, but I don't think there's even a good C/C++ API which covers this broad range of "accelerators". What we should certainly avoid is providing an API which only works with accelerator XXX of vendor YYY. If the goal of this project is to eventually provide a standard Java API, it should at least support a wide range of available "accelerators" which, to repeat my self, makes it quite ambitious. That said, how is this new library supposed to work? Will it be mainly implemented in Java with various native C/C++ back-ends or do you plan to still use VM (aka. HotSpot) support via intrinsics and various other sorts of JIT compiler optimizations? As far as I understood now, you'll plan to go for the first approach without HotSpot support, right? In that case, Trinity would certainly be a good candidate for using the new JNI work done in project Panama. > Inspired by the existing Streams API that brings succinct functional > programming to Java using lambdas, this project will try to retain such rich > features, significantly simplifying programming in Java for the performance > oriented developers focusing on bulk data processing. > > Regards, > > Karthik > > > > On 4/24/2017 4:09 AM, Doug Simon wrote: >>> >>> On 24 Apr 2017, at 10:50, Volker Simonis >>> wrote: >>> >>> On Sun, Apr 23, 2017 at 1:39 PM, Doug Simon >>> wrote: >>>>> >>>>> On 21 Apr 2017, at 23:54, Christian Thalinger >>>>> wrote: >>>>> >>>>> >>>>>> On Apr 21, 2017, at 11:41 AM, Karthik Ganesan >>>>>> wrote: >>>>>> >>>>>> Hi Christian, >>>>>> >>>>>> Thanks for your interest. This question was brought up previously in >>>>>> the discussion email thread for this project: >>>>>> >>>>>> Project Sumatra was aimed at translation of Java byte code to execute >>>>>> on >>>>>> GPU, which was an ambitious goal and a challenging task to take up. In >>>>>> this >>>>>> project, we aim to come up with APIs targeting the most common >>>>>> Analytics >>>>>> operations that can be readily offloaded to accelerators >>>>>> transparently. Most >>>>>> of the information needed for offload to the accelerator is expected >>>>>> to be >>>>>> readily provided by the API semantics and there by, simplifying the >>>>>> need to >>>>>> do tedious byte code analysis. >>>>> >>>>> I disagree. The first paragraph on the Sumatra project page says: >>>>> >>>>> "This primary goal of this project is to enable Java applications to >>>>> take advantage of graphics processing units (GPUs) and accelerated >>>>> processing units (APUs)--whether they are discrete devices or integrated >>>>> with a CPU--to improve performance.? >>>>> >>>>> while you state: >>>>> >>>>> "This Project would explore enhanced execution of bulk >>>>> aggregate calculations over Streams through offloading >>>>> calculations to hardware accelerators.? >>>>> >>>>> It?s the same thing. I just don?t see the need to spin up yet-another >>>>> OpenJDK project that aims at the same goal. >>>> >>>> Maybe this is just a discrepancy between the officially stated aims. I >>>> understood Sumatra to be about *automatic* offloading work for existing APIs >>>> (such as the Streams API) to a GPU where as Trinity seems to be more about >>>> designing an explicit API for GPU offloading. >>>> >>> So if this is about a explicit API for GPU offloading, will this be a >>> Java implementation/wrapper for already existing C/C++ APIs like >>> CUDA/OpenCL. Designing a completely new, Java-specific API seems to be >>> not very promising to me. >> >> I agree. >> >> Karthik, maybe you could discuss the differences/similarities between >> Trinity and the Arapapi project (https://github.com/aparapi/aparapi). >> >> -Doug > > From Ryan.LaMothe at pnnl.gov Mon Apr 24 17:46:07 2017 From: Ryan.LaMothe at pnnl.gov (LaMothe, Ryan R) Date: Mon, 24 Apr 2017 17:46:07 +0000 Subject: Project Trinity Message-ID: <660C1862-FB57-4ACE-9C60-6A3BC5406CED@pnnl.gov> I think it would be worthwhile to reach out to the Aparapi, Sumatra, etc. folks to find out what hurdles they encountered trying to implement the same capabilities you are proposing, and why those efforts either slowed, stalled or stopped altogether. It turns out, the devil is truly in the details when you finally start down this road, and many of us (myself included), would be more than willing to knowledge share with you to help you out. In my personal opinion, what you are proposing does not need a new project but a revival of existing efforts (i.e. Sumatra), as others have pointed out. As for Sumatra, the actual goal was to convert Java code to HSAIL, so a reviving of that effort to additionally output CUDA, VHDL, DAX, et.al. as appropriate would be welcome by many of us. If you could additionally convince the powers-that-be to support contiguous multi-dimensional arrays ([[ ]]) as part of your effort...you may even make new best friends :) -Ryan On 4/24/17, 8:00 AM, "discuss on behalf of Karthik Ganesan" wrote: I would like to thank Paul Sandoz, Christian Thalinger, Doug Simon, Mario Torre and Volker Simonis for their support and the insightful questions. What we are proposing to do as part of this project is complementary to existing efforts that enable offload to GPUs like Sumatra, AparAPI etc. These existing projects provide implementations translating existing Java API via Bytecodes to GPU language. Trinity extends these efforts and takes it one step further by readily providing the building blocks for programmers to construct complex bulk data/stream based algorithms in Java that can be easily offloaded by these existing projects. While having a route to offload to hardware accelerators is useful, but making it easier for programmers to leverage will take it one step closer to adoption. Projects like Sumatra and AparAPI use the the Stream ForEach() method to show case offloads. Trinity will offer more such methods with richer functionality, making it easier for these existing projects to leverage and deliver hardware capabilities to be readily consumed by programmers. Unlike the existing Streams API, the library for this new API is envisioned to have a stronger focus on performance, a dedicated implementation that will be offload friendly and cover more functions that are relevant to this domain of programmers. Also, please note that Trinity casts a wider a net when it comes to accelerators, not just GPUs/APUs. These accelerators can include Analytics accelerators like DAX, SIMD units on general purpose cores, FPGA based accelerators for bulk aggregate operations, GPUs and whatever more the future holds in terms of heterogeneous computing for bulk data processing. Inspired by the existing Streams API that brings succinct functional programming to Java using lambdas, this project will try to retain such rich features, significantly simplifying programming in Java for the performance oriented developers focusing on bulk data processing. Regards, Karthik On 4/24/2017 4:09 AM, Doug Simon wrote: >> On 24 Apr 2017, at 10:50, Volker Simonis wrote: >> >> On Sun, Apr 23, 2017 at 1:39 PM, Doug Simon wrote: >>>> On 21 Apr 2017, at 23:54, Christian Thalinger wrote: >>>> >>>> >>>>> On Apr 21, 2017, at 11:41 AM, Karthik Ganesan wrote: >>>>> >>>>> Hi Christian, >>>>> >>>>> Thanks for your interest. This question was brought up previously in the discussion email thread for this project: >>>>> >>>>> Project Sumatra was aimed at translation of Java byte code to execute on >>>>> GPU, which was an ambitious goal and a challenging task to take up. In this >>>>> project, we aim to come up with APIs targeting the most common Analytics >>>>> operations that can be readily offloaded to accelerators transparently. Most >>>>> of the information needed for offload to the accelerator is expected to be >>>>> readily provided by the API semantics and there by, simplifying the need to >>>>> do tedious byte code analysis. >>>> I disagree. The first paragraph on the Sumatra project page says: >>>> >>>> "This primary goal of this project is to enable Java applications to take advantage of graphics processing units (GPUs) and accelerated processing units (APUs)--whether they are discrete devices or integrated with a CPU--to improve performance.? >>>> >>>> while you state: >>>> >>>> "This Project would explore enhanced execution of bulk >>>> aggregate calculations over Streams through offloading >>>> calculations to hardware accelerators.? >>>> >>>> It?s the same thing. I just don?t see the need to spin up yet-another OpenJDK project that aims at the same goal. >>> Maybe this is just a discrepancy between the officially stated aims. I understood Sumatra to be about *automatic* offloading work for existing APIs (such as the Streams API) to a GPU where as Trinity seems to be more about designing an explicit API for GPU offloading. >>> >> So if this is about a explicit API for GPU offloading, will this be a >> Java implementation/wrapper for already existing C/C++ APIs like >> CUDA/OpenCL. Designing a completely new, Java-specific API seems to be >> not very promising to me. > I agree. > > Karthik, maybe you could discuss the differences/similarities between Trinity and the Arapapi project (https://github.com/aparapi/aparapi). > > -Doug From karthik.ganesan at oracle.com Mon Apr 24 18:32:23 2017 From: karthik.ganesan at oracle.com (Karthik Ganesan) Date: Mon, 24 Apr 2017 13:32:23 -0500 Subject: CFV: Project Trinity In-Reply-To: References: <19997aa6-aad8-da42-bdf0-3dd5f39e7d48@oracle.com> <78B4997B-9889-4991-B1A6-D54455A90F33@twitter.com> <81066cc5-0b0a-3345-4d63-87a9bc4a2909@oracle.com> <0BEEDF0A-91F0-4640-8F95-D5513200B72F@oracle.com> <38209C6C-567B-4500-ACCC-3F23A5BC5AE9@oracle.com> <12a5acf4-cc8a-97c6-b611-0cfc25c54936@oracle.com> Message-ID: <5a026d20-a516-4762-4972-30e8fd2a9ea7@oracle.com> Hi Mario, please see comments inline. On 4/24/2017 11:35 AM, Mario Torre wrote: > I still have an old PS3 with Linux, I'm looking forward to try that > out :) > I think the project idea is interesting, I personally would not mind > if it duplicated some efforts from the existing libraries, as long as > the goal is to have a generic framework within the JDK. The challenge > is that such framework should work even if no specialised hardware is > available. Our goals is also to ensure that such a framework will work even if no specialized hardware is available. > > Is "Trinity" going to be something akin the various providers based > subsystems (like the Sound, the Filesystem, JavaScript, etc...), with > multiple possible backends, maybe using one the already mentioned > projects? Yes, and I think that is a reasonable analogy. > To that extent, do you already have some code? It would be very nice > if we can look at something (including design and architecture > documents) before getting a huge patch bomb hitting the repos a week > after the project is approved. Though we have done multiple prototypes trying to change the existing Streams library to open up to accelerators and extend to cover a wider range of analytic operations, most of the useful information we bring to this project is our learning about the challenges involved than a code patch bomb. :-) > > I'll still likely vote for that, I'm intrigued. Appreciate that. Thanks, Karthik > > Cheers, > Mario From karthik.ganesan at oracle.com Mon Apr 24 19:54:54 2017 From: karthik.ganesan at oracle.com (Karthik Ganesan) Date: Mon, 24 Apr 2017 14:54:54 -0500 Subject: CFV: Project Trinity In-Reply-To: References: <19997aa6-aad8-da42-bdf0-3dd5f39e7d48@oracle.com> <78B4997B-9889-4991-B1A6-D54455A90F33@twitter.com> <81066cc5-0b0a-3345-4d63-87a9bc4a2909@oracle.com> <0BEEDF0A-91F0-4640-8F95-D5513200B72F@oracle.com> <38209C6C-567B-4500-ACCC-3F23A5BC5AE9@oracle.com> <12a5acf4-cc8a-97c6-b611-0cfc25c54936@oracle.com> Message-ID: Hi Volker, On 4/24/2017 12:30 PM, Volker Simonis wrote: > This certainly sounds very ambitious! I'm not an expert in this area, > but I don't think there's even a good C/C++ API which covers this > broad range of "accelerators". It may look ambitious, but if we restrict ourselves to a particular domain of bulk data processing and look at this library as a domain specific java library that offers a standard interface backend to multiple accelerators, it is still a plausible goal to achieve. Such an API will have the best chance for adoption in the "portable" Java world. > What we should certainly avoid is > providing an API which only works with accelerator XXX of vendor YYY. Indeed, portability will be a key design goal. > If the goal of this project is to eventually provide a standard Java > API, it should at least support a wide range of available > "accelerators" which, to repeat my self, makes it quite ambitious. The biggest of the problems with accelerator offload is detection of code patterns that are suitable to be translated to the accelerator. With a dedicated API, and operations in a specific domain, we significantly simplify this problem. Based on some prototyping work we have done using DAX, we have clearly seen the merits of this approach. We are just signing up to provide a better interface/implementation than what the current Streams API provides for offload and acceleration in this domain which is already being used by existing offload related projects. We are not targeting any dynamic code generation for these backends which would be redundant given the existing projects like Sumatra and AparAPI. > > That said, how is this new library supposed to work? Will it be mainly > implemented in Java with various native C/C++ back-ends or do you plan > to still use VM (aka. HotSpot) support via intrinsics and various > other sorts of JIT compiler optimizations? It is something that we would like to explore as part of this project with input from previous and ongoing offload related projects. Based on some of our initial experiments with both intrinsics and JNI, it does not have to be one or the other and we are open to both. Especially with the artifacts offered by Panama, this will be very interesting to explore further. Thanks, Karthik > >> Inspired by the existing Streams API that brings succinct functional >> programming to Java using lambdas, this project will try to retain such rich >> features, significantly simplifying programming in Java for the performance >> oriented developers focusing on bulk data processing. >> >> Regards, >> >> Karthik >> >> >> >> On 4/24/2017 4:09 AM, Doug Simon wrote: >>>> On 24 Apr 2017, at 10:50, Volker Simonis >>>> wrote: >>>> >>>> On Sun, Apr 23, 2017 at 1:39 PM, Doug Simon >>>> wrote: >>>>>> On 21 Apr 2017, at 23:54, Christian Thalinger >>>>>> wrote: >>>>>> >>>>>> >>>>>>> On Apr 21, 2017, at 11:41 AM, Karthik Ganesan >>>>>>> wrote: >>>>>>> >>>>>>> Hi Christian, >>>>>>> >>>>>>> Thanks for your interest. This question was brought up previously in >>>>>>> the discussion email thread for this project: >>>>>>> >>>>>>> Project Sumatra was aimed at translation of Java byte code to execute >>>>>>> on >>>>>>> GPU, which was an ambitious goal and a challenging task to take up. In >>>>>>> this >>>>>>> project, we aim to come up with APIs targeting the most common >>>>>>> Analytics >>>>>>> operations that can be readily offloaded to accelerators >>>>>>> transparently. Most >>>>>>> of the information needed for offload to the accelerator is expected >>>>>>> to be >>>>>>> readily provided by the API semantics and there by, simplifying the >>>>>>> need to >>>>>>> do tedious byte code analysis. >>>>>> I disagree. The first paragraph on the Sumatra project page says: >>>>>> >>>>>> "This primary goal of this project is to enable Java applications to >>>>>> take advantage of graphics processing units (GPUs) and accelerated >>>>>> processing units (APUs)--whether they are discrete devices or integrated >>>>>> with a CPU--to improve performance.? >>>>>> >>>>>> while you state: >>>>>> >>>>>> "This Project would explore enhanced execution of bulk >>>>>> aggregate calculations over Streams through offloading >>>>>> calculations to hardware accelerators.? >>>>>> >>>>>> It?s the same thing. I just don?t see the need to spin up yet-another >>>>>> OpenJDK project that aims at the same goal. >>>>> Maybe this is just a discrepancy between the officially stated aims. I >>>>> understood Sumatra to be about *automatic* offloading work for existing APIs >>>>> (such as the Streams API) to a GPU where as Trinity seems to be more about >>>>> designing an explicit API for GPU offloading. >>>>> >>>> So if this is about a explicit API for GPU offloading, will this be a >>>> Java implementation/wrapper for already existing C/C++ APIs like >>>> CUDA/OpenCL. Designing a completely new, Java-specific API seems to be >>>> not very promising to me. >>> I agree. >>> >>> Karthik, maybe you could discuss the differences/similarities between >>> Trinity and the Arapapi project (https://github.com/aparapi/aparapi). >>> >>> -Doug >> From karthik.ganesan at oracle.com Mon Apr 24 20:26:32 2017 From: karthik.ganesan at oracle.com (Karthik Ganesan) Date: Mon, 24 Apr 2017 15:26:32 -0500 Subject: Project Trinity In-Reply-To: <660C1862-FB57-4ACE-9C60-6A3BC5406CED@pnnl.gov> References: <660C1862-FB57-4ACE-9C60-6A3BC5406CED@pnnl.gov> Message-ID: <11542659-d23d-1515-092e-45748b5b356e@oracle.com> Hi Ryan, On 4/24/2017 12:46 PM, LaMothe, Ryan R wrote: > I think it would be worthwhile to reach out to the Aparapi, Sumatra, etc. folks to find out what hurdles they encountered trying to implement the same capabilities you are proposing, and why those efforts either slowed, stalled or stopped altogether. It turns out, the devil is truly in the details when you finally start down this road, and many of us (myself included), would be more than willing to knowledge share with you to help you out. We really appreciate this and I will reach out. Thank you. But, I want to reemphasize one point here: we have very little redundancy with Sumatra or Aparapi. We are only going to provide a better interface instead of what Stream API provides and will only make it easier for realizing these existing projects. > In my personal opinion, what you are proposing does not need a new project but a revival of existing efforts (i.e. Sumatra), as others have pointed out. Trinity is much more focused than Sumatra. We use APIs to provide the information needed for offloads, whereas existing projects like Sumatra rely on detecting code patterns and do dynamic code generation. Sumatra is completely GPU/APU focused with a significant chunk of the Java runtime functioning on the GPU. That is very clear from the project description. Trinity focuses on a wider range of accelerators, including DAX which is very different from a GPU. DAX has a fixed set of specific operations, that can be composed together. To give some perspective, example DAX operations include scan, select, sort etc., much similar to SQL queries and are a specific class of bulk aggregate operations. One can compose such operations together to form a pipeline of operations working on a Stream of data. Much of these also apply for an efficient offload to SIMD vector units on general purpose cores, multithreaded implementation on general purpose cores, Graphic processors, data processing on FPGAs etc. > > As for Sumatra, the actual goal was to convert Java code to HSAIL, so a reviving of that effort to additionally output CUDA, VHDL, DAX, et.al. as appropriate would be welcome by many of us. That is clearly not the goal of this project. This project focuses on the front end and does not target any kind of dynamic code generation, which is left with the ongoing/existing projects. I hope this clearly shows how this project is complementary to the existing offload related projects without much redundancy. We hope to work with all the existing/ongoing offload related projects as I strongly believe that these projects leveraging each other can have a significant impact than any one of them solving a small part of the puzzle. I kindly request your support and participation in Trinity. Thanks, Karthik > If you could additionally convince the powers-that-be to support contiguous multi-dimensional arrays ([[ ]]) as part of your effort...you may even make new best friends :) > > > -Ryan > > On 4/24/17, 8:00 AM, "discuss on behalf of Karthik Ganesan" wrote: > > I would like to thank Paul Sandoz, Christian Thalinger, Doug Simon, > Mario Torre and Volker Simonis for their support and the insightful > questions. > > What we are proposing to do as part of this project is complementary to > existing efforts that enable offload to GPUs like Sumatra, AparAPI etc. > These existing projects provide implementations translating existing > Java API via Bytecodes to GPU language. Trinity extends these efforts > and takes it one step further by readily providing the building blocks > for programmers to construct complex bulk data/stream based algorithms > in Java that can be easily offloaded by these existing projects. While > having a route to offload to hardware accelerators is useful, but making > it easier for programmers to leverage will take it one step closer to > adoption. > > Projects like Sumatra and AparAPI use the the Stream ForEach() method to > show case offloads. Trinity will offer more such methods with richer > functionality, making it easier for these existing projects to leverage > and deliver hardware capabilities to be readily consumed by programmers. > Unlike the existing Streams API, the library for this new API is > envisioned to have a stronger focus on performance, a dedicated > implementation that will be offload friendly and cover more functions > that are relevant to this domain of programmers. > > Also, please note that Trinity casts a wider a net when it comes to > accelerators, not just GPUs/APUs. These accelerators can include > Analytics accelerators like DAX, SIMD units on general purpose cores, > FPGA based accelerators for bulk aggregate operations, GPUs and whatever > more the future holds in terms of heterogeneous computing for bulk data > processing. > > Inspired by the existing Streams API that brings succinct functional > programming to Java using lambdas, this project will try to retain such > rich features, significantly simplifying programming in Java for the > performance oriented developers focusing on bulk data processing. > > Regards, > > Karthik > > > On 4/24/2017 4:09 AM, Doug Simon wrote: > >> On 24 Apr 2017, at 10:50, Volker Simonis wrote: > >> > >> On Sun, Apr 23, 2017 at 1:39 PM, Doug Simon wrote: > >>>> On 21 Apr 2017, at 23:54, Christian Thalinger wrote: > >>>> > >>>> > >>>>> On Apr 21, 2017, at 11:41 AM, Karthik Ganesan wrote: > >>>>> > >>>>> Hi Christian, > >>>>> > >>>>> Thanks for your interest. This question was brought up previously in the discussion email thread for this project: > >>>>> > >>>>> Project Sumatra was aimed at translation of Java byte code to execute on > >>>>> GPU, which was an ambitious goal and a challenging task to take up. In this > >>>>> project, we aim to come up with APIs targeting the most common Analytics > >>>>> operations that can be readily offloaded to accelerators transparently. Most > >>>>> of the information needed for offload to the accelerator is expected to be > >>>>> readily provided by the API semantics and there by, simplifying the need to > >>>>> do tedious byte code analysis. > >>>> I disagree. The first paragraph on the Sumatra project page says: > >>>> > >>>> "This primary goal of this project is to enable Java applications to take advantage of graphics processing units (GPUs) and accelerated processing units (APUs)--whether they are discrete devices or integrated with a CPU--to improve performance.? > >>>> > >>>> while you state: > >>>> > >>>> "This Project would explore enhanced execution of bulk > >>>> aggregate calculations over Streams through offloading > >>>> calculations to hardware accelerators.? > >>>> > >>>> It?s the same thing. I just don?t see the need to spin up yet-another OpenJDK project that aims at the same goal. > >>> Maybe this is just a discrepancy between the officially stated aims. I understood Sumatra to be about *automatic* offloading work for existing APIs (such as the Streams API) to a GPU where as Trinity seems to be more about designing an explicit API for GPU offloading. > >>> > >> So if this is about a explicit API for GPU offloading, will this be a > >> Java implementation/wrapper for already existing C/C++ APIs like > >> CUDA/OpenCL. Designing a completely new, Java-specific API seems to be > >> not very promising to me. > > I agree. > > > > Karthik, maybe you could discuss the differences/similarities between Trinity and the Arapapi project (https://github.com/aparapi/aparapi). > > > > -Doug > > > From aph at redhat.com Wed Apr 26 09:59:13 2017 From: aph at redhat.com (Andrew Haley) Date: Wed, 26 Apr 2017 10:59:13 +0100 Subject: CFV: Project Trinity In-Reply-To: References: <19997aa6-aad8-da42-bdf0-3dd5f39e7d48@oracle.com> <78B4997B-9889-4991-B1A6-D54455A90F33@twitter.com> <81066cc5-0b0a-3345-4d63-87a9bc4a2909@oracle.com> <0BEEDF0A-91F0-4640-8F95-D5513200B72F@oracle.com> <38209C6C-567B-4500-ACCC-3F23A5BC5AE9@oracle.com> <12a5acf4-cc8a-97c6-b611-0cfc25c54936@oracle.com> Message-ID: On 24/04/17 20:54, Karthik Ganesan wrote: > On 4/24/2017 12:30 PM, Volker Simonis wrote: > >> This certainly sounds very ambitious! I'm not an expert in this >> area, but I don't think there's even a good C/C++ API which covers >> this broad range of "accelerators". > > It may look ambitious, but if we restrict ourselves to a particular > domain of bulk data processing and look at this library as a domain > specific java library that offers a standard interface backend to > multiple accelerators, it is still a plausible goal to achieve. Such an > API will have the best chance for adoption in the "portable" Java world. I'm rather troubled by this. It means that we'll have a "high level" streams approach and a "bulk data" approach, presumably with different data structures and APIs. It means that a programmer coming to a problem will have to choose between these two approaches, because one doesn't meet performance targets. It is the case that was cannot use the fairly new Java streaming operations to handle bulk data accelerators? Andrew. From mark.reinhold at oracle.com Wed Apr 26 14:31:16 2017 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Wed, 26 Apr 2017 07:31:16 -0700 (PDT) Subject: CFV: Project Trinity In-Reply-To: References: <19997aa6-aad8-da42-bdf0-3dd5f39e7d48@oracle.com> <78B4997B-9889-4991-B1A6-D54455A90F33@twitter.com> <81066cc5-0b0a-3345-4d63-87a9bc4a2909@oracle.com> <0BEEDF0A-91F0-4640-8F95-D5513200B72F@oracle.com> <38209C6C-567B-4500-ACCC-3F23A5BC5AE9@oracle.com> <12a5acf4-cc8a-97c6-b611-0cfc25c54936@oracle.com> Message-ID: <20170426143116.7B74CB6718@eggemoggin.niobe.net> 2017/4/24 12:54:54 -0700, karthik.ganesan at oracle.com: > ... > > It may look ambitious, but if we restrict ourselves to a particular > domain of bulk data processing and look at this library as a domain > specific java library that offers a standard interface backend to > multiple accelerators, it is still a plausible goal to achieve. Such an > API will have the best chance for adoption in the "portable" Java world. Aside from the potential overlap with existing Projects, which others have already pointed out, what I don't yet see here is a strong reason for why this needs to be an OpenJDK Project. The Sumatra, Panama, and Valhalla Projects are exploring changes that are intimately tied to the JDK. Trinity, as far as I understand it, proposes to build a library on top of the JDK. The OpenJDK Community aims (per the Bylaws [1]) to foster the development of "implementations of present and future versions of the Java Platform, Standard Edition, as defined by the Java Community Process, and ... closely-related projects." Trinity may, in the end, prove to be a huge success, but if it's not intimately tied to the JDK then why does it need to be developed in OpenJDK Project? Why can't this work be done on GitHub or Bitbucket? - Mark [1] http://openjdk.java.net/bylaws From karthik.ganesan at oracle.com Thu Apr 27 00:53:42 2017 From: karthik.ganesan at oracle.com (Karthik Ganesan) Date: Wed, 26 Apr 2017 19:53:42 -0500 Subject: CFV: Project Trinity In-Reply-To: References: <19997aa6-aad8-da42-bdf0-3dd5f39e7d48@oracle.com> <78B4997B-9889-4991-B1A6-D54455A90F33@twitter.com> <81066cc5-0b0a-3345-4d63-87a9bc4a2909@oracle.com> <0BEEDF0A-91F0-4640-8F95-D5513200B72F@oracle.com> <38209C6C-567B-4500-ACCC-3F23A5BC5AE9@oracle.com> <12a5acf4-cc8a-97c6-b611-0cfc25c54936@oracle.com> Message-ID: <12ca9e2c-6e83-d9ee-ec92-4723c4ed4078@oracle.com> Hi Andrew, > It is the case that was cannot use the fairly new Java streaming > operations to handle bulk data accelerators? The decision of whether to enhance existing Streams library for offload to accelerators or create a new one is also part of the exploration proposed by this project. Thanks, Karthik > > Andrew. From karthik.ganesan at oracle.com Thu Apr 27 02:35:22 2017 From: karthik.ganesan at oracle.com (Karthik Ganesan) Date: Wed, 26 Apr 2017 21:35:22 -0500 Subject: CFV: Project Trinity In-Reply-To: <20170426143116.7B74CB6718@eggemoggin.niobe.net> References: <19997aa6-aad8-da42-bdf0-3dd5f39e7d48@oracle.com> <78B4997B-9889-4991-B1A6-D54455A90F33@twitter.com> <81066cc5-0b0a-3345-4d63-87a9bc4a2909@oracle.com> <0BEEDF0A-91F0-4640-8F95-D5513200B72F@oracle.com> <38209C6C-567B-4500-ACCC-3F23A5BC5AE9@oracle.com> <12a5acf4-cc8a-97c6-b611-0cfc25c54936@oracle.com> <20170426143116.7B74CB6718@eggemoggin.niobe.net> Message-ID: Hi Mark, > > The Sumatra, Panama, and Valhalla Projects are exploring changes that > are intimately tied to the JDK. Trinity, as far as I understand it, > proposes to build a library on top of the JDK. The OpenJDK Community > aims (per the Bylaws [1]) to foster the development of "implementations > of present and future versions of the Java Platform, Standard Edition, > as defined by the Java Community Process, and ... closely-related > projects." Trinity may, in the end, prove to be a huge success, but > if it's not intimately tied to the JDK then why does it need to be > developed in OpenJDK Project? Enhancing the existing Streams library as a possible direction was never off the table for the proposed project. I am sorry if that was not clear from the proposal. Based on our initial evaluation using multiple prototypes, some problems like cracking open lambdas is very important to enable offload to accelerators and a solution indeed may need a close tie to the JDK. I would like to thank every one who took the time to provide a lot of good feedback for this proposal. We will reevaluate some of the logistics related to this effort using all this input. Regards, Karthik > Why can't this work be done on GitHub > or Bitbucket? > > - Mark > > > [1] http://openjdk.java.net/bylaws From behrangsa at gmail.com Thu Apr 27 13:10:06 2017 From: behrangsa at gmail.com (Behrang Saeedzadeh) Date: Thu, 27 Apr 2017 23:10:06 +1000 Subject: Suggestion for automatic wrapping of checked exceptions inside RuntimeExceptions inside closures Message-ID: Hi, This has most likely been discussed before. In this yet another proposal, I suggest adding syntax sugar to make this automated. For example, by using a new arrow type (e.g. =>, #->, or maybe a new operator altogether: (??????? ???). So we can turn: public class Main { public static void main(String[] args) throws IOException { final Path aDir = Paths.get(args[0]); Files.list(aDir).forEach(f -> { try { throw new IOException(); } catch (IOException e) { throw new RuntimeException(e); } }); } } into: public class Main { public static void main(String[] args) throws IOException { final Path aDir = Paths.get(args[0]); Files.list(aDir).forEach(f (??????? ??? { throw new IOException(); }); } } What do you think? Best regards, Behrang Saeedzadeh From martijnverburg at gmail.com Thu Apr 27 13:18:07 2017 From: martijnverburg at gmail.com (Martijn Verburg) Date: Thu, 27 Apr 2017 14:18:07 +0100 Subject: Suggestion for automatic wrapping of checked exceptions inside RuntimeExceptions inside closures In-Reply-To: References: Message-ID: Hi Behrang, This is the wrong list to bring up proposals like this - a good place to start is the adoption-discuss mailing list. Cheers, Martijn On 27 April 2017 at 14:10, Behrang Saeedzadeh wrote: > Hi, > > This has most likely been discussed before. In this yet another proposal, I > suggest adding syntax sugar to make this automated. For example, by using a > new arrow type (e.g. =>, #->, or maybe a new operator altogether: (??????? > ???). > > So we can turn: > > public class Main { > public static void main(String[] args) throws IOException { > final Path aDir = Paths.get(args[0]); > Files.list(aDir).forEach(f -> { > try { > throw new IOException(); > } catch (IOException e) { > throw new RuntimeException(e); > } > }); > } > } > > > into: > > public class Main { > public static void main(String[] args) throws IOException { > final Path aDir = Paths.get(args[0]); > Files.list(aDir).forEach(f (??????? ??? { > throw new IOException(); > }); > } > } > > What do you think? > > > Best regards, > Behrang Saeedzadeh > From behrangsa at gmail.com Fri Apr 28 23:02:00 2017 From: behrangsa at gmail.com (Behrang Saeedzadeh) Date: Fri, 28 Apr 2017 23:02:00 +0000 Subject: Suggestion for automatic wrapping of checked exceptions inside RuntimeExceptions inside closures In-Reply-To: References: Message-ID: No worries. Will post it there. Thanks. On Thu, 27 Apr 2017 at 11:18 pm, Martijn Verburg wrote: > Hi Behrang, > > This is the wrong list to bring up proposals like this - a good place to > start is the adoption-discuss mailing list. > > Cheers, > Martijn > > On 27 April 2017 at 14:10, Behrang Saeedzadeh wrote: > >> Hi, >> >> This has most likely been discussed before. In this yet another proposal, >> I >> suggest adding syntax sugar to make this automated. For example, by using >> a >> new arrow type (e.g. =>, #->, or maybe a new operator altogether: (??????? >> ???). >> >> So we can turn: >> >> public class Main { >> public static void main(String[] args) throws IOException { >> final Path aDir = Paths.get(args[0]); >> Files.list(aDir).forEach(f -> { >> try { >> throw new IOException(); >> } catch (IOException e) { >> throw new RuntimeException(e); >> } >> }); >> } >> } >> >> >> into: >> >> public class Main { >> public static void main(String[] args) throws IOException { >> final Path aDir = Paths.get(args[0]); >> Files.list(aDir).forEach(f (??????? ??? { >> throw new IOException(); >> }); >> } >> } >> >> What do you think? >> >> >> Best regards, >> Behrang Saeedzadeh >> > > -- Best regards, Behrang Saeedzadeh