From kfogel at dawsoncollege.qc.ca Mon Mar 2 20:16:41 2020 From: kfogel at dawsoncollege.qc.ca (Kenneth Fogel) Date: Mon, 2 Mar 2020 20:16:41 +0000 Subject: Introduction and Education Message-ID: Hi, I am a teacher in a program called Computer Science Technology at Dawson College in Montreal for 31 years now. We take students mostly out of high school but also some adults returning to school and in three years train them to be software developers. It is three years of hands-on instruction with Java, for the past 18 years, as the primary language (it was Cobol before that). Some of you may know me from my outlandish proposals on Twitter such as eliminating main, an idea Cay Horstman first proposed a few years ago, and questioning why we still need to write 'new'. Regardless of what you think about these ideas they come from my interest in improving Java's reputation and ease of learning in the education space. Its not just about adding or removing features. As Brian has pointed out to me on numerous occasions there is a finite set of resources to make changes in the language and what may be simple to describe could be unmanageably complex to implement. So in discussing education it is not just about changing the language but about how we present what is already in place in such a way that teachers can do a better job. An example of this is 'records'. When I did a little iOS programming I loved the @synthesize (may not be exactly the right term) and having records has given me many new ideas on how to teach Java. Let me begin with this thought. Should all proposals for changes to the JDK et al also include how such changes could be explained to teachers and students? I recognize that some features cannot be so simply described. I used to tell my students that if they read their code out loud their grandmother should understand what they intended. Clearly something very unlikely today. Still, if we can describe features and syntax of Java in ways that a teacher or student could understand then the language may be even more relevant in education. So tell me what you think here or shout at me @omniprof. I'd love to see an Education mailing list here. Advice on how to start one will be appreciated. Thank-you for your time, [cid:image001.jpg at 01D5F0A0.AEAB1960] Ken Fogel Faculty email: kfogel at dawsoncollege.qc.ca phone: (514) 931-8731 local 4799 Dawson College, 3040 Sherbrooke St. W Westmount, Quebec, H3Z 1A4, Canada [facebook icon] [twitter icon] [youtube icon] [linkedin icon] [instagram icon] [cid:image007.jpg at 01D5F0A0.AEAB1960] [cid:image008.jpg at 01D5F0A0.AEAB1960] [cid:image009.png at 01D5F0A0.AEAB1960] From alex.buckley at oracle.com Mon Mar 2 23:30:11 2020 From: alex.buckley at oracle.com (Alex Buckley) Date: Mon, 2 Mar 2020 15:30:11 -0800 Subject: Introduction and Education In-Reply-To: References: Message-ID: <7a8a0956-570a-6f82-9fa3-9bcf47fca107@oracle.com> On 3/2/2020 12:16 PM, Kenneth Fogel wrote: > Should all proposals for changes to the JDK et al also include how > such changes could be explained to teachers and students? I recognize > that some features cannot be so simply described. I used to tell my > students that if they read their code out loud their grandmother > should understand what they intended. Clearly something very unlikely > today. Still, if we can describe features and syntax of Java in ways > that a teacher or student could understand then the language may be > even more relevant in education. The adoption of JEPs as the vehicle for proposing new features of the Java platform has been fantastically successful for boosting public understanding of such features. In my view, this is because a JEP demands two things from its author: (1) a summary that is extremely brief, and (2) a motivation of the problem that is separate from the description of the solution. At least for SE-scoped JEPs, the summary should be immediately understandable to ALL Java developers -- it's what a developer would tell a colleague at lunch. Then, the motivation gives the "real story" behind a proposal, building context and enthusiasm. The description of the new feature is where you put the examples, sketch the grammar, allude to the existence of corner cases, and show that you've considered migration. All of this material seems extremely helpful for students and teachers. In addition, when we present plans for new features at conferences, everyone in the audience is effectively a student. Even if those "students" are professional Java developers, they have a wide range of skill levels and ask all kinds of weird and wonderful questions. We strive to turn those interactions with "students" into better presentations and tighter, more convincing JEPs. (If only so that we don't have to answer the same obvious-to-the-audience-but-maybe-not-to-us questions in future.) Again, the results are directly available to help actual students and teachers understand what's coming. Finally, numerous Oracle engineers put a lot of time into reviewing drafts of articles and books by third parties. This is done on a best-effort basis, so I can't guarantee that the particular textbook used at Dawson College will include my preferred explanation of programming with modules, or Brian's preferred explanation of programming with streams. Nevertheless, the material that we contribute does get "out there", and informs how everyone, including students, learns new features. Alex From gnu.andrew at redhat.com Fri Mar 6 08:45:43 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Fri, 6 Mar 2020 08:45:43 +0000 Subject: OpenJDK Governing Board 2020 Election: Nominations Please In-Reply-To: <11c548e6-0554-4ca7-9875-7ece2ecd95a3@default> References: <11c548e6-0554-4ca7-9875-7ece2ecd95a3@default> Message-ID: <3338235b-308e-abbe-05e8-3f705cc56fe0@redhat.com> On 02/03/2020 19:30, Iris Clark wrote: > The OpenJDK Governing Board oversees the structure and operation of the > OpenJDK Community [1]. It has two At-Large Members who serve for a term of > one calendar year, nominally starting on the first day of April each year [2]. > > The two-week nomination period for candidates to fill those seats is now open. > It will end at 23:00 UTC on Monday, 16 March 2020 [3]. > > During this time any OpenJDK Member [4] may nominate an individual who does > not currently hold an appointed Governing Board seat to fill one of the > At-Large seats. That individual need not already be an OpenJDK Member. An > OpenJDK Member may make more than one such nomination. > > To nominate someone, send an e-mail message to members at openjdk.java.net > with the subject line "GB Nomination: $NAME", where $NAME is the full name of > the person you're nominating. Use the body of the message to make the best > case you can for your nominee. > > Nominees must accept their nominations by the start of voting. Those who do > accept will be invited to submit short candidate statements to be posted on > the election page [5]. > > Voting will start on Tuesday, 17 March 2020 and run for two weeks. All > OpenJDK Members as of the start of the voting period will be eligible to vote. > Detailed information on voting logistics will be available shortly. > > Iris > > [1] https://openjdk.java.net/bylaws#_9 > [2] https://openjdk.java.net/bylaws#at-large-members > [3] https://www.timeanddate.com/worldclock/fixedtime.html?msg=OpenJDK+GB+Nominations+Close&iso=20200316T23&sort=1 > [4] https://openjdk.java.net/census#members > [5] https://openjdk.java.net/poll/gb/2020 > Is it possible to make the start of voting a week later? Given this announcement was not made until late on the 2nd of March (19:30 GMT), and nomination to the OpenJDK members group needs a two week voting period, this makes it nearly impossible for someone seeing this announcement to become a member prior to the start of voting. For example, Martin Doerr was nominated yesterday [0] and the close of voting on this nomination will be two days *after* the start of the GB voting period, thus making him ineligible. [0] https://mail.openjdk.java.net/pipermail/members/2020-March/001063.html -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From mark.reinhold at oracle.com Fri Mar 6 22:25:37 2020 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Fri, 06 Mar 2020 14:25:37 -0800 Subject: OpenJDK Governing Board 2020 Election: Nominations Please In-Reply-To: <3338235b-308e-abbe-05e8-3f705cc56fe0@redhat.com> References: <11c548e6-0554-4ca7-9875-7ece2ecd95a3@default> <3338235b-308e-abbe-05e8-3f705cc56fe0@redhat.com> Message-ID: <20200306142537.815328591@eggemoggin.niobe.net> 2020/3/6 0:45:43 -0800, Andrew Hughes : > Is it possible to make the start of voting a week later? > > Given this announcement was not made until late on the 2nd of March > (19:30 GMT), and nomination to the OpenJDK members group needs a two > week voting period, this makes it nearly impossible for someone seeing > this announcement to become a member prior to the start of voting. I?ve asked the Governing Board to approve a motion to delay the start of the At-Large voting period by one week: https://mail.openjdk.java.net/pipermail/gb-discuss/2020-March/000352.html - Mark From bsrbnd at gmail.com Tue Mar 10 21:03:40 2020 From: bsrbnd at gmail.com (B. Blaser) Date: Tue, 10 Mar 2020 22:03:40 +0100 Subject: Enhancing expressions with mutability? Message-ID: Hi, Taking back the essential idea of the original publication on Lisp [1], I did the attached syntactic experiment [2] trying to bring some kind of mutability to expressions and thus giving more flexibility to the language. I hope this subject hasn't been covered too many times, otherwise I'd apologize for any disturbance. To build such mutable expressions, I've specified a new unary operator ` along with its resulting class 'java.lang.Term'. The quotation operator creates a 'Term' from any reference which can then be linked to other terms to finally be evaluated to the result of a function call for lambdas or the reference itself otherwise. Let's take some examples from the attached patch: + interface Get { + int op(); + } + + interface Sum { + int op(int i, int j); + } + int a = 0, b = 0; + Sum s = (x, y) -> x + y; + public void run() { + Get a = () -> this.a; + Get b = () -> this.b; + + Term e1 = (`s).link(`a, `b); + this.a = 1; this.b = 2; The above lines create a mutable expression e1 from the sum lambda s of the getter a and b which can then be evaluated to: (Integer)e1.value() == 3 or visualized as: e1.toString().equals("Sum( Get( ) Get( ) )") An interesting application similar to ?3.g from [1] is the computation of the partial derivative of a sum involving the mutation of the initial expression to produce a new resulting one: + // Derivative of sum e with respect to r + Term derivative(Term e, Term r) { + if (e.terms.isEmpty()) { + return `Integer.valueOf(e.that == r.that ? 1 : 0); + } + else if(e.that == (`s).that) { + return (`s).link(derivative(e.terms.get(0), r), derivative(e.terms.get(1), r)); + } + else throw new AssertionError(); + } Invoking the above method like this: + Term e2 = derivative(e1, `a); creates the resulting derivative expression e2 which can then be evaluated to: (Integer)e2.value() == 1 or visualized as: e2.toString().equals("Sum( `1 `0 )") Finally, we note that any term may be quoted to prevent its evaluation, for example: + Derivative d = this::derivative; + Term e3 = (`d).link(`e1, ``a); can be evaluated to: (Integer)((Term)e3.value()).value() == 1 or visualized as: e3.toString().equals("Derivative( `Sum( Get( ) Get( ) ) `Get( ) )") Of course, one of our main concern is how much do we need this and a reasonable answer would probably be as much as we need Lisp's S-expressions but with similar or maybe better performance than external interpreters and a more homogeneous integration to the language. Any feedback about this experiment would be welcome! Thanks, Bernard [1] http://www-formal.stanford.edu/jmc/recursive.html [2] quote.patch -------------- next part -------------- A non-text attachment was scrubbed... Name: quote.patch Type: text/x-patch Size: 18205 bytes Desc: not available URL: From jesper.wilhelmsson at oracle.com Wed Mar 11 23:51:27 2020 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Thu, 12 Mar 2020 00:51:27 +0100 Subject: Call for Discussion: New Project: Developer's Guide Message-ID: <62FA7D5A-5D25-4617-853F-3B0BC09CE154@oracle.com> Hi. I would like to discuss the possible creation of the Developer's Guide Project with myself, Jesper Wilhelmsson, as the lead and the Core-Libs, Compiler, and Hotspot groups as the sponsoring Groups. The initial goal of the project would be to create up-to-date guidelines for OpenJDK development and contributions. The intent is to update the existing OpenJDK Developer's Guide [1] which hasn't been updated since 2012. Parts of the existing guide are in need of updates while other parts are yet to be written. The initial source code for this project will be based on the current OpenJDK Developer's Guide. In more recent years some process related information has been published on the OpenJDK wiki [2], but this information was never reviewed or approved by the community. Even though large parts of this information may be accurate, it needs to go through proper review before it can be seen as official guidelines for OpenJDK development. Once the initial goal has been reached the project will transition into a maintenance project to keep the OpenJDK Developer's Guide up to date. The OpenJDK Developer's Guide is intended to contain tutorial style texts that give examples and step-by-step directions for common parts of the development process. Strict rules for OpenJDK development are better suited to a process JEP. The development of such a JEP is outside of the scope of this project but will be developed as part of a separate effort in parallel. Initial committers of the Developer's Guide Project include Mark Reinhold, Iris Clark, and Jesper Wilhelmsson. Additional committers may be identified through this discussion. The project will host at least one mailing list, guide-dev at openjdk.java.net, for discussions and reviews of changes. Thanks, /Jesper [1] http://openjdk.java.net/guide/ [2] https://wiki.openjdk.java.net/ From jonathan.gibbons at oracle.com Thu Mar 12 00:30:17 2020 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 11 Mar 2020 17:30:17 -0700 Subject: Call for Discussion: New Project: Developer's Guide In-Reply-To: <62FA7D5A-5D25-4617-853F-3B0BC09CE154@oracle.com> References: <62FA7D5A-5D25-4617-853F-3B0BC09CE154@oracle.com> Message-ID: Jesper, This is a great idea. Thanks for starting the discussion. The Compiler Group is pleased to sponsor such a Project. -- Jon On 03/11/2020 04:51 PM, Jesper Wilhelmsson wrote: > Hi. > > I would like to discuss the possible creation of the Developer's Guide Project > with myself, Jesper Wilhelmsson, as the lead and the Core-Libs, Compiler, and > Hotspot groups as the sponsoring Groups. > > The initial goal of the project would be to create up-to-date guidelines for > OpenJDK development and contributions. The intent is to update the existing > OpenJDK Developer's Guide [1] which hasn't been updated since 2012. Parts of > the existing guide are in need of updates while other parts are yet to be > written. The initial source code for this project will be based on the current > OpenJDK Developer's Guide. > > In more recent years some process related information has been published on the > OpenJDK wiki [2], but this information was never reviewed or approved by the > community. Even though large parts of this information may be accurate, it needs > to go through proper review before it can be seen as official guidelines for > OpenJDK development. > > Once the initial goal has been reached the project will transition into a > maintenance project to keep the OpenJDK Developer's Guide up to date. > > The OpenJDK Developer's Guide is intended to contain tutorial style texts that > give examples and step-by-step directions for common parts of the development > process. Strict rules for OpenJDK development are better suited to a process > JEP. The development of such a JEP is outside of the scope of this project but > will be developed as part of a separate effort in parallel. > > Initial committers of the Developer's Guide Project include Mark Reinhold, Iris > Clark, and Jesper Wilhelmsson. Additional committers may be identified through > this discussion. > > The project will host at least one mailing list, guide-dev at openjdk.java.net, > for discussions and reviews of changes. > > Thanks, > /Jesper > > [1] http://openjdk.java.net/guide/ > [2] https://wiki.openjdk.java.net/ > From martijnverburg at gmail.com Thu Mar 12 08:55:14 2020 From: martijnverburg at gmail.com (Martijn Verburg) Date: Thu, 12 Mar 2020 08:55:14 +0000 Subject: Call for Discussion: New Project: Developer's Guide In-Reply-To: References: <62FA7D5A-5D25-4617-853F-3B0BC09CE154@oracle.com> Message-ID: We'd (MSFT) be very happy to contribute (our group is fairly new to OpenJDK, so it's good timing)! Cheers, Martijn On Thu, 12 Mar 2020 at 00:30, Jonathan Gibbons wrote: > Jesper, > > This is a great idea. Thanks for starting the discussion. > > The Compiler Group is pleased to sponsor such a Project. > > -- Jon > > > On 03/11/2020 04:51 PM, Jesper Wilhelmsson wrote: > > Hi. > > > > I would like to discuss the possible creation of the Developer's Guide > Project > > with myself, Jesper Wilhelmsson, as the lead and the Core-Libs, > Compiler, and > > Hotspot groups as the sponsoring Groups. > > > > The initial goal of the project would be to create up-to-date guidelines > for > > OpenJDK development and contributions. The intent is to update the > existing > > OpenJDK Developer's Guide [1] which hasn't been updated since 2012. > Parts of > > the existing guide are in need of updates while other parts are yet to be > > written. The initial source code for this project will be based on the > current > > OpenJDK Developer's Guide. > > > > In more recent years some process related information has been published > on the > > OpenJDK wiki [2], but this information was never reviewed or approved by > the > > community. Even though large parts of this information may be accurate, > it needs > > to go through proper review before it can be seen as official guidelines > for > > OpenJDK development. > > > > Once the initial goal has been reached the project will transition into a > > maintenance project to keep the OpenJDK Developer's Guide up to date. > > > > The OpenJDK Developer's Guide is intended to contain tutorial style > texts that > > give examples and step-by-step directions for common parts of the > development > > process. Strict rules for OpenJDK development are better suited to a > process > > JEP. The development of such a JEP is outside of the scope of this > project but > > will be developed as part of a separate effort in parallel. > > > > Initial committers of the Developer's Guide Project include Mark > Reinhold, Iris > > Clark, and Jesper Wilhelmsson. Additional committers may be identified > through > > this discussion. > > > > The project will host at least one mailing list, > guide-dev at openjdk.java.net, > > for discussions and reviews of changes. > > > > Thanks, > > /Jesper > > > > [1] http://openjdk.java.net/guide/ > > [2] https://wiki.openjdk.java.net/ > > > > From jesper.wilhelmsson at oracle.com Thu Mar 12 12:10:50 2020 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Thu, 12 Mar 2020 13:10:50 +0100 Subject: Call for Discussion: New Project: Developer's Guide In-Reply-To: References: <62FA7D5A-5D25-4617-853F-3B0BC09CE154@oracle.com> Message-ID: Thank you for your support! /Jesper > On 12 Mar 2020, at 01:30, Jonathan Gibbons wrote: > > Jesper, > > This is a great idea. Thanks for starting the discussion. > > The Compiler Group is pleased to sponsor such a Project. > > -- Jon > > > On 03/11/2020 04:51 PM, Jesper Wilhelmsson wrote: >> Hi. >> >> I would like to discuss the possible creation of the Developer's Guide Project >> with myself, Jesper Wilhelmsson, as the lead and the Core-Libs, Compiler, and >> Hotspot groups as the sponsoring Groups. >> >> The initial goal of the project would be to create up-to-date guidelines for >> OpenJDK development and contributions. The intent is to update the existing >> OpenJDK Developer's Guide [1] which hasn't been updated since 2012. Parts of >> the existing guide are in need of updates while other parts are yet to be >> written. The initial source code for this project will be based on the current >> OpenJDK Developer's Guide. >> >> In more recent years some process related information has been published on the >> OpenJDK wiki [2], but this information was never reviewed or approved by the >> community. Even though large parts of this information may be accurate, it needs >> to go through proper review before it can be seen as official guidelines for >> OpenJDK development. >> >> Once the initial goal has been reached the project will transition into a >> maintenance project to keep the OpenJDK Developer's Guide up to date. >> >> The OpenJDK Developer's Guide is intended to contain tutorial style texts that >> give examples and step-by-step directions for common parts of the development >> process. Strict rules for OpenJDK development are better suited to a process >> JEP. The development of such a JEP is outside of the scope of this project but >> will be developed as part of a separate effort in parallel. >> >> Initial committers of the Developer's Guide Project include Mark Reinhold, Iris >> Clark, and Jesper Wilhelmsson. Additional committers may be identified through >> this discussion. >> >> The project will host at least one mailing list, guide-dev at openjdk.java.net, >> for discussions and reviews of changes. >> >> Thanks, >> /Jesper >> >> [1] http://openjdk.java.net/guide/ >> [2] https://wiki.openjdk.java.net/ >> > From jesper.wilhelmsson at oracle.com Thu Mar 12 12:18:53 2020 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Thu, 12 Mar 2020 13:18:53 +0100 Subject: Call for Discussion: New Project: Developer's Guide In-Reply-To: References: <62FA7D5A-5D25-4617-853F-3B0BC09CE154@oracle.com> Message-ID: <3CA5F578-A3F3-45E5-8202-CBB769B0BF62@oracle.com> Sounds good Martijn. We will likely need help both authoring and reviewing these texts so the more the merrier :-) Thanks, /Jesper > On 12 Mar 2020, at 09:55, Martijn Verburg wrote: > > We'd (MSFT) be very happy to contribute (our group is fairly new to OpenJDK, so it's good timing)! > > Cheers, > Martijn > > > On Thu, 12 Mar 2020 at 00:30, Jonathan Gibbons > wrote: > Jesper, > > This is a great idea. Thanks for starting the discussion. > > The Compiler Group is pleased to sponsor such a Project. > > -- Jon > > > On 03/11/2020 04:51 PM, Jesper Wilhelmsson wrote: > > Hi. > > > > I would like to discuss the possible creation of the Developer's Guide Project > > with myself, Jesper Wilhelmsson, as the lead and the Core-Libs, Compiler, and > > Hotspot groups as the sponsoring Groups. > > > > The initial goal of the project would be to create up-to-date guidelines for > > OpenJDK development and contributions. The intent is to update the existing > > OpenJDK Developer's Guide [1] which hasn't been updated since 2012. Parts of > > the existing guide are in need of updates while other parts are yet to be > > written. The initial source code for this project will be based on the current > > OpenJDK Developer's Guide. > > > > In more recent years some process related information has been published on the > > OpenJDK wiki [2], but this information was never reviewed or approved by the > > community. Even though large parts of this information may be accurate, it needs > > to go through proper review before it can be seen as official guidelines for > > OpenJDK development. > > > > Once the initial goal has been reached the project will transition into a > > maintenance project to keep the OpenJDK Developer's Guide up to date. > > > > The OpenJDK Developer's Guide is intended to contain tutorial style texts that > > give examples and step-by-step directions for common parts of the development > > process. Strict rules for OpenJDK development are better suited to a process > > JEP. The development of such a JEP is outside of the scope of this project but > > will be developed as part of a separate effort in parallel. > > > > Initial committers of the Developer's Guide Project include Mark Reinhold, Iris > > Clark, and Jesper Wilhelmsson. Additional committers may be identified through > > this discussion. > > > > The project will host at least one mailing list, guide-dev at openjdk.java.net , > > for discussions and reviews of changes. > > > > Thanks, > > /Jesper > > > > [1] http://openjdk.java.net/guide/ > > [2] https://wiki.openjdk.java.net/ > > > From felixxfyang at tencent.com Thu Mar 12 12:35:22 2020 From: felixxfyang at tencent.com (=?utf-8?B?ZmVsaXh4Znlhbmco5p2o5pmT5bOwKQ==?=) Date: Thu, 12 Mar 2020 12:35:22 +0000 Subject: Call for Discussion: New Project: Developer's Guide(Internet mail) In-Reply-To: <62FA7D5A-5D25-4617-853F-3B0BC09CE154@oracle.com> References: <62FA7D5A-5D25-4617-853F-3B0BC09CE154@oracle.com> Message-ID: Hi Jesper, This is badly needed! We ( Tencent) will be happy to contribute too. Best Regards, Felix Yang ?? 2020/3/12 ??7:53??discuss ?? Jesper Wilhelmsson? ??: Hi. I would like to discuss the possible creation of the Developer's Guide Project with myself, Jesper Wilhelmsson, as the lead and the Core-Libs, Compiler, and Hotspot groups as the sponsoring Groups. The initial goal of the project would be to create up-to-date guidelines for OpenJDK development and contributions. The intent is to update the existing OpenJDK Developer's Guide [1] which hasn't been updated since 2012. Parts of the existing guide are in need of updates while other parts are yet to be written. The initial source code for this project will be based on the current OpenJDK Developer's Guide. In more recent years some process related information has been published on the OpenJDK wiki [2], but this information was never reviewed or approved by the community. Even though large parts of this information may be accurate, it needs to go through proper review before it can be seen as official guidelines for OpenJDK development. Once the initial goal has been reached the project will transition into a maintenance project to keep the OpenJDK Developer's Guide up to date. The OpenJDK Developer's Guide is intended to contain tutorial style texts that give examples and step-by-step directions for common parts of the development process. Strict rules for OpenJDK development are better suited to a process JEP. The development of such a JEP is outside of the scope of this project but will be developed as part of a separate effort in parallel. Initial committers of the Developer's Guide Project include Mark Reinhold, Iris Clark, and Jesper Wilhelmsson. Additional committers may be identified through this discussion. The project will host at least one mailing list, guide-dev at openjdk.java.net, for discussions and reviews of changes. Thanks, /Jesper [1] http://openjdk.java.net/guide/ [2] https://wiki.openjdk.java.net/ From Alan.Bateman at oracle.com Thu Mar 12 12:43:03 2020 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 12 Mar 2020 12:43:03 +0000 Subject: Call for Discussion: New Project: Developer's Guide In-Reply-To: <62FA7D5A-5D25-4617-853F-3B0BC09CE154@oracle.com> References: <62FA7D5A-5D25-4617-853F-3B0BC09CE154@oracle.com> Message-ID: <6bf428d6-040c-8c61-a84a-16b97725c970@oracle.com> On 11/03/2020 23:51, Jesper Wilhelmsson wrote: > Hi. > > I would like to discuss the possible creation of the Developer's Guide Project > with myself, Jesper Wilhelmsson, as the lead and the Core-Libs, Compiler, and > Hotspot groups as the sponsoring Groups. The libraries areas gets a lot of first time contributors and the current v0.02 guide has been crying out for attention since the OpenJDK started. So this is a great idea, the Core Libraies group would be pleased to sponsor this project too. -Alan. From jesper.wilhelmsson at oracle.com Thu Mar 12 14:33:29 2020 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Thu, 12 Mar 2020 15:33:29 +0100 Subject: Call for Discussion: New Project: Developer's Guide In-Reply-To: <6bf428d6-040c-8c61-a84a-16b97725c970@oracle.com> References: <62FA7D5A-5D25-4617-853F-3B0BC09CE154@oracle.com> <6bf428d6-040c-8c61-a84a-16b97725c970@oracle.com> Message-ID: <89C0528C-F1FC-43BF-9254-1A3C6A0DF298@oracle.com> > On 12 Mar 2020, at 13:43, Alan Bateman wrote: > > On 11/03/2020 23:51, Jesper Wilhelmsson wrote: >> Hi. >> >> I would like to discuss the possible creation of the Developer's Guide Project >> with myself, Jesper Wilhelmsson, as the lead and the Core-Libs, Compiler, and >> Hotspot groups as the sponsoring Groups. > The libraries areas gets a lot of first time contributors and the current v0.02 guide has been crying out for attention since the OpenJDK started. So this is a great idea, the Core Libraies group would be pleased to sponsor this project too. Thank you for your support! /Jesper > -Alan. From jesper.wilhelmsson at oracle.com Thu Mar 12 14:45:06 2020 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Thu, 12 Mar 2020 15:45:06 +0100 Subject: Call for Discussion: New Project: Developer's Guide(Internet mail) In-Reply-To: References: <62FA7D5A-5D25-4617-853F-3B0BC09CE154@oracle.com> Message-ID: <0AED9DCA-7648-4350-8DDC-89511DC7696A@oracle.com> That's good to hear. Thanks, /Jesper > On 12 Mar 2020, at 13:35, felixxfyang(???) wrote: > > Hi Jesper, > This is badly needed! We ( Tencent) will be happy to contribute too. > > Best Regards, > Felix Yang > ?? 2020/3/12 ??7:53??discuss ?? Jesper Wilhelmsson? ??: > > Hi. > > I would like to discuss the possible creation of the Developer's Guide Project > with myself, Jesper Wilhelmsson, as the lead and the Core-Libs, Compiler, and > Hotspot groups as the sponsoring Groups. > > The initial goal of the project would be to create up-to-date guidelines for > OpenJDK development and contributions. The intent is to update the existing > OpenJDK Developer's Guide [1] which hasn't been updated since 2012. Parts of > the existing guide are in need of updates while other parts are yet to be > written. The initial source code for this project will be based on the current > OpenJDK Developer's Guide. > > In more recent years some process related information has been published on the > OpenJDK wiki [2], but this information was never reviewed or approved by the > community. Even though large parts of this information may be accurate, it needs > to go through proper review before it can be seen as official guidelines for > OpenJDK development. > > Once the initial goal has been reached the project will transition into a > maintenance project to keep the OpenJDK Developer's Guide up to date. > > The OpenJDK Developer's Guide is intended to contain tutorial style texts that > give examples and step-by-step directions for common parts of the development > process. Strict rules for OpenJDK development are better suited to a process > JEP. The development of such a JEP is outside of the scope of this project but > will be developed as part of a separate effort in parallel. > > Initial committers of the Developer's Guide Project include Mark Reinhold, Iris > Clark, and Jesper Wilhelmsson. Additional committers may be identified through > this discussion. > > The project will host at least one mailing list, guide-dev at openjdk.java.net, > for discussions and reviews of changes. > > Thanks, > /Jesper > > [1] http://openjdk.java.net/guide/ > [2] https://wiki.openjdk.java.net/ > > > > From bsrbnd at gmail.com Thu Mar 12 17:36:53 2020 From: bsrbnd at gmail.com (B. Blaser) Date: Thu, 12 Mar 2020 18:36:53 +0100 Subject: [Feedback request] Enhancing expressions with mutability? (other use cases) In-Reply-To: References: Message-ID: To go a bit further, it'd be also possible to add another field to the 'Term' class representing the name of any quoted identifier, which can concretely be made in 'Lower' by adding a couple of lines like 'makeLit(syms.stringType, ((JCIdent _or_ JCFieldAccess)arg).name.toString())' (I can share the full diff with the previous 'quote.patch' if requested). We can then use it like '(`d _or_ `this.d).name.equals("d")' in our initial example. So, not to misunderstand me, this isn't a meta-programming facility by itself but a fortunate consequence of the quotation operator which might be used to considerably reduce the amount of code in certain situations like persistence frameworks. And note also that mutable expressions might be used to build queries using a more declarative fashion, for example. Isn't that still a direction which is worth exploring? Thanks, Bernard On Tue, 10 Mar 2020 at 22:03, B. Blaser wrote: > > Hi, > > Taking back the essential idea of the original publication on Lisp > [1], I did the attached syntactic experiment [2] trying to bring some > kind of mutability to expressions and thus giving more flexibility to > the language. I hope this subject hasn't been covered too many times, > otherwise I'd apologize for any disturbance. > > To build such mutable expressions, I've specified a new unary operator > ` along with its resulting class 'java.lang.Term'. The quotation > operator creates a 'Term' from any reference which can then be linked > to other terms to finally be evaluated to the result of a function > call for lambdas or the reference itself otherwise. > > Let's take some examples from the attached patch: > > + interface Get { > + int op(); > + } > + > + interface Sum { > + int op(int i, int j); > + } > > + int a = 0, b = 0; > + Sum s = (x, y) -> x + y; > > + public void run() { > + Get a = () -> this.a; > + Get b = () -> this.b; > + > + Term e1 = (`s).link(`a, `b); > + this.a = 1; this.b = 2; > > The above lines create a mutable expression e1 from the sum lambda s > of the getter a and b which can then be evaluated to: > > (Integer)e1.value() == 3 > > or visualized as: > > e1.toString().equals("Sum( Get( ) Get( ) )") > > An interesting application similar to ?3.g from [1] is the computation > of the partial derivative of a sum involving the mutation of the > initial expression to produce a new resulting one: > > + // Derivative of sum e with respect to r > + Term derivative(Term e, Term r) { > + if (e.terms.isEmpty()) { > + return `Integer.valueOf(e.that == r.that ? 1 : 0); > + } > + else if(e.that == (`s).that) { > + return (`s).link(derivative(e.terms.get(0), r), > derivative(e.terms.get(1), r)); > + } > + else throw new AssertionError(); > + } > > Invoking the above method like this: > > + Term e2 = derivative(e1, `a); > > creates the resulting derivative expression e2 which can then be evaluated to: > > (Integer)e2.value() == 1 > > or visualized as: > > e2.toString().equals("Sum( `1 `0 )") > > Finally, we note that any term may be quoted to prevent its > evaluation, for example: > > + Derivative d = this::derivative; > > + Term e3 = (`d).link(`e1, ``a); > > can be evaluated to: > > (Integer)((Term)e3.value()).value() == 1 > > or visualized as: > > e3.toString().equals("Derivative( `Sum( Get( ) Get( ) ) `Get( ) )") > > Of course, one of our main concern is how much do we need this and a > reasonable answer would probably be as much as we need Lisp's > S-expressions but with similar or maybe better performance than > external interpreters and a more homogeneous integration to the > language. > > Any feedback about this experiment would be welcome! > > Thanks, > Bernard > > [1] http://www-formal.stanford.edu/jmc/recursive.html > [2] quote.patch From vladimir.kozlov at oracle.com Thu Mar 12 18:12:56 2020 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 12 Mar 2020 11:12:56 -0700 Subject: Call for Discussion: New Project: Developer's Guide In-Reply-To: <62FA7D5A-5D25-4617-853F-3B0BC09CE154@oracle.com> References: <62FA7D5A-5D25-4617-853F-3B0BC09CE154@oracle.com> Message-ID: Finally we can collect information spread all over internet in one place! The HotSpot group will gladly participate in sponsoring this project. Regards, Vladimir Kozlov On 3/11/20 4:51 PM, Jesper Wilhelmsson wrote: > Hi. > > I would like to discuss the possible creation of the Developer's Guide Project > with myself, Jesper Wilhelmsson, as the lead and the Core-Libs, Compiler, and > Hotspot groups as the sponsoring Groups. > > The initial goal of the project would be to create up-to-date guidelines for > OpenJDK development and contributions. The intent is to update the existing > OpenJDK Developer's Guide [1] which hasn't been updated since 2012. Parts of > the existing guide are in need of updates while other parts are yet to be > written. The initial source code for this project will be based on the current > OpenJDK Developer's Guide. > > In more recent years some process related information has been published on the > OpenJDK wiki [2], but this information was never reviewed or approved by the > community. Even though large parts of this information may be accurate, it needs > to go through proper review before it can be seen as official guidelines for > OpenJDK development. > > Once the initial goal has been reached the project will transition into a > maintenance project to keep the OpenJDK Developer's Guide up to date. > > The OpenJDK Developer's Guide is intended to contain tutorial style texts that > give examples and step-by-step directions for common parts of the development > process. Strict rules for OpenJDK development are better suited to a process > JEP. The development of such a JEP is outside of the scope of this project but > will be developed as part of a separate effort in parallel. > > Initial committers of the Developer's Guide Project include Mark Reinhold, Iris > Clark, and Jesper Wilhelmsson. Additional committers may be identified through > this discussion. > > The project will host at least one mailing list, guide-dev at openjdk.java.net, > for discussions and reviews of changes. > > Thanks, > /Jesper > > [1] http://openjdk.java.net/guide/ > [2] https://wiki.openjdk.java.net/ > From jesper.wilhelmsson at oracle.com Thu Mar 12 18:24:24 2020 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Thu, 12 Mar 2020 19:24:24 +0100 Subject: Call for Discussion: New Project: Developer's Guide In-Reply-To: References: <62FA7D5A-5D25-4617-853F-3B0BC09CE154@oracle.com> Message-ID: <9FE01EAF-159F-4C99-886C-A8DA6BA1622B@oracle.com> Thank you for your support Vladimir! /Jesper > On 12 Mar 2020, at 19:12, Vladimir Kozlov wrote: > > Finally we can collect information spread all over internet in one place! > The HotSpot group will gladly participate in sponsoring this project. > > Regards, > Vladimir Kozlov > > On 3/11/20 4:51 PM, Jesper Wilhelmsson wrote: >> Hi. >> I would like to discuss the possible creation of the Developer's Guide Project >> with myself, Jesper Wilhelmsson, as the lead and the Core-Libs, Compiler, and >> Hotspot groups as the sponsoring Groups. >> The initial goal of the project would be to create up-to-date guidelines for >> OpenJDK development and contributions. The intent is to update the existing >> OpenJDK Developer's Guide [1] which hasn't been updated since 2012. Parts of >> the existing guide are in need of updates while other parts are yet to be >> written. The initial source code for this project will be based on the current >> OpenJDK Developer's Guide. >> In more recent years some process related information has been published on the >> OpenJDK wiki [2], but this information was never reviewed or approved by the >> community. Even though large parts of this information may be accurate, it needs >> to go through proper review before it can be seen as official guidelines for >> OpenJDK development. >> Once the initial goal has been reached the project will transition into a >> maintenance project to keep the OpenJDK Developer's Guide up to date. >> The OpenJDK Developer's Guide is intended to contain tutorial style texts that >> give examples and step-by-step directions for common parts of the development >> process. Strict rules for OpenJDK development are better suited to a process >> JEP. The development of such a JEP is outside of the scope of this project but >> will be developed as part of a separate effort in parallel. >> Initial committers of the Developer's Guide Project include Mark Reinhold, Iris >> Clark, and Jesper Wilhelmsson. Additional committers may be identified through >> this discussion. >> The project will host at least one mailing list, guide-dev at openjdk.java.net, >> for discussions and reviews of changes. >> Thanks, >> /Jesper >> [1] http://openjdk.java.net/guide/ >> [2] https://wiki.openjdk.java.net/ From mark.reinhold at oracle.com Thu Mar 12 20:47:58 2020 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Thu, 12 Mar 2020 13:47:58 -0700 Subject: OpenJDK Governing Board 2020 Election: Nominations Please In-Reply-To: <20200306142537.815328591@eggemoggin.niobe.net> References: <11c548e6-0554-4ca7-9875-7ece2ecd95a3@default> <3338235b-308e-abbe-05e8-3f705cc56fe0@redhat.com> <20200306142537.815328591@eggemoggin.niobe.net> Message-ID: <20200312134758.515793464@eggemoggin.niobe.net> 2020/3/6 14:25:37 -0800, mark.reinhold at oracle.com: > 2020/3/6 0:45:43 -0800, Andrew Hughes : >> Is it possible to make the start of voting a week later? >> >> Given this announcement was not made until late on the 2nd of March >> (19:30 GMT), and nomination to the OpenJDK members group needs a two >> week voting period, this makes it nearly impossible for someone seeing >> this announcement to become a member prior to the start of voting. > > I?ve asked the Governing Board to approve a motion to delay the start > of the At-Large voting period by one week: > > https://mail.openjdk.java.net/pipermail/gb-discuss/2020-March/000352.html The Governing Board has approved the motion: https://mail.openjdk.java.net/pipermail/gb-discuss/2020-March/000357.html The 2020 Governing Board Election will begin on Tuesday, 24 March. - Mark From john.r.rose at oracle.com Fri Mar 13 05:04:28 2020 From: john.r.rose at oracle.com (John Rose) Date: Thu, 12 Mar 2020 22:04:28 -0700 Subject: Call for Discussion: New Project: Developer's Guide In-Reply-To: References: <62FA7D5A-5D25-4617-853F-3B0BC09CE154@oracle.com> Message-ID: <258E790C-13BA-44B9-8ECF-37FC5C96B59D@oracle.com> On Mar 12, 2020, at 1:55 AM, Martijn Verburg wrote: > > We'd (MSFT) be very happy to contribute (our group is fairly new to > OpenJDK, so it's good timing)! Martijn, we are absolutely delighted your team is here! I love some of the compiler explorations I?ve already seen from you folks, such as Ludovic?s PIC work. I?m going to make up a story which may or may not be relevant to this thread. I think it is. Some hospital is gearing up to refresh its policy guides, and a new doc shows up saying, ?I?m fairly new to this place, so it?s good timing to put me on that committee.? Hopefully the new doc was on a similar committee in some previous hospital, or has spent a few decades thinking about hospital policy. Even so, the doc?s contributions will have to be adjusted to the needs of the present hospital, and this will require that the new doc spend a lot of time and effort getting the feel of how things are done in the new place. The most efficient way to do that is probably to assist in some surgeries, work in the path lab, and so on, to get the necessary local perspective. How should the newly forming policy committee respond to the new doc?s friendly request to be helpful? In this toy example, the policy committee is somehow codifying some low-level, everyday best practices that all the staff of the hospital will be encouraged to follow. Various outcomes are possible, the best being that the policy committee highlights practices that everyone is willing to follow, and that actually help. The second best is that, however mixed-up the committee?s findings are, the staff can quietly ignore them. Anyone who?s ever served on a standards committee, or watched one operate, can probably imagine less constructive scenarios. I think a Developer?s Guide is something that should codify our best practices as we understand them and have lived them not only now but in some ?significant past? leading up to now (not all the past). So the hard work of creating one is to actually go out and measure what?s been done, what?s worked and what doesn?t; or if it can?t be measured, get a large amount of evidence from experience. Martijn, I?m sure you get what I?m talking about, and that you have a good idea of what you want to contribute. I suggest that you say more about this, more concretely. It won?t be ?You guys should just act like my last project? but it could be more like ?On my last project I learned some stuff which is similar to what you guys are about, and I think I can help clarify that.? And I suggest the same to others who are responding with a ?count me in?. This project will require (as Liam Neeson might say) ?a very particular set of skills, ?acquired over a very long career.? It is not a starter task, as far as I can tell. However, I?ll give deference to Jesper, who might have a different vision for this. Is this message just the old guard circling the wagons? No. Nor are other messages the newcomers mounting a hostile takeover. People clearly want to be helpful. The important thing is adding value to our shared project, however long we?ve been on it. And, because of its wide impact, as a sort of policy document, a style guide will inevitably require some steering from whatever folks have global knowledge of the project, even responsibility, starting with Mark. That comes, usually though not always, after long association. HTH ? John From fw at deneb.enyo.de Fri Mar 13 06:04:15 2020 From: fw at deneb.enyo.de (Florian Weimer) Date: Fri, 13 Mar 2020 07:04:15 +0100 Subject: Call for Discussion: New Project: Developer's Guide In-Reply-To: <258E790C-13BA-44B9-8ECF-37FC5C96B59D@oracle.com> (John Rose's message of "Thu, 12 Mar 2020 22:04:28 -0700") References: <62FA7D5A-5D25-4617-853F-3B0BC09CE154@oracle.com> <258E790C-13BA-44B9-8ECF-37FC5C96B59D@oracle.com> Message-ID: <87h7ysssdc.fsf@mid.deneb.enyo.de> * John Rose: > And I suggest the same to others who are responding > with a ?count me in?. This project will require (as > Liam Neeson might say) ?a very particular set of skills, > ?acquired over a very long career.? It is not a starter > task, as far as I can tell. However, I?ll give deference to > Jesper, who might have a different vision for this. Wouldn't input from people not completely familiar with the processes be valuable, so that it becomes clearer what needs documenting? From john.r.rose at oracle.com Fri Mar 13 08:34:35 2020 From: john.r.rose at oracle.com (John Rose) Date: Fri, 13 Mar 2020 01:34:35 -0700 Subject: Call for Discussion: New Project: Developer's Guide In-Reply-To: <87h7ysssdc.fsf@mid.deneb.enyo.de> References: <62FA7D5A-5D25-4617-853F-3B0BC09CE154@oracle.com> <258E790C-13BA-44B9-8ECF-37FC5C96B59D@oracle.com> <87h7ysssdc.fsf@mid.deneb.enyo.de> Message-ID: <91A0E45E-3383-4EEE-8773-2926138CC2DF@oracle.com> On Mar 12, 2020, at 11:04 PM, Florian Weimer wrote: > > * John Rose: > >> And I suggest the same to others who are responding >> with a ?count me in?. This project will require (as >> Liam Neeson might say) ?a very particular set of skills, >> ?acquired over a very long career.? It is not a starter >> task, as far as I can tell. However, I?ll give deference to >> Jesper, who might have a different vision for this. > > Wouldn't input from people not completely familiar with the processes > be valuable, so that it becomes clearer what needs documenting? That?s a very good point. Must that input be obtained by recruiting such people as project members, or can it be acquired via other means such as questionnaires and experience reports? Also, to be honest: I missed the import of Jesper?s initial statement, ?Strict rules for OpenJDK development are? outside of the scope of this project.? I think this means that vexed questions like code reviews and style guides are off the table for now, which means the analogy of a hospital policy committee is not nearly as applicable as I thought it was. My apologies! A new person?s experience is precious and should be captured quickly, before it is forgotten. My first response to Martijn didn?t do justice to this fact. We old-timers have no clue anymore what we know and how we learned it the first time; ?how to learn it? is the whole job of a new person?but they forget quickly once they learn the ropes. Watching this over and over again, I have noticed that we have no good way to capture those new-person experiences. (Long-haul experiences, on the other hand, are abundantly documented. The problem there is it goes stale after a few years.) I?d be really interested to hear from people who have seen successful capture of information from new folks to improve on-boarding. My best take on it is to have a place where new folks can share what they are learning *when the experience is fresh*, in such a way that their more experienced team mates can use it as raw material for the next revision of the on-boarding guide. I wish there were an OpenJDK wiki which would be immediately open to all OpenJDK authors, exactly for this purpose, but our infra isn?t set up that way. Imagine reading the experience reports of the last ten years of new folks, explaining what went right and wrong, and commenting on each others? experience? The closest thing we have to this is email archives, which are disorganized, and the cr.ojn pages, which are isolated (and not intended for documentation, though useful for it nevertheless). Regarding the parts of the guide which would be for long-haul use (not on-boarding), a big problem is extracting the information from people who have been working with the existing practices for long enough to know their good sides and bad sides. There?s always the problem of keeping such documentation fresh. Also, I think such a guide should be more descriptive than prescriptive. (Today in a different thread I talked about descriptive vs. prescriptive, in the setting of a proposal for a new prescriptive code style enforced by robots.) The current proposal to avoid ?strict? rules would seem to avoid the risks of prescriptiveness, for now. Is there a difference between ?long haul? and ?on-boarding? documentation? Yes, because they are for different audiences. Every project demands that the new folks learn a bunch of stuff before they do anything; hopefully it?s not too much and it?s easy to learn, and then your apprenticeship begins. Also, every project has a much larger set of best practices and specifications which don?t need to be learned up front, but which still shape the project as a whole. No one person knows them all at once, but people need to refer to them. I?m talking about documentation like ?how to do gatekeeping? or ?what are the bytecodes of the JVM?. I would think those would go into a dev-guide of some sort, but in a different place than the important ?how to get started? sections. I hope Jesper will have more comments on these puzzles. ? John From martijnverburg at gmail.com Fri Mar 13 09:37:31 2020 From: martijnverburg at gmail.com (Martijn Verburg) Date: Fri, 13 Mar 2020 09:37:31 +0000 Subject: Call for Discussion: New Project: Developer's Guide In-Reply-To: <91A0E45E-3383-4EEE-8773-2926138CC2DF@oracle.com> References: <62FA7D5A-5D25-4617-853F-3B0BC09CE154@oracle.com> <258E790C-13BA-44B9-8ECF-37FC5C96B59D@oracle.com> <87h7ysssdc.fsf@mid.deneb.enyo.de> <91A0E45E-3383-4EEE-8773-2926138CC2DF@oracle.com> Message-ID: Hi John, I totally get where you are coming from and the intent of message, all good! Our group will be happy to help Jesper et al in *whatever capacity he and the other experienced folks want us to*. If that?s just reviewing drafts as newcomers or doing something like (dare I say it boring) formatting work then we will roll up sleeves and do just that ??. Cheers, Martijn On Fri, 13 Mar 2020 at 08:34, John Rose wrote: > On Mar 12, 2020, at 11:04 PM, Florian Weimer wrote: > > > > * John Rose: > > > >> And I suggest the same to others who are responding > >> with a ?count me in?. This project will require (as > >> Liam Neeson might say) ?a very particular set of skills, > >> ?acquired over a very long career.? It is not a starter > >> task, as far as I can tell. However, I?ll give deference to > >> Jesper, who might have a different vision for this. > > > > Wouldn't input from people not completely familiar with the processes > > be valuable, so that it becomes clearer what needs documenting? > > That?s a very good point. Must that input be obtained by recruiting > such people as project members, or can it be acquired via other > means such as questionnaires and experience reports? > > Also, to be honest: I missed the import of Jesper?s > initial statement, ?Strict rules for OpenJDK development > are? outside of the scope of this project.? I think this > means that vexed questions like code reviews and style > guides are off the table for now, which means the analogy > of a hospital policy committee is not nearly as applicable > as I thought it was. My apologies! > > A new person?s experience is precious and should > be captured quickly, before it is forgotten. My first > response to Martijn didn?t do justice to this fact. > We old-timers have no clue anymore what we know > and how we learned it the first time; ?how to learn > it? is the whole job of a new person?but they forget > quickly once they learn the ropes. Watching this > over and over again, I have noticed that we have no > good way to capture those new-person experiences. > (Long-haul experiences, on the other hand, are > abundantly documented. The problem there is it > goes stale after a few years.) I?d be really interested > to hear from people who have seen successful capture > of information from new folks to improve on-boarding. > My best take on it is to have a place where new folks > can share what they are learning *when the experience > is fresh*, in such a way that their more experienced > team mates can use it as raw material for the next > revision of the on-boarding guide. > > I wish there were an OpenJDK wiki which would be > immediately open to all OpenJDK authors, exactly > for this purpose, but our infra isn?t set up that way. > Imagine reading the experience reports of the last > ten years of new folks, explaining what went right > and wrong, and commenting on each others? > experience? The closest thing we have to this is > email archives, which are disorganized, and the > cr.ojn pages, which are isolated (and not intended > for documentation, though useful for it nevertheless). > > Regarding the parts of the guide which would be for > long-haul use (not on-boarding), a big problem is > extracting the information from people who have been > working with the existing practices for long enough to > know their good sides and bad sides. There?s always > the problem of keeping such documentation fresh. > > Also, I think such a guide should be more descriptive > than prescriptive. (Today in a different thread I > talked about descriptive vs. prescriptive, in the setting > of a proposal for a new prescriptive code style enforced > by robots.) The current proposal to avoid ?strict? rules > would seem to avoid the risks of prescriptiveness, for now. > > Is there a difference between ?long haul? and ?on-boarding? > documentation? Yes, because they are for different audiences. > Every project demands that the new folks learn a bunch of > stuff before they do anything; hopefully it?s not too much > and it?s easy to learn, and then your apprenticeship begins. > Also, every project has a much larger set of best practices > and specifications which don?t need to be learned up front, > but which still shape the project as a whole. No one person > knows them all at once, but people need to refer to them. > I?m talking about documentation like ?how to do gatekeeping? > or ?what are the bytecodes of the JVM?. I would think > those would go into a dev-guide of some sort, but in a > different place than the important ?how to get started? > sections. > > I hope Jesper will have more comments on these puzzles. > > ? John -- Cheers, Martijn (Sent from Gmail Mobile) From jesper.wilhelmsson at oracle.com Fri Mar 13 13:29:21 2020 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Fri, 13 Mar 2020 14:29:21 +0100 Subject: Call for Discussion: New Project: Developer's Guide In-Reply-To: References: <62FA7D5A-5D25-4617-853F-3B0BC09CE154@oracle.com> <258E790C-13BA-44B9-8ECF-37FC5C96B59D@oracle.com> <87h7ysssdc.fsf@mid.deneb.enyo.de> <91A0E45E-3383-4EEE-8773-2926138CC2DF@oracle.com> Message-ID: <077FD07E-1B55-4583-9160-40BA9CCFF70E@oracle.com> Hi John, Martijn, everyone. The way I see it everyone can contribute in some way. We already have a lot of material that needs to be updated and converted to some form of markdown. There are also several missing parts that needs to be authored from scratch. Work done by people new to the project will of course have to be reviewed by those who have been here for a while, and I'm sure that work done by the experienced members of our community will also benefit from being reviewed by new members to catch parts and language that isn't obvious unless you have the background. I don't really think there is any big difference here compared to how we treat our source code. We wouldn't let a newcomer push code into the JDK without review, the same is true here, but still we appreciate any contributions made by new members of the community. For this guide I'm personally more interested in process questions than code style. Taking code review as an example the guide should have examples of how to perform a review; currently using webrev, emails, etc. (Skara will likely change things a lot.) It should talk about the 24 hour rule and give examples of what might be considered a trivial change. Some of this is already covered by http://openjdk.java.net/contribute/ and there are pages in the Hotspot how-to [1] that covers this as well, so we'll see what will be considered useful for inclusion in the end. My hope is that the pages contained in the Hotspot how-to [1] and other pages spread on the wiki and in other places can be removed once we are done with the guide. There is a section for code conventions in the current guide. It's empty. I think a good start here could be to either link to John's JVM code conventions, or move that page into the guide. For the Java code there are several pages out there that could serve as a foundation, or just be linked to. However, I consider this implementation details that can be discussed once the project has been created and someone sets out to actually update those pages. The question right now I think is more of the kind; Do we think it would be useful to have an up-to-date developer's guide, and do we think an OpenJDK project is the right way to do that work? One concern that has been brought to my attention is that one OpenJDK project isn't normally entitled to dictate how other OpenJDK projects should work. This is clearly a valid concern but I think that if we stick to tutorials and how-to guides, these won't really dictate anything, just explain how to do things (at least in my mind there is a difference). Another option could of course be to move the guide into the JDK source tree and have the JDK project be responsible for its maintenance. I don't have a strong preference here, I just want to update the guide. /Jesper [1] https://wiki.openjdk.java.net/display/HotSpot/HotSpot+How+To > On 13 Mar 2020, at 10:37, Martijn Verburg wrote: > > Hi John, > > I totally get where you are coming from and the intent of message, all good! > > Our group will be happy to help Jesper et al in *whatever capacity he and > the other experienced folks want us to*. > > If that?s just reviewing drafts as newcomers or doing something like (dare > I say it boring) formatting work then we will roll up sleeves and do just > that ??. > > Cheers, > Martijn > > > > On Fri, 13 Mar 2020 at 08:34, John Rose wrote: > >> On Mar 12, 2020, at 11:04 PM, Florian Weimer wrote: >>> >>> * John Rose: >>> >>>> And I suggest the same to others who are responding >>>> with a ?count me in?. This project will require (as >>>> Liam Neeson might say) ?a very particular set of skills, >>>> ?acquired over a very long career.? It is not a starter >>>> task, as far as I can tell. However, I?ll give deference to >>>> Jesper, who might have a different vision for this. >>> >>> Wouldn't input from people not completely familiar with the processes >>> be valuable, so that it becomes clearer what needs documenting? >> >> That?s a very good point. Must that input be obtained by recruiting >> such people as project members, or can it be acquired via other >> means such as questionnaires and experience reports? >> >> Also, to be honest: I missed the import of Jesper?s >> initial statement, ?Strict rules for OpenJDK development >> are? outside of the scope of this project.? I think this >> means that vexed questions like code reviews and style >> guides are off the table for now, which means the analogy >> of a hospital policy committee is not nearly as applicable >> as I thought it was. My apologies! >> >> A new person?s experience is precious and should >> be captured quickly, before it is forgotten. My first >> response to Martijn didn?t do justice to this fact. >> We old-timers have no clue anymore what we know >> and how we learned it the first time; ?how to learn >> it? is the whole job of a new person?but they forget >> quickly once they learn the ropes. Watching this >> over and over again, I have noticed that we have no >> good way to capture those new-person experiences. >> (Long-haul experiences, on the other hand, are >> abundantly documented. The problem there is it >> goes stale after a few years.) I?d be really interested >> to hear from people who have seen successful capture >> of information from new folks to improve on-boarding. >> My best take on it is to have a place where new folks >> can share what they are learning *when the experience >> is fresh*, in such a way that their more experienced >> team mates can use it as raw material for the next >> revision of the on-boarding guide. >> >> I wish there were an OpenJDK wiki which would be >> immediately open to all OpenJDK authors, exactly >> for this purpose, but our infra isn?t set up that way. >> Imagine reading the experience reports of the last >> ten years of new folks, explaining what went right >> and wrong, and commenting on each others? >> experience? The closest thing we have to this is >> email archives, which are disorganized, and the >> cr.ojn pages, which are isolated (and not intended >> for documentation, though useful for it nevertheless). >> >> Regarding the parts of the guide which would be for >> long-haul use (not on-boarding), a big problem is >> extracting the information from people who have been >> working with the existing practices for long enough to >> know their good sides and bad sides. There?s always >> the problem of keeping such documentation fresh. >> >> Also, I think such a guide should be more descriptive >> than prescriptive. (Today in a different thread I >> talked about descriptive vs. prescriptive, in the setting >> of a proposal for a new prescriptive code style enforced >> by robots.) The current proposal to avoid ?strict? rules >> would seem to avoid the risks of prescriptiveness, for now. >> >> Is there a difference between ?long haul? and ?on-boarding? >> documentation? Yes, because they are for different audiences. >> Every project demands that the new folks learn a bunch of >> stuff before they do anything; hopefully it?s not too much >> and it?s easy to learn, and then your apprenticeship begins. >> Also, every project has a much larger set of best practices >> and specifications which don?t need to be learned up front, >> but which still shape the project as a whole. No one person >> knows them all at once, but people need to refer to them. >> I?m talking about documentation like ?how to do gatekeeping? >> or ?what are the bytecodes of the JVM?. I would think >> those would go into a dev-guide of some sort, but in a >> different place than the important ?how to get started? >> sections. >> >> I hope Jesper will have more comments on these puzzles. >> >> ? John > > -- > Cheers, Martijn (Sent from Gmail Mobile) From john.r.rose at oracle.com Sat Mar 14 00:15:26 2020 From: john.r.rose at oracle.com (John Rose) Date: Fri, 13 Mar 2020 17:15:26 -0700 Subject: Call for Discussion: New Project: Developer's Guide In-Reply-To: References: <62FA7D5A-5D25-4617-853F-3B0BC09CE154@oracle.com> <258E790C-13BA-44B9-8ECF-37FC5C96B59D@oracle.com> <87h7ysssdc.fsf@mid.deneb.enyo.de> <91A0E45E-3383-4EEE-8773-2926138CC2DF@oracle.com> Message-ID: On Mar 13, 2020, at 2:37 AM, Martijn Verburg wrote: > > I totally get where you are coming from and the intent of message, all good! > > Our group will be happy to help Jesper et al in *whatever capacity he and the other experienced folks want us to*. > > If that?s just reviewing drafts as newcomers or doing something like (dare I say it boring) formatting work then we will roll up sleeves and do just that ??. +100 And did I mention how glad I am you guys are here? :-) From john.r.rose at oracle.com Sat Mar 14 00:21:19 2020 From: john.r.rose at oracle.com (John Rose) Date: Fri, 13 Mar 2020 17:21:19 -0700 Subject: Call for Discussion: New Project: Developer's Guide In-Reply-To: <077FD07E-1B55-4583-9160-40BA9CCFF70E@oracle.com> References: <62FA7D5A-5D25-4617-853F-3B0BC09CE154@oracle.com> <258E790C-13BA-44B9-8ECF-37FC5C96B59D@oracle.com> <87h7ysssdc.fsf@mid.deneb.enyo.de> <91A0E45E-3383-4EEE-8773-2926138CC2DF@oracle.com> <077FD07E-1B55-4583-9160-40BA9CCFF70E@oracle.com> Message-ID: <8DA995CB-7EE6-4749-80D1-5EA9356B5655@oracle.com> On Mar 13, 2020, at 6:29 AM, Jesper Wilhelmsson wrote: > > The question right now I think is more of the kind; Do we think it would be useful to have an up-to-date developer's guide, and do we think an OpenJDK project is the right way to do that work? Yes, please. Thanks for taking this on. Please see my previous comments; maybe they are helpful. I?m particularly passionate about our poor information capture from the experiences of new people, and I think this project might consider making that better somehow, on the grounds that the dev-guide can a living document, if it can keep its information fresh, and otherwise will have a short career. Capturing thoughtful experience reports from new folks would seem to be the raw material of a healthy dev-guide, specifically the on-boarding part. The long-haul part has similar care-and-feeding requirements, but those should be satisfied by bug/rfe reports from the group as a whole. ? John From joe.darcy at oracle.com Sat Mar 14 00:53:26 2020 From: joe.darcy at oracle.com (Joe Darcy) Date: Fri, 13 Mar 2020 17:53:26 -0700 Subject: Call for Discussion: New Project: Developer's Guide In-Reply-To: <62FA7D5A-5D25-4617-853F-3B0BC09CE154@oracle.com> References: <62FA7D5A-5D25-4617-853F-3B0BC09CE154@oracle.com> Message-ID: Hello, From a Project Skara perspective, we would also welcome an up-to-date guide; thanks for leading up this effort Jesper! Cheers, -Joe On 3/11/2020 4:51 PM, Jesper Wilhelmsson wrote: > Hi. > > I would like to discuss the possible creation of the Developer's Guide Project > with myself, Jesper Wilhelmsson, as the lead and the Core-Libs, Compiler, and > Hotspot groups as the sponsoring Groups. > > The initial goal of the project would be to create up-to-date guidelines for > OpenJDK development and contributions. The intent is to update the existing > OpenJDK Developer's Guide [1] which hasn't been updated since 2012. Parts of > the existing guide are in need of updates while other parts are yet to be > written. The initial source code for this project will be based on the current > OpenJDK Developer's Guide. > > In more recent years some process related information has been published on the > OpenJDK wiki [2], but this information was never reviewed or approved by the > community. Even though large parts of this information may be accurate, it needs > to go through proper review before it can be seen as official guidelines for > OpenJDK development. > > Once the initial goal has been reached the project will transition into a > maintenance project to keep the OpenJDK Developer's Guide up to date. > > The OpenJDK Developer's Guide is intended to contain tutorial style texts that > give examples and step-by-step directions for common parts of the development > process. Strict rules for OpenJDK development are better suited to a process > JEP. The development of such a JEP is outside of the scope of this project but > will be developed as part of a separate effort in parallel. > > Initial committers of the Developer's Guide Project include Mark Reinhold, Iris > Clark, and Jesper Wilhelmsson. Additional committers may be identified through > this discussion. > > The project will host at least one mailing list, guide-dev at openjdk.java.net, > for discussions and reviews of changes. > > Thanks, > /Jesper > > [1] http://openjdk.java.net/guide/ > [2] https://wiki.openjdk.java.net/ > From joe.darcy at oracle.com Sat Mar 14 01:34:27 2020 From: joe.darcy at oracle.com (Joe Darcy) Date: Fri, 13 Mar 2020 18:34:27 -0700 Subject: Call for Discussion: New Project: Developer's Guide -- suggestion to separate information having different life cycles In-Reply-To: <62FA7D5A-5D25-4617-853F-3B0BC09CE154@oracle.com> References: <62FA7D5A-5D25-4617-853F-3B0BC09CE154@oracle.com> Message-ID: Hello, Having penned a complementary "OpenJDK Developers' Guide" back in 2010 [1], I wanted to offer a suggestion on structuring the new guide: separate information of different life cycles into different documents. For example, put any release-specific information into release-specific documents and put stable, mostly time-invariant information into the main developer's guide. In the JDK code base, over the years we've recognized that hard-coded release values used in tests or the javadoc are often a maintenance burden. I think the same would be true of a developer's guide; the guide shouldn't necessarily need to be updated every six months (or three months) just because the feature releases have a six-month cadence and update releases come out every three months. [2] HTH, -Joe [1] http://cr.openjdk.java.net/~darcy/OpenJdkDevGuide/OpenJdkDevelopersGuide.v0.777.html This material was used to seed the CSR compatibility discussion years later: https://wiki.openjdk.java.net/display/csr/Kinds+of+Compatibility [2] HT Prof. Edsger W. Dijkstra on describing the Buxton Index in his essay "The strengths of the academic enterprise" (https://www.cs.utexas.edu/users/EWD/transcriptions/EWD11xx/EWD1175.html). To rephrase the suggestion: avoid shear stress in the guide by not mixing content with different Buxton indexes. From jesper.wilhelmsson at oracle.com Sat Mar 14 02:02:42 2020 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Sat, 14 Mar 2020 03:02:42 +0100 Subject: Call for Discussion: New Project: Developer's Guide In-Reply-To: <8DA995CB-7EE6-4749-80D1-5EA9356B5655@oracle.com> References: <62FA7D5A-5D25-4617-853F-3B0BC09CE154@oracle.com> <258E790C-13BA-44B9-8ECF-37FC5C96B59D@oracle.com> <87h7ysssdc.fsf@mid.deneb.enyo.de> <91A0E45E-3383-4EEE-8773-2926138CC2DF@oracle.com> <077FD07E-1B55-4583-9160-40BA9CCFF70E@oracle.com> <8DA995CB-7EE6-4749-80D1-5EA9356B5655@oracle.com> Message-ID: <0D13CE26-5DD5-406D-A10C-FC0D86DAD205@oracle.com> > On 14 Mar 2020, at 01:21, John Rose wrote: > > On Mar 13, 2020, at 6:29 AM, Jesper Wilhelmsson > wrote: >> >> The question right now I think is more of the kind; Do we think it would be useful to have an up-to-date developer's guide, and do we think an OpenJDK project is the right way to do that work? > > Yes, please. Thanks for taking this on. Please see my previous > comments; maybe they are helpful. I?m particularly passionate > about our poor information capture from the experiences of > new people, and I think this project might consider making > that better somehow, on the grounds that the dev-guide can > a living document, if it can keep its information fresh, and > otherwise will have a short career. > > Capturing thoughtful experience reports from new folks > would seem to be the raw material of a healthy dev-guide, > specifically the on-boarding part. The long-haul part > has similar care-and-feeding requirements, but those > should be satisfied by bug/rfe reports from the group > as a whole. I'm absolutely pro capturing comments and experiences from new people, and I think that as the guide is updated and people see that it is a living document suggestions for improvements will start dropping in automatically. If we need some extra action to capture new peoples experiences from the guide, let's do that, but to be honest I don't think it will be necessary as long as the guide is a living document. If I read a document and find some small issue in the text I'm a lot more motivated to file a report if I see that the document has been updated recently and the issue I found was the only bug in there, compared to if the document hasn't been updated since 2012 and is completely out of date. We could always encourage feedback by a note of the first page like: "We hope that you will enjoy this guide and find it helpful. If you find anything that seems odd, or something that is not clearly explained, please let us know by sending an email to guide-dev at openjdk.java.net. Thank you for your feedback! And by the way, here's the guide for how to join the OpenJDK mail lists: ..." Cheers, /Jesper From jesper.wilhelmsson at oracle.com Sat Mar 14 02:42:21 2020 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Sat, 14 Mar 2020 03:42:21 +0100 Subject: Call for Discussion: New Project: Developer's Guide -- suggestion to separate information having different life cycles In-Reply-To: References: <62FA7D5A-5D25-4617-853F-3B0BC09CE154@oracle.com> Message-ID: > On 14 Mar 2020, at 02:34, Joe Darcy wrote: > > Hello, > > Having penned a complementary "OpenJDK Developers' Guide" back in 2010 [1], I wanted to offer a suggestion on structuring the new guide: separate information of different life cycles into different documents. For example, put any release-specific information into release-specific documents and put stable, mostly time-invariant information into the main developer's guide. If you don't mind I think it would make sense to copy parts of that guide into the new developer's guide. Unless it's a document that you intend to keep around and maintain. I agree that separating information based on life cycles is a good idea. Looking at the index of the old guide I don't think there is anything in there that is release specific. Some of my how-tos on the OpenJDK wiki do have release numbers in some examples but I think that can be re-worked as the processes themself are not release dependent. > In the JDK code base, over the years we've recognized that hard-coded release values used in tests or the javadoc are often a maintenance burden. I think the same would be true of a developer's guide; the guide shouldn't necessarily need to be updated every six months (or three months) just because the feature releases have a six-month cadence and update releases come out every three months. [2] I'm personally allergic to version numbers in version controlled documents. Especially these days when the document is online and most people have constant access to the latest version. The same goes for references to the JDK version in the text. If it can be made version agnostic (and most often it can) I think it should. Thanks, /Jesper > > HTH, > > -Joe > > [1] http://cr.openjdk.java.net/~darcy/OpenJdkDevGuide/OpenJdkDevelopersGuide.v0.777.html > > This material was used to seed the CSR compatibility discussion years later: > > https://wiki.openjdk.java.net/display/csr/Kinds+of+Compatibility > > [2] HT Prof. Edsger W. Dijkstra on describing the Buxton Index in his essay "The strengths of the academic enterprise" (https://www.cs.utexas.edu/users/EWD/transcriptions/EWD11xx/EWD1175.html). To rephrase the suggestion: avoid shear stress in the guide by not mixing content with different Buxton indexes. > From lars.francke at gmail.com Sat Mar 14 06:31:14 2020 From: lars.francke at gmail.com (Lars Francke) Date: Sat, 14 Mar 2020 07:31:14 +0100 Subject: Call for Discussion: New Project: Developer's Guide In-Reply-To: <077FD07E-1B55-4583-9160-40BA9CCFF70E@oracle.com> References: <62FA7D5A-5D25-4617-853F-3B0BC09CE154@oracle.com> <258E790C-13BA-44B9-8ECF-37FC5C96B59D@oracle.com> <87h7ysssdc.fsf@mid.deneb.enyo.de> <91A0E45E-3383-4EEE-8773-2926138CC2DF@oracle.com> <077FD07E-1B55-4583-9160-40BA9CCFF70E@oracle.com> Message-ID: On Fri, Mar 13, 2020 at 2:30 PM Jesper Wilhelmsson < jesper.wilhelmsson at oracle.com> wrote: > Hi John, Martijn, everyone. > > The way I see it everyone can contribute in some way. We already have a > lot of material that needs to be updated and converted to some form of > markdown. There are also several missing parts that needs to be authored > from scratch. Work done by people new to the project will of course have to > be reviewed by those who have been here for a while, and I'm sure that work > done by the experienced members of our community will also benefit from > being reviewed by new members to catch parts and language that isn't > obvious unless you have the background. I don't really think there is any > big difference here compared to how we treat our source code. We wouldn't > let a newcomer push code into the JDK without review, the same is true > here, but still we appreciate any contributions made by new members of the > community. > > For this guide I'm personally more interested in process questions than > code style. Taking code review as an example the guide should have examples > of how to perform a review; currently using webrev, emails, etc. (Skara > will likely change things a lot.) It should talk about the 24 hour rule and > give examples of what might be considered a trivial change. Some of this is > already covered by http://openjdk.java.net/contribute/ and there are > pages in the Hotspot how-to [1] that covers this as well, so we'll see what > will be considered useful for inclusion in the end. My hope is that the > pages contained in the Hotspot how-to [1] and other pages spread on the > wiki and in other places can be removed once we are done with the guide. > > There is a section for code conventions in the current guide. It's empty. > I think a good start here could be to either link to John's JVM code > conventions, or move that page into the guide. For the Java code there are > several pages out there that could serve as a foundation, or just be linked > to. However, I consider this implementation details that can be discussed > once the project has been created and someone sets out to actually update > those pages. > > The question right now I think is more of the kind; Do we think it would > be useful to have an up-to-date developer's guide, and do we think an > OpenJDK project is the right way to do that work? > As someone who tried to get a patch in for the first time last year: Yes, that'd be incredibly helpful. There's lots of information out there, some is _clearly_ outdated and marked as such, other things are outdated but not marked again others seem up-to-date but to distinguish them from each other is hard if you know nothing. So I'd be happy to review things as well from the complete newcomer perspective. > > One concern that has been brought to my attention is that one OpenJDK > project isn't normally entitled to dictate how other OpenJDK projects > should work. This is clearly a valid concern but I think that if we stick > to tutorials and how-to guides, these won't really dictate anything, just > explain how to do things (at least in my mind there is a difference). > Another option could of course be to move the guide into the JDK source > tree and have the JDK project be responsible for its maintenance. I don't > have a strong preference here, I just want to update the guide. > > /Jesper > > [1] https://wiki.openjdk.java.net/display/HotSpot/HotSpot+How+To > > > On 13 Mar 2020, at 10:37, Martijn Verburg > wrote: > > > > Hi John, > > > > I totally get where you are coming from and the intent of message, all > good! > > > > Our group will be happy to help Jesper et al in *whatever capacity he and > > the other experienced folks want us to*. > > > > If that?s just reviewing drafts as newcomers or doing something like > (dare > > I say it boring) formatting work then we will roll up sleeves and do just > > that ??. > > > > Cheers, > > Martijn > > > > > > > > On Fri, 13 Mar 2020 at 08:34, John Rose wrote: > > > >> On Mar 12, 2020, at 11:04 PM, Florian Weimer wrote: > >>> > >>> * John Rose: > >>> > >>>> And I suggest the same to others who are responding > >>>> with a ?count me in?. This project will require (as > >>>> Liam Neeson might say) ?a very particular set of skills, > >>>> ?acquired over a very long career.? It is not a starter > >>>> task, as far as I can tell. However, I?ll give deference to > >>>> Jesper, who might have a different vision for this. > >>> > >>> Wouldn't input from people not completely familiar with the processes > >>> be valuable, so that it becomes clearer what needs documenting? > >> > >> That?s a very good point. Must that input be obtained by recruiting > >> such people as project members, or can it be acquired via other > >> means such as questionnaires and experience reports? > >> > >> Also, to be honest: I missed the import of Jesper?s > >> initial statement, ?Strict rules for OpenJDK development > >> are? outside of the scope of this project.? I think this > >> means that vexed questions like code reviews and style > >> guides are off the table for now, which means the analogy > >> of a hospital policy committee is not nearly as applicable > >> as I thought it was. My apologies! > >> > >> A new person?s experience is precious and should > >> be captured quickly, before it is forgotten. My first > >> response to Martijn didn?t do justice to this fact. > >> We old-timers have no clue anymore what we know > >> and how we learned it the first time; ?how to learn > >> it? is the whole job of a new person?but they forget > >> quickly once they learn the ropes. Watching this > >> over and over again, I have noticed that we have no > >> good way to capture those new-person experiences. > >> (Long-haul experiences, on the other hand, are > >> abundantly documented. The problem there is it > >> goes stale after a few years.) I?d be really interested > >> to hear from people who have seen successful capture > >> of information from new folks to improve on-boarding. > >> My best take on it is to have a place where new folks > >> can share what they are learning *when the experience > >> is fresh*, in such a way that their more experienced > >> team mates can use it as raw material for the next > >> revision of the on-boarding guide. > >> > >> I wish there were an OpenJDK wiki which would be > >> immediately open to all OpenJDK authors, exactly > >> for this purpose, but our infra isn?t set up that way. > >> Imagine reading the experience reports of the last > >> ten years of new folks, explaining what went right > >> and wrong, and commenting on each others? > >> experience? The closest thing we have to this is > >> email archives, which are disorganized, and the > >> cr.ojn pages, which are isolated (and not intended > >> for documentation, though useful for it nevertheless). > >> > >> Regarding the parts of the guide which would be for > >> long-haul use (not on-boarding), a big problem is > >> extracting the information from people who have been > >> working with the existing practices for long enough to > >> know their good sides and bad sides. There?s always > >> the problem of keeping such documentation fresh. > >> > >> Also, I think such a guide should be more descriptive > >> than prescriptive. (Today in a different thread I > >> talked about descriptive vs. prescriptive, in the setting > >> of a proposal for a new prescriptive code style enforced > >> by robots.) The current proposal to avoid ?strict? rules > >> would seem to avoid the risks of prescriptiveness, for now. > >> > >> Is there a difference between ?long haul? and ?on-boarding? > >> documentation? Yes, because they are for different audiences. > >> Every project demands that the new folks learn a bunch of > >> stuff before they do anything; hopefully it?s not too much > >> and it?s easy to learn, and then your apprenticeship begins. > >> Also, every project has a much larger set of best practices > >> and specifications which don?t need to be learned up front, > >> but which still shape the project as a whole. No one person > >> knows them all at once, but people need to refer to them. > >> I?m talking about documentation like ?how to do gatekeeping? > >> or ?what are the bytecodes of the JVM?. I would think > >> those would go into a dev-guide of some sort, but in a > >> different place than the important ?how to get started? > >> sections. > >> > >> I hope Jesper will have more comments on these puzzles. > >> > >> ? John > > > > -- > > Cheers, Martijn (Sent from Gmail Mobile) > > From joe.darcy at oracle.com Sat Mar 14 17:02:48 2020 From: joe.darcy at oracle.com (Joe Darcy) Date: Sat, 14 Mar 2020 10:02:48 -0700 Subject: Call for Discussion: New Project: Developer's Guide -- suggestion to separate information having different life cycles In-Reply-To: References: <62FA7D5A-5D25-4617-853F-3B0BC09CE154@oracle.com> Message-ID: <05bc7094-b731-70ab-a57d-1b851608cdba@oracle.com> Hi Jesper, On 3/13/2020 7:42 PM, Jesper Wilhelmsson wrote: >> On 14 Mar 2020, at 02:34, Joe Darcy wrote: >> >> Hello, >> >> Having penned a complementary "OpenJDK Developers' Guide" back in 2010 [1], I wanted to offer a suggestion on structuring the new guide: separate information of different life cycles into different documents. For example, put any release-specific information into release-specific documents and put stable, mostly time-invariant information into the main developer's guide. > If you don't mind I think it would make sense to copy parts of that guide into the new developer's guide. Unless it's a document that you intend to keep around and maintain. The text in the document is free to use for copying or inspiration :-) -Joe From javajiva at amazon.com Mon Mar 16 17:38:39 2020 From: javajiva at amazon.com (Jiva, Azeem) Date: Mon, 16 Mar 2020 17:38:39 +0000 Subject: Call for Discussion: New Project: Developer's Guide Message-ID: <9C6C4096-CB5F-4D29-BA1B-9785ED7DF162@amazon.com> Jesper, Amazon is willing to help with a hotspot debug guide as well as participating in hotspot related documentation. Hi. I would like to discuss the possible creation of the Developer's Guide Project with myself, Jesper Wilhelmsson, as the lead and the Core-Libs, Compiler, and Hotspot groups as the sponsoring Groups. The initial goal of the project would be to create up-to-date guidelines for OpenJDK development and contributions. The intent is to update the existing OpenJDK Developer's Guide [1] which hasn't been updated since 2012. Parts of the existing guide are in need of updates while other parts are yet to be written. The initial source code for this project will be based on the current OpenJDK Developer's Guide. In more recent years some process related information has been published on the OpenJDK wiki [2], but this information was never reviewed or approved by the community. Even though large parts of this information may be accurate, it needs to go through proper review before it can be seen as official guidelines for OpenJDK development. Once the initial goal has been reached the project will transition into a maintenance project to keep the OpenJDK Developer's Guide up to date. The OpenJDK Developer's Guide is intended to contain tutorial style texts that give examples and step-by-step directions for common parts of the development process. Strict rules for OpenJDK development are better suited to a process JEP. The development of such a JEP is outside of the scope of this project but will be developed as part of a separate effort in parallel. Initial committers of the Developer's Guide Project include Mark Reinhold, Iris Clark, and Jesper Wilhelmsson. Additional committers may be identified through this discussion. The project will host at least one mailing list, guide-dev at openjdk.java.net, for discussions and reviews of changes. Thanks, /Jesper [1] http://openjdk.java.net/guide/ [2] https://wiki.openjdk.java.net/ -- Azeem Jiva From jesper.wilhelmsson at oracle.com Mon Mar 16 17:44:25 2020 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Mon, 16 Mar 2020 18:44:25 +0100 Subject: Call for Discussion: New Project: Developer's Guide In-Reply-To: <9C6C4096-CB5F-4D29-BA1B-9785ED7DF162@amazon.com> References: <9C6C4096-CB5F-4D29-BA1B-9785ED7DF162@amazon.com> Message-ID: > On 16 Mar 2020, at 18:38, Jiva, Azeem wrote: > > Jesper, > > Amazon is willing to help with a hotspot debug guide as well as participating in hotspot related documentation. > Thank you for your support Azeem! /Jesper > > > > > Hi. > > > > I would like to discuss the possible creation of the Developer's Guide Project > > with myself, Jesper Wilhelmsson, as the lead and the Core-Libs, Compiler, and > > Hotspot groups as the sponsoring Groups. > > > > The initial goal of the project would be to create up-to-date guidelines for > > OpenJDK development and contributions. The intent is to update the existing > > OpenJDK Developer's Guide [1] which hasn't been updated since 2012. Parts of > > the existing guide are in need of updates while other parts are yet to be > > written. The initial source code for this project will be based on the current > > OpenJDK Developer's Guide. > > > > In more recent years some process related information has been published on the > > OpenJDK wiki [2], but this information was never reviewed or approved by the > > community. Even though large parts of this information may be accurate, it needs > > to go through proper review before it can be seen as official guidelines for > > OpenJDK development. > > > > Once the initial goal has been reached the project will transition into a > > maintenance project to keep the OpenJDK Developer's Guide up to date. > > > > The OpenJDK Developer's Guide is intended to contain tutorial style texts that > > give examples and step-by-step directions for common parts of the development > > process. Strict rules for OpenJDK development are better suited to a process > > JEP. The development of such a JEP is outside of the scope of this project but > > will be developed as part of a separate effort in parallel. > > > > Initial committers of the Developer's Guide Project include Mark Reinhold, Iris > > Clark, and Jesper Wilhelmsson. Additional committers may be identified through > > this discussion. > > > > The project will host at least one mailing list, guide-dev at openjdk.java.net, > > for discussions and reviews of changes. > > > > Thanks, > > /Jesper > > > > [1] http://openjdk.java.net/guide/ > > [2] https://wiki.openjdk.java.net/ > > > -- > Azeem Jiva From zen at freedbms.net Thu Mar 19 23:35:27 2020 From: zen at freedbms.net (Zenaan Harkness) Date: Fri, 20 Mar 2020 10:35:27 +1100 Subject: Java's strings, UTF-8 etc Message-ID: <20200319233527.wmuzlfit7nb4hx4l@eye.freedbms.net> Hi Brian, in case it is of interest, I did an exploration over a week or two, and wrote up that journey here: https://zenaan.github.io/zen/javadoc/zen/lang/string.html See also of course: https://github.com/zenaan/zen And for reference, see also: https://mail.openjdk.java.net/pipermail/discuss/2016-November/004065.html https://mail.openjdk.java.net/pipermail/discuss/2016-November/004070.html https://mail.openjdk.java.net/pipermail/discuss/2016-November/004072.html (I was hoping to one day do a proof of concept for byte array backed UTF-8 strings in Java, but have not returned to this little project - in any case, I do believe this would be a fundamental improvement to the core of Java.) Best regards, Zenaan From magnus.ihse.bursie at oracle.com Fri Mar 20 10:33:42 2020 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 20 Mar 2020 11:33:42 +0100 Subject: Call for Discussion: New Project: Developer's Guide In-Reply-To: <62FA7D5A-5D25-4617-853F-3B0BC09CE154@oracle.com> References: <62FA7D5A-5D25-4617-853F-3B0BC09CE154@oracle.com> Message-ID: <00451a01-61c3-926c-9612-4649bc7a0e72@oracle.com> On 2020-03-12 00:51, Jesper Wilhelmsson wrote: > Hi. > > I would like to discuss the possible creation of the Developer's Guide Project > with myself, Jesper Wilhelmsson, as the lead and the Core-Libs, Compiler, and > Hotspot groups as the sponsoring Groups. > > The initial goal of the project would be to create up-to-date guidelines for > OpenJDK development and contributions. The intent is to update the existing > OpenJDK Developer's Guide [1] which hasn't been updated since 2012. Parts of > the existing guide are in need of updates while other parts are yet to be > written. The initial source code for this project will be based on the current > OpenJDK Developer's Guide. > > In more recent years some process related information has been published on the > OpenJDK wiki [2], but this information was never reviewed or approved by the > community. Even though large parts of this information may be accurate, it needs > to go through proper review before it can be seen as official guidelines for > OpenJDK development. > > Once the initial goal has been reached the project will transition into a > maintenance project to keep the OpenJDK Developer's Guide up to date. > > The OpenJDK Developer's Guide is intended to contain tutorial style texts that > give examples and step-by-step directions for common parts of the development > process. Strict rules for OpenJDK development are better suited to a process > JEP. The development of such a JEP is outside of the scope of this project but > will be developed as part of a separate effort in parallel. Hi Jesper, I've browsed through the discussion, but could not easily find if you consider style guides (this neverending hot topic!) as being included in, or excluded from, this effort. Personally, as a newcomer to any project, I would consider a style guide helpful when trying to submit code that'd be readily accepted. Even if it's just a "descriptive" guide, not a normative one. So, given this, I'd strongly recommend that the project ends up with promoting a single source of truth style guide, even if it is just descriptive of most current practices, rather than normative. And, in that respect, I'd kindly want to point out the effort made by Andreas Lundblad some years ago [1]. His style guide went through multiple iterations, incorporated a lot of feedback from many OpenJDK developers, and is probably the best document to capture the current "best practices" of OpenJDK source code style. Unfortunately, it basically fell short of the finishing line since there were no good way, process-wise, on how to handle the resulting document. /Magnus [1] http://cr.openjdk.java.net/~alundblad/styleguide/index-v6.html From jesper.wilhelmsson at oracle.com Fri Mar 20 10:56:01 2020 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Fri, 20 Mar 2020 11:56:01 +0100 Subject: Call for Discussion: New Project: Developer's Guide In-Reply-To: <00451a01-61c3-926c-9612-4649bc7a0e72@oracle.com> References: <62FA7D5A-5D25-4617-853F-3B0BC09CE154@oracle.com> <00451a01-61c3-926c-9612-4649bc7a0e72@oracle.com> Message-ID: > On 20 Mar 2020, at 11:33, Magnus Ihse Bursie wrote: > On 2020-03-12 00:51, Jesper Wilhelmsson wrote: >> Hi. >> >> I would like to discuss the possible creation of the Developer's Guide Project >> with myself, Jesper Wilhelmsson, as the lead and the Core-Libs, Compiler, and >> Hotspot groups as the sponsoring Groups. >> >> The initial goal of the project would be to create up-to-date guidelines for >> OpenJDK development and contributions. The intent is to update the existing >> OpenJDK Developer's Guide [1] which hasn't been updated since 2012. Parts of >> the existing guide are in need of updates while other parts are yet to be >> written. The initial source code for this project will be based on the current >> OpenJDK Developer's Guide. >> >> In more recent years some process related information has been published on the >> OpenJDK wiki [2], but this information was never reviewed or approved by the >> community. Even though large parts of this information may be accurate, it needs >> to go through proper review before it can be seen as official guidelines for >> OpenJDK development. >> >> Once the initial goal has been reached the project will transition into a >> maintenance project to keep the OpenJDK Developer's Guide up to date. >> >> The OpenJDK Developer's Guide is intended to contain tutorial style texts that >> give examples and step-by-step directions for common parts of the development >> process. Strict rules for OpenJDK development are better suited to a process >> JEP. The development of such a JEP is outside of the scope of this project but >> will be developed as part of a separate effort in parallel. > > Hi Jesper, Hi Magnus. > I've browsed through the discussion, but could not easily find if you consider style guides (this neverending hot topic!) as being included in, or excluded from, this effort. From my earlier reply on this topic: "There is a section for code conventions in the current guide. It's empty. I think a good start here [for the C++ code] could be to either link to John's JVM code conventions, or move that page into the guide. For the Java code there are several pages out there that could serve as a foundation, or just be linked to. However, I consider this implementation details that can be discussed once the project has been created and someone sets out to actually update those pages." > Personally, as a newcomer to any project, I would consider a style guide helpful when trying to submit code that'd be readily accepted. Even if it's just a "descriptive" guide, not a normative one. So, given this, I'd strongly recommend that the project ends up with promoting a single source of truth style guide, even if it is just descriptive of most current practices, rather than normative. Yes, there is much interest in getting a style guide in place so I'm sure this will be one of the first things that is brought up on the new mailing list once created. > And, in that respect, I'd kindly want to point out the effort made by Andreas Lundblad some years ago [1]. His style guide went through multiple iterations, incorporated a lot of feedback from many OpenJDK developers, and is probably the best document to capture the current "best practices" of OpenJDK source code style. Unfortunately, it basically fell short of the finishing line since there were no good way, process-wise, on how to handle the resulting document. Andreas did reach out to me on this topic last week and will be in the loop once we get the project up and running. One of the first things to do though, before we add a lot of new stuff, is to convert the existing material to some form of markdown and decide on a layout etc that works for a guide like this. I think your expertise in markdown and makefiles for such usage would come in very handy in that work ;-) Thanks, /Jesper > /Magnus > > [1] http://cr.openjdk.java.net/~alundblad/styleguide/index-v6.html > From bsrbnd at gmail.com Fri Mar 20 18:16:19 2020 From: bsrbnd at gmail.com (B. Blaser) Date: Fri, 20 Mar 2020 19:16:19 +0100 Subject: Type inference heuristics (was: Enhancing expressions with mutability?) In-Reply-To: References: Message-ID: A common use of mutable expressions is for implementing evolutionary heuristics which typically might be helpful to solve performance issues like JDK-8152289. So, I tried to write such an algorithm using the quotation operator ` to infer the following similar example: class Point

