From volker.simonis at gmail.com Tue Apr 1 09:26:12 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 1 Apr 2014 11:26:12 +0200 Subject: OpenJDK repo list In-Reply-To: <53397612.7070004@oracle.com> References: <53397612.7070004@oracle.com> Message-ID: On Mon, Mar 31, 2014 at 4:05 PM, Chris Hegarty wrote: > Already reported to the openjdk infrastructure group. > > http://mail.openjdk.java.net/pipermail/web-discuss/2014-March/000445.html > But what means soon in that context? Displaying a listing of available repositories seems like a trivial thing to have. And not having it is really annoying! Regards, Volker > -Chris. > > > On 31/03/14 14:54, Richard Fearn wrote: >> >> Hi >> >> I believe this: >> >> http://hg.openjdk.java.net/ >> >> is meant to show a list of OpenJDK repositories, but I get a 503 error. >> That URL is given on error pages, like this one: >> >> http://hg.openjdk.java.net/jdk8/bad >> >> Is this a known problem? >> >> Regards, >> >> Rich >> > From volker.simonis at gmail.com Thu Apr 3 08:04:20 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 3 Apr 2014 10:04:20 +0200 Subject: hg.openjdk.java.net project and per-project repository lists In-Reply-To: <20140402120133.478052@eggemoggin.niobe.net> References: <20140402120133.478052@eggemoggin.niobe.net> Message-ID: Great! I'd consider this a major achievement. Thanks, Volker On Wed, Apr 2, 2014 at 9:01 PM, wrote: > http://hg.openjdk.java.net now displays a list of Projects rather > than every single repository on the server (or, more annoyingly, > a "503 Service Unavailable" error). > > http://hg.openjdk.java.net/$PROJECT now displays a list of all the > repositories for $PROJECT; e.g., http://hg.openjdk.java.net/jdk9 . > > The non-root repositories of Mercurial forests are indented so as > to make the overall list easier to read. > > Please report any problems to ops at openjdk dot java dot net. > > - Mark From martijnverburg at gmail.com Thu Apr 3 08:17:25 2014 From: martijnverburg at gmail.com (Martijn Verburg) Date: Thu, 3 Apr 2014 09:17:25 +0100 Subject: hg.openjdk.java.net project and per-project repository lists In-Reply-To: References: <20140402120133.478052@eggemoggin.niobe.net> Message-ID: Hi Mark, Thanks for pushing this through - it clears up a major point of confusion for folks new to OpenJDK. Cheers, Martijn On 3 April 2014 09:04, Volker Simonis wrote: > Great! > > I'd consider this a major achievement. > > Thanks, > Volker > > > On Wed, Apr 2, 2014 at 9:01 PM, wrote: > > http://hg.openjdk.java.net now displays a list of Projects rather > > than every single repository on the server (or, more annoyingly, > > a "503 Service Unavailable" error). > > > > http://hg.openjdk.java.net/$PROJECT now displays a list of all the > > repositories for $PROJECT; e.g., http://hg.openjdk.java.net/jdk9 . > > > > The non-root repositories of Mercurial forests are indented so as > > to make the overall list easier to read. > > > > Please report any problems to ops at openjdk dot java dot net. > > > > - Mark > From curoli at gmail.com Thu Apr 3 18:44:42 2014 From: curoli at gmail.com (Oliver Ruebenacker) Date: Thu, 3 Apr 2014 14:44:42 -0400 Subject: Java vs JAVA Message-ID: Hello, Just wondering: why sometimes people write Java in all capital letters ("JAVA")? Thanks! Best, Oliver -- Oliver Ruebenacker Founder at Relomics Consulting Be always grateful, but never satisfied. From donald.smith at oracle.com Thu Apr 3 18:56:49 2014 From: donald.smith at oracle.com (Donald Smith) Date: Thu, 03 Apr 2014 14:56:49 -0400 Subject: Java vs JAVA In-Reply-To: References: Message-ID: <533DAEF1.70900@oracle.com> When it's not an acronym, writing in all capitals is a common strategy for identifying a name as a trademark in plain text. Some may chose to write "Java(TM)" in plain text, but that's a bit awkward, depending on the context. - Don On 03/04/2014 2:44 PM, Oliver Ruebenacker wrote: > Hello, > > Just wondering: why sometimes people write Java in all capital letters > ("JAVA")? > > Thanks! > > Best, > Oliver > From benjamin.john.evans at gmail.com Thu Apr 3 19:14:56 2014 From: benjamin.john.evans at gmail.com (Ben Evans) Date: Thu, 3 Apr 2014 20:14:56 +0100 Subject: Java vs JAVA In-Reply-To: References: Message-ID: Generally, the capitalised form is a shorthand for "recruiter that does not deserve your time of day". On 3 Apr 2014 19:46, "Oliver Ruebenacker" wrote: > Hello, > > Just wondering: why sometimes people write Java in all capital letters > ("JAVA")? > > Thanks! > > Best, > Oliver > > -- > Oliver Ruebenacker > Founder at Relomics Consulting > Be always grateful, but never satisfied. > From daniel.smith at oracle.com Thu Apr 3 21:00:33 2014 From: daniel.smith at oracle.com (Dan Smith) Date: Thu, 3 Apr 2014 15:00:33 -0600 Subject: JEPs 1 & 2: Interaction of JEPs with JCP Message-ID: <18AD74C7-6C42-4159-B1CE-3E49206E4346@oracle.com> JEPs 1 & 2 present an unclear picture of how JEPs interact with the JCP. From JEP 1: > If a proposal accepted into this process intends to revise existing standard interfaces, or to define new ones, then a parallel effort to design, review, and approve those changes must be undertaken in the JCP, either as part of a Maintenance Review of an existing JSR or in the context of a new JSR. The "parallel effort" referred to seems to be external to the JEP itself. > It?s up to Group Leads, Area Leads, and the OpenJDK Lead to ascertain whether sufficient Committers and other Contributors have signed up to do all of the work required to complete a JEP so that it may considered to be funded. This work includes not just design and implementation but also, as appropriate, QA test development, TCK test development, documentation, and any other activities that might be necessary. Here, TCK test development is considered part of the "work required to complete a JEP". "Documentation" or "other activities" might be interpreted to mean a JCP specification, if we're viewing the JCP effort as part of the JEP. This seems inconsistent with the "parallel effort" view. From JEP 2: > // Rough effort estimate, one of: > // XS -- Less than one developer-month (20 working days) > // S -- Less than three dev-months > // M -- Less than six dev-months > // L -- Less than one dev-year > // XL -- More than one dev-year > // > Effort: XS Here's the most concrete problem: is the effort to run a JSR, produce a specification and TCK, etc., part of this estimate or not? > // Rough duration estimate, one of: > // XS -- Less than one month (calendar) > // S -- Less than three months > // M -- Less than six months > // L -- Less than one year > // XL -- More than one year > // > // The duration reflects the calendar time needed to complete the > // proposed work. It can be more or less than the effort estimate. If the JSR is not part of the JEP: does this timeline include the full JSR timeline? or is it better to think of the JEP as a prototype feature that can be completed and later standardized/tweaked by a JSR? > Dependences > ----------- > > // Describe all dependences that this JEP has on other JEPs, components, > // products, or anything else. Dependences upon other JEPs should also > // be listed in the "Depends:" header at the top of the file. > // > // Describe any JEPs that depend upon this JEP, and likewise make sure > // they are listed in the "Blocks:" header at the top of this file. It might make sense to list the JCP as a thing that depends on this JEP. Or are "depends on this" dependencies supposed to be restricted to just other JEPs? (After all, the set of things that depend on any particular JEP is unbounded.) > Impact > ------ > > // How will this work impact other parts of the platform, the product, > // and the contributors working on them? Omit any irrelevant items. > > - Other JDK components: ... > - Compatibility: ... > - Security: ... > - Performance/scalability: ... > - User experience: ... > - I18n/L10n: ... > - Accessibility: ... > - Portability: ... > - Packaging/installation: ... > - Documentation: ... > - TCK: ... > - Other: ... Or maybe it makes sense to list the JCP here... It's unclear to me whether this is a list of things that are _part of_ the JEP, or external things that _interact with_ the JEP. I note that "TCK" is on the list, but I'm not sure how to interpret it. ?Dan From julien.nicoulaud at gmail.com Sat Apr 5 09:57:29 2014 From: julien.nicoulaud at gmail.com (Julien Nicoulaud) Date: Sat, 5 Apr 2014 11:57:29 +0200 Subject: C2 compiler bug closed as incomplete Message-ID: Hi all, I don't know if it's the right place to discuss this, but here is my issue : I reported a VM crash in C2 compilation, but it was closed as incomplete with the following comment "We need a clear instructions how to reproduce the problem". I clearly explained in the report I could not provide a simple, self-contained test case to reproduce the bug, and I provided hs_err and JIT replay log file instead. So what am I supposed to do in this case ? Debug it myself ? Or are there another options so I can provide useful debug output ? Here is the bug report: https://bugs.openjdk.java.net/browse/JDK-8038985 http://bugs.java.com/bugdatabase/view_bug.do?bug_id=8038985 Regards, Julien Nicoulaud From staffan.larsen at oracle.com Mon Apr 7 06:40:49 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Mon, 7 Apr 2014 08:40:49 +0200 Subject: C2 compiler bug closed as incomplete In-Reply-To: References: Message-ID: <0683159B-E5FD-4E3C-847A-9D7A85C657C8@oracle.com> Maybe ask on the hotspot-compiler-dev alias? On 5 apr 2014, at 11:57, Julien Nicoulaud wrote: > Hi all, > > I don't know if it's the right place to discuss this, but here is my issue : > > I reported a VM crash in C2 compilation, but it was closed as incomplete > with the following comment "We need a clear instructions how to reproduce > the problem". > > I clearly explained in the report I could not provide a simple, > self-contained test case to reproduce the bug, and I provided hs_err and > JIT replay log file instead. > > So what am I supposed to do in this case ? Debug it myself ? Or are there > another options so I can provide useful debug output ? > > Here is the bug report: > https://bugs.openjdk.java.net/browse/JDK-8038985 > http://bugs.java.com/bugdatabase/view_bug.do?bug_id=8038985 > > Regards, > Julien Nicoulaud From gnu.andrew at redhat.com Tue Apr 8 15:22:30 2014 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Tue, 8 Apr 2014 11:22:30 -0400 (EDT) Subject: hg.openjdk.java.net project and per-project repository lists In-Reply-To: <20140402120133.478052@eggemoggin.niobe.net> References: <20140402120133.478052@eggemoggin.niobe.net> Message-ID: <1751360160.1628499.1396970550830.JavaMail.zimbra@redhat.com> ----- Original Message ----- > http://hg.openjdk.java.net now displays a list of Projects rather > than every single repository on the server (or, more annoyingly, > a "503 Service Unavailable" error). > > http://hg.openjdk.java.net/$PROJECT now displays a list of all the > repositories for $PROJECT; e.g., http://hg.openjdk.java.net/jdk9 . > > The non-root repositories of Mercurial forests are indented so as > to make the overall list easier to read. > > Please report any problems to ops at openjdk dot java dot net. > > - Mark > Can we have an option to get the old view? This makes it really hard to find repositories now. Thanks, -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From mark.reinhold at oracle.com Tue Apr 8 15:29:39 2014 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Tue, 08 Apr 2014 08:29:39 -0700 Subject: hg.openjdk.java.net project and per-project repository lists In-Reply-To: <1751360160.1628499.1396970550830.JavaMail.zimbra@redhat.com> References: <20140402120133.478052@eggemoggin.niobe.net>, <1751360160.1628499.1396970550830.JavaMail.zimbra@redhat.com> Message-ID: <20140408082939.181746@eggemoggin.niobe.net> 2014/4/8 1:22 -0700, gnu.andrew at redhat.com: > Can we have an option to get the old view? This makes it really hard > to find repositories now. The problem with the old view is that it opens every repository, and with over 800 repos that's quite a load on the server. If you just want a fast, simple list of all the repos, try this: http://hg.openjdk.java.net/?style=raw - Mark From mark.reinhold at oracle.com Tue Apr 8 20:54:12 2014 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Tue, 08 Apr 2014 13:54:12 -0700 Subject: Draft proposal: JEP 2.0 Message-ID: <20140408135412.415597@eggemoggin.niobe.net> The JEP Process [1] has served us well as a way to document proposed enhancements to the JDK. The process does not, however, say how we decide to target a JEP to a particular JDK Release Project, nor does it help track the work subsequently done on a JEP. We also don't have a documented process by which we can create and maintain the overall schedule of a Release Project. To fill these gaps I've drafted an extension of the JEP Process which covers the planning of Release Projects, the tracking of the work done for their Feature JEPs, and the tracking of work done for other kinds of JEPs that are not associated with specific releases. The current draft of the proposal is here: http://cr.openjdk.java.net/~mr/jep/jep-2.0.html The proposal suggests, among other things, that we create a new "JEP" issue type in the JBS JIRA system so that it's easy to see the status of a particular JEP as well as the overall status of an entire Release Project. This draft has been reviewed by a handful of people so far. My thanks to Mathias Axelsson, Brian Beck, Iris Clark, Joe Darcy, Brian Goetz, Georges Saab, and Dalibor Topic for their feedback. If you have comments or suggestions on this draft, please send them in a public reply to this message by Monday, 21 April 2011. I'd like to put this new process in place shortly thereafter. - Mark [1] http://openjdk.java.net/jeps/ From gnu.andrew at redhat.com Tue Apr 8 21:00:58 2014 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Tue, 8 Apr 2014 17:00:58 -0400 (EDT) Subject: hg.openjdk.java.net project and per-project repository lists In-Reply-To: <20140408082939.181746@eggemoggin.niobe.net> References: <20140402120133.478052@eggemoggin.niobe.net> <1751360160.1628499.1396970550830.JavaMail.zimbra@redhat.com> <20140408082939.181746@eggemoggin.niobe.net> Message-ID: <52341904.1889889.1396990858837.JavaMail.zimbra@redhat.com> ----- Original Message ----- > 2014/4/8 1:22 -0700, gnu.andrew at redhat.com: > > Can we have an option to get the old view? This makes it really hard > > to find repositories now. > > The problem with the old view is that it opens every repository, > and with over 800 repos that's quite a load on the server. > > If you just want a fast, simple list of all the repos, try this: > > http://hg.openjdk.java.net/?style=raw > > - Mark > That's perfect. Thanks Mark. -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From mark.reinhold at oracle.com Tue Apr 8 21:29:49 2014 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Tue, 08 Apr 2014 14:29:49 -0700 Subject: Draft proposal: JEP 2.0 In-Reply-To: <20140408135412.415597@eggemoggin.niobe.net> References: <20140408135412.415597@eggemoggin.niobe.net> Message-ID: <20140408142949.287375@eggemoggin.niobe.net> 2014/4/8 6:54 -0700, mark.reinhold at oracle.com: > ... > > If you have comments or suggestions on this draft, please send them in > a public reply to this message by Monday, 21 April 2011. Oops! Make that Monday, 21 April 2014. - Mark From bob.vandette at oracle.com Tue Apr 8 21:31:56 2014 From: bob.vandette at oracle.com (Bob Vandette) Date: Tue, 8 Apr 2014 17:31:56 -0400 Subject: Project Proposal: Device I/O Message-ID: I'd like to discuss the creation of the Device I/O Project with myself (Bob Vandette) as the Lead and the Core Libraries Group as the sponsoring group. The Device I/O Project would implement a generic device peripheral access API for Java applications running on embedded devices, providing APIs for common peripheral devices currently found in in embedded platforms such as GPIO, I2C, SPI, UART, USB and others. Currently, developers are forced into writing JNI code in order to access these elements. We intend to provide a Java level API for developers to use instead and to keep the public API consistent across Java SE and Java ME, although the open project will initially only support Java SE. I have been in the Java SE Organization for over 15 years and have been the Java SE Embedded Lead for the last 9 years. The initial Reviews and Committers suggested here are made up of representatives from both the Java SE Embedded and Java ME development teams. The initial Reviewers will be Jen Dority, Riaz Aimandi, Alexey Konstantinov, Thierry Violleau and Jens P?tzold. The initial Committers will be: Andrey Petushkov, Petr Panteleyev, Sergey Nazarkin, Vladimir Danushevsky and Derek White, Gary Collins, Pavel Safrata, Kinsley Wong, Bill Pittore, Dean Long and Lubomir Nerad. From aph at redhat.com Wed Apr 9 09:29:39 2014 From: aph at redhat.com (Andrew Haley) Date: Wed, 09 Apr 2014 10:29:39 +0100 Subject: hg.openjdk.java.net project and per-project repository lists In-Reply-To: <52341904.1889889.1396990858837.JavaMail.zimbra@redhat.com> References: <20140402120133.478052@eggemoggin.niobe.net> <1751360160.1628499.1396970550830.JavaMail.zimbra@redhat.com> <20140408082939.181746@eggemoggin.niobe.net> <52341904.1889889.1396990858837.JavaMail.zimbra@redhat.com> Message-ID: <53451303.2060106@redhat.com> On 04/08/2014 10:00 PM, Andrew Hughes wrote: > > > ----- Original Message ----- >> 2014/4/8 1:22 -0700, gnu.andrew at redhat.com: >>> Can we have an option to get the old view? This makes it really hard >>> to find repositories now. >> >> The problem with the old view is that it opens every repository, >> and with over 800 repos that's quite a load on the server. >> >> If you just want a fast, simple list of all the repos, try this: >> >> http://hg.openjdk.java.net/?style=raw > That's perfect. Thanks Mark. Brilliant! Who knew? Erm, is there any way to link to that list from the OpenJDK pages? Andrew. From iris.clark at oracle.com Wed Apr 9 16:21:12 2014 From: iris.clark at oracle.com (Iris Clark) Date: Wed, 9 Apr 2014 09:21:12 -0700 (PDT) Subject: hg.openjdk.java.net project and per-project repository lists In-Reply-To: <53451303.2060106@redhat.com> References: <20140402120133.478052@eggemoggin.niobe.net> <1751360160.1628499.1396970550830.JavaMail.zimbra@redhat.com> <20140408082939.181746@eggemoggin.niobe.net> <52341904.1889889.1396990858837.JavaMail.zimbra@redhat.com> <53451303.2060106@redhat.com> Message-ID: <6559e7be-3956-42fa-9f48-d0f49792a1f6@default> Hi. >>> If you just want a fast, simple list of all the repos, try this: >>> >>> http://hg.openjdk.java.net/?style=raw > >> That's perfect. Thanks Mark. > > Brilliant! Who knew? Erm, is there any way to link to that list from the OpenJDK pages? Would make sense to add a "Repositories" section to the Web Group's static page [1] with links to the friendly hg.ojn and Mark's link? Thanks, iris [1]: http://openjdk.java.net/groups/web/ [2]: http://hg.openjdk.java.net From bob.vandette at oracle.com Wed Apr 9 16:41:45 2014 From: bob.vandette at oracle.com (Bob Vandette) Date: Wed, 9 Apr 2014 12:41:45 -0400 Subject: Draft proposal: JEP 2.0 In-Reply-To: <20140408140825.43296@eggemoggin.niobe.net> References: <20140408140825.43296@eggemoggin.niobe.net> Message-ID: Mark, I like the idea of using JIRA for the JEP process but ... Why are you proposing to continue supporting some of the JEP content in Mercurial form rather than using the description field in JBS and providing a template for this area of the JIRA entry? We've done this successfully for internal project tracking. If it's for format validation, you might be able to do this as part of the workflow process as you change states and not have to maintain information in two places. Bob. > From: mark.reinhold at oracle.com > Subject: Draft proposal: JEP 2.0 > Date: April 8, 2014 at 1:54:12 PM EDT > To: discuss at openjdk.java.net > > > The JEP Process [1] has served us well as a way to document proposed > enhancements to the JDK. The process does not, however, say how we > decide to target a JEP to a particular JDK Release Project, nor does > it help track the work subsequently done on a JEP. We also don't have > a documented process by which we can create and maintain the overall > schedule of a Release Project. > > To fill these gaps I've drafted an extension of the JEP Process which > covers the planning of Release Projects, the tracking of the work done > for their Feature JEPs, and the tracking of work done for other kinds > of JEPs that are not associated with specific releases. The current > draft of the proposal is here: > > http://cr.openjdk.java.net/~mr/jep/jep-2.0.html > > The proposal suggests, among other things, that we create a new "JEP" > issue type in the JBS JIRA system so that it's easy to see the status > of a particular JEP as well as the overall status of an entire Release > Project. > > This draft has been reviewed by a handful of people so far. My thanks > to Mathias Axelsson, Brian Beck, Iris Clark, Joe Darcy, Brian Goetz, > Georges Saab, and Dalibor Topic for their feedback. > > If you have comments or suggestions on this draft, please send them in > a public reply to this message by Monday, 21 April 2011. I'd like to > put this new process in place shortly thereafter. > > - Mark > > > [1] http://openjdk.java.net/jeps/ > > From Alan.Bateman at oracle.com Thu Apr 10 12:21:02 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 10 Apr 2014 13:21:02 +0100 Subject: Project Proposal: Device I/O In-Reply-To: References: Message-ID: <53468CAE.9030505@oracle.com> On 08/04/2014 22:31, Bob Vandette wrote: > I'd like to discuss the creation of the Device I/O Project with myself (Bob Vandette) as the Lead and the Core Libraries Group as the sponsoring group. > > The Device I/O Project would implement a generic device peripheral access API for Java applications running on embedded devices, providing APIs for common peripheral devices currently found in in embedded platforms such as GPIO, I2C, SPI, UART, USB and others. > > Currently, developers are forced into writing JNI code in order to access these elements. We intend to provide a Java level API for developers to use instead and to keep the public API consistent across Java SE and Java ME, although the open project will initially only support Java SE. > This seems a very worthy project and good to see that it might be proposed to do in OpenJDK. This may be a case where the FFI proposed in JEP 191 might be useful. The Bylaws require that it be supported by at least one Group Lead so I would like to offer support for this project with the Core Libraries group as spsonor. -Alan. From paul.sandoz at oracle.com Thu Apr 10 12:46:47 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 10 Apr 2014 14:46:47 +0200 Subject: Project Proposal: Device I/O In-Reply-To: <53468CAE.9030505@oracle.com> References: <53468CAE.9030505@oracle.com> Message-ID: <22EC3FED-EE12-457F-BED0-76A791B7B2F0@oracle.com> On Apr 10, 2014, at 2:21 PM, Alan Bateman wrote: > On 08/04/2014 22:31, Bob Vandette wrote: >> I'd like to discuss the creation of the Device I/O Project with myself (Bob Vandette) as the Lead and the Core Libraries Group as the sponsoring group. >> >> The Device I/O Project would implement a generic device peripheral access API for Java applications running on embedded devices, providing APIs for common peripheral devices currently found in in embedded platforms such as GPIO, I2C, SPI, UART, USB and others. >> >> Currently, developers are forced into writing JNI code in order to access these elements. We intend to provide a Java level API for developers to use instead and to keep the public API consistent across Java SE and Java ME, although the open project will initially only support Java SE. >> > This seems a very worthy project and good to see that it might be proposed to do in OpenJDK. This may be a case where the FFI proposed in JEP 191 might be useful. > Yes, plus see also the proposal for Project Panama. Paul. > The Bylaws require that it be supported by at least one Group Lead so I would like to offer support for this project with the Core Libraries group as spsonor. > > -Alan. From bob.vandette at oracle.com Thu Apr 10 14:10:44 2014 From: bob.vandette at oracle.com (Bob Vandette) Date: Thu, 10 Apr 2014 10:10:44 -0400 Subject: Project Proposal: Device I/O In-Reply-To: <22EC3FED-EE12-457F-BED0-76A791B7B2F0@oracle.com> References: <53468CAE.9030505@oracle.com> <22EC3FED-EE12-457F-BED0-76A791B7B2F0@oracle.com> Message-ID: On Apr 10, 2014, at 8:46 AM, Paul Sandoz wrote: > > On Apr 10, 2014, at 2:21 PM, Alan Bateman wrote: > >> On 08/04/2014 22:31, Bob Vandette wrote: >>> I'd like to discuss the creation of the Device I/O Project with myself (Bob Vandette) as the Lead and the Core Libraries Group as the sponsoring group. >>> >>> The Device I/O Project would implement a generic device peripheral access API for Java applications running on embedded devices, providing APIs for common peripheral devices currently found in in embedded platforms such as GPIO, I2C, SPI, UART, USB and others. >>> >>> Currently, developers are forced into writing JNI code in order to access these elements. We intend to provide a Java level API for developers to use instead and to keep the public API consistent across Java SE and Java ME, although the open project will initially only support Java SE. >>> >> This seems a very worthy project and good to see that it might be proposed to do in OpenJDK. This may be a case where the FFI proposed in JEP 191 might be useful. >> > > Yes, plus see also the proposal for Project Panama. > These are both very beneficial enhancements to the Java platform that the Device I/O APIs could take advantage over time. However, we are hoping that an initial implementation can be created to target existing Java runtimes. At a minimum, we hope to support Java SE 8 and compact profiles but running on Java SE 7 should also be possible. We are planning on providing a pluggable driver interface that can allow developers to adapt these APIs to different underlying operating systems and hardware OS driver interfaces. Although I imagine that Panama and it's use of FFI are more applicable to creating native implementations where no Java API exists, but these DIO drivers we're implementing will be able to take advantage of these new JDK 9 capabilities in order to provide a cleaner and more readable implementation. Bob. > Paul. > >> The Bylaws require that it be supported by at least one Group Lead so I would like to offer support for this project with the Core Libraries group as spsonor. >> >> -Alan. > From mike.duigou at oracle.com Fri Apr 11 03:41:40 2014 From: mike.duigou at oracle.com (Mike Duigou) Date: Thu, 10 Apr 2014 20:41:40 -0700 Subject: Draft proposal: JEP 2.0 Message-ID: <8C0D60E7-F0E5-4179-A37B-26AA95C862B5@oracle.com> Some comments. Tracking: - I'll add my voice to Bob's that we want only one system of record for JEPs and that should be JBS. JEPs are either managed entirely within JBS or we shouldn't bother with using JBS for JEPS at all. If we are going to go with the many-staged workflow described in the proposal then having JBS to manage that workflow would be a huge boon. - "Alert Status (updated weekly once Funded)". This seems onerous for projects that are green (or irredeemably yellow). Required increment-the-date weekly updates has been a significant annoyance for internal processes which I would prefer not to repeat with JEPs. Workflow: - The diagram unfortunately reminds me too much of a LHC "Higgs Boson detection event" graphic. Many of these states are overlapping and are worked coincidentally. Since only some of them are strictly gating can we collapse the softer states to a smaller number of strictly gating states? General: - The JEP process doesn't feel very approachable to an outsider/first time submitter. Either we have to provide a lot more guidance about how to fill out a JEP and/or make the process simpler. This has been a consistent comment from both Oracle internal and external JEP authors. The typical pattern seems to be to get someone else who's previously successfully filed a JEP to file your JEP for you or to crib answers from some other JEP. Submitters should be able to readily provide the necessary information or recognize that they aren't ready to file their JEP, but most importantly, they should be able to know mostly independently whether they have supplied the appropriate responses. Mike From martijnverburg at gmail.com Fri Apr 11 08:08:43 2014 From: martijnverburg at gmail.com (Martijn Verburg) Date: Fri, 11 Apr 2014 09:08:43 +0100 Subject: Draft proposal: JEP 2.0 In-Reply-To: <8C0D60E7-F0E5-4179-A37B-26AA95C862B5@oracle.com> References: <8C0D60E7-F0E5-4179-A37B-26AA95C862B5@oracle.com> Message-ID: Hi all, Overall JEP 2.0 is a great step forwards! - It was always hard as new Contributor or outsider to OpenJDK to see what stage any JEP was up to, it'll definitely help coordinate work between Oracle and non-Oracle folks in OpenJDK as well. Big +1 on the proposal to allow Contributors to author (but not submit) a JEP and to have a 'cross-discipline' mailing list. Some folks are fairly new to OpenJDK, yet have genuinely interesting ideas / prototypes and need a place where they can have guidance as to whether it's realistic for them to spend concerted time and effort to get that into OpenJDK or (as an example) spin off their idea as a 3rd party lib if it's simply not feasible to include it in OpenJDK. I agree with Mike that it would be nice to have the workflow all managed in one place, I'm putting together a 'guide for new contributors' for the Adoption Group and it's made me realise how much useful information there is..... but scattered in lots of different locations, would be nice to have more consolidation. Cheers, Martijn On 11 April 2014 04:41, Mike Duigou wrote: > Some comments. > > Tracking: > > - I'll add my voice to Bob's that we want only one system of record for > JEPs and that should be JBS. JEPs are either managed entirely within JBS or > we shouldn't bother with using JBS for JEPs at all. If we are going to go > with the many-staged workflow described in the proposal then having JBS to > manage that workflow would be a huge boon. > > - "Alert Status (updated weekly once Funded)". This seems onerous for > projects that are green (or irredeemably yellow). Required > increment-the-date weekly updates has been a significant annoyance for > internal processes which I would prefer not to repeat with JEPs. > > Workflow: > > - The diagram unfortunately reminds me too much of a LHC "Higgs Boson > detection event" graphic. Many of these states are overlapping and are > worked coincidentally. Since only some of them are strictly gating can we > collapse the softer states to a smaller number of strictly gating states? > > General: > > - The JEP process doesn't feel very approachable to an outsider/first time > submitter. Either we have to provide a lot more guidance about how to fill > out a JEP and/or make the process simpler. This has been a consistent > comment from both Oracle internal and external JEP authors. The typical > pattern seems to be to get someone else who's previously successfully filed > a JEP to file your JEP for you or to crib answers from some other JEP. > Submitters should be able to readily provide the necessary information or > recognize that they aren't ready to file their JEP, but most importantly, > they should be able to know mostly independently whether they have supplied > the appropriate responses. > > > Mike From martijnverburg at gmail.com Fri Apr 11 16:12:16 2014 From: martijnverburg at gmail.com (Martijn Verburg) Date: Fri, 11 Apr 2014 17:12:16 +0100 Subject: OpenJDK Governing Board 2014 Election: Results In-Reply-To: <20140411090847.217205@eggemoggin.niobe.net> References: <20140411090847.217205@eggemoggin.niobe.net> Message-ID: Congrats Andrew and Doug - you have done a great job, long may it continue! Cheers, Martijn On 11 April 2014 17:08, wrote: > I'm pleased to announce that the nominees to the two At-Large > seats of the OpenJDK Governing Board have been ratified [1]. > > Yes No Abstain > Andrew Haley 34 0 5 > Doug Lea 38 0 0 > > On behalf of the Board I hereby welcome Andrew and Doug back > for another year. > > Thanks to everyone who voted! > > - Mark > > > [1] http://openjdk.java.net/poll/gb/2014/ > From neugens at redhat.com Fri Apr 11 16:41:22 2014 From: neugens at redhat.com (Mario Torre) Date: Fri, 11 Apr 2014 18:41:22 +0200 Subject: OpenJDK Governing Board 2014 Election: Results In-Reply-To: <20140411090847.217205@eggemoggin.niobe.net> References: <20140411090847.217205@eggemoggin.niobe.net> Message-ID: <1397234482.12179.8.camel@galactica.localdomain> On Fri, 2014-04-11 at 09:08 -0700, mark.reinhold at oracle.com wrote: > I'm pleased to announce that the nominees to the two At-Large > seats of the OpenJDK Governing Board have been ratified [1]. > > Yes No Abstain > Andrew Haley 34 0 5 > Doug Lea 38 0 0 > > On behalf of the Board I hereby welcome Andrew and Doug back > for another year. > > Thanks to everyone who voted! Congratulations to both! > - Mark > > > [1] http://openjdk.java.net/poll/gb/2014/ 404 Not Found :) Cheers, Mario From donald.smith at oracle.com Fri Apr 11 16:42:43 2014 From: donald.smith at oracle.com (Donald Smith) Date: Fri, 11 Apr 2014 12:42:43 -0400 Subject: OpenJDK Governing Board 2014 Election: Results In-Reply-To: <1397234482.12179.8.camel@galactica.localdomain> References: <20140411090847.217205@eggemoggin.niobe.net> <1397234482.12179.8.camel@galactica.localdomain> Message-ID: <53481B83.5050800@oracle.com> Drop the trailing slash: http://openjdk.java.net/poll/gb/2014 - Don On 11/04/2014 12:41 PM, Mario Torre wrote: > On Fri, 2014-04-11 at 09:08 -0700, mark.reinhold at oracle.com wrote: >> I'm pleased to announce that the nominees to the two At-Large >> seats of the OpenJDK Governing Board have been ratified [1]. >> >> Yes No Abstain >> Andrew Haley 34 0 5 >> Doug Lea 38 0 0 >> >> On behalf of the Board I hereby welcome Andrew and Doug back >> for another year. >> >> Thanks to everyone who voted! > Congratulations to both! > >> - Mark >> >> >> [1] http://openjdk.java.net/poll/gb/2014/ > 404 Not Found :) > > Cheers, > Mario > > From mark.reinhold at oracle.com Fri Apr 11 16:47:22 2014 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Fri, 11 Apr 2014 09:47:22 -0700 Subject: OpenJDK Governing Board 2014 Election: Results In-Reply-To: <1397234482.12179.8.camel@galactica.localdomain> References: <20140411090847.217205@eggemoggin.niobe.net>, <1397234482.12179.8.camel@galactica.localdomain> Message-ID: <20140411094722.116375@eggemoggin.niobe.net> 2014/4/11 2:41 -0700, neugens at redhat.com: > On Fri, 2014-04-11 at 09:08 -0700, mark.reinhold at oracle.com wrote: >> [1] http://openjdk.java.net/poll/gb/2014/ > > 404 Not Found :) Oops. I've added a redirect to make that URL work. Thanks, - Mark From joe.darcy at oracle.com Sun Apr 13 01:21:15 2014 From: joe.darcy at oracle.com (Joe Darcy) Date: Sat, 12 Apr 2014 18:21:15 -0700 Subject: Draft proposal: JEP 2.0 In-Reply-To: <8C0D60E7-F0E5-4179-A37B-26AA95C862B5@oracle.com> References: <8C0D60E7-F0E5-4179-A37B-26AA95C862B5@oracle.com> Message-ID: <5349E68B.6000301@oracle.com> On 04/10/2014 08:41 PM, Mike Duigou wrote: > Some comments. > > Tracking: > > - I'll add my voice to Bob's that we want only one system of record for JEPs and that should be JBS. JEPs are either managed entirely within JBS or we shouldn't bother with using JBS for JEPS at all. If we are going to go with the many-staged workflow described in the proposal then having JBS to manage that workflow would be a huge boon. > > - "Alert Status (updated weekly once Funded)". This seems onerous for projects that are green (or irredeemably yellow). Required increment-the-date weekly updates has been a significant annoyance for internal processes which I would prefer not to repeat with JEPs. > > > Workflow: > > - The diagram unfortunately reminds me too much of a LHC "Higgs Boson detection event" graphic. Many of these states are overlapping and are worked coincidentally. Since only some of them are strictly gating can we collapse the softer states to a smaller number of strictly gating states? > [snip] In the JDK project of JBS, I've found the separation of Status (New, Open, In Progress, Resolved, Closed) from Resolution (Fixed, Duplicate, etc.) to be helpful when categorizing the state of a bug. (To a lesser extent, the separation of "understaning" is useful too.) Perhaps an analogous refactoring could be applied to JEP state. -Joe From jonathan.gibbons at oracle.com Sun Apr 13 01:42:40 2014 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Sat, 12 Apr 2014 18:42:40 -0700 Subject: Draft proposal: JEP 2.0 In-Reply-To: References: <20140408140825.43296@eggemoggin.niobe.net> Message-ID: <5349EB90.1050602@oracle.com> On 04/09/2014 09:41 AM, Bob Vandette wrote: > Mark, > > I like the idea of using JIRA for the JEP process but ... > > Why are you proposing to continue supporting some of the JEP content in Mercurial > form rather than using the description field in JBS and providing a template for this area > of the JIRA entry? We've done this successfully for internal project tracking. > > If it's for format validation, you might be able to do this as part of the workflow > process as you change states and not have to maintain information in two places. > > Bob. While the current JEP pages "look nice", the current system seems like Yet Another Ad-hoc System, which now seems unnecessary given that we have a standard issue tracking system that is designed to be capable of supporting stuff like this. So, another +1 on leveraging standard infrastructure, and keeping all the info all together in one place. -- Jon From mark.reinhold at oracle.com Sat Apr 12 19:28:04 2014 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Sat, 12 Apr 2014 12:28:04 -0700 Subject: Draft proposal: JEP 2.0 In-Reply-To: References: <20140408140825.43296@eggemoggin.niobe.net>, Message-ID: <20140412122804.210238@eggemoggin.niobe.net> 2014/4/9 2:41 -0700, bob.vandette at oracle.com: > I like the idea of using JIRA for the JEP process but ... > > Why are you proposing to continue supporting some of the JEP content > in Mercurial form rather than using the description field in JBS and > providing a template for this area of the JIRA entry? We've done this > successfully for internal project tracking. The short answer: JEPs are structured, long-form documents, and JIRA is not an effective tool for creating, editing, curating, and presenting a collection of such documents. The longer answer: - Some people, including yours truly, find any amount of non-trivial text editing in a web browser to be extraordinarily painful. Maybe it's just me, but if I can't edit something in Emacs then it just isn't real. (Yes, you can cut and paste individual text areas back and forth, but that's too tedious to bear.) - Incoming JEPs invariably require at least some light copy-editing. Some JEPs require much more than that. I'm not going to do all that work in a web browser, nor am I going to ask anyone else to do so. - The largest constituency for JEPs is the people who read them, not those who write or edit them. JIRA, unfortunately, does not do a very good job of displaying large bodies of structured text. It's certainly possible to encode a long-form text document into some text fields in a JIRA issue, but the result is far from easy to read, never mind actually attractive. - JIRA's history display is fairly primitive, showing just the new and old values for each field modified in a particular transaction. To comprehend the changes to a long document over time you really need something more like an actual diff. Now perhaps we can eventually customize JIRA and the systems around it to overcome these issues, but unless and until we do so I think we'll all be better served by continuing to create and maintain the bodies of JEPs as Markdown documents in Mercurial while tracking their workflow status and related tasks in JBS. - Mark From mark.reinhold at oracle.com Sat Apr 12 19:28:23 2014 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Sat, 12 Apr 2014 12:28:23 -0700 Subject: Draft proposal: JEP 2.0 In-Reply-To: <8C0D60E7-F0E5-4179-A37B-26AA95C862B5@oracle.com> References: <8C0D60E7-F0E5-4179-A37B-26AA95C862B5@oracle.com> Message-ID: <20140412122823.131240@eggemoggin.niobe.net> 2014/4/10 13:41 -0700, mike.duigou at oracle.com: > Some comments. > > Tracking: > > - I'll add my voice to Bob's that we want only one system of record > for JEPs and that should be JBS. JEPs are either managed entirely > within JBS or we shouldn't bother with using JBS for JEPS at all. If > we are going to go with the many-staged workflow described in the > proposal then having JBS to manage that workflow would be a huge boon. I agree (obviously) that we should use JBS to implement the proposed new workflow. As implied by my answer to Bob, though, I don't think that we must choose one system over the other. What might not be clear in the current draft is that no workflow status is ever recorded in a JEP document. You can draft a JEP, pass it around in e-mail or put it on a wiki for initial review, and then once you submit it for posting to the Mercurial archive it gets a JBS issue and the workflow is tracked in JBS. In the current proposal some information is duplicated in both a JEP document and its corresponding JBS issue, hence the need for automated consistency checks. To simplify things perhaps we should move as much information as possible from a JEP document into its JBS issue at the time the issue is created. A "proto-JEP", then, would contain all the headers mentioned in the proposal, but once it's posted and has a JBS issue then the only header the document would absolutely need would be the "Issue" header, to link it to the issue. (To make editing JEP documents easier we might want to retain a couple of other headers, e.g., "Title".) The rendering of a posted JEP document would then be based upon information in both the Mercurial archive and JBS. Would you prefer this kind of approach? (A related optimization would be to remove the "Impact" section from the document once a JEP reaches the Funded state, since by then presumably anyone impacted by the proposal will have been included in the JEP's plan.) > - "Alert Status (updated weekly once Funded)". This seems onerous for > projects that are green (or irredeemably yellow). Required > increment-the-date weekly updates has been a significant annoyance for > internal processes which I would prefer not to repeat with JEPs. I see what you mean about having to update the status weekly when a feature is Green. If a feature is Yellow, though, then I don't think it's unreasonable to ask for a weekly update, and making such an update in JBS should take only a moment. (If a feature is irredeemably Yellow then perhaps it shouldn't be in the Funded state, or any later state.) How about "updated weekly if not Green, once Funded"? > Workflow: > > - The diagram unfortunately reminds me too much of a LHC "Higgs Boson > detection event" graphic. Many of these states are overlapping and are > worked coincidentally. Since only some of them are strictly gating can > we collapse the softer states to a smaller number of strictly gating > states? I'm all for eliminating needless states, but each one does serve a distinct purpose, especially in terms of communicating the status of work on a feature. It's true that some kinds of work are likely to overlap -- just because a feature isn't yet Funded doesn't mean you can't, e.g., do some prototyping work (which can arguably be part of the Planning stage anyway). Do you have specific suggestions of states to collapse? > General: > > - The JEP process doesn't feel very approachable to an outsider/first > time submitter. Either we have to provide a lot more guidance about > how to fill out a JEP and/or make the process simpler. ... I agree that we could do better here. Improving in this way would help submitters and it would also reduce the workload of those of us who edit incoming JEPs. Perhaps we should use our wiki to collect a list of FAQ items and, once it settles, publish it as an informational JEP? Thanks for your comments! - Mark From iris.clark at oracle.com Mon Apr 14 21:28:29 2014 From: iris.clark at oracle.com (Iris Clark) Date: Mon, 14 Apr 2014 14:28:29 -0700 (PDT) Subject: hg.openjdk.java.net project and per-project repository lists In-Reply-To: <6559e7be-3956-42fa-9f48-d0f49792a1f6@default> References: <20140402120133.478052@eggemoggin.niobe.net> <1751360160.1628499.1396970550830.JavaMail.zimbra@redhat.com> <20140408082939.181746@eggemoggin.niobe.net> <52341904.1889889.1396990858837.JavaMail.zimbra@redhat.com> <53451303.2060106@redhat.com> <6559e7be-3956-42fa-9f48-d0f49792a1f6@default> Message-ID: Hi. http://openjdk.java.net/groups/web/ "Source Code" section now contains a link to the simple repo listing: http://hg.openjdk.java.net/?style=raw Thanks, iris -----Original Message----- From: Iris Clark Sent: Wednesday, April 09, 2014 9:21 AM To: Andrew Haley; Andrew Hughes; Mark Reinhold Cc: discuss at openjdk.java.net Subject: RE: hg.openjdk.java.net project and per-project repository lists Hi. >>> If you just want a fast, simple list of all the repos, try this: >>> >>> http://hg.openjdk.java.net/?style=raw > >> That's perfect. Thanks Mark. > > Brilliant! Who knew? Erm, is there any way to link to that list from the OpenJDK pages? Would make sense to add a "Repositories" section to the Web Group's static page [1] with links to the friendly hg.ojn and Mark's link? Thanks, iris [1]: http://openjdk.java.net/groups/web/ [2]: http://hg.openjdk.java.net From aph at redhat.com Tue Apr 15 07:19:17 2014 From: aph at redhat.com (Andrew Haley) Date: Tue, 15 Apr 2014 08:19:17 +0100 Subject: hg.openjdk.java.net project and per-project repository lists In-Reply-To: References: <20140402120133.478052@eggemoggin.niobe.net> <1751360160.1628499.1396970550830.JavaMail.zimbra@redhat.com> <20140408082939.181746@eggemoggin.niobe.net> <52341904.1889889.1396990858837.JavaMail.zimbra@redhat.com> <53451303.2060106@redhat.com> <6559e7be-3956-42fa-9f48-d0f49792a1f6@default> Message-ID: <534CDD75.6040106@redhat.com> On 04/14/2014 10:28 PM, Iris Clark wrote: > http://openjdk.java.net/groups/web/ > > "Source Code" section now contains a link to the simple repo listing: > > http://hg.openjdk.java.net/?style=raw That's excellent. Thank you very much. Andrew. From per at bothner.com Tue Apr 15 19:34:05 2014 From: per at bothner.com (Per Bothner) Date: Tue, 15 Apr 2014 12:34:05 -0700 Subject: Draft proposal: JEP 2.0 Message-ID: <534D89AD.6030505@bothner.com> [Sorry for the bad message linkage - I just subscribed.] On Apr 12 Mark Reinhold wrote: > - Some people, including yours truly, find any amount of non-trivial > text editing in a web browser to be extraordinarily painful. ... > - Incoming JEPs invariably require at least some light copy-editing. > Some JEPs require much more than that. ... As you point out "The largest constituency for JEPs is the people who read them, not those who write or edit them." I think most people (even those of us more comfortable with Emacs) can handle editing in a web browser. > JIRA, unfortunately, does not do a > very good job of displaying large bodies of structured text. Actually, JIRA supports rich text tolerably well - about as well as the Markdown use by JEP (thought it doesn't have the "escape to HTML" fall-back). Of course they use their own idiosyncratic markup format, which matches the Confluence wiki engine. Any text field can be configured to the use the "Wiki Style Renderer": https://confluence.atlassian.com/display/JIRA/Configuring+Renderers https://jira.atlassian.com/secure/WikiRendererHelpAction.jspa The result is quite readable, and looks decent enough. (There are plugins to use Markdown, but I don't believe any is supported by Atlassian, so I think its more simple and robust to stick with the native markup format.) > It's certainly possible to encode a long-form text document into > some text fields in a JIRA issue, but the result is far from easy > to read, never mind actually attractive. One could use a separate JIRA field for each JEP section, or just put it all in the Description field and use headings to mark the sections. It's not clear which is better. > - JIRA's history display is fairly primitive, showing just the new > and old values for each field modified in a particular transaction. > To comprehend the changes to a long document over time you really > need something more like an actual diff. Yes, JIRA isn't very diff-friendly nor very friendly to the kind of workflow we're used to from Mercurial, including patches. I wrote some experimental tools in this area. The idea is to use JIRA's REST interface, which allows you to extract the fields of an issue in a JSON representation - as well as optionally update them. I wrote a filter to convert to and from what I call "pretty JSON", which does line-breaking, indentation, removes the redundant commas, and quotes around field names. This format is much more diff-friendly - as well as friendlier to human readers and editors. Our goal was to version-control JIRA configuration information, as well as copy information from one JIRA instance to another. It seems we could modify these command-line tools could to make it more pleasant to diff (or even patch) JEP issues. -- --Per Bothner per at bothner.com http://per.bothner.com/ From jon.masamitsu at oracle.com Tue Apr 15 21:09:44 2014 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Tue, 15 Apr 2014 14:09:44 -0700 Subject: Draft proposal: JEP 2.0 In-Reply-To: <534D89AD.6030505@bothner.com> References: <534D89AD.6030505@bothner.com> Message-ID: <534DA018.4080209@oracle.com> > The JEP owner is expected to update the Alert Status on a weekly basis > once a JEP is Funded and active development work is under way. If the > Alert Status is Yellow or Red then the owner must use the Alert Reason > field to explain what is required to return the Status to Green. This > way everyone working on the release or otherwise interested in the JEP > can easily understand its current state. This sounds a lot like the status I have to report to my managers. Except that I talk to my manager about how things are going. This I have to compose and publish. Sorry but it's something that I'll easily forget to do. > Any Committer to a Project may propose to target a Feature JEP to a > release of that Project after documenting a realistic delivery plan > and adequate funding. The proposer should be the JEP's owner, or > arrange to become the owner. If I provided a "realistic delivery plan" how are you (people in the OpenJDK community, this is a question for you) going to use it? Is it that much more valuable than a delivery in a milestone date (as was done in JDK8)? Jon Subject: Draft proposal: JEP 2.0 From: mark.reinhold at oracle.com Date: 4/8/14 1:54 PM To: discuss at openjdk.java.net The JEP Process [1] has served us well as a way to document proposed enhancements to the JDK. The process does not, however, say how we decide to target a JEP to a particular JDK Release Project, nor does it help track the work subsequently done on a JEP. We also don't have a documented process by which we can create and maintain the overall schedule of a Release Project. To fill these gaps I've drafted an extension of the JEP Process which covers the planning of Release Projects, the tracking of the work done for their Feature JEPs, and the tracking of work done for other kinds of JEPs that are not associated with specific releases. The current draft of the proposal is here: http://cr.openjdk.java.net/~mr/jep/jep-2.0.html The proposal suggests, among other things, that we create a new "JEP" issue type in the JBS JIRA system so that it's easy to see the status of a particular JEP as well as the overall status of an entire Release Project. This draft has been reviewed by a handful of people so far. My thanks to Mathias Axelsson, Brian Beck, Iris Clark, Joe Darcy, Brian Goetz, Georges Saab, and Dalibor Topic for their feedback. If you have comments or suggestions on this draft, please send them in a public reply to this message by Monday, 21 April 2011. I'd like to put this new process in place shortly thereafter. - Mark [1]http://openjdk.java.net/jeps/ From bengt.rutisson at oracle.com Wed Apr 16 07:14:41 2014 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Wed, 16 Apr 2014 09:14:41 +0200 Subject: Draft proposal: JEP 2.0 In-Reply-To: <534D89AD.6030505@bothner.com> References: <534D89AD.6030505@bothner.com> Message-ID: <534E2DE1.1020002@oracle.com> On 4/15/14 9:34 PM, Per Bothner wrote: > [Sorry for the bad message linkage - I just subscribed.] > > On Apr 12 Mark Reinhold wrote: > > > - Some people, including yours truly, find any amount of non-trivial > > text editing in a web browser to be extraordinarily painful. ... > > > - Incoming JEPs invariably require at least some light copy-editing. > > Some JEPs require much more than that. ... > > As you point out "The largest constituency for JEPs is the people who > read them, not those who write or edit them." I think most people > (even those of us more comfortable with Emacs) can handle editing > in a web browser. Totally agree. One more comment further down. > > > JIRA, unfortunately, does not do a > > very good job of displaying large bodies of structured text. > > Actually, JIRA supports rich text tolerably well - about as well > as the Markdown use by JEP (thought it doesn't have the "escape to > HTML" fall-back). Of course they use their own idiosyncratic > markup format, which matches the Confluence wiki engine. Any text > field can be configured to the use the "Wiki Style Renderer": > > https://confluence.atlassian.com/display/JIRA/Configuring+Renderers > https://jira.atlassian.com/secure/WikiRendererHelpAction.jspa > > The result is quite readable, and looks decent enough. > > (There are plugins to use Markdown, but I don't believe any is > supported by Atlassian, so I think its more simple and robust to stick > with the native markup format.) > > > It's certainly possible to encode a long-form text document into > > some text fields in a JIRA issue, but the result is far from easy > > to read, never mind actually attractive. > > One could use a separate JIRA field for each JEP section, or just put > it all in the Description field and use headings to mark the sections. > It's not clear which is better. > > > - JIRA's history display is fairly primitive, showing just the new > > and old values for each field modified in a particular transaction. > > To comprehend the changes to a long document over time you really > > need something more like an actual diff. > > Yes, JIRA isn't very diff-friendly nor very friendly to the kind of > workflow we're used to from Mercurial, including patches. True, but note that the proposal is already suggesting that the "static" parts of a JEP should be in the Mercurial repository and that the "dynamic" part should be in JIRA. So, even with the current proposal we will be using JIRA for the tracking information that is changing the most. Thus, I don't think that saying that Mercurial is better at tracking changes is much of an argument for keeping part of the JEP there. I think we need to decide to either have the full JEP in Mercurial or in JIRA. Having it in both places just does not make sense. Bengt > > I wrote some experimental tools in this area. The idea is to use > JIRA's REST interface, which allows you to extract the fields of an > issue in a JSON representation - as well as optionally update them. > I wrote a filter to convert to and from what I call "pretty JSON", > which does line-breaking, indentation, removes the redundant commas, > and quotes around field names. This format is much more diff-friendly > - as well as friendlier to human readers and editors. Our goal was to > version-control JIRA configuration information, as well as copy > information from one JIRA instance to another. It seems we could > modify these command-line tools could to make it more pleasant to diff > (or even patch) JEP issues. From staffan.larsen at oracle.com Wed Apr 16 08:16:58 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Wed, 16 Apr 2014 10:16:58 +0200 Subject: Draft proposal: JEP 2.0 In-Reply-To: <534E2DE1.1020002@oracle.com> References: <534D89AD.6030505@bothner.com> <534E2DE1.1020002@oracle.com> Message-ID: On 16 apr 2014, at 09:14, Bengt Rutisson wrote: > On 4/15/14 9:34 PM, Per Bothner wrote: >> [Sorry for the bad message linkage - I just subscribed.] >> >> On Apr 12 Mark Reinhold wrote: >> >> > - Some people, including yours truly, find any amount of non-trivial >> > text editing in a web browser to be extraordinarily painful. ... >> >> > - Incoming JEPs invariably require at least some light copy-editing. >> > Some JEPs require much more than that. ... >> >> As you point out "The largest constituency for JEPs is the people who >> read them, not those who write or edit them." I think most people >> (even those of us more comfortable with Emacs) can handle editing >> in a web browser. > > Totally agree. If we can?t enable markup mode in the JIRA field, then maybe the openjdk wiki is a better place than markdown files in a mercurial repository? I assume that the goal is for the text of the JEPs to be living updated document that would change as a JEP is taken from the initial idea into a deliverable feature. If that is the case, then it is absolutely necessary that the text be easy to update by the author or it will be just another dead document. /Staffan > > One more comment further down. > >> >> > JIRA, unfortunately, does not do a >> > very good job of displaying large bodies of structured text. >> >> Actually, JIRA supports rich text tolerably well - about as well >> as the Markdown use by JEP (thought it doesn't have the "escape to >> HTML" fall-back). Of course they use their own idiosyncratic >> markup format, which matches the Confluence wiki engine. Any text >> field can be configured to the use the "Wiki Style Renderer": >> >> https://confluence.atlassian.com/display/JIRA/Configuring+Renderers >> https://jira.atlassian.com/secure/WikiRendererHelpAction.jspa >> >> The result is quite readable, and looks decent enough. >> >> (There are plugins to use Markdown, but I don't believe any is supported by Atlassian, so I think its more simple and robust to stick >> with the native markup format.) >> >> > It's certainly possible to encode a long-form text document into >> > some text fields in a JIRA issue, but the result is far from easy >> > to read, never mind actually attractive. >> >> One could use a separate JIRA field for each JEP section, or just put >> it all in the Description field and use headings to mark the sections. >> It's not clear which is better. >> >> > - JIRA's history display is fairly primitive, showing just the new >> > and old values for each field modified in a particular transaction. >> > To comprehend the changes to a long document over time you really >> > need something more like an actual diff. >> >> Yes, JIRA isn't very diff-friendly nor very friendly to the kind of >> workflow we're used to from Mercurial, including patches. > > True, but note that the proposal is already suggesting that the "static" parts of a JEP should be in the Mercurial repository and that the "dynamic" part should be in JIRA. So, even with the current proposal we will be using JIRA for the tracking information that is changing the most. Thus, I don't think that saying that Mercurial is better at tracking changes is much of an argument for keeping part of the JEP there. > > I think we need to decide to either have the full JEP in Mercurial or in JIRA. Having it in both places just does not make sense. > > Bengt >> >> I wrote some experimental tools in this area. The idea is to use >> JIRA's REST interface, which allows you to extract the fields of an >> issue in a JSON representation - as well as optionally update them. >> I wrote a filter to convert to and from what I call "pretty JSON", >> which does line-breaking, indentation, removes the redundant commas, >> and quotes around field names. This format is much more diff-friendly - as well as friendlier to human readers and editors. Our goal was to version-control JIRA configuration information, as well as copy information from one JIRA instance to another. It seems we could >> modify these command-line tools could to make it more pleasant to diff >> (or even patch) JEP issues. From stefan.karlsson at oracle.com Wed Apr 16 08:20:26 2014 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Wed, 16 Apr 2014 10:20:26 +0200 Subject: Draft proposal: JEP 2.0 In-Reply-To: References: <534D89AD.6030505@bothner.com> <534E2DE1.1020002@oracle.com> Message-ID: <534E3D4A.6090401@oracle.com> On 2014-04-16 10:16, Staffan Larsen wrote: > On 16 apr 2014, at 09:14, Bengt Rutisson wrote: > >> On 4/15/14 9:34 PM, Per Bothner wrote: >>> [Sorry for the bad message linkage - I just subscribed.] >>> >>> On Apr 12 Mark Reinhold wrote: >>> >>>> - Some people, including yours truly, find any amount of non-trivial >>>> text editing in a web browser to be extraordinarily painful. ... >>>> - Incoming JEPs invariably require at least some light copy-editing. >>>> Some JEPs require much more than that. ... >>> As you point out "The largest constituency for JEPs is the people who >>> read them, not those who write or edit them." I think most people >>> (even those of us more comfortable with Emacs) can handle editing >>> in a web browser. >> Totally agree. > If we can?t enable markup mode in the JIRA field, then maybe the openjdk wiki is a better place than markdown files in a mercurial repository? Is there a reason why we can't/won't enable markup mode in the JIRA field? StefanK > > I assume that the goal is for the text of the JEPs to be living updated document that would change as a JEP is taken from the initial idea into a deliverable feature. If that is the case, then it is absolutely necessary that the text be easy to update by the author or it will be just another dead document. > > /Staffan > > >> One more comment further down. >> >>>> JIRA, unfortunately, does not do a >>>> very good job of displaying large bodies of structured text. >>> Actually, JIRA supports rich text tolerably well - about as well >>> as the Markdown use by JEP (thought it doesn't have the "escape to >>> HTML" fall-back). Of course they use their own idiosyncratic >>> markup format, which matches the Confluence wiki engine. Any text >>> field can be configured to the use the "Wiki Style Renderer": >>> >>> https://confluence.atlassian.com/display/JIRA/Configuring+Renderers >>> https://jira.atlassian.com/secure/WikiRendererHelpAction.jspa >>> >>> The result is quite readable, and looks decent enough. >>> >>> (There are plugins to use Markdown, but I don't believe any is supported by Atlassian, so I think its more simple and robust to stick >>> with the native markup format.) >>> >>>> It's certainly possible to encode a long-form text document into >>>> some text fields in a JIRA issue, but the result is far from easy >>>> to read, never mind actually attractive. >>> One could use a separate JIRA field for each JEP section, or just put >>> it all in the Description field and use headings to mark the sections. >>> It's not clear which is better. >>> >>>> - JIRA's history display is fairly primitive, showing just the new >>>> and old values for each field modified in a particular transaction. >>>> To comprehend the changes to a long document over time you really >>>> need something more like an actual diff. >>> Yes, JIRA isn't very diff-friendly nor very friendly to the kind of >>> workflow we're used to from Mercurial, including patches. >> True, but note that the proposal is already suggesting that the "static" parts of a JEP should be in the Mercurial repository and that the "dynamic" part should be in JIRA. So, even with the current proposal we will be using JIRA for the tracking information that is changing the most. Thus, I don't think that saying that Mercurial is better at tracking changes is much of an argument for keeping part of the JEP there. >> >> I think we need to decide to either have the full JEP in Mercurial or in JIRA. Having it in both places just does not make sense. >> >> Bengt >>> I wrote some experimental tools in this area. The idea is to use >>> JIRA's REST interface, which allows you to extract the fields of an >>> issue in a JSON representation - as well as optionally update them. >>> I wrote a filter to convert to and from what I call "pretty JSON", >>> which does line-breaking, indentation, removes the redundant commas, >>> and quotes around field names. This format is much more diff-friendly - as well as friendlier to human readers and editors. Our goal was to version-control JIRA configuration information, as well as copy information from one JIRA instance to another. It seems we could >>> modify these command-line tools could to make it more pleasant to diff >>> (or even patch) JEP issues. From martijnverburg at gmail.com Wed Apr 16 08:58:58 2014 From: martijnverburg at gmail.com (Martijn Verburg) Date: Wed, 16 Apr 2014 09:58:58 +0100 Subject: Draft proposal: JEP 2.0 In-Reply-To: <534DA018.4080209@oracle.com> References: <534D89AD.6030505@bothner.com> <534DA018.4080209@oracle.com> Message-ID: Hi Jon, On 15 April 2014 22:09, Jon Masamitsu wrote: > The JEP owner is expected to update the Alert Status on a weekly basis >> once a JEP is Funded and active development work is under way. If the Alert >> Status is Yellow or Red then the owner must use the Alert Reason field to >> explain what is required to return the Status to Green. This way everyone >> working on the release or otherwise interested in the JEP can easily >> understand its current state. >> > This sounds a lot like the status I have to report to my managers. Except > that > I talk to my manager about how things are going. This I have to compose > and > publish. Sorry but it's something that I'll easily forget to do. > >> Any Committer to a Project may propose to target a Feature JEP to a >> release of that Project after documenting a realistic delivery plan and >> adequate funding. The proposer should be the JEP's owner, or arrange to >> become the owner. >> > > If I provided a "realistic delivery plan" how are you (people in the > OpenJDK community, this is > a question for you) going to use it? Is it that much more valuable than > a delivery in a milestone > date (as was done in JDK8)? > At the very least it will certainly help the Adoption Group in that we can plan for hackdays where day to day developers can test new JEPs early and provide feedback on API design, implementation, bugs etc (much like we did for Date & Time and Lambdas). Cheers, Martijn > Jon > > > > Subject: > Draft proposal: JEP 2.0 > From: > mark.reinhold at oracle.com > Date: > 4/8/14 1:54 PM > > To: > discuss at openjdk.java.net > > > The JEP Process [1] has served us well as a way to document proposed > enhancements to the JDK. The process does not, however, say how we > decide to target a JEP to a particular JDK Release Project, nor does > it help track the work subsequently done on a JEP. We also don't have > a documented process by which we can create and maintain the overall > schedule of a Release Project. > > To fill these gaps I've drafted an extension of the JEP Process which > covers the planning of Release Projects, the tracking of the work done > for their Feature JEPs, and the tracking of work done for other kinds > of JEPs that are not associated with specific releases. The current > draft of the proposal is here: > > http://cr.openjdk.java.net/~mr/jep/jep-2.0.html > > The proposal suggests, among other things, that we create a new "JEP" > issue type in the JBS JIRA system so that it's easy to see the status > of a particular JEP as well as the overall status of an entire Release > Project. > > This draft has been reviewed by a handful of people so far. My thanks > to Mathias Axelsson, Brian Beck, Iris Clark, Joe Darcy, Brian Goetz, > Georges Saab, and Dalibor Topic for their feedback. > > If you have comments or suggestions on this draft, please send them in > a public reply to this message by Monday, 21 April 2011. I'd like to > put this new process in place shortly thereafter. > > - Mark > > > [1]http://openjdk.java.net/jeps/ > > > From jon.masamitsu at oracle.com Wed Apr 16 23:59:56 2014 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Wed, 16 Apr 2014 16:59:56 -0700 Subject: Draft proposal: JEP 2.0 In-Reply-To: References: <534D89AD.6030505@bothner.com> <534DA018.4080209@oracle.com> Message-ID: <534F197C.6000700@oracle.com> On 4/16/2014 1:58 AM, Martijn Verburg wrote: > Hi Jon, > > On 15 April 2014 22:09, Jon Masamitsu > wrote: > > The JEP owner is expected to update the Alert Status on a > weekly basis once a JEP is Funded and active development work > is under way. If the Alert Status is Yellow or Red then the > owner must use the Alert Reason field to explain what is > required to return the Status to Green. This way everyone > working on the release or otherwise interested in the JEP can > easily understand its current state. > > This sounds a lot like the status I have to report to my managers. > Except that > I talk to my manager about how things are going. This I have to > compose and > publish. Sorry but it's something that I'll easily forget to do. > > Any Committer to a Project may propose to target a Feature JEP > to a release of that Project after documenting a realistic > delivery plan and adequate funding. The proposer should be the > JEP's owner, or arrange to become the owner. > > > If I provided a "realistic delivery plan" how are you (people in > the OpenJDK community, this is > a question for you) going to use it? Is it that much more > valuable than a delivery in a milestone > date (as was done in JDK8)? > > > At the very least it will certainly help the Adoption Group in that we > can plan for hackdays where day to day developers can test new JEPs > early and provide feedback on API design, implementation, bugs etc > (much like we did for Date & Time and Lambdas). Granted that would be good use but would it be just as good to have an early access milestone. A delivery plan sounds like more than most would want to look at and feels like a duplicate of what I have to produce for my management. And I don't want to cut-and-paste-and-sanitize an internal document to publish as delivery plan. Jon > > Cheers, > Martijn > > Jon > > > > Subject: > Draft proposal: JEP 2.0 > From: > mark.reinhold at oracle.com > Date: > 4/8/14 1:54 PM > > To: > discuss at openjdk.java.net > > > The JEP Process [1] has served us well as a way to document proposed > enhancements to the JDK. The process does not, however, say how we > decide to target a JEP to a particular JDK Release Project, nor does > it help track the work subsequently done on a JEP. We also don't have > a documented process by which we can create and maintain the overall > schedule of a Release Project. > > To fill these gaps I've drafted an extension of the JEP Process which > covers the planning of Release Projects, the tracking of the work done > for their Feature JEPs, and the tracking of work done for other kinds > of JEPs that are not associated with specific releases. The current > draft of the proposal is here: > > http://cr.openjdk.java.net/~mr/jep/jep-2.0.html > > > The proposal suggests, among other things, that we create a new "JEP" > issue type in the JBS JIRA system so that it's easy to see the status > of a particular JEP as well as the overall status of an entire Release > Project. > > This draft has been reviewed by a handful of people so far. My thanks > to Mathias Axelsson, Brian Beck, Iris Clark, Joe Darcy, Brian Goetz, > Georges Saab, and Dalibor Topic for their feedback. > > If you have comments or suggestions on this draft, please send them in > a public reply to this message by Monday, 21 April 2011. I'd like to > put this new process in place shortly thereafter. > > - Mark > > > [1]http://openjdk.java.net/jeps/ > > > From jonathan.gibbons at oracle.com Thu Apr 17 00:19:00 2014 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 16 Apr 2014 17:19:00 -0700 Subject: Draft proposal: JEP 2.0 In-Reply-To: <534DA018.4080209@oracle.com> References: <534D89AD.6030505@bothner.com> <534DA018.4080209@oracle.com> Message-ID: <534F1DF4.2040708@oracle.com> On 04/15/2014 02:09 PM, Jon Masamitsu wrote: >> The JEP owner is expected to update the Alert Status on a weekly >> basis once a JEP is Funded and active development work is under way. >> If the Alert Status is Yellow or Red then the owner must use the >> Alert Reason field to explain what is required to return the Status >> to Green. This way everyone working on the release or otherwise >> interested in the JEP can easily understand its current state. > This sounds a lot like the status I have to report to my managers. > Except that > I talk to my manager about how things are going. This I have to > compose and > publish. Sorry but it's something that I'll easily forget to do. I think the point is that this will supersede some of the ad-hoc infrastructure we currently use to track project progress, so this is not something that you'll forget to do: it is simply a formalized replacement of what you do today. It is just an "enum" (green/yellow/red) and a text field. I doubt that folk are expecting you to write an essay each week for the Alert Reason field. The good news is that by having the alert status in a system like JIRA, we can do intelligent queries about work in progress to create useful summary reports, rather than working with miscellaneous ad-hoc infrastructure (i.e. wiki pages, uugh!) -- Jon From jonathan.gibbons at oracle.com Thu Apr 17 01:14:17 2014 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 16 Apr 2014 18:14:17 -0700 Subject: Draft proposal: JEP 2.0 In-Reply-To: <534E3D4A.6090401@oracle.com> References: <534D89AD.6030505@bothner.com> <534E2DE1.1020002@oracle.com> <534E3D4A.6090401@oracle.com> Message-ID: <534F2AE9.4060107@oracle.com> On 04/16/2014 01:20 AM, Stefan Karlsson wrote: > > On 2014-04-16 10:16, Staffan Larsen wrote: >> On 16 apr 2014, at 09:14, Bengt Rutisson >> wrote: >> >>> On 4/15/14 9:34 PM, Per Bothner wrote: >>>> [Sorry for the bad message linkage - I just subscribed.] >>>> >>>> On Apr 12 Mark Reinhold wrote: >>>> >>>>> - Some people, including yours truly, find any amount of >>>>> non-trivial >>>>> text editing in a web browser to be extraordinarily painful. >>>>> ... >>>>> - Incoming JEPs invariably require at least some light >>>>> copy-editing. >>>>> Some JEPs require much more than that. ... >>>> As you point out "The largest constituency for JEPs is the people who >>>> read them, not those who write or edit them." I think most people >>>> (even those of us more comfortable with Emacs) can handle editing >>>> in a web browser. >>> Totally agree. >> If we can?t enable markup mode in the JIRA field, then maybe the >> openjdk wiki is a better place than markdown files in a mercurial >> repository? > > Is there a reason why we can't/won't enable markup mode in the JIRA > field? I know we didn't enable markup mode on the fields that were used to store the info that was imported from the legacy bug system, but here we're talking about new fields. And, from the Atlassian documentation, it seems we should be able to configure the mode on a per-field basis... https://confluence.atlassian.com/display/JIRA/Configuring+Renderers > Renderers are configured on a per field basis. To configure a renderer > for a particular field, see Specifying Field Behavior > . > Note that you can configure the same field differently for different > projects and issue types ? see Associating Field Behavior with Issue > Types > . -- Jon > > StefanK > >> >> I assume that the goal is for the text of the JEPs to be living >> updated document that would change as a JEP is taken from the initial >> idea into a deliverable feature. If that is the case, then it is >> absolutely necessary that the text be easy to update by the author or >> it will be just another dead document. >> >> /Staffan >> >> >>> One more comment further down. >>> >>>>> JIRA, unfortunately, does not do a >>>>> very good job of displaying large bodies of structured text. >>>> Actually, JIRA supports rich text tolerably well - about as well >>>> as the Markdown use by JEP (thought it doesn't have the "escape to >>>> HTML" fall-back). Of course they use their own idiosyncratic >>>> markup format, which matches the Confluence wiki engine. Any text >>>> field can be configured to the use the "Wiki Style Renderer": >>>> >>>> https://confluence.atlassian.com/display/JIRA/Configuring+Renderers >>>> https://jira.atlassian.com/secure/WikiRendererHelpAction.jspa >>>> >>>> The result is quite readable, and looks decent enough. >>>> >>>> (There are plugins to use Markdown, but I don't believe any is >>>> supported by Atlassian, so I think its more simple and robust to stick >>>> with the native markup format.) >>>> >>>>> It's certainly possible to encode a long-form text document into >>>>> some text fields in a JIRA issue, but the result is far from easy >>>>> to read, never mind actually attractive. >>>> One could use a separate JIRA field for each JEP section, or just put >>>> it all in the Description field and use headings to mark the sections. >>>> It's not clear which is better. >>>> >>>>> - JIRA's history display is fairly primitive, showing just the new >>>>> and old values for each field modified in a particular >>>>> transaction. >>>>> To comprehend the changes to a long document over time you really >>>>> need something more like an actual diff. >>>> Yes, JIRA isn't very diff-friendly nor very friendly to the kind of >>>> workflow we're used to from Mercurial, including patches. >>> True, but note that the proposal is already suggesting that the >>> "static" parts of a JEP should be in the Mercurial repository and >>> that the "dynamic" part should be in JIRA. So, even with the current >>> proposal we will be using JIRA for the tracking information that is >>> changing the most. Thus, I don't think that saying that Mercurial is >>> better at tracking changes is much of an argument for keeping part >>> of the JEP there. >>> >>> I think we need to decide to either have the full JEP in Mercurial >>> or in JIRA. Having it in both places just does not make sense. >>> >>> Bengt >>>> I wrote some experimental tools in this area. The idea is to use >>>> JIRA's REST interface, which allows you to extract the fields of an >>>> issue in a JSON representation - as well as optionally update them. >>>> I wrote a filter to convert to and from what I call "pretty JSON", >>>> which does line-breaking, indentation, removes the redundant commas, >>>> and quotes around field names. This format is much more >>>> diff-friendly - as well as friendlier to human readers and >>>> editors. Our goal was to version-control JIRA configuration >>>> information, as well as copy information from one JIRA instance to >>>> another. It seems we could >>>> modify these command-line tools could to make it more pleasant to diff >>>> (or even patch) JEP issues. > From mike.duigou at oracle.com Thu Apr 17 02:03:36 2014 From: mike.duigou at oracle.com (Mike Duigou) Date: Wed, 16 Apr 2014 19:03:36 -0700 Subject: Draft proposal: JEP 2.0 In-Reply-To: <534F2AE9.4060107@oracle.com> References: <534D89AD.6030505@bothner.com> <534E2DE1.1020002@oracle.com> <534E3D4A.6090401@oracle.com> <534F2AE9.4060107@oracle.com> Message-ID: <56820AA2-3099-4A89-BDA4-2CEC2E064233@oracle.com> On Apr 16 2014, at 18:14 , Jonathan Gibbons wrote: > > On 04/16/2014 01:20 AM, Stefan Karlsson wrote: >> >> On 2014-04-16 10:16, Staffan Larsen wrote: >>> On 16 apr 2014, at 09:14, Bengt Rutisson wrote: >>> >>>> On 4/15/14 9:34 PM, Per Bothner wrote: >>>>> [Sorry for the bad message linkage - I just subscribed.] >>>>> >>>>> On Apr 12 Mark Reinhold wrote: >>>>> >>>>>> - Some people, including yours truly, find any amount of non-trivial >>>>>> text editing in a web browser to be extraordinarily painful. ... >>>>>> - Incoming JEPs invariably require at least some light copy-editing. >>>>>> Some JEPs require much more than that. ... >>>>> As you point out "The largest constituency for JEPs is the people who >>>>> read them, not those who write or edit them." I think most people >>>>> (even those of us more comfortable with Emacs) can handle editing >>>>> in a web browser. >>>> Totally agree. >>> If we can?t enable markup mode in the JIRA field, then maybe the openjdk wiki is a better place than markdown files in a mercurial repository? >> >> Is there a reason why we can't/won't enable markup mode in the JIRA field? I am not clear on why we need markup if we are able to have fields. Most of the current markup is to distinguish sections and fields. > > I know we didn't enable markup mode on the fields that were used to store the info that was imported from the legacy bug system, but here we're talking about new fields. And, from the Atlassian documentation, it seems we should be able to configure the mode on a per-field basis... > > https://confluence.atlassian.com/display/JIRA/Configuring+Renderers >> Renderers are configured on a per field basis. To configure a renderer for a particular field, see Specifying Field Behavior . Note that you can configure the same field differently for different projects and issue types ? see Associating Field Behavior with Issue Types . > > -- Jon From jon.masamitsu at oracle.com Thu Apr 17 03:10:13 2014 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Wed, 16 Apr 2014 20:10:13 -0700 Subject: Draft proposal: JEP 2.0 In-Reply-To: <534F1DF4.2040708@oracle.com> References: <534D89AD.6030505@bothner.com> <534DA018.4080209@oracle.com> <534F1DF4.2040708@oracle.com> Message-ID: <534F4615.2060107@oracle.com> On 4/16/2014 5:19 PM, Jonathan Gibbons wrote: > > On 04/15/2014 02:09 PM, Jon Masamitsu wrote: >>> The JEP owner is expected to update the Alert Status on a weekly >>> basis once a JEP is Funded and active development work is under way. >>> If the Alert Status is Yellow or Red then the owner must use the >>> Alert Reason field to explain what is required to return the Status >>> to Green. This way everyone working on the release or otherwise >>> interested in the JEP can easily understand its current state. >> This sounds a lot like the status I have to report to my managers. >> Except that >> I talk to my manager about how things are going. This I have to >> compose and >> publish. Sorry but it's something that I'll easily forget to do. > > I think the point is that this will supersede some of the ad-hoc > infrastructure we currently use to track project progress, so this is > not something that you'll forget to do: it is simply a formalized > replacement of what you do today. It is just an "enum" > (green/yellow/red) and a text field. I doubt that folk are expecting > you to write an essay each week for the Alert Reason field. So you're saying that management will accept the updates to the JEP as the way of tracking progress on a project. That I like. Jon > > The good news is that by having the alert status in a system like > JIRA, we can do intelligent queries about work in progress to create > useful summary reports, rather than working with miscellaneous ad-hoc > infrastructure (i.e. wiki pages, uugh!) > > -- Jon From stefan.karlsson at oracle.com Thu Apr 17 05:43:12 2014 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Thu, 17 Apr 2014 07:43:12 +0200 Subject: Draft proposal: JEP 2.0 In-Reply-To: <56820AA2-3099-4A89-BDA4-2CEC2E064233@oracle.com> References: <534D89AD.6030505@bothner.com> <534E2DE1.1020002@oracle.com> <534E3D4A.6090401@oracle.com> <534F2AE9.4060107@oracle.com> <56820AA2-3099-4A89-BDA4-2CEC2E064233@oracle.com> Message-ID: <534F69F0.3030107@oracle.com> On 2014-04-17 04:03, Mike Duigou wrote: > On Apr 16 2014, at 18:14 , Jonathan Gibbons wrote: > >> On 04/16/2014 01:20 AM, Stefan Karlsson wrote: >>> On 2014-04-16 10:16, Staffan Larsen wrote: >>>> On 16 apr 2014, at 09:14, Bengt Rutisson wrote: >>>> >>>>> On 4/15/14 9:34 PM, Per Bothner wrote: >>>>>> [Sorry for the bad message linkage - I just subscribed.] >>>>>> >>>>>> On Apr 12 Mark Reinhold wrote: >>>>>> >>>>>>> - Some people, including yours truly, find any amount of non-trivial >>>>>>> text editing in a web browser to be extraordinarily painful. ... >>>>>>> - Incoming JEPs invariably require at least some light copy-editing. >>>>>>> Some JEPs require much more than that. ... >>>>>> As you point out "The largest constituency for JEPs is the people who >>>>>> read them, not those who write or edit them." I think most people >>>>>> (even those of us more comfortable with Emacs) can handle editing >>>>>> in a web browser. >>>>> Totally agree. >>>> If we can?t enable markup mode in the JIRA field, then maybe the openjdk wiki is a better place than markdown files in a mercurial repository? >>> Is there a reason why we can't/won't enable markup mode in the JIRA field? > I am not clear on why we need markup if we are able to have fields. Most of the current markup is to distinguish sections and fields. Maybe it's not going to be needed, but I got the impression from Mark's mail that we still we'll be maintaining documents outside JIRA, using Markdown: [1] "Now perhaps we can eventually customize JIRA and the systems around it to overcome these issues, but unless and until we do so I think we'll all be better served by continuing to create and maintain the bodies of JEPs as Markdown documents in Mercurial while tracking their workflow status and related tasks in JBS." I just don't want the lack of Markdown / markup mode to be the reason why we should be using separate documents outside JIRA. StefanK [1] http://mail.openjdk.java.net/pipermail/discuss/2014-April/003354.html > >> I know we didn't enable markup mode on the fields that were used to store the info that was imported from the legacy bug system, but here we're talking about new fields. And, from the Atlassian documentation, it seems we should be able to configure the mode on a per-field basis... >> >> https://confluence.atlassian.com/display/JIRA/Configuring+Renderers >>> Renderers are configured on a per field basis. To configure a renderer for a particular field, see Specifying Field Behavior . Note that you can configure the same field differently for different projects and issue types ? see Associating Field Behavior with Issue Types . >> -- Jon From mike.duigou at oracle.com Thu Apr 17 21:40:04 2014 From: mike.duigou at oracle.com (Mike Duigou) Date: Thu, 17 Apr 2014 14:40:04 -0700 Subject: Draft proposal: JEP 2.0 In-Reply-To: <20140412122823.131240@eggemoggin.niobe.net> References: <8C0D60E7-F0E5-4179-A37B-26AA95C862B5@oracle.com> <20140412122823.131240@eggemoggin.niobe.net> Message-ID: <9C9BC48F-1F9D-41A1-873F-A58234327FF6@oracle.com> On Apr 12 2014, at 12:28 , mark.reinhold at oracle.com wrote: > 2014/4/10 13:41 -0700, mike.duigou at oracle.com: >> Some comments. >> >> Tracking: >> >> - I'll add my voice to Bob's that we want only one system of record >> for JEPs and that should be JBS. JEPs are either managed entirely >> within JBS or we shouldn't bother with using JBS for JEPS at all. If >> we are going to go with the many-staged workflow described in the >> proposal then having JBS to manage that workflow would be a huge boon. > > I agree (obviously) that we should use JBS to implement the proposed new > workflow. As implied by my answer to Bob, though, I don't think that we > must choose one system over the other. > > What might not be clear in the current draft is that no workflow status > is ever recorded in a JEP document. You can draft a JEP, pass it around > in e-mail or put it on a wiki for initial review, and then once you > submit it for posting to the Mercurial archive it gets a JBS issue and > the workflow is tracked in JBS. > > In the current proposal some information is duplicated in both a JEP > document and its corresponding JBS issue, hence the need for automated > consistency checks. To simplify things perhaps we should move as much > information as possible from a JEP document into its JBS issue at the > time the issue is created. A "proto-JEP", then, would contain all the > headers mentioned in the proposal, but once it's posted and has a JBS > issue then the only header the document would absolutely need would be > the "Issue" header, to link it to the issue. (To make editing JEP > documents easier we might want to retain a couple of other headers, > e.g., "Title".) The rendering of a posted JEP document would then be > based upon information in both the Mercurial archive and JBS. > > Would you prefer this kind of approach? Very much so. I still question the value of the Mercurial > > (A related optimization would be to remove the "Impact" section from the > document once a JEP reaches the Funded state, since by then presumably > anyone impacted by the proposal will have been included in the JEP's > plan.) > >> - "Alert Status (updated weekly once Funded)". This seems onerous for >> projects that are green (or irredeemably yellow). Required >> increment-the-date weekly updates has been a significant annoyance for >> internal processes which I would prefer not to repeat with JEPs. > > I see what you mean about having to update the status weekly when a > feature is Green. If a feature is Yellow, though, then I don't think > it's unreasonable to ask for a weekly update, and making such an update > in JBS should take only a moment. (If a feature is irredeemably Yellow > then perhaps it shouldn't be in the Funded state, or any later state.) The "irredeemably yellow" condition is an expression of risk and has generally occurred after funding during the development when a feature uses up all of it's schedule slack and/or meeting the originally promised timelines becomes impossible. In most cases we should not fund features with non-green levels of risk but we do sometimes end up there. In the past we have done replans to keep a feature within the existing timelines but a higher degree of risk remains. In very few cases is a replan able to reduce the risk back to "full green". Perhaps something finer grained than Green-Yellow-Red to classify schedule risk might help. > How about "updated weekly if not Green, once Funded"? Sounds reasonable. The greater the remaining risk, the closer the monitoring. > >> Workflow: >> >> - The diagram unfortunately reminds me too much of a LHC "Higgs Boson >> detection event" graphic. Many of these states are overlapping and are >> worked coincidentally. Since only some of them are strictly gating can >> we collapse the softer states to a smaller number of strictly gating >> states? > > I'm all for eliminating needless states, but each one does serve a > distinct purpose, especially in terms of communicating the status of > work on a feature. It's true that some kinds of work are likely to > overlap -- just because a feature isn't yet Funded doesn't mean you > can't, e.g., do some prototyping work (which can arguably be part of > the Planning stage anyway). > > Do you have specific suggestions of states to collapse? I think I like Joe Darcy's suggestion of moving the terminal states (all of the closed states) to a separate categorization. >> General: >> >> - The JEP process doesn't feel very approachable to an outsider/first >> time submitter. Either we have to provide a lot more guidance about >> how to fill out a JEP and/or make the process simpler. ... > > I agree that we could do better here. Improving in this way would help > submitters and it would also reduce the workload of those of us who edit > incoming JEPs. Perhaps we should use our wiki to collect a list of FAQ > items and, once it settles, publish it as an informational JEP? I think that would be very helpful and I am encouraged to see interest in this particular concern from the AdoptOpenJDK folks. The amount of interest and enthusiasm in your proposal from the wider community is also encouraging! Moving forward! Mike From karen.kinnear at oracle.com Fri Apr 18 19:34:18 2014 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Fri, 18 Apr 2014 15:34:18 -0400 Subject: Draft proposal: JEP 2.0 In-Reply-To: <20140408135412.415597@eggemoggin.niobe.net> References: <20140408135412.415597@eggemoggin.niobe.net> Message-ID: <2A59EA4E-1A33-437F-A4AD-AB43FC9E31C2@oracle.com> A couple of questions on the JEP workflow. 1) Before "Integrated" could we add a "Validated" state? It is probably already assumed that prior to Integrated, that a JEP's owner is required to have the code pass unit tests as well as system tests. Would there be value in calling out a separate state here, such as "Validated"? This could be of help in ensuring that unit tests are ready and pass before code gets integrated. It might also be of extra help for folks who need assistance in running any system tests. 2) Funded Could you possibly add performance testing to the funded detail list? I know the current statement is not intended to be exhaustive, but it might be helpful to explicitly add performance. thanks, Karen On Apr 8, 2014, at 4:54 PM, mark.reinhold at oracle.com wrote: > The JEP Process [1] has served us well as a way to document proposed > enhancements to the JDK. The process does not, however, say how we > decide to target a JEP to a particular JDK Release Project, nor does > it help track the work subsequently done on a JEP. We also don't have > a documented process by which we can create and maintain the overall > schedule of a Release Project. > > To fill these gaps I've drafted an extension of the JEP Process which > covers the planning of Release Projects, the tracking of the work done > for their Feature JEPs, and the tracking of work done for other kinds > of JEPs that are not associated with specific releases. The current > draft of the proposal is here: > > http://cr.openjdk.java.net/~mr/jep/jep-2.0.html > > The proposal suggests, among other things, that we create a new "JEP" > issue type in the JBS JIRA system so that it's easy to see the status > of a particular JEP as well as the overall status of an entire Release > Project. > > This draft has been reviewed by a handful of people so far. My thanks > to Mathias Axelsson, Brian Beck, Iris Clark, Joe Darcy, Brian Goetz, > Georges Saab, and Dalibor Topic for their feedback. > > If you have comments or suggestions on this draft, please send them in > a public reply to this message by Monday, 21 April 2011. I'd like to > put this new process in place shortly thereafter. > > - Mark > > > [1] http://openjdk.java.net/jeps/ From brian.beck at oracle.com Mon Apr 21 18:15:47 2014 From: brian.beck at oracle.com (Brian Beck) Date: Mon, 21 Apr 2014 11:15:47 -0700 Subject: Draft proposal: JEP 2.0 In-Reply-To: <534F2AE9.4060107@oracle.com> References: <534D89AD.6030505@bothner.com> <534E2DE1.1020002@oracle.com> <534E3D4A.6090401@oracle.com> <534F2AE9.4060107@oracle.com> Message-ID: <53556053.1020209@oracle.com> On 4/16/14 6:14 PM, Jonathan Gibbons wrote: > >> Is there a reason why we can't/won't enable markup mode in the JIRA >> field? > > I know we didn't enable markup mode on the fields that were used to > store the info that was imported from the legacy bug system, but here > we're talking about new fields. And, from the Atlassian > documentation, it seems we should be able to configure the mode on a > per-field basis... Enabling wiki markup for bugs & enhancements caused too much chaos with all the legacy data. We tried to figure out ways to selectively turn it off but never succeeded. Wiki markup is an often requested feature however. Our (Infra team's) thought is to turn it on for any new issue type or new field that doesn't have a boat load of legacy data to confuse. We've got it turned on in the JEP prototype with good results so far. Brian. > > https://confluence.atlassian.com/display/JIRA/Configuring+Renderers >> Renderers are configured on a per field basis. To configure a >> renderer for a particular field, see Specifying Field Behavior >> . >> Note that you can configure the same field differently for different >> projects and issue types ? see Associating Field Behavior with Issue >> Types >> . > > -- Jon > > > >> >> StefanK >> >>> >>> I assume that the goal is for the text of the JEPs to be living >>> updated document that would change as a JEP is taken from the >>> initial idea into a deliverable feature. If that is the case, then >>> it is absolutely necessary that the text be easy to update by the >>> author or it will be just another dead document. >>> >>> /Staffan >>> >>> >>>> One more comment further down. >>>> >>>>>> JIRA, unfortunately, does not do a >>>>>> very good job of displaying large bodies of structured text. >>>>> Actually, JIRA supports rich text tolerably well - about as well >>>>> as the Markdown use by JEP (thought it doesn't have the "escape to >>>>> HTML" fall-back). Of course they use their own idiosyncratic >>>>> markup format, which matches the Confluence wiki engine. Any text >>>>> field can be configured to the use the "Wiki Style Renderer": >>>>> >>>>> https://confluence.atlassian.com/display/JIRA/Configuring+Renderers >>>>> https://jira.atlassian.com/secure/WikiRendererHelpAction.jspa >>>>> >>>>> The result is quite readable, and looks decent enough. >>>>> >>>>> (There are plugins to use Markdown, but I don't believe any is >>>>> supported by Atlassian, so I think its more simple and robust to >>>>> stick >>>>> with the native markup format.) >>>>> >>>>>> It's certainly possible to encode a long-form text document into >>>>>> some text fields in a JIRA issue, but the result is far from >>>>>> easy >>>>>> to read, never mind actually attractive. >>>>> One could use a separate JIRA field for each JEP section, or just put >>>>> it all in the Description field and use headings to mark the >>>>> sections. >>>>> It's not clear which is better. >>>>> >>>>>> - JIRA's history display is fairly primitive, showing just the new >>>>>> and old values for each field modified in a particular >>>>>> transaction. >>>>>> To comprehend the changes to a long document over time you >>>>>> really >>>>>> need something more like an actual diff. >>>>> Yes, JIRA isn't very diff-friendly nor very friendly to the kind of >>>>> workflow we're used to from Mercurial, including patches. >>>> True, but note that the proposal is already suggesting that the >>>> "static" parts of a JEP should be in the Mercurial repository and >>>> that the "dynamic" part should be in JIRA. So, even with the >>>> current proposal we will be using JIRA for the tracking information >>>> that is changing the most. Thus, I don't think that saying that >>>> Mercurial is better at tracking changes is much of an argument for >>>> keeping part of the JEP there. >>>> >>>> I think we need to decide to either have the full JEP in Mercurial >>>> or in JIRA. Having it in both places just does not make sense. >>>> >>>> Bengt >>>>> I wrote some experimental tools in this area. The idea is to use >>>>> JIRA's REST interface, which allows you to extract the fields of an >>>>> issue in a JSON representation - as well as optionally update them. >>>>> I wrote a filter to convert to and from what I call "pretty JSON", >>>>> which does line-breaking, indentation, removes the redundant commas, >>>>> and quotes around field names. This format is much more >>>>> diff-friendly - as well as friendlier to human readers and >>>>> editors. Our goal was to version-control JIRA configuration >>>>> information, as well as copy information from one JIRA instance to >>>>> another. It seems we could >>>>> modify these command-line tools could to make it more pleasant to >>>>> diff >>>>> (or even patch) JEP issues. >> From per at bothner.com Mon Apr 21 19:08:51 2014 From: per at bothner.com (Per Bothner) Date: Mon, 21 Apr 2014 12:08:51 -0700 Subject: Draft proposal: JEP 2.0 In-Reply-To: <53556053.1020209@oracle.com> References: <534D89AD.6030505@bothner.com> <534E2DE1.1020002@oracle.com> <534E3D4A.6090401@oracle.com> <534F2AE9.4060107@oracle.com> <53556053.1020209@oracle.com> Message-ID: <53556CC3.6040103@bothner.com> On 04/21/2014 11:15 AM, Brian Beck wrote: > Enabling wiki markup for bugs & enhancements caused too much chaos with > all the legacy data. We tried to figure out ways to selectively turn it > off but never succeeded. Wiki markup is an often requested feature > however. Our (Infra team's) thought is to turn it on for any new issue > type or new field that doesn't have a boat load of legacy data to > confuse. It might be possible to possible to turn on Wiki markup *and* at the same time convert all the existing issues so they render more-or-less as they did before Wiki markup. For example wrap each paragraph in a {noformat}...{noformat} block. One could use the REST API to do a bulk update. Of course some experimentation would be needed to find the best conversion. The problem is it's hard to know the intent of the plain text, so something like using {noformat} is probably safest. [Aside: Using the same delimiter as both the start and end of multi-line marked block is clearly a pretty bad design blunder, but that's what JIRA does.] -- --Per Bothner per at bothner.com http://per.bothner.com/ From John.Coomes at oracle.com Mon Apr 21 23:46:12 2014 From: John.Coomes at oracle.com (John Coomes) Date: Mon, 21 Apr 2014 16:46:12 -0700 Subject: Draft proposal: JEP 2.0 In-Reply-To: <20140412122804.210238@eggemoggin.niobe.net> References: <20140408140825.43296@eggemoggin.niobe.net> <20140412122804.210238@eggemoggin.niobe.net> Message-ID: <21333.44484.157091.199374@mykonos.us.oracle.com> mark.reinhold at oracle.com wrote: > 2014/4/9 2:41 -0700, bob.vandette at oracle.com: > > I like the idea of using JIRA for the JEP process but ... > > > > Why are you proposing to continue supporting some of the JEP content > > in Mercurial form rather than using the description field in JBS and > > providing a template for this area of the JIRA entry? We've done this > > successfully for internal project tracking. > > The short answer: JEPs are structured, long-form documents, and JIRA is > not an effective tool for creating, editing, curating, and presenting a > collection of such documents. > > The longer answer: > > - Some people, including yours truly, find any amount of non-trivial > text editing in a web browser to be extraordinarily painful. Maybe > it's just me, but if I can't edit something in Emacs then it just > isn't real. (Yes, you can cut and paste individual text areas back > and forth, but that's too tedious to bear.) > > - Incoming JEPs invariably require at least some light copy-editing. > Some JEPs require much more than that. I'm not going to do all that > work in a web browser, nor am I going to ask anyone else to do so. I'm a long-time emacs user--even this email was written in emacs--yet despite my strong preference, I think the disadvantages of splitting JEPs across two management systems outweigh benefits like easier editing or clear diffs. If JEPS are split, we immediately run into consistency problems. In a follow-up on this thread, you mentioned eliminating almost all duplicate headers, except the issue, title and a few others, and implementing consistency checks. But every field that is duplicated would need a rule about how and where it can be changed. What if I want to change the Title? Do I do that in JBS, mercurial, or both? What if I change the issue in the mercurial document? How can the system automatically verify that the new issue is correct (or not)? I'd really rather not have to define and explain all the special cases; each one is another burden on JEP authors and maintainers, especially newcomers. As is the need to know two methods to update the different parts of a JEP. Also, I think any effort spent automating the consistency checks would be better spent customizing JIRA. > - The largest constituency for JEPs is the people who read them, not > those who write or edit them. JIRA, unfortunately, does not do a > very good job of displaying large bodies of structured text. It's > certainly possible to encode a long-form text document into some > text fields in a JIRA issue, but the result is far from easy to > read, never mind actually attractive. If the JIRA display does end up being that ungainly, then a read-only view (accessed via REST) could be made that extracts the necessary data from the JIRA db and formats it nicely. I wouldn't find that necessary, certainly not initially. It might be worth exploring, though, since we could then better separate content from formatting. > - JIRA's history display is fairly primitive, showing just the new > and old values for each field modified in a particular transaction. > To comprehend the changes to a long document over time you really > need something more like an actual diff. If JEPs are split, it will be extremely tedious to get a history of the entire JEP (both issue and document), or to correlate events across the two systems. I'd have to cut and paste JIRA history and mercurial history (into emacs :-)) and manually compare. I'd much prefer a single system for anything like that, and would be willing to cut-n-paste to/from emacs to avoid it. If truly needed, we should customize Jira to display better diffs for JEP fields. But I can certainly live with what's there. > Now perhaps we can eventually customize JIRA and the systems around it > to overcome these issues, but unless and until we do so I think we'll > all be better served by continuing to create and maintain the bodies of > JEPs as Markdown documents in Mercurial while tracking their workflow > status and related tasks in JBS. If we split JEPS, then once we do get JIRA customized, it will require "JEP 3.0" (a significant process change) to move everything into JIRA. I'd much rather have JEP 2.0 move everything into JIRA now so we get a consistent, if not necessarily pretty, view of JEPs. Then the beautification & ease of use can be done over time, without changing the process. -John From david.holmes at oracle.com Wed Apr 23 09:28:20 2014 From: david.holmes at oracle.com (David Holmes) Date: Wed, 23 Apr 2014 19:28:20 +1000 Subject: CFV: New Project: Device I/O In-Reply-To: References: Message-ID: <535787B4.50206@oracle.com> Vote: yes David On 23/04/2014 3:17 AM, Bob Vandette wrote: > I hereby propose the creation of the Device I/O Project with > myself (Bob Vandette) as the Lead and the Core Libraries Group > as the sponsoring group. > > The Device I/O Project would implement a generic device peripheral > access API for Java applications running on embedded devices, > providing APIs for common peripheral devices currently found > in embedded platforms such as GPIO, I2C, SPI, UART, USB and others. > > Currently, developers are forced into writing JNI code in order > to access these elements. We intend to provide a Java level API > for developers to use instead and to keep the public API consistent > across Java SE and Java ME, although this Project will initially > only support Java SE. > > I have been in Oracle's Java SE Organization for over 15 years and have > been Oracle's Java SE Embedded Lead for the last 9 years. > > The initial Reviewers and Committers suggested here are made up of > representatives from Oracle's Java SE Embedded and Java ME development > teams. > > The initial Reviewers will be Jen Dority, Riaz Aimandi, Alexey Konstantinov, > Thierry Violleau and Jens P?tzold. > > The initial Committers will be: Andrey Petushkov, Petr Panteleyev, > Sergey Nazarkin, Vladimir Danushevsky, Derek White, Gary Collins, > Pavel Safrata, Kinsley Wong, Bill Pittore, Dean Long and Lubomir Nerad. > > Votes are due by 6th May 2014 10:00 PM Eastern US Time > (7th May 2014 02:00 GMT) > > Only current OpenJDK Members [1] 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 [2]. > > [1] http://openjdk.java.net/census#members > [2] http://openjdk.java.net/projects/#new-project-vote > From biboudis at gmail.com Wed Apr 23 17:15:59 2014 From: biboudis at gmail.com (Aggelos Biboudis) Date: Wed, 23 Apr 2014 20:15:59 +0300 Subject: Hello from a new member Message-ID: Hello all! I had my OCA processed recently (to submit a small patch to JMH) and I would like to introduce myself. I am Aggelos Biboudis from Greece doing my PhD in Programming Languages, at the University of Athens. My research interests are compilers and (modular) metaprogramming facilities, so for the past few months I am intensively exploring javac / jvm internals. Hopefully, I will also be able to assist you on bug fixes, as well. Kind regards, Aggelos Biboudis @biboudis | homepage From martijnverburg at gmail.com Wed Apr 23 19:09:05 2014 From: martijnverburg at gmail.com (Martijn Verburg) Date: Wed, 23 Apr 2014 20:09:05 +0100 Subject: Hello from a new member In-Reply-To: References: Message-ID: Hi Aggelos, Welcome to OpenJDK, we hope you enjoy your time in the community! Cheers, Martijn On 23 April 2014 18:15, Aggelos Biboudis wrote: > Hello all! > > I had my OCA processed recently (to submit a small patch to JMH) and I > would like to introduce myself. I am Aggelos Biboudis from Greece doing my > PhD in Programming Languages, at the University of Athens. > > My research interests are compilers and (modular) metaprogramming > facilities, so for the past few months I am intensively exploring javac / > jvm internals. Hopefully, I will also be able to assist you on bug fixes, > as well. > > Kind regards, > Aggelos Biboudis > > @biboudis | > homepage > From kmcguigan at twitter.com Thu Apr 24 14:08:07 2014 From: kmcguigan at twitter.com (Keith McGuigan) Date: Thu, 24 Apr 2014 10:08:07 -0400 Subject: Anyone doing public/private customized distributions based on OpenJDK sources? Message-ID: (Apologies if I sent this twice, I don't think my last one went through) Hello, I was wondering if anyone on this list does or knows of someone who puts together their own JRE/JDK distribution based upon the OpenJDK sources, but not a pure OpenJDK implementation. We do something like this at Twitter as a staging ground to try stuff out locally before trying to "upstream" our work to the open. I'd be very interested in getting together with any such people to discuss development strategies to see what works in these hybrid cases (such as repository management, submitting upstream code changes, maintenance, etc.). Thanks for any pointers or references! -- - Keith @kamggg kmcguigan at twitter.com From roger.riggs at oracle.com Thu Apr 24 20:22:37 2014 From: roger.riggs at oracle.com (roger riggs) Date: Thu, 24 Apr 2014 16:22:37 -0400 Subject: Project Proposal: Device I/O In-Reply-To: References: Message-ID: <5359728D.7010403@oracle.com> Vote: Yes On 4/8/2014 5:31 PM, Bob Vandette wrote: > I'd like to discuss the creation of the Device I/O Project with myself (Bob Vandette) as the Lead and the Core Libraries Group as the sponsoring group. > > The Device I/O Project would implement a generic device peripheral access API for Java applications running on embedded devices, providing APIs for common peripheral devices currently found in in embedded platforms such as GPIO, I2C, SPI, UART, USB and others. > > From karen.kinnear at oracle.com Thu Apr 24 20:25:00 2014 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Thu, 24 Apr 2014 16:25:00 -0400 Subject: CFV: New Project: Device I/O In-Reply-To: References: Message-ID: <96B5E737-5D9E-40D6-856A-F589E1907D65@oracle.com> vote: yes On Apr 22, 2014, at 1:17 PM, Bob Vandette wrote: > I hereby propose the creation of the Device I/O Project with > myself (Bob Vandette) as the Lead and the Core Libraries Group > as the sponsoring group. > > The Device I/O Project would implement a generic device peripheral > access API for Java applications running on embedded devices, > providing APIs for common peripheral devices currently found > in embedded platforms such as GPIO, I2C, SPI, UART, USB and others. > > Currently, developers are forced into writing JNI code in order > to access these elements. We intend to provide a Java level API > for developers to use instead and to keep the public API consistent > across Java SE and Java ME, although this Project will initially > only support Java SE. > > I have been in Oracle's Java SE Organization for over 15 years and have > been Oracle's Java SE Embedded Lead for the last 9 years. > > The initial Reviewers and Committers suggested here are made up of > representatives from Oracle's Java SE Embedded and Java ME development > teams. > > The initial Reviewers will be Jen Dority, Riaz Aimandi, Alexey Konstantinov, > Thierry Violleau and Jens P?tzold. > > The initial Committers will be: Andrey Petushkov, Petr Panteleyev, > Sergey Nazarkin, Vladimir Danushevsky, Derek White, Gary Collins, > Pavel Safrata, Kinsley Wong, Bill Pittore, Dean Long and Lubomir Nerad. > > Votes are due by 6th May 2014 10:00 PM Eastern US Time > (7th May 2014 02:00 GMT) > > Only current OpenJDK Members [1] 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 [2]. > > [1] http://openjdk.java.net/census#members > [2] http://openjdk.java.net/projects/#new-project-vote From jonathan.gibbons at oracle.com Thu Apr 24 20:29:44 2014 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 24 Apr 2014 13:29:44 -0700 Subject: CFV: New Project: Device I/O In-Reply-To: References: Message-ID: <53597438.5090602@oracle.com> Vote: yes On 04/22/2014 10:17 AM, Bob Vandette wrote: > I hereby propose the creation of the Device I/O Project with > myself (Bob Vandette) as the Lead and the Core Libraries Group > as the sponsoring group. > > The Device I/O Project would implement a generic device peripheral > access API for Java applications running on embedded devices, > providing APIs for common peripheral devices currently found > in embedded platforms such as GPIO, I2C, SPI, UART, USB and others. > > Currently, developers are forced into writing JNI code in order > to access these elements. We intend to provide a Java level API > for developers to use instead and to keep the public API consistent > across Java SE and Java ME, although this Project will initially > only support Java SE. > > I have been in Oracle's Java SE Organization for over 15 years and have > been Oracle's Java SE Embedded Lead for the last 9 years. > > The initial Reviewers and Committers suggested here are made up of > representatives from Oracle's Java SE Embedded and Java ME development > teams. > > The initial Reviewers will be Jen Dority, Riaz Aimandi, Alexey Konstantinov, > Thierry Violleau and Jens P?tzold. > > The initial Committers will be: Andrey Petushkov, Petr Panteleyev, > Sergey Nazarkin, Vladimir Danushevsky, Derek White, Gary Collins, > Pavel Safrata, Kinsley Wong, Bill Pittore, Dean Long and Lubomir Nerad. > > Votes are due by 6th May 2014 10:00 PM Eastern US Time > (7th May 2014 02:00 GMT) > > Only current OpenJDK Members [1] 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 [2]. > > [1] http://openjdk.java.net/census#members > [2] http://openjdk.java.net/projects/#new-project-vote From Alan.Bateman at oracle.com Fri Apr 25 06:51:24 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 25 Apr 2014 07:51:24 +0100 Subject: CFV: New Project: Device I/O In-Reply-To: References: Message-ID: <535A05EC.9030809@oracle.com> Vote: yes From neugens.limasoftware at gmail.com Fri Apr 25 07:06:03 2014 From: neugens.limasoftware at gmail.com (Mario Torre) Date: Fri, 25 Apr 2014 09:06:03 +0200 Subject: CFV: New Project: Device I/O In-Reply-To: References: Message-ID: Vote: Yes, Cheers, Mario 2014-04-22 19:17 GMT+02:00 Bob Vandette : > I hereby propose the creation of the Device I/O Project with > myself (Bob Vandette) as the Lead and the Core Libraries Group > as the sponsoring group. > > The Device I/O Project would implement a generic device peripheral > access API for Java applications running on embedded devices, > providing APIs for common peripheral devices currently found > in embedded platforms such as GPIO, I2C, SPI, UART, USB and others. > > Currently, developers are forced into writing JNI code in order > to access these elements. We intend to provide a Java level API > for developers to use instead and to keep the public API consistent > across Java SE and Java ME, although this Project will initially > only support Java SE. > > I have been in Oracle's Java SE Organization for over 15 years and have > been Oracle's Java SE Embedded Lead for the last 9 years. > > The initial Reviewers and Committers suggested here are made up of > representatives from Oracle's Java SE Embedded and Java ME development > teams. > > The initial Reviewers will be Jen Dority, Riaz Aimandi, Alexey Konstantinov, > Thierry Violleau and Jens P?tzold. > > The initial Committers will be: Andrey Petushkov, Petr Panteleyev, > Sergey Nazarkin, Vladimir Danushevsky, Derek White, Gary Collins, > Pavel Safrata, Kinsley Wong, Bill Pittore, Dean Long and Lubomir Nerad. > > Votes are due by 6th May 2014 10:00 PM Eastern US Time > (7th May 2014 02:00 GMT) > > Only current OpenJDK Members [1] 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 [2]. > > [1] http://openjdk.java.net/census#members > [2] http://openjdk.java.net/projects/#new-project-vote -- pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF Blog: http://neugens.wordpress.com - Twitter: @neugens Proud GNU Classpath developer: http://www.classpath.org/ Read About us at: http://planet.classpath.org OpenJDK: http://openjdk.java.net/projects/caciocavallo/ Please, support open standards: http://endsoftpatents.org/ From dmitry.samersoff at oracle.com Fri Apr 25 08:12:18 2014 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Fri, 25 Apr 2014 12:12:18 +0400 Subject: Anyone doing public/private customized distributions based on OpenJDK sources? In-Reply-To: References: Message-ID: <535A18E2.1000203@oracle.com> Keith, (* CC'in Greg Lewis *) BSD port process might be close to what you need. -Dmitry On 2014-04-24 18:08, Keith McGuigan wrote: > (Apologies if I sent this twice, I don't think my last one went through) > > Hello, > > I was wondering if anyone on this list does or knows of someone who puts > together their own JRE/JDK distribution based upon the OpenJDK sources, but > not a pure OpenJDK implementation. > > We do something like this at Twitter as a staging ground to try stuff out > locally before trying to "upstream" our work to the open. > > I'd be very interested in getting together with any such people to discuss > development strategies to see what works in these hybrid cases (such as > repository management, submitting upstream code changes, maintenance, etc.). > > Thanks for any pointers or references! > > -- > - Keith > > @kamggg > kmcguigan at twitter.com > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From jaroslav.bachorik at oracle.com Fri Apr 25 11:27:08 2014 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Fri, 25 Apr 2014 13:27:08 +0200 Subject: CFV: New Project: Device I/O In-Reply-To: References: Message-ID: <535A468C.9090605@oracle.com> Vote: Yes -JB- From martinrb at google.com Fri Apr 25 16:44:59 2014 From: martinrb at google.com (Martin Buchholz) Date: Fri, 25 Apr 2014 09:44:59 -0700 Subject: Anyone doing public/private customized distributions based on OpenJDK sources? In-Reply-To: <535A18E2.1000203@oracle.com> References: <535A18E2.1000203@oracle.com> Message-ID: JVMLS 2013: OpenJDK at Google http://medianetwork.oracle.com/video/player/2630310903001 On Fri, Apr 25, 2014 at 1:12 AM, Dmitry Samersoff < dmitry.samersoff at oracle.com> wrote: > Keith, > > (* CC'in Greg Lewis *) > > BSD port process might be close to what you need. > > -Dmitry > > > On 2014-04-24 18:08, Keith McGuigan wrote: > > (Apologies if I sent this twice, I don't think my last one went through) > > > > Hello, > > > > I was wondering if anyone on this list does or knows of someone who puts > > together their own JRE/JDK distribution based upon the OpenJDK sources, > but > > not a pure OpenJDK implementation. > > > > We do something like this at Twitter as a staging ground to try stuff out > > locally before trying to "upstream" our work to the open. > > > > I'd be very interested in getting together with any such people to > discuss > > development strategies to see what works in these hybrid cases (such as > > repository management, submitting upstream code changes, maintenance, > etc.). > > > > Thanks for any pointers or references! > > > > -- > > - Keith > > > > @kamggg > > kmcguigan at twitter.com > > > > > -- > Dmitry Samersoff > Oracle Java development team, Saint Petersburg, Russia > * I would love to change the world, but they won't give me the sources. > From simonsharry at gmail.com Sun Apr 27 08:55:39 2014 From: simonsharry at gmail.com (Harry Simons) Date: Sun, 27 Apr 2014 14:25:39 +0530 Subject: Unit tests for OpenJDK? Message-ID: Hi, I downloaded OpenJDK 7u40 source bundle, and was expecting to find in it tons and tons of unit tests for, well, at least all public methods of all of its public classes. However, under the openjdk/jdk/test/ directory of the downloaded bundle, are sitting merely *regression* tests -- or, tests created for *specific* bugs. I'd like to know if OpenJDK comes with its unit tests or not? And, if yes, where can I find them? If not, why are they not being shared openly. Context: I'm writing a custom file system using the Java NIO2 API. To test it fully, I'd like to ensure that it at least passes the unit tests of the JDK itself. Right now, I don't know what all tests to create, even the so-called corner cases appear to be huge in number! Regards, /HS From aph at redhat.com Sun Apr 27 09:00:32 2014 From: aph at redhat.com (Andrew Haley) Date: Sun, 27 Apr 2014 10:00:32 +0100 Subject: Unit tests for OpenJDK? In-Reply-To: References: Message-ID: <535CC730.2050705@redhat.com> On 04/27/2014 09:55 AM, Harry Simons wrote: > I downloaded OpenJDK 7u40 source bundle, and was expecting to find in it > tons and tons of unit tests for, well, at least all public methods of all > of its public classes. > > However, under the openjdk/jdk/test/ directory of the downloaded bundle, > are sitting merely *regression* tests -- or, tests created for *specific* > bugs. > > I'd like to know if OpenJDK comes with its unit tests or not? And, if yes, > where can I find them? If not, why are they not being shared openly. Because the JCK is shipped separately. http://openjdk.java.net/groups/conformance/JckAccess/ Andrew. From Alan.Bateman at oracle.com Sun Apr 27 10:15:42 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 27 Apr 2014 11:15:42 +0100 Subject: Unit tests for OpenJDK? In-Reply-To: References: Message-ID: <535CD8CE.9020404@oracle.com> On 27/04/2014 09:55, Harry Simons wrote: > Hi, > > I downloaded OpenJDK 7u40 source bundle, and was expecting to find in it > tons and tons of unit tests for, well, at least all public methods of all > of its public classes. > > However, under the openjdk/jdk/test/ directory of the downloaded bundle, > are sitting merely *regression* tests -- or, tests created for *specific* > bugs. > > I'd like to know if OpenJDK comes with its unit tests or not? And, if yes, > where can I find them? If not, why are they not being shared openly. > Context: I'm writing a custom file system using the Java NIO2 API. To test > it fully, I'd like to ensure that it at least passes the unit tests of the > JDK itself. Right now, I don't know what all tests to create, even the > so-called corner cases appear to be huge in number! > The test tree can be difficult to grok when you initially approach it but at a high level it has a mix of unit, regression, stress and other tests. For historical reasons that pre-date OpenJDK, the percentage, quality and coverage of each type depends wildly on the area. For older areas of the platform then you might not find much that resembles a traditional unit test. The reason for this is that development in those areas at the time mostly relied on other test suites (JCK for conformance tests, unit and functional test suites that resided elsewhere, these are test suites are not in OpenJDK). In more recent time it has become practice to push the tests for new features and new APIs with the feature/API itself. So you should see that newer areas do have a lot more unit tests. They might not be unit tests in the style of JUnit or TestNG tests that you might expect and it does takes a bit of getting used to the jtreg test runner. As to the number of regression tests for bugs then this is just the long standing rule that all bug fixes should come with test coverage unless there is a good reason not to. In some areas then bug fixes drive improvements and better test coverage to existing tests, in order areas then tests are just added to exercise the specific issue. So definitely a lot of inconsistency to baffle new people. Stuart Marks and I recorded a couple of sessions on the OpenJDK tests some time ago that I think on are YouTube if you can find them. As regards the tests for the NIO file system area then then you are in jdk/test/java/nio/file. They are 12k+ lines of test code that provide reasonable coverage on all platforms. They pre-date the use of TestNG in OpenJDK so might not be initially obvious how you run, that just takes getting used to. That said, those tests are focused on the default/platform file system, they are not tests that will help much with a custom file system provider. You'll see the zip provider that we have in the JDK has its own tests. The reason for this is that you quickly get into specifies when testing a custom provider (the syntax of file paths is specific to the file system provider for example). This is a topic to bring up on nio-dev where there are others working on other file system providers. There might be opportunities to collaborate or contribute tests for example. -Alan. From simonsharry at gmail.com Sun Apr 27 10:17:32 2014 From: simonsharry at gmail.com (Harry Simons) Date: Sun, 27 Apr 2014 15:47:32 +0530 Subject: Unit tests for OpenJDK? In-Reply-To: <535CC730.2050705@redhat.com> References: <535CC730.2050705@redhat.com> Message-ID: Thanks for your response. Looks like, without a formal form-submission and form-approval process I will not be given JCK. May I ask the members in the community that without free and easy access to JCK to one and all, how on earth could an applications developer (like myself) possibly ever finish writing (complete with unit testing!) a custom file-system based on the FileSystemProvider API which Java itself provides? If not the full JCK, I think the powers-that-be should provide to all application developers, freely and easily, at least a subset of the JCK that covers nontrivial API such as FileSystemProvider! Wonder, how other developers like myself would handle this situation. On Sun, Apr 27, 2014 at 2:30 PM, Andrew Haley wrote: > On 04/27/2014 09:55 AM, Harry Simons wrote: > > > I downloaded OpenJDK 7u40 source bundle, and was expecting to find in it > > tons and tons of unit tests for, well, at least all public methods of all > > of its public classes. > > > > However, under the openjdk/jdk/test/ directory of the downloaded bundle, > > are sitting merely *regression* tests -- or, tests created for *specific* > > bugs. > > > > I'd like to know if OpenJDK comes with its unit tests or not? And, if > yes, > > where can I find them? If not, why are they not being shared openly. > > Because the JCK is shipped separately. > > http://openjdk.java.net/groups/conformance/JckAccess/ > > Andrew. > > From neugens.limasoftware at gmail.com Sun Apr 27 12:10:15 2014 From: neugens.limasoftware at gmail.com (Mario Torre) Date: Sun, 27 Apr 2014 14:10:15 +0200 Subject: Unit tests for OpenJDK? In-Reply-To: References: <535CC730.2050705@redhat.com> Message-ID: Hi Harry, The JCK is a bit funny, you can have access to it, but how I let other to say :) and yes, its a complicated process. Some test are in the JDK tree, but you may find helpful to run non official test suites like mauve. Interestingly, the winehq page seems to do a better job than the OpenJDK wiki in listing the options: http://wiki.winehq.org/JavaTestSuite Mauve covers a lot of areas very well, I believe the filesystem is one of those. Of course, I totally understand your pain, we have the same problem, and the only way to be 100% is to apply for the JCK. Cheers, Mario Il 27/apr/2014 12:18 "Harry Simons" ha scritto: > Thanks for your response. > > Looks like, without a formal form-submission and form-approval process I > will not be given JCK. > > May I ask the members in the community that without free and easy access to > JCK to one and all, how on earth could an applications developer (like > myself) possibly ever finish writing (complete with unit testing!) a custom > file-system based on the FileSystemProvider API which Java itself provides? > > If not the full JCK, I think the powers-that-be should provide to all > application developers, freely and easily, at least a subset of the JCK > that covers nontrivial API such as FileSystemProvider! > > Wonder, how other developers like myself would handle this situation. > > > On Sun, Apr 27, 2014 at 2:30 PM, Andrew Haley wrote: > > > On 04/27/2014 09:55 AM, Harry Simons wrote: > > > > > I downloaded OpenJDK 7u40 source bundle, and was expecting to find in > it > > > tons and tons of unit tests for, well, at least all public methods of > all > > > of its public classes. > > > > > > However, under the openjdk/jdk/test/ directory of the downloaded > bundle, > > > are sitting merely *regression* tests -- or, tests created for > *specific* > > > bugs. > > > > > > I'd like to know if OpenJDK comes with its unit tests or not? And, if > > yes, > > > where can I find them? If not, why are they not being shared openly. > > > > Because the JCK is shipped separately. > > > > http://openjdk.java.net/groups/conformance/JckAccess/ > > > > Andrew. > > > > > From Alan.Bateman at oracle.com Sun Apr 27 19:30:14 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 27 Apr 2014 20:30:14 +0100 Subject: Unit tests for OpenJDK? In-Reply-To: References: <535CC730.2050705@redhat.com> Message-ID: <535D5AC6.1060707@oracle.com> On 27/04/2014 11:17, Harry Simons wrote: > : > > If not the full JCK, I think the powers-that-be should provide to all > application developers, freely and easily, at least a subset of the JCK > that covers nontrivial API such as FileSystemProvider! > I don't think the JCK is exactly what you are looking for. In other to properly test a custom file system provider then the test suite needs to know about its URI scheme and syntax, file path syntax, at least something about its capabilities and features, and often other details related to configuration and setup. If your file system provider replaces or interposes on the default provider then the tests in the jdk repository will exercise it. If your file system provider is very different then I think you will need to write tests, this is why we created separate tests for the zip provider for example. As I suggested in previous, there might be an opportunity to hook up with others that are developing their own file system implementations and maybe something could come of this that would be useful to others. -Alan. From simonsharry at gmail.com Mon Apr 28 04:04:38 2014 From: simonsharry at gmail.com (Harry Simons) Date: Mon, 28 Apr 2014 09:34:38 +0530 Subject: Unit tests for OpenJDK? In-Reply-To: <535D5AC6.1060707@oracle.com> References: <535CC730.2050705@redhat.com> <535D5AC6.1060707@oracle.com> Message-ID: Alan, I agree fully that I wouldn't be able to reuse the JCK tests -- verbatim -- for such a thing as a custom file-system. For this, I was thinking of editing small parts of the "OpenJDK tests" (e.g., changing the filesystem scheme in the test code from "file:/" or "zip:/" to "myScheme:/") but reusing almost everything else. Thanks for both your responses, esp the first one. Regards, /HS On Mon, Apr 28, 2014 at 1:00 AM, Alan Bateman wrote: > On 27/04/2014 11:17, Harry Simons wrote: > >> : >> >> >> If not the full JCK, I think the powers-that-be should provide to all >> application developers, freely and easily, at least a subset of the JCK >> that covers nontrivial API such as FileSystemProvider! >> >> I don't think the JCK is exactly what you are looking for. In other to > properly test a custom file system provider then the test suite needs to > know about its URI scheme and syntax, file path syntax, at least something > about its capabilities and features, and often other details related to > configuration and setup. If your file system provider replaces or > interposes on the default provider then the tests in the jdk repository > will exercise it. If your file system provider is very different then I > think you will need to write tests, this is why we created separate tests > for the zip provider for example. As I suggested in previous, there might > be an opportunity to hook up with others that are developing their own file > system implementations and maybe something could come of this that would be > useful to others. > > -Alan. > From simonsharry at gmail.com Mon Apr 28 04:11:38 2014 From: simonsharry at gmail.com (Harry Simons) Date: Mon, 28 Apr 2014 09:41:38 +0530 Subject: Unit tests for OpenJDK? In-Reply-To: References: <535CC730.2050705@redhat.com> Message-ID: Hi Mario, The JCK link on the JavaTestSuite page is apparently hitting the wrong page, looks like Oracle has either moved or removed it. I didn't know about Mauve, will definitely check it out. Thanks a lot! Regards, /HS On Sun, Apr 27, 2014 at 5:40 PM, Mario Torre wrote: > Hi Harry, > > The JCK is a bit funny, you can have access to it, but how I let other to > say :) and yes, its a complicated process. > > Some test are in the JDK tree, but you may find helpful to run non > official test suites like mauve. > > Interestingly, the winehq page seems to do a better job than the OpenJDK > wiki in listing the options: > > http://wiki.winehq.org/JavaTestSuite > > Mauve covers a lot of areas very well, I believe the filesystem is one of > those. > > Of course, I totally understand your pain, we have the same problem, and > the only way to be 100% is to apply for the JCK. > > Cheers, > Mario > Il 27/apr/2014 12:18 "Harry Simons" ha scritto: > > Thanks for your response. >> >> Looks like, without a formal form-submission and form-approval process I >> will not be given JCK. >> >> May I ask the members in the community that without free and easy access >> to >> JCK to one and all, how on earth could an applications developer (like >> myself) possibly ever finish writing (complete with unit testing!) a >> custom >> file-system based on the FileSystemProvider API which Java itself >> provides? >> >> If not the full JCK, I think the powers-that-be should provide to all >> application developers, freely and easily, at least a subset of the JCK >> that covers nontrivial API such as FileSystemProvider! >> >> Wonder, how other developers like myself would handle this situation. >> >> >> On Sun, Apr 27, 2014 at 2:30 PM, Andrew Haley wrote: >> >> > On 04/27/2014 09:55 AM, Harry Simons wrote: >> > >> > > I downloaded OpenJDK 7u40 source bundle, and was expecting to find in >> it >> > > tons and tons of unit tests for, well, at least all public methods of >> all >> > > of its public classes. >> > > >> > > However, under the openjdk/jdk/test/ directory of the downloaded >> bundle, >> > > are sitting merely *regression* tests -- or, tests created for >> *specific* >> > > bugs. >> > > >> > > I'd like to know if OpenJDK comes with its unit tests or not? And, if >> > yes, >> > > where can I find them? If not, why are they not being shared openly. >> > >> > Because the JCK is shipped separately. >> > >> > http://openjdk.java.net/groups/conformance/JckAccess/ >> > >> > Andrew. >> > >> > >> > From aph at redhat.com Mon Apr 28 08:13:44 2014 From: aph at redhat.com (Andrew Haley) Date: Mon, 28 Apr 2014 09:13:44 +0100 Subject: Unit tests for OpenJDK? In-Reply-To: References: <535CC730.2050705@redhat.com> Message-ID: <535E0DB8.5000802@redhat.com> On 04/27/2014 11:17 AM, Harry Simons wrote: > Thanks for your response. > > Looks like, without a formal form-submission and form-approval process I > will not be given JCK. > > May I ask the members in the community that without free and easy access to > JCK to one and all, how on earth could an applications developer (like > myself) possibly ever finish writing (complete with unit testing!) a custom > file-system based on the FileSystemProvider API which Java itself provides? > > If not the full JCK, I think the powers-that-be should provide to all > application developers, freely and easily, at least a subset of the JCK > that covers nontrivial API such as FileSystemProvider! > > Wonder, how other developers like myself would handle this situation. There are (at least) three kinds of Java tests. There are the regression tests in OpenJDK which are fully open, the JCK which is licenced but free to use for OpenJDK users, and a some Oracle-only internal tests. The JCK tests an implementation for Java compatibility, so it'll not stress your FileSystemProvider. There are also some test suites that are external to OpenJDK itself, such as jcstress for concurrency. Andrew. From scolebourne at joda.org Mon Apr 28 09:43:57 2014 From: scolebourne at joda.org (Stephen Colebourne) Date: Mon, 28 Apr 2014 10:43:57 +0100 Subject: Unit tests for OpenJDK? In-Reply-To: <535E0DB8.5000802@redhat.com> References: <535CC730.2050705@redhat.com> <535E0DB8.5000802@redhat.com> Message-ID: On 28 April 2014 09:13, Andrew Haley wrote: > There are (at least) three kinds of Java tests. There are the > regression tests in OpenJDK which are fully open, the JCK which is > licenced but free to use for OpenJDK users, and a some Oracle-only > internal tests. > > The JCK tests an implementation for Java compatibility, so it'll not > stress your FileSystemProvider. > > There are also some test suites that are external to OpenJDK itself, > such as jcstress for concurrency. Just to note that the java.time package developed TCK tests alongside other tests and both are checked into OpenJDK. (The actual JCK for java.time is officially part of the main JCK, but the original basis is public). Personally, I'd like to see more areas of the JDK follow this model. Stephen From dalibor.topic at oracle.com Mon Apr 28 10:21:09 2014 From: dalibor.topic at oracle.com (dalibor topic) Date: Mon, 28 Apr 2014 12:21:09 +0200 Subject: Unit tests for OpenJDK? In-Reply-To: References: <535CC730.2050705@redhat.com> Message-ID: <535E2B95.4070301@oracle.com> On 28.04.2014 06:11, Harry Simons wrote: > Hi Mario, > > The JCK link on the JavaTestSuite page is apparently hitting the wrong > page, looks like Oracle has either moved or removed it. See http://openjdk.java.net/groups/conformance/ cheers, dalibor topic -- Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile: +491737185961 ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Gesch?ftsf?hrer: J?rgen Kunz Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Astrid Kepper, Val Maher Oracle is committed to developing practices and products that help protect the environment From dalibor.topic at oracle.com Mon Apr 28 14:44:29 2014 From: dalibor.topic at oracle.com (dalibor topic) Date: Mon, 28 Apr 2014 16:44:29 +0200 Subject: CFV: New Project: Device I/O In-Reply-To: References: Message-ID: <535E694D.1020902@oracle.com> Vote: Yes. -- Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile: +491737185961 ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Gesch?ftsf?hrer: J?rgen Kunz Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Astrid Kepper, Val Maher Oracle is committed to developing practices and products that help protect the environment From joe.darcy at oracle.com Wed Apr 30 19:40:28 2014 From: joe.darcy at oracle.com (Joe Darcy) Date: Wed, 30 Apr 2014 12:40:28 -0700 Subject: Recommended usage of backports in JBS Message-ID: <536151AC.2010600@oracle.com> Hello, It has come to my attention that there are continuing questions about policies around how to use backports in JBS. This email is intended to give guidelines on effective usage of backports and to provide a brief design rationale for the backport facility. By default, JIRA uses multiple values in the "Fix Version/s" field to track a bug in multiple releases. When JBS was being designed, this out of the box "Fix Version/s" facility was judged as inadequate for tracking JDK bugs across numerous release trains and versions. Semantically, for each release a tuple of information was wanted like: (status in release, resolution in release, assignee for release, release-specific comments) An approximation to this design was implemented in JBS. [1] Instead of changing this set of fields to be tuples in JIRA, a release-specific issue with these fields (and all the other fields) is used to store the release-specific information. The issues for releases other than the release used for the main issues have the custom "backport" issue type and are displayed grouped together in the main bug. The setting of the "Fix Version/s" field indicates which release a particular backport is tracking. If a bug was pushed to both JDK 9 and, say, JDK 8u20, there would be two issues for the conceptual bug in JBS. The canonical configuration for a case like this is a main bug with its "Fix Version/s" field set to "9" and a backport with its "Fix Version/s" set to 8u20. I think of backports as vestigial issues whose only contribution is holding the value of a few fields. All notions of the identity of the issue relate to the master issue. A consequence of this is the first rule of backports: First rule of backports: Only push changesets using the master bug id and *not* a backport bug id. (It would be technically possible for a tool like jcheck to verify that a bug id corresponded to a main bug rather than a backport. As a matter of design, we have not wanted to prevent pushes from going through due to an outage of the bug database. However, we may want to reconsider the design trade offs in this regard and perform such a check if JBS is available, but not block the push from going through if JBS happens to be down.) Other questions about backports concern when backports should be created, which leads to the second rule of backports: Second rule of backports: Only create a backport when it is necessary to do so. It is necessary to create a backport as soon as there is a need to track release-specific information about an issue. Sometimes a backport is not needed until a fix is pushed to a particular release. For example, say a bug has already been fixed in JDK 9 and an engineer believes the fix would be beneficial to the 8 update train. Following the process for backporting fixes to the always-open mainline 8 update train [2], the engineer would request approval for the backport. Assuming that approval was granted, the fix is pushed to the appropriate 8 update repo using the main bug id. At this point, the Hg update daemon would create a backport for the particular 8 update release the 8u repo currently corresponded to, say, 8u20. [3] The Hg updater process would also set the fields of the new backport accordingly, status = resolved, resolution = fixed, etc. Letting Hg updater create backports is the least error prone method for creating them and is the recommended procedure when other factors don't require the creation of a backport sooner. A corollary to the second rule is that if a backport is created before a change is pushed, it should be created with the least specific information necessary. For example, if it doesn't matter very much which 8 update release the fix goes into, the backport should be created with a "Fix Version/s" of 8-pool rather than a particular 8 update release like 8u20 or 8u40. That way, if the bug is fixed in any member of the 8 update family, Hg Updater will see the existing backport for 8-pool and adjust the Fix Version/s field of that backport to the specific 8 release where the fix is going. When a fix needs to be targeted to a specific update release and tracking for that release is needed before the fix gets pushed, then it is reasonable to create a backport with a Fix Version/s field set to that release ahead of time. (This is commonly the case for bugs being tracked for inclusion in a security release.) Consider another bug to be fixed in JDK 9 and specifically also in 8u20. In that case, two issues are needed, a main bug and a backport. What should be the Fix Version/s of the main bug and what should be the Fix Version/s of the backport? It is preferable if the main bug has a Fix Version/s setting of 9 and the backport has a setting of 8u20. This dovetails with the 8 update release policy of not approving backports that haven't already been fixed in JDK 9. However, it is marginally acceptable for the main bug to have Fix Version/s of 8u20 and the backport a Fix Version/s of 9 *as long as* the first rule is followed and the push to 9 uses the main bug id (even though the main bug was in 8u20). (In a case like this the "backport" is just going in a negative direction ;-) I hope this helps clarify the recommended use of backports. Cheers, -Joe [1] JBS Overview, https://wiki.openjdk.java.net/display/general/JBS+Overview [2] http://openjdk.java.net/projects/jdk8u/ [3] Over time, pushes to the always-open mainline repos for the 8 update release correspond to makigg a fix in a different particular 8 update release. For example, today a fix pushed to one of these repos will be shipped as part of 8u20, but in a few months time, a fix pushed to one of these repos will be fixed as part of 8u40. Meta-data on the Hg server used by Hg updater records which particular 8 update release a push to the 8 update repo will correspond to. From jonathan.gibbons at oracle.com Wed Apr 30 20:37:38 2014 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 30 Apr 2014 13:37:38 -0700 Subject: Recommended usage of backports in JBS In-Reply-To: <536151AC.2010600@oracle.com> References: <536151AC.2010600@oracle.com> Message-ID: <53615F12.3020305@oracle.com> Joe, This would seem to be potentially excellent content for the OpenJDK Developers' Guide. -- Jon On 04/30/2014 12:40 PM, Joe Darcy wrote: > Hello, > > It has come to my attention that there are continuing questions about > policies around how to use backports in JBS. This email is intended to > give guidelines on effective usage of backports and to provide a brief > design rationale for the backport facility. > > By default, JIRA uses multiple values in the "Fix Version/s" field to > track a bug in multiple releases. When JBS was being designed, this > out of the box "Fix Version/s" facility was judged as inadequate for > tracking JDK bugs across numerous release trains and versions. > Semantically, for each release a tuple of information was wanted like: > > (status in release, resolution in release, assignee for release, > release-specific comments) > > An approximation to this design was implemented in JBS. [1] Instead of > changing this set of fields to be tuples in JIRA, a release-specific > issue with these fields (and all the other fields) is used to store > the release-specific information. The issues for releases other than > the release used for the main issues have the custom "backport" issue > type and are displayed grouped together in the main bug. The setting > of the "Fix Version/s" field indicates which release a particular > backport is tracking. If a bug was pushed to both JDK 9 and, say, JDK > 8u20, there would be two issues for the conceptual bug in JBS. The > canonical configuration for a case like this is a main bug with its > "Fix Version/s" field set to "9" and a backport with its "Fix > Version/s" set to 8u20. > > I think of backports as vestigial issues whose only contribution is > holding the value of a few fields. All notions of the identity of the > issue relate to the master issue. A consequence of this is the first > rule of backports: > > First rule of backports: > Only push changesets using the master bug id and *not* a backport > bug id. > > (It would be technically possible for a tool like jcheck to verify > that a bug id corresponded to a main bug rather than a backport. As a > matter of design, we have not wanted to prevent pushes from going > through due to an outage of the bug database. However, we may want to > reconsider the design trade offs in this regard and perform such a > check if JBS is available, but not block the push from going through > if JBS happens to be down.) > > Other questions about backports concern when backports should be > created, which leads to the second rule of backports: > > Second rule of backports: > Only create a backport when it is necessary to do so. > > It is necessary to create a backport as soon as there is a need to > track release-specific information about an issue. Sometimes a > backport is not needed until a fix is pushed to a particular release. > > For example, say a bug has already been fixed in JDK 9 and an engineer > believes the fix would be beneficial to the 8 update train. Following > the process for backporting fixes to the always-open mainline 8 update > train [2], the engineer would request approval for the backport. > Assuming that approval was granted, the fix is pushed to the > appropriate 8 update repo using the main bug id. At this point, the Hg > update daemon would create a backport for the particular 8 update > release the 8u repo currently corresponded to, say, 8u20. [3] The Hg > updater process would also set the fields of the new backport > accordingly, status = resolved, resolution = fixed, etc. > > Letting Hg updater create backports is the least error prone method > for creating them and is the recommended procedure when other factors > don't require the creation of a backport sooner. > > A corollary to the second rule is that if a backport is created before > a change is pushed, it should be created with the least specific > information necessary. For example, if it doesn't matter very much > which 8 update release the fix goes into, the backport should be > created with a "Fix Version/s" of 8-pool rather than a particular 8 > update release like 8u20 or 8u40. That way, if the bug is fixed in any > member of the 8 update family, Hg Updater will see the existing > backport for 8-pool and adjust the Fix Version/s field of that > backport to the specific 8 release where the fix is going. > > When a fix needs to be targeted to a specific update release and > tracking for that release is needed before the fix gets pushed, then > it is reasonable to create a backport with a Fix Version/s field set > to that release ahead of time. (This is commonly the case for bugs > being tracked for inclusion in a security release.) > > Consider another bug to be fixed in JDK 9 and specifically also in > 8u20. In that case, two issues are needed, a main bug and a backport. > What should be the Fix Version/s of the main bug and what should be > the Fix Version/s of the backport? It is preferable if the main bug > has a Fix Version/s setting of 9 and the backport has a setting of > 8u20. This dovetails with the 8 update release policy of not approving > backports that haven't already been fixed in JDK 9. However, it is > marginally acceptable for the main bug to have Fix Version/s of 8u20 > and the backport a Fix Version/s of 9 *as long as* the first rule is > followed and the push to 9 uses the main bug id (even though the main > bug was in 8u20). (In a case like this the "backport" is just going in > a negative direction ;-) > > I hope this helps clarify the recommended use of backports. > > Cheers, > > -Joe > > [1] JBS Overview, > https://wiki.openjdk.java.net/display/general/JBS+Overview > > [2] http://openjdk.java.net/projects/jdk8u/ > > [3] Over time, pushes to the always-open mainline repos for the 8 > update release correspond to makigg a fix in a different particular 8 > update release. For example, today a fix pushed to one of these repos > will be shipped as part of 8u20, but in a few months time, a fix > pushed to one of these repos will be fixed as part of 8u40. Meta-data > on the Hg server used by Hg updater records which particular 8 update > release a push to the 8 update repo will correspond to. From mike.duigou at oracle.com Wed Apr 30 22:55:24 2014 From: mike.duigou at oracle.com (Mike Duigou) Date: Wed, 30 Apr 2014 15:55:24 -0700 Subject: Recommended usage of backports in JBS In-Reply-To: <536151AC.2010600@oracle.com> References: <536151AC.2010600@oracle.com> Message-ID: <26AE266D-8A8F-4E4D-8644-C165E07A38BB@oracle.com> On Apr 30 2014, at 12:40 , Joe Darcy wrote: > Hello, > > It has come to my attention that there are continuing questions about policies around how to use backports in JBS. This email is intended to give guidelines on effective usage of backports and to provide a brief design rationale for the backport facility. > > By default, JIRA uses multiple values in the "Fix Version/s" field to track a bug in multiple releases. Can we change the default behaviour? > (It would be technically possible for a tool like jcheck to verify that a bug id corresponded to a main bug rather than a backport. As a matter of design, we have not wanted to prevent pushes from going through due to an outage of the bug database. However, we may want to reconsider the design trade offs in this regard and perform such a check if JBS is available, but not block the push from going through if JBS happens to be down.) Ideally this should require a manual "--force" option. Mike From jeffhain at rocketmail.com Wed Apr 30 22:59:51 2014 From: jeffhain at rocketmail.com (Jeff Hain) Date: Wed, 30 Apr 2014 23:59:51 +0100 (BST) Subject: Hello Message-ID: <1398898791.58505.YahooMailNeo@web172405.mail.ir2.yahoo.com> I'm Olivier Masle, from France, and just joined the OCA signatories - but have been in core-libs-dev for a few years already. I spare-time-code only from time to time (*), but will happily contribute if my ideas are worth it (Brian thought one was, so here I am). (*) Mostly reinventing or upgrading the wheel in some small and low-level (for Java) open source libraries, with mostly performances and simplicity in mind, under "Jeff Hain" alias (https://sourceforge.net/u/omaamo/profile/ and http://code.google.com/p/jodk/). Regards. From joe.darcy at oracle.com Wed Apr 30 23:06:03 2014 From: joe.darcy at oracle.com (Joe Darcy) Date: Wed, 30 Apr 2014 16:06:03 -0700 Subject: Recommended usage of backports in JBS In-Reply-To: <26AE266D-8A8F-4E4D-8644-C165E07A38BB@oracle.com> References: <536151AC.2010600@oracle.com> <26AE266D-8A8F-4E4D-8644-C165E07A38BB@oracle.com> Message-ID: <536181DB.6030509@oracle.com> Hi Mike On 04/30/2014 03:55 PM, Mike Duigou wrote: > On Apr 30 2014, at 12:40 , Joe Darcy wrote: > >> Hello, >> >> It has come to my attention that there are continuing questions about policies around how to use backports in JBS. This email is intended to give guidelines on effective usage of backports and to provide a brief design rationale for the backport facility. >> >> By default, JIRA uses multiple values in the "Fix Version/s" field to track a bug in multiple releases. > Can we change the default behaviour? Certainly not easily. We looked into this during early days of JBS and there was no ready way to do it. If not impossible, the effort required was not judged worthwhile compared to other kinds of customizations we were working on at the time. > >> (It would be technically possible for a tool like jcheck to verify that a bug id corresponded to a main bug rather than a backport. As a matter of design, we have not wanted to prevent pushes from going through due to an outage of the bug database. However, we may want to reconsider the design trade offs in this regard and perform such a check if JBS is available, but not block the push from going through if JBS happens to be down.) > Ideally this should require a manual "--force" option. > > Mike I agree that would be a good feature to have. Cheers, -Joe