{ Point(P label) {} } class Graph { public Graph(Point... vertices) {} } class Test { Test() { new Graph<>( new Point<>(1), ..., new Point<>(200) ); } } The attached dedicated evolutionary heuristic [3] infers all variables in no more than one second whereas javac takes currently between one and two minutes on my machine. It assumes the following initial bound set: G <: Number = P1 ... Pn Pn <: Number :> Integer = G The set of potential solutions is deduced from the initial bound set including combinations of them (intersection types): + private final Class[] classes = new Class[] { + Integer.class, Number.class, Object.class + }; + + private final Class[] interfs = new Class[] { + Serializable.class, Comparable.class, + Constable.class, ConstantDesc.class + }; The evolutionary algorithm traditionally starts with creating individuals and then iteratively chooses the best ones to perform cross-over and mutations until the prefect one is found. The interesting part is, of course, how their ADN is encoded. Each gene is dedicated to one inference variable and represents the individual ability to solve it, which can be expressed by the following formula: + adn[i] = (`able).link(`p, `type()); where `able is a function that checks all the bounds of the inference variable `p against the potential instantiation `type(). The evaluation of an individual, which is also the function to minimize, is the sum of all bad genes not able to solve their inference variable, the perfect individual having only good genes. However, this heuristic is only designed to infer this particular example. So, it might be interesting to generalize it as much as possible to solve a wider range of performance issues in this area. What do you think? Thanks, Bernard [3] heuristic.patch (attached) On Thu, 12 Mar 2020 at 18:36, B. Blaser wrote: > > To go a bit further, it'd be also possible to add another field to the > 'Term' class representing the name of any quoted identifier, which can > concretely be made in 'Lower' by adding a couple of lines like > 'makeLit(syms.stringType, ((JCIdent _or_ > JCFieldAccess)arg).name.toString())' (I can share the full diff with > the previous 'quote.patch' if requested). We can then use it like '(`d > _or_ `this.d).name.equals("d")' in our initial example. > > So, not to misunderstand me, this isn't a meta-programming facility by > itself but a fortunate consequence of the quotation operator which > might be used to considerably reduce the amount of code in certain > situations like persistence frameworks. And note also that mutable > expressions might be used to build queries using a more declarative > fashion, for example. > > Isn't that still a direction which is worth exploring? > > Thanks, > Bernard > > On Tue, 10 Mar 2020 at 22:03, B. Blaser wrote: > > > > Hi, > > > > Taking back the essential idea of the original publication on Lisp > > [1], I did the attached syntactic experiment [2] trying to bring some > > kind of mutability to expressions and thus giving more flexibility to > > the language. I hope this subject hasn't been covered too many times, > > otherwise I'd apologize for any disturbance. > > > > To build such mutable expressions, I've specified a new unary operator > > ` along with its resulting class 'java.lang.Term'. The quotation > > operator creates a 'Term' from any reference which can then be linked > > to other terms to finally be evaluated to the result of a function > > call for lambdas or the reference itself otherwise. > > > > Let's take some examples from the attached patch: > > > > + interface Get { > > + int op(); > > + } > > + > > + interface Sum { > > + int op(int i, int j); > > + } > > > > + int a = 0, b = 0; > > + Sum s = (x, y) -> x + y; > > > > + public void run() { > > + Get a = () -> this.a; > > + Get b = () -> this.b; > > + > > + Term e1 = (`s).link(`a, `b); > > + this.a = 1; this.b = 2; > > > > The above lines create a mutable expression e1 from the sum lambda s > > of the getter a and b which can then be evaluated to: > > > > (Integer)e1.value() == 3 > > > > or visualized as: > > > > e1.toString().equals("Sum( Get( ) Get( ) )") > > > > An interesting application similar to ?3.g from [1] is the computation > > of the partial derivative of a sum involving the mutation of the > > initial expression to produce a new resulting one: > > > > + // Derivative of sum e with respect to r > > + Term derivative(Term e, Term r) { > > + if (e.terms.isEmpty()) { > > + return `Integer.valueOf(e.that == r.that ? 1 : 0); > > + } > > + else if(e.that == (`s).that) { > > + return (`s).link(derivative(e.terms.get(0), r), > > derivative(e.terms.get(1), r)); > > + } > > + else throw new AssertionError(); > > + } > > > > Invoking the above method like this: > > > > + Term e2 = derivative(e1, `a); > > > > creates the resulting derivative expression e2 which can then be evaluated to: > > > > (Integer)e2.value() == 1 > > > > or visualized as: > > > > e2.toString().equals("Sum( `1 `0 )") > > > > Finally, we note that any term may be quoted to prevent its > > evaluation, for example: > > > > + Derivative d = this::derivative; > > > > + Term e3 = (`d).link(`e1, ``a); > > > > can be evaluated to: > > > > (Integer)((Term)e3.value()).value() == 1 > > > > or visualized as: > > > > e3.toString().equals("Derivative( `Sum( Get( ) Get( ) ) `Get( ) )") > > > > Of course, one of our main concern is how much do we need this and a > > reasonable answer would probably be as much as we need Lisp's > > S-expressions but with similar or maybe better performance than > > external interpreters and a more homogeneous integration to the > > language. > > > > Any feedback about this experiment would be welcome! > > > > Thanks, > > Bernard > > > > [1] http://www-formal.stanford.edu/jmc/recursive.html > > [2] quote.patch -------------- next part -------------- A non-text attachment was scrubbed... Name: heuristic.patch Type: text/x-patch Size: 6452 bytes Desc: not available URL: From maurizio.cimadamore at oracle.com Mon Mar 23 14:31:00 2020 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Mon, 23 Mar 2020 14:31:00 +0000 Subject: Enhancing expressions with mutability? In-Reply-To: References: Message-ID: <9238fa7d-3035-6f10-7334-3772df712584@oracle.com> Hey Bernard, cool stuff. Your patch seems to be missing the Term class, which is kind of important to look at to see how it interoperates with javac. That said, while the ideas you explore are interesting, I do not seem them being applicable 'as is' to Java. That said, one direction which overlaps a lot to what you describe here, especially in your derivative example is support for the so called expression trees feature - C# for example has it [1]. Expression trees gives the language a new super power, in that it allows the static compiler to create a richer intermediate form for the compiled expression (e.g. other than bytecode), which is then amenable to further processing at runtime - e.g. we could take this IR and compile it down to: * regular bytecode - e.g. to generate a method handle * assembly - very useful for native interop (a la Panama) * GPU kernel - very useful for offloading computation to GPU or other resources At the same time, if the IR is expressive enough, you can do things like differentiating functions and the likes, which are use cases very important in machine learning. So, my feeling is that, at some point, we'll start seeing some more concrete experiments in that direction - stay tuned :-) Maurizio [1] - https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/concepts/expression-trees/ On 10/03/2020 21:03, B. Blaser wrote: > Hi, > > Taking back the essential idea of the original publication on Lisp > [1], I did the attached syntactic experiment [2] trying to bring some > kind of mutability to expressions and thus giving more flexibility to > the language. I hope this subject hasn't been covered too many times, > otherwise I'd apologize for any disturbance. > > To build such mutable expressions, I've specified a new unary operator > ` along with its resulting class 'java.lang.Term'. The quotation > operator creates a 'Term' from any reference which can then be linked > to other terms to finally be evaluated to the result of a function > call for lambdas or the reference itself otherwise. > > Let's take some examples from the attached patch: > > + interface Get { > + int op(); > + } > + > + interface Sum { > + int op(int i, int j); > + } > > + int a = 0, b = 0; > + Sum s = (x, y) -> x + y; > > + public void run() { > + Get a = () -> this.a; > + Get b = () -> this.b; > + > + Term e1 = (`s).link(`a, `b); > + this.a = 1; this.b = 2; > > The above lines create a mutable expression e1 from the sum lambda s > of the getter a and b which can then be evaluated to: > > (Integer)e1.value() == 3 > > or visualized as: > > e1.toString().equals("Sum( Get( ) Get( ) )") > > An interesting application similar to ?3.g from [1] is the computation > of the partial derivative of a sum involving the mutation of the > initial expression to produce a new resulting one: > > + // Derivative of sum e with respect to r > + Term derivative(Term e, Term r) { > + if (e.terms.isEmpty()) { > + return `Integer.valueOf(e.that == r.that ? 1 : 0); > + } > + else if(e.that == (`s).that) { > + return (`s).link(derivative(e.terms.get(0), r), > derivative(e.terms.get(1), r)); > + } > + else throw new AssertionError(); > + } > > Invoking the above method like this: > > + Term e2 = derivative(e1, `a); > > creates the resulting derivative expression e2 which can then be evaluated to: > > (Integer)e2.value() == 1 > > or visualized as: > > e2.toString().equals("Sum( `1 `0 )") > > Finally, we note that any term may be quoted to prevent its > evaluation, for example: > > + Derivative d = this::derivative; > > + Term e3 = (`d).link(`e1, ``a); > > can be evaluated to: > > (Integer)((Term)e3.value()).value() == 1 > > or visualized as: > > e3.toString().equals("Derivative( `Sum( Get( ) Get( ) ) `Get( ) )") > > Of course, one of our main concern is how much do we need this and a > reasonable answer would probably be as much as we need Lisp's > S-expressions but with similar or maybe better performance than > external interpreters and a more homogeneous integration to the > language. > > Any feedback about this experiment would be welcome! > > Thanks, > Bernard > > [1] http://www-formal.stanford.edu/jmc/recursive.html > [2] quote.patch From paul.sandoz at oracle.com Mon Mar 23 16:00:30 2020 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 23 Mar 2020 09:00:30 -0700 Subject: Enhancing expressions with mutability? In-Reply-To: <9238fa7d-3035-6f10-7334-3772df712584@oracle.com> References: <9238fa7d-3035-6f10-7334-3772df712584@oracle.com> Message-ID: <3C71B207-24D0-429F-80A9-EB9C6E2AC381@oracle.com> Hi, Yes, interesting stuff. I agree with Maurizio here, naturally because we have talked about this area a few times. C# expression trees and LINQ is a great example. I think we can apply this more broadly to source compile time, link time and runtime, and more broadly to the source that can be ?quoted? (or target typed, rather than built programmatically). Such an IR could be an interchange format between various domains. A significant challenge is to find the right structural form to support many use cases. The machine learning area is particularly interesting to me in this respect. There appears to be an explosion in bespoke static compiler pipelines and analysis of code. Paul. > On Mar 23, 2020, at 7:31 AM, Maurizio Cimadamore wrote: > > Hey Bernard, > cool stuff. Your patch seems to be missing the Term class, which is kind of important to look at to see how it interoperates with javac. > > That said, while the ideas you explore are interesting, I do not seem them being applicable 'as is' to Java. That said, one direction which overlaps a lot to what you describe here, especially in your derivative example is support for the so called expression trees feature - C# for example has it [1]. > > Expression trees gives the language a new super power, in that it allows the static compiler to create a richer intermediate form for the compiled expression (e.g. other than bytecode), which is then amenable to further processing at runtime - e.g. we could take this IR and compile it down to: > > * regular bytecode - e.g. to generate a method handle > * assembly - very useful for native interop (a la Panama) > * GPU kernel - very useful for offloading computation to GPU or other resources > > At the same time, if the IR is expressive enough, you can do things like differentiating functions and the likes, which are use cases very important in machine learning. > > So, my feeling is that, at some point, we'll start seeing some more concrete experiments in that direction - stay tuned :-) > > Maurizio > > [1] - https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/concepts/expression-trees/ > > On 10/03/2020 21:03, B. Blaser wrote: >> Hi, >> >> Taking back the essential idea of the original publication on Lisp >> [1], I did the attached syntactic experiment [2] trying to bring some >> kind of mutability to expressions and thus giving more flexibility to >> the language. I hope this subject hasn't been covered too many times, >> otherwise I'd apologize for any disturbance. >> >> To build such mutable expressions, I've specified a new unary operator >> ` along with its resulting class 'java.lang.Term'. The quotation >> operator creates a 'Term' from any reference which can then be linked >> to other terms to finally be evaluated to the result of a function >> call for lambdas or the reference itself otherwise. >> >> Let's take some examples from the attached patch: >> >> + interface Get { >> + int op(); >> + } >> + >> + interface Sum { >> + int op(int i, int j); >> + } >> >> + int a = 0, b = 0; >> + Sum s = (x, y) -> x + y; >> >> + public void run() { >> + Get a = () -> this.a; >> + Get b = () -> this.b; >> + >> + Term e1 = (`s).link(`a, `b); >> + this.a = 1; this.b = 2; >> >> The above lines create a mutable expression e1 from the sum lambda s >> of the getter a and b which can then be evaluated to: >> >> (Integer)e1.value() == 3 >> >> or visualized as: >> >> e1.toString().equals("Sum( Get( ) Get( ) )") >> >> An interesting application similar to ?3.g from [1] is the computation >> of the partial derivative of a sum involving the mutation of the >> initial expression to produce a new resulting one: >> >> + // Derivative of sum e with respect to r >> + Term derivative(Term e, Term r) { >> + if (e.terms.isEmpty()) { >> + return `Integer.valueOf(e.that == r.that ? 1 : 0); >> + } >> + else if(e.that == (`s).that) { >> + return (`s).link(derivative(e.terms.get(0), r), >> derivative(e.terms.get(1), r)); >> + } >> + else throw new AssertionError(); >> + } >> >> Invoking the above method like this: >> >> + Term e2 = derivative(e1, `a); >> >> creates the resulting derivative expression e2 which can then be evaluated to: >> >> (Integer)e2.value() == 1 >> >> or visualized as: >> >> e2.toString().equals("Sum( `1 `0 )") >> >> Finally, we note that any term may be quoted to prevent its >> evaluation, for example: >> >> + Derivative d = this::derivative; >> >> + Term e3 = (`d).link(`e1, ``a); >> >> can be evaluated to: >> >> (Integer)((Term)e3.value()).value() == 1 >> >> or visualized as: >> >> e3.toString().equals("Derivative( `Sum( Get( ) Get( ) ) `Get( ) )") >> >> Of course, one of our main concern is how much do we need this and a >> reasonable answer would probably be as much as we need Lisp's >> S-expressions but with similar or maybe better performance than >> external interpreters and a more homogeneous integration to the >> language. >> >> Any feedback about this experiment would be welcome! >> >> Thanks, >> Bernard >> >> [1] http://www-formal.stanford.edu/jmc/recursive.html >> [2] quote.patch From bsrbnd at gmail.com Mon Mar 23 19:01:50 2020 From: bsrbnd at gmail.com (B. Blaser) Date: Mon, 23 Mar 2020 20:01:50 +0100 Subject: Enhancing expressions with mutability? In-Reply-To: <3C71B207-24D0-429F-80A9-EB9C6E2AC381@oracle.com> References: <9238fa7d-3035-6f10-7334-3772df712584@oracle.com> <3C71B207-24D0-429F-80A9-EB9C6E2AC381@oracle.com> Message-ID: Thanks for your feedback, Paul and Maurizio. On Mon, 23 Mar 2020 at 17:00, Paul Sandoz wrote: > > Hi, > > Yes, interesting stuff. > > I agree with Maurizio here, naturally because we have talked about this area a few times. > > C# expression trees and LINQ is a great example. I think we can apply this more broadly to source compile time, link time and runtime, and more broadly to the source that can be ?quoted? (or target typed, rather than built programmatically). > > Such an IR could be an interchange format between various domains. A significant challenge is to find the right structural form to support many use cases. The machine learning area is particularly interesting to me in this respect. There appears to be an explosion in bespoke static compiler pipelines and analysis of code. > I agree that finding the right design is a challenge. I chose the very flexible approach of Lisp-like S-Expressions, but C# offers interesting more restrictive expression trees too which seem to be used in dynamic queries, for example (as I suggested in [2]). But another common use would be for AI in general like evolutionary computation that I'm planning to employ experimentally to solve some tricky performance issues in javac's type inference solving system, see [3]. > Paul. > > > On Mar 23, 2020, at 7:31 AM, Maurizio Cimadamore wrote: > > > > Hey Bernard, > > cool stuff. Your patch seems to be missing the Term class, which is kind of important to look at to see how it interoperates with javac. > > I believe this is the first class of the initially attached 'quote.patch' [4] (next are javac changes along with the test), did you miss it? > > That said, while the ideas you explore are interesting, I do not seem them being applicable 'as is' to Java. That said, one direction which overlaps a lot to what you describe here, especially in your derivative example is support for the so called expression trees feature - C# for example has it [1]. > > I'm not so familiar with C# but some difference I can immediately see is that expression trees seem to use some static typing discipline which prevents them from being modified directly (new ones have to be created). My suggestion is closer to Lisp's S-Expression using a more relaxed dynamic typing discipline enabling full manipulation of existing expressions. > > Expression trees gives the language a new super power, in that it allows the static compiler to create a richer intermediate form for the compiled expression (e.g. other than bytecode), which is then amenable to further processing at runtime - e.g. we could take this IR and compile it down to: > > > > * regular bytecode - e.g. to generate a method handle > > * assembly - very useful for native interop (a la Panama) > > * GPU kernel - very useful for offloading computation to GPU or other resources > > > > At the same time, if the IR is expressive enough, you can do things like differentiating functions and the likes, which are use cases very important in machine learning. > > Yes, my prototype currently relies on reflection to evaluate expressions but the perfect solution would be to ask the JVM to compile them, of course :-) > > So, my feeling is that, at some point, we'll start seeing some more concrete experiments in that direction - stay tuned :-) > > Great, are you planning to do this as part of an existing project like Panama or are you going to create a new one? Ciao, Bernard > > Maurizio > > > > [1] - https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/concepts/expression-trees/ > > [2] http://mail.openjdk.java.net/pipermail/compiler-dev/2020-March/014340.html [3] http://mail.openjdk.java.net/pipermail/compiler-dev/2020-March/014377.html [4] https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20200310/54c5274c/quote-0001.patch From maurizio.cimadamore at oracle.com Mon Mar 23 19:33:38 2020 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Mon, 23 Mar 2020 19:33:38 +0000 Subject: Enhancing expressions with mutability? In-Reply-To: References: <9238fa7d-3035-6f10-7334-3772df712584@oracle.com> <3C71B207-24D0-429F-80A9-EB9C6E2AC381@oracle.com> Message-ID: <6a4113cb-5e51-4406-cf26-d24d8474f257@oracle.com> > I'm planning to employ experimentally to solve some > tricky performance issues in javac's type inference solving system, > see [3]. With respect to implement type inference using these algorithms, I feel less sanguine. While theoretically possible, genetic algorithms usually goes through making random variations in a set of values, and iteratively keeping the values that fit best a given scoring function. Yes, we can define the scoring function to be "does the solution satisfy the bounds" - but getting there by randomly changing variable resolution until you find "one that sticks" doesn't seem amenable in the general case, although I can definitively buy that, in _that specific example_ you refer to, doing things that way is faster than doing things how javac does it (which is wildly suboptimal - hence the bug). There are also other assumptions in your prototype that are, I think, too simplistic - e.g. the fact that you can replace subtyping with subclassing (the latter is of course much faster, and has many many less degrees of freedom) - and, while a strategy like this might converge quickly to a solution, when writing a static compiler is also very important to take into account the case where no solution exists (e.g. compiler error) - do I have to wait forever until all possible permutations are ran? How will error messages be reported (or even determined)? So, while expression-tree-like approaches are very powerful and expressive, I think that a properly implemented and optimized type inference algorithm will always provide better and more predictable performances in the general case. >>> Hey Bernard, >>> cool stuff. Your patch seems to be missing the Term class, which is kind of important to look at to see how it interoperates with javac. >>> > I believe this is the first class of the initially attached > 'quote.patch' [4] (next are javac changes along with the test), did > you miss it? Whoops - yes! > Great, are you planning to do this as part of an existing project like > Panama or are you going to create a new one? At this moment we're exploring what's available out there - we have some ideas of the use cases we'd like to cover, but no specific proposal as of yet. While it's true that some of the core use cases are close to the spirit of Panama, some of the applications are also much broader - so I can see this going both ways. In any case, it's way too early to make such a call :-) Maurizio > > Ciao, > Bernard > >>> Maurizio >>> >>> [1] - https://urldefense.com/v3/__https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/concepts/expression-trees/__;!!GqivPVa7Brio!NfcoHAGJenwaQiTQ8X9WraJnbuoptP3p-CDxaw9iRIV0u9WCJI8z_RuUJLBrpHWd0BFKVWs$ >>> > [2] http://mail.openjdk.java.net/pipermail/compiler-dev/2020-March/014340.html > [3] http://mail.openjdk.java.net/pipermail/compiler-dev/2020-March/014377.html > [4] https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20200310/54c5274c/quote-0001.patch From Tomasz.Poreba at siemens-logistics.com Fri Mar 27 10:27:53 2020 From: Tomasz.Poreba at siemens-logistics.com (Poreba, Tomasz) Date: Fri, 27 Mar 2020 10:27:53 +0000 Subject: Why is Java11 keeping java.util.zip.ZipFile$Source on heap? Message-ID: I noticed that after migrating a Java app from JDK8 to JDK11 a significant portion of heap is being used up by some data related to my jars from the classpath. These are byte[] from java.util.zip.ZipFile$Source (field "cen"), it appears that static map "files" keeps them. Is it deliberate? I couldn't post it to OpenJDK bug tracker, so I described the issue in detail here: https://stackoverflow.com/questions/60835946/why-is-java11-keeping-java-util-zip-zipfilesource-on-heap Regards Tomasz Por?ba From claes.redestad at oracle.com Fri Mar 27 11:17:23 2020 From: claes.redestad at oracle.com (Claes Redestad) Date: Fri, 27 Mar 2020 12:17:23 +0100 Subject: Why is Java11 keeping java.util.zip.ZipFile$Source on heap? In-Reply-To: References: Message-ID: <799a165c-98ec-ce0b-45e7-68b9da396003@oracle.com> Hi Tomasz, this is deliberate and the observation that memory use seem to increase is caused by moving from a native to pure java-based implementation[1] for zip/jar files in JDK 9. Mainly for stability purposes. I'll note that the native implementation allocates similar and similarly sized data structures, but they were hidden out of sight from tools inspecting the java heap. So while total memory footprint should be more or less neutral with the java-based implementation, there might be a need to increase the java heap size to encompass the increased java heap usage. Regards /Claes [1] https://bugs.openjdk.java.net/browse/JDK-8145260 On 2020-03-27 11:27, Poreba, Tomasz wrote: > I noticed that after migrating a Java app from JDK8 to JDK11 a significant portion of heap is being used up by some data related to my jars from the classpath. > These are byte[] from java.util.zip.ZipFile$Source (field "cen"), it appears that static map "files" keeps them. > > Is it deliberate? > > I couldn't post it to OpenJDK bug tracker, so I described the issue in detail here: https://stackoverflow.com/questions/60835946/why-is-java11-keeping-java-util-zip-zipfilesource-on-heap > Regards > Tomasz Por?ba > From Tomasz.Poreba at siemens-logistics.com Fri Mar 27 11:21:11 2020 From: Tomasz.Poreba at siemens-logistics.com (Poreba, Tomasz) Date: Fri, 27 Mar 2020 11:21:11 +0000 Subject: Why is Java11 keeping java.util.zip.ZipFile$Source on heap? In-Reply-To: <799a165c-98ec-ce0b-45e7-68b9da396003@oracle.com> References: <799a165c-98ec-ce0b-45e7-68b9da396003@oracle.com> Message-ID: OK, this makes sense. I will estimate the additional footprint and increase my Xmx accordingly. Would you mind if I put your explanation as an answer to my stackoverflow question? Tomasz > -----Original Message----- > From: Claes Redestad > Sent: Friday, March 27, 2020 12:17 > To: Poreba, Tomasz (SL DB DL TEC R&D-AX4 SD2) logistics.com>; discuss at openjdk.java.net > Subject: Re: Why is Java11 keeping java.util.zip.ZipFile$Source on heap? > > Hi Tomasz, > > this is deliberate and the observation that memory use seem to increase > is caused by moving from a native to pure java-based implementation[1] > for zip/jar files in JDK 9. Mainly for stability purposes. > > I'll note that the native implementation allocates similar and similarly > sized data structures, but they were hidden out of sight from tools > inspecting the java heap. So while total memory footprint should be more > or less neutral with the java-based implementation, there might be a > need to increase the java heap size to encompass the increased java > heap usage. > > Regards > > /Claes > > [1] https://bugs.openjdk.java.net/browse/JDK-8145260 > > On 2020-03-27 11:27, Poreba, Tomasz wrote: > > I noticed that after migrating a Java app from JDK8 to JDK11 a significant > portion of heap is being used up by some data related to my jars from the > classpath. > > These are byte[] from java.util.zip.ZipFile$Source (field "cen"), it appears that > static map "files" keeps them. > > > > Is it deliberate? > > > > I couldn't post it to OpenJDK bug tracker, so I described the issue in detail here: > https://stackoverflow.com/questions/60835946/why-is-java11-keeping-java- > util-zip-zipfilesource-on-heap > > Regards > > Tomasz Por?ba > > From Alan.Bateman at oracle.com Fri Mar 27 11:27:39 2020 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 27 Mar 2020 11:27:39 +0000 Subject: Why is Java11 keeping java.util.zip.ZipFile$Source on heap? In-Reply-To: References: Message-ID: <83bd28d6-0755-6a14-c114-8fcd02df2beb@oracle.com> On 27/03/2020 10:27, Poreba, Tomasz wrote: > I noticed that after migrating a Java app from JDK8 to JDK11 a significant portion of heap is being used up by some data related to my jars from the classpath. > These are byte[] from java.util.zip.ZipFile$Source (field "cen"), it appears that static map "files" keeps them. > > Is it deliberate? > ZipFile was significantly re-implemented in 2015 (for JDK 9) to remove JNI overhead and also the problematic memory mapping of the ZIP file central directory. So yes, you will see a difference between the native and heap usage. The core-libs-dev mailing list is the place to being issues if you find a memory leak or bugs. -Alan From mohammed.moayed at gmail.com Sun Mar 29 09:39:07 2020 From: mohammed.moayed at gmail.com (Mohammed Al-Moayed) Date: Sun, 29 Mar 2020 12:39:07 +0300 Subject: Call for Discussion: New Project: Developer's Guide In-Reply-To: <00451a01-61c3-926c-9612-4649bc7a0e72@oracle.com> References: <00451a01-61c3-926c-9612-4649bc7a0e72@oracle.com> Message-ID: <4D3DDDFE-90D0-4551-B35E-E4F3331EE85F@gmail.com> Hi guys I tried to opt out from this mailing list. Please, anybody help me on how to do that Regards > On Mar 20, 2020, at 1:34 PM, Magnus Ihse Bursie wrote: > > ?On 2020-03-12 00:51, Jesper Wilhelmsson wrote: >> Hi. >> >> I would like to discuss the possible creation of the Developer's Guide Project >> with myself, Jesper Wilhelmsson, as the lead and the Core-Libs, Compiler, and >> Hotspot groups as the sponsoring Groups. >> >> The initial goal of the project would be to create up-to-date guidelines for >> OpenJDK development and contributions. The intent is to update the existing >> OpenJDK Developer's Guide [1] which hasn't been updated since 2012. Parts of >> the existing guide are in need of updates while other parts are yet to be >> written. The initial source code for this project will be based on the current >> OpenJDK Developer's Guide. >> >> In more recent years some process related information has been published on the >> OpenJDK wiki [2], but this information was never reviewed or approved by the >> community. Even though large parts of this information may be accurate, it needs >> to go through proper review before it can be seen as official guidelines for >> OpenJDK development. >> >> Once the initial goal has been reached the project will transition into a >> maintenance project to keep the OpenJDK Developer's Guide up to date. >> >> The OpenJDK Developer's Guide is intended to contain tutorial style texts that >> give examples and step-by-step directions for common parts of the development >> process. Strict rules for OpenJDK development are better suited to a process >> JEP. The development of such a JEP is outside of the scope of this project but >> will be developed as part of a separate effort in parallel. > > Hi Jesper, > > I've browsed through the discussion, but could not easily find if you consider style guides (this neverending hot topic!) as being included in, or excluded from, this effort. > > Personally, as a newcomer to any project, I would consider a style guide helpful when trying to submit code that'd be readily accepted. Even if it's just a "descriptive" guide, not a normative one. So, given this, I'd strongly recommend that the project ends up with promoting a single source of truth style guide, even if it is just descriptive of most current practices, rather than normative. > > And, in that respect, I'd kindly want to point out the effort made by Andreas Lundblad some years ago [1]. His style guide went through multiple iterations, incorporated a lot of feedback from many OpenJDK developers, and is probably the best document to capture the current "best practices" of OpenJDK source code style. Unfortunately, it basically fell short of the finishing line since there were no good way, process-wise, on how to handle the resulting document. > > /Magnus > > [1] http://cr.openjdk.java.net/~alundblad/styleguide/index-v6.html > From mohammed.moayed at gmail.com Sun Mar 29 09:43:25 2020 From: mohammed.moayed at gmail.com (Mohammed Al-Moayed) Date: Sun, 29 Mar 2020 12:43:25 +0300 Subject: Call for Discussion: New Project: Developer's Guide In-Reply-To: <62FA7D5A-5D25-4617-853F-3B0BC09CE154@oracle.com> References: <62FA7D5A-5D25-4617-853F-3B0BC09CE154@oracle.com> Message-ID: <0D9DE337-FD2D-41ED-BA1C-832ACF2D1988@gmail.com> Hi All I am interested to be part of this. Please, let me know next steps Regards Mohammed Almo > On Mar 12, 2020, at 2:51 AM, Jesper Wilhelmsson wrote: > > ?Hi. > > I would like to discuss the possible creation of the Developer's Guide Project > with myself, Jesper Wilhelmsson, as the lead and the Core-Libs, Compiler, and > Hotspot groups as the sponsoring Groups. > > The initial goal of the project would be to create up-to-date guidelines for > OpenJDK development and contributions. The intent is to update the existing > OpenJDK Developer's Guide [1] which hasn't been updated since 2012. Parts of > the existing guide are in need of updates while other parts are yet to be > written. The initial source code for this project will be based on the current > OpenJDK Developer's Guide. > > In more recent years some process related information has been published on the > OpenJDK wiki [2], but this information was never reviewed or approved by the > community. Even though large parts of this information may be accurate, it needs > to go through proper review before it can be seen as official guidelines for > OpenJDK development. > > Once the initial goal has been reached the project will transition into a > maintenance project to keep the OpenJDK Developer's Guide up to date. > > The OpenJDK Developer's Guide is intended to contain tutorial style texts that > give examples and step-by-step directions for common parts of the development > process. Strict rules for OpenJDK development are better suited to a process > JEP. The development of such a JEP is outside of the scope of this project but > will be developed as part of a separate effort in parallel. > > Initial committers of the Developer's Guide Project include Mark Reinhold, Iris > Clark, and Jesper Wilhelmsson. Additional committers may be identified through > this discussion. > > The project will host at least one mailing list, guide-dev at openjdk.java.net, > for discussions and reviews of changes. > > Thanks, > /Jesper > > [1] http://openjdk.java.net/guide/ > [2] https://wiki.openjdk.java.net/ > From mohammed.moayed at gmail.com Sun Mar 29 09:44:15 2020 From: mohammed.moayed at gmail.com (Mohammed Al-Moayed) Date: Sun, 29 Mar 2020 12:44:15 +0300 Subject: Call for Discussion: New Project: Developer's Guide In-Reply-To: <4D3DDDFE-90D0-4551-B35E-E4F3331EE85F@gmail.com> References: <4D3DDDFE-90D0-4551-B35E-E4F3331EE85F@gmail.com> Message-ID: Please, neglect below email. Sent by mistake , intended to other mailing list > On Mar 29, 2020, at 12:39 PM, Mohammed Al-Moayed wrote: > > ?Hi guys > > I tried to opt out from this mailing list. Please, anybody help me on how to do that > > Regards > >>> On Mar 20, 2020, at 1:34 PM, Magnus Ihse Bursie wrote: >>> >>> ?On 2020-03-12 00:51, Jesper Wilhelmsson wrote: >>> Hi. >>> >>> I would like to discuss the possible creation of the Developer's Guide Project >>> with myself, Jesper Wilhelmsson, as the lead and the Core-Libs, Compiler, and >>> Hotspot groups as the sponsoring Groups. >>> >>> The initial goal of the project would be to create up-to-date guidelines for >>> OpenJDK development and contributions. The intent is to update the existing >>> OpenJDK Developer's Guide [1] which hasn't been updated since 2012. Parts of >>> the existing guide are in need of updates while other parts are yet to be >>> written. The initial source code for this project will be based on the current >>> OpenJDK Developer's Guide. >>> >>> In more recent years some process related information has been published on the >>> OpenJDK wiki [2], but this information was never reviewed or approved by the >>> community. Even though large parts of this information may be accurate, it needs >>> to go through proper review before it can be seen as official guidelines for >>> OpenJDK development. >>> >>> Once the initial goal has been reached the project will transition into a >>> maintenance project to keep the OpenJDK Developer's Guide up to date. >>> >>> The OpenJDK Developer's Guide is intended to contain tutorial style texts that >>> give examples and step-by-step directions for common parts of the development >>> process. Strict rules for OpenJDK development are better suited to a process >>> JEP. The development of such a JEP is outside of the scope of this project but >>> will be developed as part of a separate effort in parallel. >> >> Hi Jesper, >> >> I've browsed through the discussion, but could not easily find if you consider style guides (this neverending hot topic!) as being included in, or excluded from, this effort. >> >> Personally, as a newcomer to any project, I would consider a style guide helpful when trying to submit code that'd be readily accepted. Even if it's just a "descriptive" guide, not a normative one. So, given this, I'd strongly recommend that the project ends up with promoting a single source of truth style guide, even if it is just descriptive of most current practices, rather than normative. >> >> And, in that respect, I'd kindly want to point out the effort made by Andreas Lundblad some years ago [1]. His style guide went through multiple iterations, incorporated a lot of feedback from many OpenJDK developers, and is probably the best document to capture the current "best practices" of OpenJDK source code style. Unfortunately, it basically fell short of the finishing line since there were no good way, process-wise, on how to handle the resulting document. >> >> /Magnus >> >> [1] http://cr.openjdk.java.net/~alundblad/styleguide/index-v6.html >> From jiaywe at gmail.com Mon Mar 30 08:42:34 2020 From: jiaywe at gmail.com (JiaYanwei) Date: Mon, 30 Mar 2020 16:42:34 +0800 Subject: Introduction: Jia Yanwei Message-ID: Hello everyone, I'm glad that my OCA has been processed. I want to fix a corner case crash of Java compiler recently and I wish I can do more in the future. I have been working on in server-side development for 12 years, including 5 years in Java development. I'm familiar with programming languages such as Java, Kotlin, C++ and Rust etc. I'm also an open source developer, maintained several small open source projects, and also contributed small patches to a few other projects. I am new here, guidance is highly appreciated. Best Regards, Yanwei From zoltan.jose at gmail.com Mon Mar 30 15:27:27 2020 From: zoltan.jose at gmail.com (Timmy Jose) Date: Mon, 30 Mar 2020 20:57:27 +0530 Subject: Introduction Message-ID: Hello all, I am Timmy Jose, and am stoked that my OCA application approved. I have been a Java developer for around 10 years with forays into Python, Ruby, and Rust. I am also deeply interested in Programming Language Theory and dabble in Haskell, Common Lisp, Idris and Zig. I would be mostly interested in contributing (both bugfixes as well as features) to the JDK itself, and also perhaps eventually get to work on the JVM itself, which would be extremely interesting. I'm very happy to be here, and to meet all you nice folks. Cheers! Timmy From martijnverburg at gmail.com Mon Mar 30 19:56:04 2020 From: martijnverburg at gmail.com (Martijn Verburg) Date: Mon, 30 Mar 2020 19:56:04 +0000 Subject: Introduction: Jia Yanwei In-Reply-To: References: Message-ID: Welcome, Yanwei, The place to start is: http://openjdk.java.net/contribute/ Cheers, Martijn On Mon, 30 Mar 2020 at 09:43, JiaYanwei wrote: > Hello everyone, > > I'm glad that my OCA has been processed. I want to fix a corner case crash > of Java compiler recently and I wish I can do more in the future. > > I have been working on in server-side development for 12 years, including 5 > years in Java development. I'm familiar with programming languages such as > Java, Kotlin, C++ and Rust etc. I'm also an open source developer, > maintained several small open source projects, and also contributed small > patches to a few other projects. > > I am new here, guidance is highly appreciated. > > Best Regards, > Yanwei > From martijnverburg at gmail.com Mon Mar 30 19:59:57 2020 From: martijnverburg at gmail.com (Martijn Verburg) Date: Mon, 30 Mar 2020 19:59:57 +0000 Subject: Introduction In-Reply-To: References: Message-ID: Welcome, Timmy! Cheers, Martijn On Mon, 30 Mar 2020 at 16:29, Timmy Jose wrote: > Hello all, > > I am Timmy Jose, and am stoked that my OCA application approved. > > I have been a Java developer for around 10 years with forays into Python, > Ruby, and Rust. I am also deeply interested in Programming Language Theory > and dabble in Haskell, Common Lisp, Idris and Zig. > > I would be mostly interested in contributing (both bugfixes as well as > features) to the JDK itself, and also perhaps eventually get to work on the > JVM itself, which would be extremely interesting. > > I'm very happy to be here, and to meet all you nice folks. > > Cheers! > > Timmy > From john.r.rose at oracle.com Mon Mar 30 22:57:18 2020 From: john.r.rose at oracle.com (John Rose) Date: Mon, 30 Mar 2020 15:57:18 -0700 Subject: CFV: New Project: Developer's Guide In-Reply-To: <96139BAE-FB33-44F1-ADA6-04E6068A842D@oracle.com> References: <96139BAE-FB33-44F1-ADA6-04E6068A842D@oracle.com> Message-ID: Vote: yes From jonathan.gibbons at oracle.com Mon Mar 30 23:02:02 2020 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Mon, 30 Mar 2020 16:02:02 -0700 Subject: CFV: New Project: Developer's Guide In-Reply-To: <96139BAE-FB33-44F1-ADA6-04E6068A842D@oracle.com> References: <96139BAE-FB33-44F1-ADA6-04E6068A842D@oracle.com> Message-ID: <0b13921d-ba65-ada0-34ee-e7180a364d48@oracle.com> Vote: yes -- Jon On 3/30/20 2:35 PM, Jesper Wilhelmsson wrote: > I hereby propose the creation of the Developer's Guide Project with myself, > Jesper Wilhelmsson, as the lead and the Core Libraries, Compiler, and HotSpot > Groups as the sponsoring Groups. > > The suggested project has been out for discussion on discuss at openjdk.java.net > for two weeks [1]. It was well-received and I haven't noted any concerns with > creating the project in that discussion. > > The initial goal of the project would be to create up-to-date guidelines for > OpenJDK development and contributions. The intent is to update the existing > OpenJDK Developer's Guide [2] which hasn't been updated since 2012. Parts of > the existing guide are in need of updates while other parts are yet to be > written. The initial source code for this project will be based on the current > OpenJDK Developer's Guide. > > In more recent years some process related information has been published on the > OpenJDK wiki [3], but this information was never reviewed or approved by the > community. Even though large parts of this information may be accurate, it > needs to go through proper review before it can be seen as official guidelines > for OpenJDK development. > > Once the initial goal has been reached the project will transition into a > maintenance project to keep the OpenJDK Developer's Guide up to date. > > The OpenJDK Developer's Guide is intended to contain tutorial style texts that > give examples and step-by-step directions for common parts of the development > process. Strict rules for OpenJDK development are better suited to a process > JEP. The development of such a JEP is outside of the scope of this project but > will be developed as part of a separate effort in parallel. > > I (Jesper Wilhelmsson) am part of the Java Platform Group at Oracle and have > been working with virtual machine development since 2001. My initial focus was > on memory management and garbage collection but over the last few years I've > been more involved in gatekeeping and process questions around the OpenJDK. > I authored several of the guides available on the OpenJDK HotSpot wiki and I > regularly give talks on how to contribute to the OpenJDK. > > Initial committers of the Developer's Guide Project include Mark Reinhold (mr), > Iris Clark (iris), and Jesper Wilhelmsson (jwilhelm). A complete list will be > provided to the registrar at the successful conclusion of this CFV. > > The project will host at least one mailing list, guide-dev at openjdk.java.net, > for discussions and reviews of changes. > > Votes are due by 5pm PDT on Tuesday April 14 2020. > > 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]. > > Thanks, > /Jesper > > [1] https://mail.openjdk.java.net/pipermail/discuss/2020-March/005298.html > [2] http://openjdk.java.net/guide/ > [3] https://wiki.openjdk.java.net/ > [4] http://openjdk.java.net/census#members > [5] http://openjdk.java.net/projects/#new-project-vote > From kusrinivasan at vmware.com Mon Mar 30 23:04:23 2020 From: kusrinivasan at vmware.com (Kumar Srinivasan) Date: Mon, 30 Mar 2020 23:04:23 +0000 Subject: CFV: New Project: Developer's Guide In-Reply-To: <96139BAE-FB33-44F1-ADA6-04E6068A842D@oracle.com> References: <96139BAE-FB33-44F1-ADA6-04E6068A842D@oracle.com> Message-ID: <45E17BBC-6CAD-4F4C-991E-7A4DA39FF424@vmware.com> Vote: yes > On Mar 30, 2020, at 2:35 PM, Jesper Wilhelmsson wrote: > > I hereby propose the creation of the Developer's Guide Project with myself, > Jesper Wilhelmsson, as the lead and the Core Libraries, Compiler, and HotSpot > Groups as the sponsoring Groups. > > The suggested project has been out for discussion on discuss at openjdk.java.net > for two weeks [1]. It was well-received and I haven't noted any concerns with > creating the project in that discussion. > > The initial goal of the project would be to create up-to-date guidelines for > OpenJDK development and contributions. The intent is to update the existing > OpenJDK Developer's Guide [2] which hasn't been updated since 2012. Parts of > the existing guide are in need of updates while other parts are yet to be > written. The initial source code for this project will be based on the current > OpenJDK Developer's Guide. > > In more recent years some process related information has been published on the > OpenJDK wiki [3], but this information was never reviewed or approved by the > community. Even though large parts of this information may be accurate, it > needs to go through proper review before it can be seen as official guidelines > for OpenJDK development. > > Once the initial goal has been reached the project will transition into a > maintenance project to keep the OpenJDK Developer's Guide up to date. > > The OpenJDK Developer's Guide is intended to contain tutorial style texts that > give examples and step-by-step directions for common parts of the development > process. Strict rules for OpenJDK development are better suited to a process > JEP. The development of such a JEP is outside of the scope of this project but > will be developed as part of a separate effort in parallel. > > I (Jesper Wilhelmsson) am part of the Java Platform Group at Oracle and have > been working with virtual machine development since 2001. My initial focus was > on memory management and garbage collection but over the last few years I've > been more involved in gatekeeping and process questions around the OpenJDK. > I authored several of the guides available on the OpenJDK HotSpot wiki and I > regularly give talks on how to contribute to the OpenJDK. > > Initial committers of the Developer's Guide Project include Mark Reinhold (mr), > Iris Clark (iris), and Jesper Wilhelmsson (jwilhelm). A complete list will be > provided to the registrar at the successful conclusion of this CFV. > > The project will host at least one mailing list, guide-dev at openjdk.java.net, > for discussions and reviews of changes. > > Votes are due by 5pm PDT on Tuesday April 14 2020. > > 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]. > > Thanks, > /Jesper > > [1] https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.openjdk.java.net%2Fpipermail%2Fdiscuss%2F2020-March%2F005298.html&data=02%7C01%7Ckusrinivasan%40vmware.com%7C9c092db3d3434683300208d7d4fb64ff%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637212048509011293&sdata=T%2B8Fq90AXkk6sP2a6ET45%2BoHMgIqpWmhuXdPxeux%2FDk%3D&reserved=0 > [2] https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fopenjdk.java.net%2Fguide%2F&data=02%7C01%7Ckusrinivasan%40vmware.com%7C9c092db3d3434683300208d7d4fb64ff%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637212048509011293&sdata=4d76r6K2g7mEKUEGgoA9JZrcSU0dKG%2FZadZzi5QcV4A%3D&reserved=0 > [3] https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwiki.openjdk.java.net%2F&data=02%7C01%7Ckusrinivasan%40vmware.com%7C9c092db3d3434683300208d7d4fb64ff%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637212048509021290&sdata=j4Ao%2B2c3dRpmkZy3uzmdS%2BNrHyuhp8DgNDaDK5s6%2BHY%3D&reserved=0 > [4] https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fopenjdk.java.net%2Fcensus%23members&data=02%7C01%7Ckusrinivasan%40vmware.com%7C9c092db3d3434683300208d7d4fb64ff%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637212048509021290&sdata=1uM2K%2FB4JGMjj0QMIaBwnykHP8tAIsW3KJZXorV4%2FcM%3D&reserved=0 > [5] https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fopenjdk.java.net%2Fprojects%2F%23new-project-vote&data=02%7C01%7Ckusrinivasan%40vmware.com%7C9c092db3d3434683300208d7d4fb64ff%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637212048509021290&sdata=xDJa2lE3hoB4VEgH4DCP36wLArJXfDFoj8AfCB0hzRQ%3D&reserved=0 > From lance.andersen at oracle.com Mon Mar 30 23:10:59 2020 From: lance.andersen at oracle.com (Lance Andersen) Date: Mon, 30 Mar 2020 19:10:59 -0400 Subject: CFV: New Project: Developer's Guide In-Reply-To: <96139BAE-FB33-44F1-ADA6-04E6068A842D@oracle.com> References: <96139BAE-FB33-44F1-ADA6-04E6068A842D@oracle.com> Message-ID: <81388A22-EC1B-4EF9-A8B6-EA32C349595D@oracle.com> vote: YES > On Mar 30, 2020, at 5:35 PM, Jesper Wilhelmsson wrote: > > I hereby propose the creation of the Developer's Guide Project with myself, > Jesper Wilhelmsson, as the lead and the Core Libraries, Compiler, and HotSpot > Groups as the sponsoring Groups. > > The suggested project has been out for discussion on discuss at openjdk.java.net > for two weeks [1]. It was well-received and I haven't noted any concerns with > creating the project in that discussion. > > The initial goal of the project would be to create up-to-date guidelines for > OpenJDK development and contributions. The intent is to update the existing > OpenJDK Developer's Guide [2] which hasn't been updated since 2012. Parts of > the existing guide are in need of updates while other parts are yet to be > written. The initial source code for this project will be based on the current > OpenJDK Developer's Guide. > > In more recent years some process related information has been published on the > OpenJDK wiki [3], but this information was never reviewed or approved by the > community. Even though large parts of this information may be accurate, it > needs to go through proper review before it can be seen as official guidelines > for OpenJDK development. > > Once the initial goal has been reached the project will transition into a > maintenance project to keep the OpenJDK Developer's Guide up to date. > > The OpenJDK Developer's Guide is intended to contain tutorial style texts that > give examples and step-by-step directions for common parts of the development > process. Strict rules for OpenJDK development are better suited to a process > JEP. The development of such a JEP is outside of the scope of this project but > will be developed as part of a separate effort in parallel. > > I (Jesper Wilhelmsson) am part of the Java Platform Group at Oracle and have > been working with virtual machine development since 2001. My initial focus was > on memory management and garbage collection but over the last few years I've > been more involved in gatekeeping and process questions around the OpenJDK. > I authored several of the guides available on the OpenJDK HotSpot wiki and I > regularly give talks on how to contribute to the OpenJDK. > > Initial committers of the Developer's Guide Project include Mark Reinhold (mr), > Iris Clark (iris), and Jesper Wilhelmsson (jwilhelm). A complete list will be > provided to the registrar at the successful conclusion of this CFV. > > The project will host at least one mailing list, guide-dev at openjdk.java.net, > for discussions and reviews of changes. > > Votes are due by 5pm PDT on Tuesday April 14 2020. > > 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]. > > Thanks, > /Jesper > > [1] https://mail.openjdk.java.net/pipermail/discuss/2020-March/005298.html > [2] http://openjdk.java.net/guide/ > [3] https://wiki.openjdk.java.net/ > [4] http://openjdk.java.net/census#members > [5] http://openjdk.java.net/projects/#new-project-vote > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From joe.darcy at oracle.com Mon Mar 30 23:25:00 2020 From: joe.darcy at oracle.com (Joe Darcy) Date: Mon, 30 Mar 2020 16:25:00 -0700 Subject: CFV: New Project: Developer's Guide In-Reply-To: <96139BAE-FB33-44F1-ADA6-04E6068A842D@oracle.com> References: <96139BAE-FB33-44F1-ADA6-04E6068A842D@oracle.com> Message-ID: <0378fab8-b999-a3b1-0ba3-eefb11ee6ce9@oracle.com> Vote: yes -Joe On 3/30/2020 2:35 PM, Jesper Wilhelmsson wrote: > I hereby propose the creation of the Developer's Guide Project with myself, > Jesper Wilhelmsson, as the lead and the Core Libraries, Compiler, and HotSpot > Groups as the sponsoring Groups. > > The suggested project has been out for discussion on discuss at openjdk.java.net > for two weeks [1]. It was well-received and I haven't noted any concerns with > creating the project in that discussion. > > The initial goal of the project would be to create up-to-date guidelines for > OpenJDK development and contributions. The intent is to update the existing > OpenJDK Developer's Guide [2] which hasn't been updated since 2012. Parts of > the existing guide are in need of updates while other parts are yet to be > written. The initial source code for this project will be based on the current > OpenJDK Developer's Guide. > > In more recent years some process related information has been published on the > OpenJDK wiki [3], but this information was never reviewed or approved by the > community. Even though large parts of this information may be accurate, it > needs to go through proper review before it can be seen as official guidelines > for OpenJDK development. > > Once the initial goal has been reached the project will transition into a > maintenance project to keep the OpenJDK Developer's Guide up to date. > > The OpenJDK Developer's Guide is intended to contain tutorial style texts that > give examples and step-by-step directions for common parts of the development > process. Strict rules for OpenJDK development are better suited to a process > JEP. The development of such a JEP is outside of the scope of this project but > will be developed as part of a separate effort in parallel. > > I (Jesper Wilhelmsson) am part of the Java Platform Group at Oracle and have > been working with virtual machine development since 2001. My initial focus was > on memory management and garbage collection but over the last few years I've > been more involved in gatekeeping and process questions around the OpenJDK. > I authored several of the guides available on the OpenJDK HotSpot wiki and I > regularly give talks on how to contribute to the OpenJDK. > > Initial committers of the Developer's Guide Project include Mark Reinhold (mr), > Iris Clark (iris), and Jesper Wilhelmsson (jwilhelm). A complete list will be > provided to the registrar at the successful conclusion of this CFV. > > The project will host at least one mailing list, guide-dev at openjdk.java.net, > for discussions and reviews of changes. > > Votes are due by 5pm PDT on Tuesday April 14 2020. > > 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]. > > Thanks, > /Jesper > > [1] https://mail.openjdk.java.net/pipermail/discuss/2020-March/005298.html > [2] http://openjdk.java.net/guide/ > [3] https://wiki.openjdk.java.net/ > [4] http://openjdk.java.net/census#members > [5] http://openjdk.java.net/projects/#new-project-vote > From jesper.wilhelmsson at oracle.com Mon Mar 30 23:30:58 2020 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Tue, 31 Mar 2020 01:30:58 +0200 Subject: Call for Discussion: New Project: Developer's Guide In-Reply-To: <0D9DE337-FD2D-41ED-BA1C-832ACF2D1988@gmail.com> References: <62FA7D5A-5D25-4617-853F-3B0BC09CE154@oracle.com> <0D9DE337-FD2D-41ED-BA1C-832ACF2D1988@gmail.com> Message-ID: <0C45825A-821F-4C9A-A88D-2F5EAC406F01@oracle.com> Hi Mohammed. I'm happy to hear that you are interested in this project. The next step is the vote that has been initiated now. All Members of the OpenJDK have a vote and if they approve to creating the project it will be created. Once the project is in place we can start discussing the future. Thanks, /Jesper > On 29 Mar 2020, at 11:43, Mohammed Al-Moayed wrote: > > Hi All > > I am interested to be part of this. > > Please, let me know next steps > > Regards > Mohammed Almo > >> On Mar 12, 2020, at 2:51 AM, Jesper Wilhelmsson wrote: >> >> ?Hi. >> >> I would like to discuss the possible creation of the Developer's Guide Project >> with myself, Jesper Wilhelmsson, as the lead and the Core-Libs, Compiler, and >> Hotspot groups as the sponsoring Groups. >> >> The initial goal of the project would be to create up-to-date guidelines for >> OpenJDK development and contributions. The intent is to update the existing >> OpenJDK Developer's Guide [1] which hasn't been updated since 2012. Parts of >> the existing guide are in need of updates while other parts are yet to be >> written. The initial source code for this project will be based on the current >> OpenJDK Developer's Guide. >> >> In more recent years some process related information has been published on the >> OpenJDK wiki [2], but this information was never reviewed or approved by the >> community. Even though large parts of this information may be accurate, it needs >> to go through proper review before it can be seen as official guidelines for >> OpenJDK development. >> >> Once the initial goal has been reached the project will transition into a >> maintenance project to keep the OpenJDK Developer's Guide up to date. >> >> The OpenJDK Developer's Guide is intended to contain tutorial style texts that >> give examples and step-by-step directions for common parts of the development >> process. Strict rules for OpenJDK development are better suited to a process >> JEP. The development of such a JEP is outside of the scope of this project but >> will be developed as part of a separate effort in parallel. >> >> Initial committers of the Developer's Guide Project include Mark Reinhold, Iris >> Clark, and Jesper Wilhelmsson. Additional committers may be identified through >> this discussion. >> >> The project will host at least one mailing list, guide-dev at openjdk.java.net, >> for discussions and reviews of changes. >> >> Thanks, >> /Jesper >> >> [1] http://openjdk.java.net/guide/ >> [2] https://wiki.openjdk.java.net/ >> From david.holmes at oracle.com Mon Mar 30 23:33:45 2020 From: david.holmes at oracle.com (David Holmes) Date: Tue, 31 Mar 2020 09:33:45 +1000 Subject: CFV: New Project: Developer's Guide In-Reply-To: <96139BAE-FB33-44F1-ADA6-04E6068A842D@oracle.com> References: <96139BAE-FB33-44F1-ADA6-04E6068A842D@oracle.com> Message-ID: <98d03a7e-9258-7c91-1cdc-f4767189acdf@oracle.com> Vote: yes David On 31/03/2020 7:35 am, Jesper Wilhelmsson wrote: > I hereby propose the creation of the Developer's Guide Project with myself, > Jesper Wilhelmsson, as the lead and the Core Libraries, Compiler, and HotSpot > Groups as the sponsoring Groups. > > The suggested project has been out for discussion on discuss at openjdk.java.net > for two weeks [1]. It was well-received and I haven't noted any concerns with > creating the project in that discussion. > > The initial goal of the project would be to create up-to-date guidelines for > OpenJDK development and contributions. The intent is to update the existing > OpenJDK Developer's Guide [2] which hasn't been updated since 2012. Parts of > the existing guide are in need of updates while other parts are yet to be > written. The initial source code for this project will be based on the current > OpenJDK Developer's Guide. > > In more recent years some process related information has been published on the > OpenJDK wiki [3], but this information was never reviewed or approved by the > community. Even though large parts of this information may be accurate, it > needs to go through proper review before it can be seen as official guidelines > for OpenJDK development. > > Once the initial goal has been reached the project will transition into a > maintenance project to keep the OpenJDK Developer's Guide up to date. > > The OpenJDK Developer's Guide is intended to contain tutorial style texts that > give examples and step-by-step directions for common parts of the development > process. Strict rules for OpenJDK development are better suited to a process > JEP. The development of such a JEP is outside of the scope of this project but > will be developed as part of a separate effort in parallel. > > I (Jesper Wilhelmsson) am part of the Java Platform Group at Oracle and have > been working with virtual machine development since 2001. My initial focus was > on memory management and garbage collection but over the last few years I've > been more involved in gatekeeping and process questions around the OpenJDK. > I authored several of the guides available on the OpenJDK HotSpot wiki and I > regularly give talks on how to contribute to the OpenJDK. > > Initial committers of the Developer's Guide Project include Mark Reinhold (mr), > Iris Clark (iris), and Jesper Wilhelmsson (jwilhelm). A complete list will be > provided to the registrar at the successful conclusion of this CFV. > > The project will host at least one mailing list, guide-dev at openjdk.java.net, > for discussions and reviews of changes. > > Votes are due by 5pm PDT on Tuesday April 14 2020. > > 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]. > > Thanks, > /Jesper > > [1] https://mail.openjdk.java.net/pipermail/discuss/2020-March/005298.html > [2] http://openjdk.java.net/guide/ > [3] https://wiki.openjdk.java.net/ > [4] http://openjdk.java.net/census#members > [5] http://openjdk.java.net/projects/#new-project-vote > From george45312 at gmail.com Mon Mar 30 23:42:59 2020 From: george45312 at gmail.com (Geo) Date: Mon, 30 Mar 2020 19:42:59 -0400 Subject: CFV: New Project: Developer's Guide In-Reply-To: <98d03a7e-9258-7c91-1cdc-f4767189acdf@oracle.com> References: <98d03a7e-9258-7c91-1cdc-f4767189acdf@oracle.com> Message-ID: <43FCB935-F085-49F4-BA21-8499435B4FA7@gmail.com> yes Best regards, George Siciaridis > On Mar 30, 2020, at 7:34 PM, David Holmes wrote: > > ?Vote: yes > > David > >> On 31/03/2020 7:35 am, Jesper Wilhelmsson wrote: >> I hereby propose the creation of the Developer's Guide Project with myself, >> Jesper Wilhelmsson, as the lead and the Core Libraries, Compiler, and HotSpot >> Groups as the sponsoring Groups. >> The suggested project has been out for discussion on discuss at openjdk.java.net >> for two weeks [1]. It was well-received and I haven't noted any concerns with >> creating the project in that discussion. >> The initial goal of the project would be to create up-to-date guidelines for >> OpenJDK development and contributions. The intent is to update the existing >> OpenJDK Developer's Guide [2] which hasn't been updated since 2012. Parts of >> the existing guide are in need of updates while other parts are yet to be >> written. The initial source code for this project will be based on the current >> OpenJDK Developer's Guide. >> In more recent years some process related information has been published on the >> OpenJDK wiki [3], but this information was never reviewed or approved by the >> community. Even though large parts of this information may be accurate, it >> needs to go through proper review before it can be seen as official guidelines >> for OpenJDK development. >> Once the initial goal has been reached the project will transition into a >> maintenance project to keep the OpenJDK Developer's Guide up to date. >> The OpenJDK Developer's Guide is intended to contain tutorial style texts that >> give examples and step-by-step directions for common parts of the development >> process. Strict rules for OpenJDK development are better suited to a process >> JEP. The development of such a JEP is outside of the scope of this project but >> will be developed as part of a separate effort in parallel. >> I (Jesper Wilhelmsson) am part of the Java Platform Group at Oracle and have >> been working with virtual machine development since 2001. My initial focus was >> on memory management and garbage collection but over the last few years I've >> been more involved in gatekeeping and process questions around the OpenJDK. >> I authored several of the guides available on the OpenJDK HotSpot wiki and I >> regularly give talks on how to contribute to the OpenJDK. >> Initial committers of the Developer's Guide Project include Mark Reinhold (mr), >> Iris Clark (iris), and Jesper Wilhelmsson (jwilhelm). A complete list will be >> provided to the registrar at the successful conclusion of this CFV. >> The project will host at least one mailing list, guide-dev at openjdk.java.net, >> for discussions and reviews of changes. >> Votes are due by 5pm PDT on Tuesday April 14 2020. >> 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]. >> Thanks, >> /Jesper >> [1] https://mail.openjdk.java.net/pipermail/discuss/2020-March/005298.html >> [2] http://openjdk.java.net/guide/ >> [3] https://wiki.openjdk.java.net/ >> [4] http://openjdk.java.net/census#members >> [5] http://openjdk.java.net/projects/#new-project-vote From vicente.romero at oracle.com Tue Mar 31 01:26:26 2020 From: vicente.romero at oracle.com (Vicente Romero) Date: Mon, 30 Mar 2020 21:26:26 -0400 Subject: CFV: New Project: Developer's Guide In-Reply-To: <96139BAE-FB33-44F1-ADA6-04E6068A842D@oracle.com> References: <96139BAE-FB33-44F1-ADA6-04E6068A842D@oracle.com> Message-ID: vote: yes Vicente On 3/30/20 5:35 PM, Jesper Wilhelmsson wrote: > I hereby propose the creation of the Developer's Guide Project with myself, > Jesper Wilhelmsson, as the lead and the Core Libraries, Compiler, and HotSpot > Groups as the sponsoring Groups. > > The suggested project has been out for discussion on discuss at openjdk.java.net > for two weeks [1]. It was well-received and I haven't noted any concerns with > creating the project in that discussion. > > The initial goal of the project would be to create up-to-date guidelines for > OpenJDK development and contributions. The intent is to update the existing > OpenJDK Developer's Guide [2] which hasn't been updated since 2012. Parts of > the existing guide are in need of updates while other parts are yet to be > written. The initial source code for this project will be based on the current > OpenJDK Developer's Guide. > > In more recent years some process related information has been published on the > OpenJDK wiki [3], but this information was never reviewed or approved by the > community. Even though large parts of this information may be accurate, it > needs to go through proper review before it can be seen as official guidelines > for OpenJDK development. > > Once the initial goal has been reached the project will transition into a > maintenance project to keep the OpenJDK Developer's Guide up to date. > > The OpenJDK Developer's Guide is intended to contain tutorial style texts that > give examples and step-by-step directions for common parts of the development > process. Strict rules for OpenJDK development are better suited to a process > JEP. The development of such a JEP is outside of the scope of this project but > will be developed as part of a separate effort in parallel. > > I (Jesper Wilhelmsson) am part of the Java Platform Group at Oracle and have > been working with virtual machine development since 2001. My initial focus was > on memory management and garbage collection but over the last few years I've > been more involved in gatekeeping and process questions around the OpenJDK. > I authored several of the guides available on the OpenJDK HotSpot wiki and I > regularly give talks on how to contribute to the OpenJDK. > > Initial committers of the Developer's Guide Project include Mark Reinhold (mr), > Iris Clark (iris), and Jesper Wilhelmsson (jwilhelm). A complete list will be > provided to the registrar at the successful conclusion of this CFV. > > The project will host at least one mailing list, guide-dev at openjdk.java.net, > for discussions and reviews of changes. > > Votes are due by 5pm PDT on Tuesday April 14 2020. > > 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]. > > Thanks, > /Jesper > > [1] https://mail.openjdk.java.net/pipermail/discuss/2020-March/005298.html > [2] http://openjdk.java.net/guide/ > [3] https://wiki.openjdk.java.net/ > [4] http://openjdk.java.net/census#members > [5] http://openjdk.java.net/projects/#new-project-vote > From james.laskey at oracle.com Tue Mar 31 01:46:24 2020 From: james.laskey at oracle.com (James Laskey) Date: Mon, 30 Mar 2020 22:46:24 -0300 Subject: CFV: New Project: Developer's Guide In-Reply-To: <96139BAE-FB33-44F1-ADA6-04E6068A842D@oracle.com> References: <96139BAE-FB33-44F1-ADA6-04E6068A842D@oracle.com> Message-ID: <7552A29E-F7A4-4DF6-AED8-C682F6AD0AA4@oracle.com> Vote: yes On the road. > On Mar 30, 2020, at 7:42 PM, Jesper Wilhelmsson wrote: > > ?I hereby propose the creation of the Developer's Guide Project with myself, > Jesper Wilhelmsson, as the lead and the Core Libraries, Compiler, and HotSpot > Groups as the sponsoring Groups. > > The suggested project has been out for discussion on discuss at openjdk.java.net > for two weeks [1]. It was well-received and I haven't noted any concerns with > creating the project in that discussion. > > The initial goal of the project would be to create up-to-date guidelines for > OpenJDK development and contributions. The intent is to update the existing > OpenJDK Developer's Guide [2] which hasn't been updated since 2012. Parts of > the existing guide are in need of updates while other parts are yet to be > written. The initial source code for this project will be based on the current > OpenJDK Developer's Guide. > > In more recent years some process related information has been published on the > OpenJDK wiki [3], but this information was never reviewed or approved by the > community. Even though large parts of this information may be accurate, it > needs to go through proper review before it can be seen as official guidelines > for OpenJDK development. > > Once the initial goal has been reached the project will transition into a > maintenance project to keep the OpenJDK Developer's Guide up to date. > > The OpenJDK Developer's Guide is intended to contain tutorial style texts that > give examples and step-by-step directions for common parts of the development > process. Strict rules for OpenJDK development are better suited to a process > JEP. The development of such a JEP is outside of the scope of this project but > will be developed as part of a separate effort in parallel. > > I (Jesper Wilhelmsson) am part of the Java Platform Group at Oracle and have > been working with virtual machine development since 2001. My initial focus was > on memory management and garbage collection but over the last few years I've > been more involved in gatekeeping and process questions around the OpenJDK. > I authored several of the guides available on the OpenJDK HotSpot wiki and I > regularly give talks on how to contribute to the OpenJDK. > > Initial committers of the Developer's Guide Project include Mark Reinhold (mr), > Iris Clark (iris), and Jesper Wilhelmsson (jwilhelm). A complete list will be > provided to the registrar at the successful conclusion of this CFV. > > The project will host at least one mailing list, guide-dev at openjdk.java.net, > for discussions and reviews of changes. > > Votes are due by 5pm PDT on Tuesday April 14 2020. > > 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]. > > Thanks, > /Jesper > > [1] https://mail.openjdk.java.net/pipermail/discuss/2020-March/005298.html > [2] http://openjdk.java.net/guide/ > [3] https://wiki.openjdk.java.net/ > [4] http://openjdk.java.net/census#members > [5] http://openjdk.java.net/projects/#new-project-vote > From ChrisPhi at LGonQn.Org Tue Mar 31 03:48:45 2020 From: ChrisPhi at LGonQn.Org (Chris Phillips) Date: Mon, 30 Mar 2020 23:48:45 -0400 Subject: CFV: New Project: Developer's Guide In-Reply-To: <96139BAE-FB33-44F1-ADA6-04E6068A842D@oracle.com> References: <96139BAE-FB33-44F1-ADA6-04E6068A842D@oracle.com> Message-ID: Vote: Yes ChrisPhi On 2020-03-30 5:35 p.m., Jesper Wilhelmsson wrote: > I hereby propose the creation of the Developer's Guide Project with myself, > Jesper Wilhelmsson, as the lead and the Core Libraries, Compiler, and HotSpot > Groups as the sponsoring Groups. > > The suggested project has been out for discussion on discuss at openjdk.java.net > for two weeks [1]. It was well-received and I haven't noted any concerns with > creating the project in that discussion. > > The initial goal of the project would be to create up-to-date guidelines for > OpenJDK development and contributions. The intent is to update the existing > OpenJDK Developer's Guide [2] which hasn't been updated since 2012. Parts of > the existing guide are in need of updates while other parts are yet to be > written. The initial source code for this project will be based on the current > OpenJDK Developer's Guide. > > In more recent years some process related information has been published on the > OpenJDK wiki [3], but this information was never reviewed or approved by the > community. Even though large parts of this information may be accurate, it > needs to go through proper review before it can be seen as official guidelines > for OpenJDK development. > > Once the initial goal has been reached the project will transition into a > maintenance project to keep the OpenJDK Developer's Guide up to date. > > The OpenJDK Developer's Guide is intended to contain tutorial style texts that > give examples and step-by-step directions for common parts of the development > process. Strict rules for OpenJDK development are better suited to a process > JEP. The development of such a JEP is outside of the scope of this project but > will be developed as part of a separate effort in parallel. > > I (Jesper Wilhelmsson) am part of the Java Platform Group at Oracle and have > been working with virtual machine development since 2001. My initial focus was > on memory management and garbage collection but over the last few years I've > been more involved in gatekeeping and process questions around the OpenJDK. > I authored several of the guides available on the OpenJDK HotSpot wiki and I > regularly give talks on how to contribute to the OpenJDK. > > Initial committers of the Developer's Guide Project include Mark Reinhold (mr), > Iris Clark (iris), and Jesper Wilhelmsson (jwilhelm). A complete list will be > provided to the registrar at the successful conclusion of this CFV. > > The project will host at least one mailing list, guide-dev at openjdk.java.net, > for discussions and reviews of changes. > > Votes are due by 5pm PDT on Tuesday April 14 2020. > > 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]. > > Thanks, > /Jesper > > [1] https://mail.openjdk.java.net/pipermail/discuss/2020-March/005298.html > [2] http://openjdk.java.net/guide/ > [3] https://wiki.openjdk.java.net/ > [4] http://openjdk.java.net/census#members > [5] http://openjdk.java.net/projects/#new-project-vote > > > From volker.simonis at gmail.com Tue Mar 31 06:47:49 2020 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 31 Mar 2020 08:47:49 +0200 Subject: CFV: New Project: Developer's Guide In-Reply-To: <96139BAE-FB33-44F1-ADA6-04E6068A842D@oracle.com> References: <96139BAE-FB33-44F1-ADA6-04E6068A842D@oracle.com> Message-ID: Vote: yes Jesper Wilhelmsson schrieb am Di., 31. M?rz 2020, 00:37: > I hereby propose the creation of the Developer's Guide Project with myself, > Jesper Wilhelmsson, as the lead and the Core Libraries, Compiler, and > HotSpot > Groups as the sponsoring Groups. > > The suggested project has been out for discussion on > discuss at openjdk.java.net > for two weeks [1]. It was well-received and I haven't noted any concerns > with > creating the project in that discussion. > > The initial goal of the project would be to create up-to-date guidelines > for > OpenJDK development and contributions. The intent is to update the existing > OpenJDK Developer's Guide [2] which hasn't been updated since 2012. Parts > of > the existing guide are in need of updates while other parts are yet to be > written. The initial source code for this project will be based on the > current > OpenJDK Developer's Guide. > > In more recent years some process related information has been published > on the > OpenJDK wiki [3], but this information was never reviewed or approved by > the > community. Even though large parts of this information may be accurate, it > needs to go through proper review before it can be seen as official > guidelines > for OpenJDK development. > > Once the initial goal has been reached the project will transition into a > maintenance project to keep the OpenJDK Developer's Guide up to date. > > The OpenJDK Developer's Guide is intended to contain tutorial style texts > that > give examples and step-by-step directions for common parts of the > development > process. Strict rules for OpenJDK development are better suited to a > process > JEP. The development of such a JEP is outside of the scope of this project > but > will be developed as part of a separate effort in parallel. > > I (Jesper Wilhelmsson) am part of the Java Platform Group at Oracle and > have > been working with virtual machine development since 2001. My initial focus > was > on memory management and garbage collection but over the last few years > I've > been more involved in gatekeeping and process questions around the OpenJDK. > I authored several of the guides available on the OpenJDK HotSpot wiki and > I > regularly give talks on how to contribute to the OpenJDK. > > Initial committers of the Developer's Guide Project include Mark Reinhold > (mr), > Iris Clark (iris), and Jesper Wilhelmsson (jwilhelm). A complete list will > be > provided to the registrar at the successful conclusion of this CFV. > > The project will host at least one mailing list, > guide-dev at openjdk.java.net, > for discussions and reviews of changes. > > Votes are due by 5pm PDT on Tuesday April 14 2020. > > 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]. > > Thanks, > /Jesper > > [1] https://mail.openjdk.java.net/pipermail/discuss/2020-March/005298.html > [2] http://openjdk.java.net/guide/ > [3] https://wiki.openjdk.java.net/ > [4] http://openjdk.java.net/census#members > [5] http://openjdk.java.net/projects/#new-project-vote > > From Alan.Bateman at oracle.com Tue Mar 31 06:52:37 2020 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 31 Mar 2020 07:52:37 +0100 Subject: CFV: New Project: Developer's Guide In-Reply-To: <96139BAE-FB33-44F1-ADA6-04E6068A842D@oracle.com> References: <96139BAE-FB33-44F1-ADA6-04E6068A842D@oracle.com> Message-ID: Vote: yes From mohammed.moayed at gmail.com Tue Mar 31 06:58:08 2020 From: mohammed.moayed at gmail.com (Mohammed Al-Moayed) Date: Tue, 31 Mar 2020 09:58:08 +0300 Subject: CFV: New Project: Developer's Guide In-Reply-To: References: Message-ID: Vote: yes > On Mar 31, 2020, at 9:55 AM, Alan Bateman wrote: > > ?Vote: yes From laurent.daynes at oracle.com Tue Mar 31 07:30:09 2020 From: laurent.daynes at oracle.com (Laurent Daynes) Date: Tue, 31 Mar 2020 09:30:09 +0200 Subject: CFV: New Project: Developer's Guide In-Reply-To: References: <96139BAE-FB33-44F1-ADA6-04E6068A842D@oracle.com> Message-ID: <7bed74d5-6a77-2158-755a-f8cdb750237a@oracle.com> Vote: yes From adinn at redhat.com Tue Mar 31 08:07:12 2020 From: adinn at redhat.com (Andrew Dinn) Date: Tue, 31 Mar 2020 09:07:12 +0100 Subject: CFV: New Project: Developer's Guide In-Reply-To: <96139BAE-FB33-44F1-ADA6-04E6068A842D@oracle.com> References: <96139BAE-FB33-44F1-ADA6-04E6068A842D@oracle.com> Message-ID: Vote: yes On 30/03/2020 22:35, Jesper Wilhelmsson wrote: > I hereby propose the creation of the Developer's Guide Project with myself, > Jesper Wilhelmsson, as the lead and the Core Libraries, Compiler, and HotSpot > Groups as the sponsoring Groups. > > The suggested project has been out for discussion on discuss at openjdk.java.net > for two weeks [1]. It was well-received and I haven't noted any concerns with > creating the project in that discussion. > > The initial goal of the project would be to create up-to-date guidelines for > OpenJDK development and contributions. The intent is to update the existing > OpenJDK Developer's Guide [2] which hasn't been updated since 2012. Parts of > the existing guide are in need of updates while other parts are yet to be > written. The initial source code for this project will be based on the current > OpenJDK Developer's Guide. > > In more recent years some process related information has been published on the > OpenJDK wiki [3], but this information was never reviewed or approved by the > community. Even though large parts of this information may be accurate, it > needs to go through proper review before it can be seen as official guidelines > for OpenJDK development. > > Once the initial goal has been reached the project will transition into a > maintenance project to keep the OpenJDK Developer's Guide up to date. > > The OpenJDK Developer's Guide is intended to contain tutorial style texts that > give examples and step-by-step directions for common parts of the development > process. Strict rules for OpenJDK development are better suited to a process > JEP. The development of such a JEP is outside of the scope of this project but > will be developed as part of a separate effort in parallel. > > I (Jesper Wilhelmsson) am part of the Java Platform Group at Oracle and have > been working with virtual machine development since 2001. My initial focus was > on memory management and garbage collection but over the last few years I've > been more involved in gatekeeping and process questions around the OpenJDK. > I authored several of the guides available on the OpenJDK HotSpot wiki and I > regularly give talks on how to contribute to the OpenJDK. > > Initial committers of the Developer's Guide Project include Mark Reinhold (mr), > Iris Clark (iris), and Jesper Wilhelmsson (jwilhelm). A complete list will be > provided to the registrar at the successful conclusion of this CFV. > > The project will host at least one mailing list, guide-dev at openjdk.java.net, > for discussions and reviews of changes. > > Votes are due by 5pm PDT on Tuesday April 14 2020. > > 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]. > > Thanks, > /Jesper > > [1] https://mail.openjdk.java.net/pipermail/discuss/2020-March/005298.html > [2] http://openjdk.java.net/guide/ > [3] https://wiki.openjdk.java.net/ > [4] http://openjdk.java.net/census#members > [5] http://openjdk.java.net/projects/#new-project-vote > -- regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill From sean.coffey at oracle.com Tue Mar 31 08:18:24 2020 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Tue, 31 Mar 2020 09:18:24 +0100 Subject: CFV: New Project: Developer's Guide In-Reply-To: <96139BAE-FB33-44F1-ADA6-04E6068A842D@oracle.com> References: <96139BAE-FB33-44F1-ADA6-04E6068A842D@oracle.com> Message-ID: <25dc07bb-ef54-eee8-1128-64f6b1ef4ebc@oracle.com> vote: yes regards, Sean. On 30/03/2020 22:35, Jesper Wilhelmsson wrote: > I hereby propose the creation of the Developer's Guide Project with myself, > Jesper Wilhelmsson, as the lead and the Core Libraries, Compiler, and HotSpot > Groups as the sponsoring Groups. > > The suggested project has been out for discussion on discuss at openjdk.java.net > for two weeks [1]. It was well-received and I haven't noted any concerns with > creating the project in that discussion. > > The initial goal of the project would be to create up-to-date guidelines for > OpenJDK development and contributions. The intent is to update the existing > OpenJDK Developer's Guide [2] which hasn't been updated since 2012. Parts of > the existing guide are in need of updates while other parts are yet to be > written. The initial source code for this project will be based on the current > OpenJDK Developer's Guide. > > In more recent years some process related information has been published on the > OpenJDK wiki [3], but this information was never reviewed or approved by the > community. Even though large parts of this information may be accurate, it > needs to go through proper review before it can be seen as official guidelines > for OpenJDK development. > > Once the initial goal has been reached the project will transition into a > maintenance project to keep the OpenJDK Developer's Guide up to date. > > The OpenJDK Developer's Guide is intended to contain tutorial style texts that > give examples and step-by-step directions for common parts of the development > process. Strict rules for OpenJDK development are better suited to a process > JEP. The development of such a JEP is outside of the scope of this project but > will be developed as part of a separate effort in parallel. > > I (Jesper Wilhelmsson) am part of the Java Platform Group at Oracle and have > been working with virtual machine development since 2001. My initial focus was > on memory management and garbage collection but over the last few years I've > been more involved in gatekeeping and process questions around the OpenJDK. > I authored several of the guides available on the OpenJDK HotSpot wiki and I > regularly give talks on how to contribute to the OpenJDK. > > Initial committers of the Developer's Guide Project include Mark Reinhold (mr), > Iris Clark (iris), and Jesper Wilhelmsson (jwilhelm). A complete list will be > provided to the registrar at the successful conclusion of this CFV. > > The project will host at least one mailing list, guide-dev at openjdk.java.net, > for discussions and reviews of changes. > > Votes are due by 5pm PDT on Tuesday April 14 2020. > > 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]. > > Thanks, > /Jesper > > [1] https://mail.openjdk.java.net/pipermail/discuss/2020-March/005298.html > [2] http://openjdk.java.net/guide/ > [3] https://wiki.openjdk.java.net/ > [4] http://openjdk.java.net/census#members > [5] http://openjdk.java.net/projects/#new-project-vote > From chris.hegarty at oracle.com Tue Mar 31 10:33:34 2020 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 31 Mar 2020 11:33:34 +0100 Subject: CFV: New Project: Developer's Guide In-Reply-To: <96139BAE-FB33-44F1-ADA6-04E6068A842D@oracle.com> References: <96139BAE-FB33-44F1-ADA6-04E6068A842D@oracle.com> Message-ID: <3E417A06-9B9B-422E-86CE-EB3AAEF9109E@oracle.com> > On 30 Mar 2020, at 22:35, Jesper Wilhelmsson wrote: > > I hereby propose the creation of the Developer's Guide Project with myself, > Jesper Wilhelmsson, as the lead and the Core Libraries, Compiler, and HotSpot > Groups as the sponsoring Groups. Vote: YES. -Chris. From daniel.fuchs at oracle.com Tue Mar 31 10:36:56 2020 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 31 Mar 2020 11:36:56 +0100 Subject: CFV: New Project: Developer's Guide In-Reply-To: <96139BAE-FB33-44F1-ADA6-04E6068A842D@oracle.com> References: <96139BAE-FB33-44F1-ADA6-04E6068A842D@oracle.com> Message-ID: Vote: yes best regards, -- daniel On 30/03/2020 22:35, Jesper Wilhelmsson wrote: > I hereby propose the creation of the Developer's Guide Project with myself, > Jesper Wilhelmsson, as the lead and the Core Libraries, Compiler, and HotSpot > Groups as the sponsoring Groups. From zoltan.jose at gmail.com Tue Mar 31 12:34:42 2020 From: zoltan.jose at gmail.com (Timmy Jose) Date: Tue, 31 Mar 2020 18:04:42 +0530 Subject: Introduction In-Reply-To: References: Message-ID: Thank you, Martijn! Best, Timmy On Tue, Mar 31, 2020 at 1:30 AM Martijn Verburg wrote: > Welcome, Timmy! > > Cheers, > Martijn > > > On Mon, 30 Mar 2020 at 16:29, Timmy Jose wrote: > >> Hello all, >> >> I am Timmy Jose, and am stoked that my OCA application approved. >> >> I have been a Java developer for around 10 years with forays into Python, >> Ruby, and Rust. I am also deeply interested in Programming Language Theory >> and dabble in Haskell, Common Lisp, Idris and Zig. >> >> I would be mostly interested in contributing (both bugfixes as well as >> features) to the JDK itself, and also perhaps eventually get to work on >> the >> JVM itself, which would be extremely interesting. >> >> I'm very happy to be here, and to meet all you nice folks. >> >> Cheers! >> >> Timmy >> > From Roger.Riggs at oracle.com Tue Mar 31 13:40:51 2020 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Tue, 31 Mar 2020 09:40:51 -0400 Subject: CFV: New Project: Developer's Guide In-Reply-To: <96139BAE-FB33-44F1-ADA6-04E6068A842D@oracle.com> References: <96139BAE-FB33-44F1-ADA6-04E6068A842D@oracle.com> Message-ID: <7ee412cd-dce3-bc53-20b4-979fcb9cfe07@oracle.com> Vote: Yes On 3/30/20 5:35 PM, Jesper Wilhelmsson wrote: > I hereby propose the creation of the Developer's Guide Project with myself, > Jesper Wilhelmsson, as the lead and the Core Libraries, Compiler, and HotSpot > Groups as the sponsoring Groups. From vladimir.kozlov at oracle.com Tue Mar 31 15:57:09 2020 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 31 Mar 2020 08:57:09 -0700 Subject: CFV: New Project: Developer's Guide In-Reply-To: <96139BAE-FB33-44F1-ADA6-04E6068A842D@oracle.com> References: <96139BAE-FB33-44F1-ADA6-04E6068A842D@oracle.com> Message-ID: <66476819-ba25-0ef9-768d-3266778ea6fa@oracle.com> Vote: yes On 3/30/20 2:35 PM, Jesper Wilhelmsson wrote: > I hereby propose the creation of the Developer's Guide Project with myself, > Jesper Wilhelmsson, as the lead and the Core Libraries, Compiler, and HotSpot > Groups as the sponsoring Groups. > > The suggested project has been out for discussion on discuss at openjdk.java.net > for two weeks [1]. It was well-received and I haven't noted any concerns with > creating the project in that discussion. > > The initial goal of the project would be to create up-to-date guidelines for > OpenJDK development and contributions. The intent is to update the existing > OpenJDK Developer's Guide [2] which hasn't been updated since 2012. Parts of > the existing guide are in need of updates while other parts are yet to be > written. The initial source code for this project will be based on the current > OpenJDK Developer's Guide. > > In more recent years some process related information has been published on the > OpenJDK wiki [3], but this information was never reviewed or approved by the > community. Even though large parts of this information may be accurate, it > needs to go through proper review before it can be seen as official guidelines > for OpenJDK development. > > Once the initial goal has been reached the project will transition into a > maintenance project to keep the OpenJDK Developer's Guide up to date. > > The OpenJDK Developer's Guide is intended to contain tutorial style texts that > give examples and step-by-step directions for common parts of the development > process. Strict rules for OpenJDK development are better suited to a process > JEP. The development of such a JEP is outside of the scope of this project but > will be developed as part of a separate effort in parallel. > > I (Jesper Wilhelmsson) am part of the Java Platform Group at Oracle and have > been working with virtual machine development since 2001. My initial focus was > on memory management and garbage collection but over the last few years I've > been more involved in gatekeeping and process questions around the OpenJDK. > I authored several of the guides available on the OpenJDK HotSpot wiki and I > regularly give talks on how to contribute to the OpenJDK. > > Initial committers of the Developer's Guide Project include Mark Reinhold (mr), > Iris Clark (iris), and Jesper Wilhelmsson (jwilhelm). A complete list will be > provided to the registrar at the successful conclusion of this CFV. > > The project will host at least one mailing list, guide-dev at openjdk.java.net, > for discussions and reviews of changes. > > Votes are due by 5pm PDT on Tuesday April 14 2020. > > 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]. > > Thanks, > /Jesper > > [1] https://mail.openjdk.java.net/pipermail/discuss/2020-March/005298.html > [2] http://openjdk.java.net/guide/ > [3] https://wiki.openjdk.java.net/ > [4] http://openjdk.java.net/census#members > [5] http://openjdk.java.net/projects/#new-project-vote > From neugens at redhat.com Tue Mar 31 16:00:32 2020 From: neugens at redhat.com (Mario Torre) Date: Tue, 31 Mar 2020 18:00:32 +0200 Subject: CFV: New Project: Developer's Guide In-Reply-To: <96139BAE-FB33-44F1-ADA6-04E6068A842D@oracle.com> References: <96139BAE-FB33-44F1-ADA6-04E6068A842D@oracle.com> Message-ID: Vote: Yes, Cheers, Mario On Tue, Mar 31, 2020 at 12:38 AM Jesper Wilhelmsson wrote: > > I hereby propose the creation of the Developer's Guide Project with myself, > Jesper Wilhelmsson, as the lead and the Core Libraries, Compiler, and HotSpot > Groups as the sponsoring Groups. > > The suggested project has been out for discussion on discuss at openjdk.java.net > for two weeks [1]. It was well-received and I haven't noted any concerns with > creating the project in that discussion. > > The initial goal of the project would be to create up-to-date guidelines for > OpenJDK development and contributions. The intent is to update the existing > OpenJDK Developer's Guide [2] which hasn't been updated since 2012. Parts of > the existing guide are in need of updates while other parts are yet to be > written. The initial source code for this project will be based on the current > OpenJDK Developer's Guide. > > In more recent years some process related information has been published on the > OpenJDK wiki [3], but this information was never reviewed or approved by the > community. Even though large parts of this information may be accurate, it > needs to go through proper review before it can be seen as official guidelines > for OpenJDK development. > > Once the initial goal has been reached the project will transition into a > maintenance project to keep the OpenJDK Developer's Guide up to date. > > The OpenJDK Developer's Guide is intended to contain tutorial style texts that > give examples and step-by-step directions for common parts of the development > process. Strict rules for OpenJDK development are better suited to a process > JEP. The development of such a JEP is outside of the scope of this project but > will be developed as part of a separate effort in parallel. > > I (Jesper Wilhelmsson) am part of the Java Platform Group at Oracle and have > been working with virtual machine development since 2001. My initial focus was > on memory management and garbage collection but over the last few years I've > been more involved in gatekeeping and process questions around the OpenJDK. > I authored several of the guides available on the OpenJDK HotSpot wiki and I > regularly give talks on how to contribute to the OpenJDK. > > Initial committers of the Developer's Guide Project include Mark Reinhold (mr), > Iris Clark (iris), and Jesper Wilhelmsson (jwilhelm). A complete list will be > provided to the registrar at the successful conclusion of this CFV. > > The project will host at least one mailing list, guide-dev at openjdk.java.net, > for discussions and reviews of changes. > > Votes are due by 5pm PDT on Tuesday April 14 2020. > > 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]. > > Thanks, > /Jesper > > [1] https://mail.openjdk.java.net/pipermail/discuss/2020-March/005298.html > [2] http://openjdk.java.net/guide/ > [3] https://wiki.openjdk.java.net/ > [4] http://openjdk.java.net/census#members > [5] http://openjdk.java.net/projects/#new-project-vote > -- Mario Torre Associate Manager, Software Engineering Red Hat GmbH 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From andru at cs.cornell.edu Tue Mar 31 16:13:28 2020 From: andru at cs.cornell.edu (Andrew Myers) Date: Tue, 31 Mar 2020 12:13:28 -0400 Subject: New release of JLang, a Java-to-LLVM ahead-of-time compiler Message-ID: <7c43498c-6fb7-b1a6-255b-b3a0c5aa0062@cs.cornell.edu> We are pleased to announce a new release of JLang, a Java-to-LLVM ahead-of-time compiler, on Github at https://polyglot-compiler.github.io/JLang/. JLang compiles Java source code directly to LLVM, allowing a variety of LLVM back ends to be used to target various architectures. The JVM and JNI interfaces are supported with a shared library whose source code is also distributed as part of JLang. Support for Java libraries is provided by compiling the OpenJDK Java source into a shared library with JLang and then linking the OpenJDK native libraries. JLang is built on top of the Polyglot extensible compiler framework, so it supports experimentation with new language features and with new implementation techniques. The new release adds support for basic Java concurrency mechanisms, including threads, mutexes (synchronized), and condition variables (wait/notify/notifyAll). Support for the java.util.concurrency package has not been added yet. Note that JLang implements Java 7, so it does not yet support some newer Java features such as lambdas, default methods, and modules. This release was primarily the work of Yiteng Guo and Drew Zagieboylo. Community involvement in further development of JLang is welcome. Andrew Myers From mandy.chung at oracle.com Tue Mar 31 16:31:34 2020 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 31 Mar 2020 09:31:34 -0700 Subject: CFV: New Project: Developer's Guide In-Reply-To: <96139BAE-FB33-44F1-ADA6-04E6068A842D@oracle.com> References: <96139BAE-FB33-44F1-ADA6-04E6068A842D@oracle.com> Message-ID: <2b47b876-91af-0e18-337f-44d039208308@oracle.com> Vote: yes Mandy On 3/30/20 2:35 PM, Jesper Wilhelmsson wrote: > I hereby propose the creation of the Developer's Guide Project with myself, > Jesper Wilhelmsson, as the lead and the Core Libraries, Compiler, and HotSpot > Groups as the sponsoring Groups. > > The suggested project has been out for discussion on discuss at openjdk.java.net > for two weeks [1]. It was well-received and I haven't noted any concerns with > creating the project in that discussion. > > The initial goal of the project would be to create up-to-date guidelines for > OpenJDK development and contributions. The intent is to update the existing > OpenJDK Developer's Guide [2] which hasn't been updated since 2012. Parts of > the existing guide are in need of updates while other parts are yet to be > written. The initial source code for this project will be based on the current > OpenJDK Developer's Guide. > > In more recent years some process related information has been published on the > OpenJDK wiki [3], but this information was never reviewed or approved by the > community. Even though large parts of this information may be accurate, it > needs to go through proper review before it can be seen as official guidelines > for OpenJDK development. > > Once the initial goal has been reached the project will transition into a > maintenance project to keep the OpenJDK Developer's Guide up to date. > > The OpenJDK Developer's Guide is intended to contain tutorial style texts that > give examples and step-by-step directions for common parts of the development > process. Strict rules for OpenJDK development are better suited to a process > JEP. The development of such a JEP is outside of the scope of this project but > will be developed as part of a separate effort in parallel. > > I (Jesper Wilhelmsson) am part of the Java Platform Group at Oracle and have > been working with virtual machine development since 2001. My initial focus was > on memory management and garbage collection but over the last few years I've > been more involved in gatekeeping and process questions around the OpenJDK. > I authored several of the guides available on the OpenJDK HotSpot wiki and I > regularly give talks on how to contribute to the OpenJDK. > > Initial committers of the Developer's Guide Project include Mark Reinhold (mr), > Iris Clark (iris), and Jesper Wilhelmsson (jwilhelm). A complete list will be > provided to the registrar at the successful conclusion of this CFV. > > The project will host at least one mailing list, guide-dev at openjdk.java.net, > for discussions and reviews of changes. > > Votes are due by 5pm PDT on Tuesday April 14 2020. > > 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]. > > Thanks, > /Jesper > > [1] https://mail.openjdk.java.net/pipermail/discuss/2020-March/005298.html > [2] http://openjdk.java.net/guide/ > [3] https://wiki.openjdk.java.net/ > [4] http://openjdk.java.net/census#members > [5] http://openjdk.java.net/projects/#new-project-vote > From christoph.langer at sap.com Tue Mar 31 19:06:28 2020 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 31 Mar 2020 19:06:28 +0000 Subject: CFV: New Project: Developer's Guide In-Reply-To: <96139BAE-FB33-44F1-ADA6-04E6068A842D@oracle.com> References: <96139BAE-FB33-44F1-ADA6-04E6068A842D@oracle.com> Message-ID: Vote: yes /Christoph > -----Original Message----- > From: announce On Behalf Of > Jesper Wilhelmsson > Sent: Montag, 30. M?rz 2020 23:35 > To: announce at openjdk.java.net > Subject: CFV: New Project: Developer's Guide > > I hereby propose the creation of the Developer's Guide Project with myself, > Jesper Wilhelmsson, as the lead and the Core Libraries, Compiler, and > HotSpot > Groups as the sponsoring Groups. > > The suggested project has been out for discussion on > discuss at openjdk.java.net > for two weeks [1]. It was well-received and I haven't noted any concerns > with > creating the project in that discussion. > > The initial goal of the project would be to create up-to-date guidelines for > OpenJDK development and contributions. The intent is to update the > existing > OpenJDK Developer's Guide [2] which hasn't been updated since 2012. Parts > of > the existing guide are in need of updates while other parts are yet to be > written. The initial source code for this project will be based on the current > OpenJDK Developer's Guide. > > In more recent years some process related information has been published > on the > OpenJDK wiki [3], but this information was never reviewed or approved by > the > community. Even though large parts of this information may be accurate, it > needs to go through proper review before it can be seen as official guidelines > for OpenJDK development. > > Once the initial goal has been reached the project will transition into a > maintenance project to keep the OpenJDK Developer's Guide up to date. > > The OpenJDK Developer's Guide is intended to contain tutorial style texts > that > give examples and step-by-step directions for common parts of the > development > process. Strict rules for OpenJDK development are better suited to a process > JEP. The development of such a JEP is outside of the scope of this project but > will be developed as part of a separate effort in parallel. > > I (Jesper Wilhelmsson) am part of the Java Platform Group at Oracle and > have > been working with virtual machine development since 2001. My initial focus > was > on memory management and garbage collection but over the last few years > I've > been more involved in gatekeeping and process questions around the > OpenJDK. > I authored several of the guides available on the OpenJDK HotSpot wiki and I > regularly give talks on how to contribute to the OpenJDK. > > Initial committers of the Developer's Guide Project include Mark Reinhold > (mr), > Iris Clark (iris), and Jesper Wilhelmsson (jwilhelm). A complete list will be > provided to the registrar at the successful conclusion of this CFV. > > The project will host at least one mailing list, guide-dev at openjdk.java.net, > for discussions and reviews of changes. > > Votes are due by 5pm PDT on Tuesday April 14 2020. > > 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]. > > Thanks, > /Jesper > > [1] https://mail.openjdk.java.net/pipermail/discuss/2020- > March/005298.html > [2] http://openjdk.java.net/guide/ > [3] https://wiki.openjdk.java.net/ > [4] http://openjdk.java.net/census#members > [5] http://openjdk.java.net/projects/#new-project-vote From sean.mullan at oracle.com Tue Mar 31 21:24:35 2020 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 31 Mar 2020 17:24:35 -0400 Subject: CFV: New Project: Developer's Guide In-Reply-To: <96139BAE-FB33-44F1-ADA6-04E6068A842D@oracle.com> References: <96139BAE-FB33-44F1-ADA6-04E6068A842D@oracle.com> Message-ID: Vote: yes --Sean From mark.reinhold at oracle.com Tue Mar 31 21:40:42 2020 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Tue, 31 Mar 2020 14:40:42 -0700 Subject: CFV: New Project: Developer's Guide In-Reply-To: <96139BAE-FB33-44F1-ADA6-04E6068A842D@oracle.com> References: <96139BAE-FB33-44F1-ADA6-04E6068A842D@oracle.com> Message-ID: <20200331144042.650853267@eggemoggin.niobe.net> Vote: yes - Mark