From maurizio.cimadamore at oracle.com Fri Mar 1 16:28:06 2019 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Fri, 1 Mar 2019 16:28:06 +0000 Subject: Group Proposal, for discussion: IDE & Tooling support Message-ID: <0f1a6f83-db25-b1e8-beb3-a6b6b8d84b85@oracle.com> (This is not a call for votes; it is just a call for discussion.) At the last OpenJDK Committer Workshop in Brussels, we agreed to set up some channel in which to discuss issues related to OpenJDK tooling, and, more specifically IDE support. We already have pretty comprehensive support for OpenJDK development in both IntelliJ and Netbeans, but the main, long standing problem has been one of lack of adequate communication and coordination between these various efforts, which often led (frustrated) developers to the path of "I'll write my own support". The goal of this group is, first and foremost, to extensively document the alternatives that are already available at present, as well as to capture discussions related to tooling support which are currently scattered among many mailing list (compiler-dev, jtreg-dev, build-dev). After some internal discussions, it feels like proposing a group is the right thing to do because: (i) a group automatically gets a mailing list and a page on openjdk.java.net - which can be useful for communicating within the group and also for publishing the much needed documentation; also (ii) a group is not tied to any specific set of deliverables (unlike, say, an OpenJDK project), which feels right in this case, as IDE support is likely to be a recurring activity. We want OpenJDK to be a welcoming place for developers, and I feel that improving IDE/tooling support plays a crucial role in reducing the activation energy required to start hacking on the OpenJDK codebase. Thoughts? Cheers Maurizio From jonathan.gibbons at oracle.com Fri Mar 1 18:05:25 2019 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Fri, 1 Mar 2019 10:05:25 -0800 Subject: Group Proposal, for discussion: IDE & Tooling support In-Reply-To: <0f1a6f83-db25-b1e8-beb3-a6b6b8d84b85@oracle.com> References: <0f1a6f83-db25-b1e8-beb3-a6b6b8d84b85@oracle.com> Message-ID: <5d9c6b56-33e8-d20f-c402-6b29696e1054@oracle.com> Maurizio, Sounds good to me. I presume this will subsume the curiously-named "NetBeans Project" Group, that never quite gained any traction. -- Jon On 03/01/2019 08:28 AM, Maurizio Cimadamore wrote: > (This is not a call for votes; it is just a call for discussion.) > > At the last OpenJDK Committer Workshop in Brussels, we agreed to set > up some channel in which to discuss issues related to OpenJDK tooling, > and, more specifically IDE support. We already have pretty > comprehensive support for OpenJDK development in both IntelliJ and > Netbeans, but the main, long standing problem has been one of lack of > adequate communication and coordination between these various efforts, > which often led (frustrated) developers to the path of "I'll write my > own support". > > The goal of this group is, first and foremost, to extensively document > the alternatives that are already available at present, as well as to > capture discussions related to tooling support which are currently > scattered among many mailing list (compiler-dev, jtreg-dev, > build-dev). After some internal discussions, it feels like proposing a > group is the right thing to do because: (i) a group automatically gets > a mailing list and a page on openjdk.java.net - which can be useful > for communicating within the group and also for publishing the much > needed documentation; also (ii) a group is not tied to any specific > set of deliverables (unlike, say, an OpenJDK project), which feels > right in this case, as IDE support is likely to be a recurring activity. > > We want OpenJDK to be a welcoming place for developers, and I feel > that improving IDE/tooling support plays a crucial role in reducing > the activation energy required to start hacking on the OpenJDK codebase. > > Thoughts? > > Cheers > Maurizio > > From maurizio.cimadamore at oracle.com Fri Mar 1 18:12:11 2019 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Fri, 1 Mar 2019 18:12:11 +0000 Subject: Group Proposal, for discussion: IDE & Tooling support In-Reply-To: <5d9c6b56-33e8-d20f-c402-6b29696e1054@oracle.com> References: <0f1a6f83-db25-b1e8-beb3-a6b6b8d84b85@oracle.com> <5d9c6b56-33e8-d20f-c402-6b29696e1054@oracle.com> Message-ID: <41981bd3-b8cb-ff6e-b615-ce80cce716b1@oracle.com> On 01/03/2019 18:05, Jonathan Gibbons wrote: > Maurizio, > > Sounds good to me. > > I presume this will subsume the curiously-named "NetBeans Project" > Group, that never quite gained any traction. Yep - that happens to have a bit of a confusing name, as it's a Group with the P-word in it; this new group will eventually subsume the other (which will be garbage collected at some point). Maurizio > > -- Jon > > > On 03/01/2019 08:28 AM, Maurizio Cimadamore wrote: >> (This is not a call for votes; it is just a call for discussion.) >> >> At the last OpenJDK Committer Workshop in Brussels, we agreed to set >> up some channel in which to discuss issues related to OpenJDK >> tooling, and, more specifically IDE support. We already have pretty >> comprehensive support for OpenJDK development in both IntelliJ and >> Netbeans, but the main, long standing problem has been one of lack of >> adequate communication and coordination between these various >> efforts, which often led (frustrated) developers to the path of "I'll >> write my own support". >> >> The goal of this group is, first and foremost, to extensively >> document the alternatives that are already available at present, as >> well as to capture discussions related to tooling support which are >> currently scattered among many mailing list (compiler-dev, jtreg-dev, >> build-dev). After some internal discussions, it feels like proposing >> a group is the right thing to do because: (i) a group automatically >> gets a mailing list and a page on openjdk.java.net - which can be >> useful for communicating within the group and also for publishing the >> much needed documentation; also (ii) a group is not tied to any >> specific set of deliverables (unlike, say, an OpenJDK project), which >> feels right in this case, as IDE support is likely to be a recurring >> activity. >> >> We want OpenJDK to be a welcoming place for developers, and I feel >> that improving IDE/tooling support plays a crucial role in reducing >> the activation energy required to start hacking on the OpenJDK codebase. >> >> Thoughts? >> >> Cheers >> Maurizio >> >> > From augustnagro at gmail.com Mon Mar 4 00:40:33 2019 From: augustnagro at gmail.com (August Nagro) Date: Sun, 3 Mar 2019 18:40:33 -0600 Subject: Group Proposal, for discussion: IDE & Tooling support In-Reply-To: <41981bd3-b8cb-ff6e-b615-ce80cce716b1@oracle.com> References: <0f1a6f83-db25-b1e8-beb3-a6b6b8d84b85@oracle.com> <5d9c6b56-33e8-d20f-c402-6b29696e1054@oracle.com> <41981bd3-b8cb-ff6e-b615-ce80cce716b1@oracle.com> Message-ID: Hi Maurizio, I think this is a great idea. I personally find things easiest when all developer documentation/instructions are aggregated in a single directory, or even single file. The big building.html in the jdk is a good example of this. Maybe create a doc/development.html? - August On Fri, Mar 1, 2019 at 12:14 PM Maurizio Cimadamore < maurizio.cimadamore at oracle.com> wrote: > > On 01/03/2019 18:05, Jonathan Gibbons wrote: > > Maurizio, > > > > Sounds good to me. > > > > I presume this will subsume the curiously-named "NetBeans Project" > > Group, that never quite gained any traction. > > Yep - that happens to have a bit of a confusing name, as it's a Group > with the P-word in it; this new group will eventually subsume the other > (which will be garbage collected at some point). > > Maurizio > > > > > -- Jon > > > > > > On 03/01/2019 08:28 AM, Maurizio Cimadamore wrote: > >> (This is not a call for votes; it is just a call for discussion.) > >> > >> At the last OpenJDK Committer Workshop in Brussels, we agreed to set > >> up some channel in which to discuss issues related to OpenJDK > >> tooling, and, more specifically IDE support. We already have pretty > >> comprehensive support for OpenJDK development in both IntelliJ and > >> Netbeans, but the main, long standing problem has been one of lack of > >> adequate communication and coordination between these various > >> efforts, which often led (frustrated) developers to the path of "I'll > >> write my own support". > >> > >> The goal of this group is, first and foremost, to extensively > >> document the alternatives that are already available at present, as > >> well as to capture discussions related to tooling support which are > >> currently scattered among many mailing list (compiler-dev, jtreg-dev, > >> build-dev). After some internal discussions, it feels like proposing > >> a group is the right thing to do because: (i) a group automatically > >> gets a mailing list and a page on openjdk.java.net - which can be > >> useful for communicating within the group and also for publishing the > >> much needed documentation; also (ii) a group is not tied to any > >> specific set of deliverables (unlike, say, an OpenJDK project), which > >> feels right in this case, as IDE support is likely to be a recurring > >> activity. > >> > >> We want OpenJDK to be a welcoming place for developers, and I feel > >> that improving IDE/tooling support plays a crucial role in reducing > >> the activation energy required to start hacking on the OpenJDK codebase. > >> > >> Thoughts? > >> > >> Cheers > >> Maurizio > >> > >> > > > From maurizio.cimadamore at oracle.com Mon Mar 4 13:20:22 2019 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Mon, 4 Mar 2019 13:20:22 +0000 Subject: Group Proposal, for discussion: IDE & Tooling support In-Reply-To: References: <0f1a6f83-db25-b1e8-beb3-a6b6b8d84b85@oracle.com> <5d9c6b56-33e8-d20f-c402-6b29696e1054@oracle.com> <41981bd3-b8cb-ff6e-b615-ce80cce716b1@oracle.com> Message-ID: <49f40096-9c9d-a014-d262-5a94bba448be@oracle.com> Hi August, having a document checked into the repo is certainly something to consider; we have to balance some factors here - IDE support might be more fluid than e.g. build/make interface (e.g. some IDE support might come and go), which might point at the fact that the OpenJDK wiki might be a more suitable place where to host such a collaborative document. But these are all valid points in the space, I'm sure we will find a reasonable place where to put the documentation, the satisfies the set of constraints we (as a group) decide are important. Maurizio On 04/03/2019 00:40, August Nagro wrote: > Hi Maurizio, > > I think this is a great idea. I personally find things easiest when > all developer documentation/instructions are aggregated in a single > directory, or even single file. The big building.html in the jdk is a > good example of this. Maybe create a doc/development.html? > > - August > > On Fri, Mar 1, 2019 at 12:14 PM Maurizio Cimadamore > > wrote: > > > On 01/03/2019 18:05, Jonathan Gibbons wrote: > > Maurizio, > > > > Sounds good to me. > > > > I presume this will subsume the curiously-named "NetBeans Project" > > Group, that never quite gained any traction. > > Yep - that happens to have a bit of a confusing name, as it's a Group > with the P-word in it; this new group will eventually subsume the > other > (which will be garbage collected at some point). > > Maurizio > > > > > -- Jon > > > > > > On 03/01/2019 08:28 AM, Maurizio Cimadamore wrote: > >> (This is not a call for votes; it is just a call for discussion.) > >> > >> At the last OpenJDK Committer Workshop in Brussels, we agreed > to set > >> up some channel in which to discuss issues related to OpenJDK > >> tooling, and, more specifically IDE support. We already have > pretty > >> comprehensive support for OpenJDK development in both IntelliJ and > >> Netbeans, but the main, long standing problem has been one of > lack of > >> adequate communication and coordination between these various > >> efforts, which often led (frustrated) developers to the path of > "I'll > >> write my own support". > >> > >> The goal of this group is, first and foremost, to extensively > >> document the alternatives that are already available at > present, as > >> well as to capture discussions related to tooling support which > are > >> currently scattered among many mailing list (compiler-dev, > jtreg-dev, > >> build-dev). After some internal discussions, it feels like > proposing > >> a group is the right thing to do because: (i) a group > automatically > >> gets a mailing list and a page on openjdk.java.net > - which can be > >> useful for communicating within the group and also for > publishing the > >> much needed documentation; also (ii) a group is not tied to any > >> specific set of deliverables (unlike, say, an OpenJDK project), > which > >> feels right in this case, as IDE support is likely to be a > recurring > >> activity. > >> > >> We want OpenJDK to be a welcoming place for developers, and I feel > >> that improving IDE/tooling support plays a crucial role in > reducing > >> the activation energy required to start hacking on the OpenJDK > codebase. > >> > >> Thoughts? > >> > >> Cheers > >> Maurizio > >> > >> > > > From lance.andersen at oracle.com Mon Mar 4 18:47:41 2019 From: lance.andersen at oracle.com (Lance Andersen) Date: Mon, 4 Mar 2019 13:47:41 -0500 Subject: Group Proposal, for discussion: IDE & Tooling support In-Reply-To: <0f1a6f83-db25-b1e8-beb3-a6b6b8d84b85@oracle.com> References: <0f1a6f83-db25-b1e8-beb3-a6b6b8d84b85@oracle.com> Message-ID: Hi Maurizio, I think this will be extremely valuable. I know when I started using Intellij in-place of Netbeans, I definitely hit a few speed bumps so this would be very welcome. Best Lance > On Mar 1, 2019, at 11:28 AM, Maurizio Cimadamore wrote: > > (This is not a call for votes; it is just a call for discussion.) > > At the last OpenJDK Committer Workshop in Brussels, we agreed to set up some channel in which to discuss issues related to OpenJDK tooling, and, more specifically IDE support. We already have pretty comprehensive support for OpenJDK development in both IntelliJ and Netbeans, but the main, long standing problem has been one of lack of adequate communication and coordination between these various efforts, which often led (frustrated) developers to the path of "I'll write my own support". > > The goal of this group is, first and foremost, to extensively document the alternatives that are already available at present, as well as to capture discussions related to tooling support which are currently scattered among many mailing list (compiler-dev, jtreg-dev, build-dev). After some internal discussions, it feels like proposing a group is the right thing to do because: (i) a group automatically gets a mailing list and a page on openjdk.java.net - which can be useful for communicating within the group and also for publishing the much needed documentation; also (ii) a group is not tied to any specific set of deliverables (unlike, say, an OpenJDK project), which feels right in this case, as IDE support is likely to be a recurring activity. > > We want OpenJDK to be a welcoming place for developers, and I feel that improving IDE/tooling support plays a crucial role in reducing the activation energy required to start hacking on the OpenJDK codebase. > > Thoughts? > > Cheers > Maurizio > > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From magnus.ihse.bursie at oracle.com Tue Mar 5 11:10:32 2019 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 5 Mar 2019 12:10:32 +0100 Subject: Group Proposal, for discussion: IDE & Tooling support In-Reply-To: <0f1a6f83-db25-b1e8-beb3-a6b6b8d84b85@oracle.com> References: <0f1a6f83-db25-b1e8-beb3-a6b6b8d84b85@oracle.com> Message-ID: <3e611669-3f72-54c5-249b-0076664fdd08@oracle.com> On 2019-03-01 17:28, Maurizio Cimadamore wrote: > (This is not a call for votes; it is just a call for discussion.) > > At the last OpenJDK Committer Workshop in Brussels, we agreed to set > up some channel in which to discuss issues related to OpenJDK tooling, > and, more specifically IDE support. We already have pretty > comprehensive support for OpenJDK development in both IntelliJ and > Netbeans, but the main, long standing problem has been one of lack of > adequate communication and coordination between these various efforts, > which often led (frustrated) developers to the path of "I'll write my > own support". > > The goal of this group is, first and foremost, to extensively document > the alternatives that are already available at present, as well as to > capture discussions related to tooling support which are currently > scattered among many mailing list (compiler-dev, jtreg-dev, > build-dev). After some internal discussions, it feels like proposing a > group is the right thing to do because: (i) a group automatically gets > a mailing list and a page on openjdk.java.net - which can be useful > for communicating within the group and also for publishing the much > needed documentation; also (ii) a group is not tied to any specific > set of deliverables (unlike, say, an OpenJDK project), which feels > right in this case, as IDE support is likely to be a recurring activity. > > We want OpenJDK to be a welcoming place for developers, and I feel > that improving IDE/tooling support plays a crucial role in reducing > the activation energy required to start hacking on the OpenJDK codebase. > > Thoughts? It has been the long-time intention of the Build Group to take responsibility for providing IDE integration to OpenJDK developers. However, due to the combination of lack of resources, and developer support not getting high enough on the priority list, this has never actually happened. :-( Instead our involvement has been to provide basic support and assistance for build system integration for the actual developers who has been fixing the current IDE integration solutions. I still think there is (or should be) a strong coupling between the build system and IDE support. Ideally, IDE project generators should utilize the "knowlegde" embedded in the build system, and there should be minimal redundancy between doing stuff using make and using the IDE. However, it is also clear that JDK/Hotspot developers know better exactly what features they want from IDE integration. And, it still looks like there is not enough resources in the build team to do anything serious about IDE support, so other developers who can work on this are definitely needed. I agree that providing a great IDE experience is a very beneficial thing, both for existing OpenJDK developers, and for attracting new ones. Is this goal is best served by creating a new group? I don't know. I'm a bit skeptical, and think that this work still fits quite well under the Build Group umbrella, but if this is not the general perception, I will not protest against creating a new group. Also, an alternative to creating a group is to create a Project. I'm certain the Build Group could sponsor an IDE Integration Project, or something like that. A Project can also get mailing lists and repos, but does not need to have a Group Lead that needs to perform additional duties like sending a yearly status report, etc. /Magnus > > Cheers > Maurizio > > From magnus.ihse.bursie at oracle.com Tue Mar 5 11:36:26 2019 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 5 Mar 2019 12:36:26 +0100 Subject: Group Proposal, for discussion: IDE & Tooling support In-Reply-To: References: <0f1a6f83-db25-b1e8-beb3-a6b6b8d84b85@oracle.com> <5d9c6b56-33e8-d20f-c402-6b29696e1054@oracle.com> <41981bd3-b8cb-ff6e-b615-ce80cce716b1@oracle.com> Message-ID: <4b0ef425-096b-cefd-ce5c-2c422cf9702c@oracle.com> On 2019-03-04 01:40, August Nagro wrote: > Hi Maurizio, > > I think this is a great idea. I personally find things easiest when all > developer documentation/instructions are aggregated in a single directory, > or even single file. The big building.html in the jdk is a good example of > this. Maybe create a doc/development.html? Writing down the existing IDE support in doc/development.md seems like a good idea to me, and an excellent start! Let me add in some of my documentation from my latest unofficial survey on IDE usage, and the perceived quality of IDE integration in OpenJDK. This is based solely on the replies of my fellow OpenJDK developers in the Stockholm Office, which means it is quite Hotspot-skewed, and it does not have that many data points. Still, I think it is a good starting point, and probably is in the right ballpark. List of IDEs used: ?* Eclipse (Java) [3 developers] ?* Eclipse (CDT) [3 developers] ?* XCode [2 developers] ?* Visual Studio [2 developers] ?* IntelliJ [1 developer] ?* CLion [1 developer] ?* Vim [2 developers] ?* Emacs [1-2 developers] ?* NetBeans [0 developers] Some general reflections: ?* OpenJDK is a huge project. None of the IDEs tend to deal well with *all* of the OpenJDK being imported at once, so some kind of selection mechanism seems to be required, and this goes for all IDEs. ?* A clear split from the developer perspective is Hotspot/non-Hotspot developers. Hotspot developers cares only (or mostly) about src/hotspot, and is only (or mostly) interested in C++ code. Non-hotspot developers typically focus on certain selected modules from src, and needs to work with either pure Java, or a mix of Java and native code. * No current IDE solution works well with a mix of native and Java code. It's unclear to me if this is an inherent limitations on the IDEs (might be in some cases, but perhaps not in all) or just in the way we currently interact with them. ?* Initial setup for IDE projects, even where generators exist, are perceived as a problem. A general "make -project" initial run was generally considered a reasonable approach, but this should not need to build the full product using make, but needs to be much faster. ?* The current situation is a hodgepodge of home brewed solution. Everyone has their own script or methods for setting up new clones with their IDE. ?* A comprehensive set of instructions, per IDE, was requested. Good instructions might even go a long way of removing the need for automatic tooling. ?* No current IDE solutions deal with test source code in a reasonable way. Opinion differed on whether the amount of tests were so large that they, too, needed to be selectively imported in the IDE. ?* A more concrete problem with tests was that the jtreg tests all belong to their own packages, which resulted in an explosion of packages that at least Eclipse had a hard time handling. This is my interpretation of the developers' thought of the general quality of the existing integrations : ?* Eclipse (Java) -- works really lousy ?* Eclipse (CDT) -- works quite well ?* XCode -- works okay (for C++) ?* Visual Studio -- works quite well (for C++) ?* IntelliJ -- ? (I didn't record any reply) ?* CLion -- acceptable, but have some annoying issues ?* Vim -- you learn your way around ?* Emacs -- as for Vim ?* NetBeans -- unclear. One developer tried it but could not get it to work properly. /Magnus > > - August > > On Fri, Mar 1, 2019 at 12:14 PM Maurizio Cimadamore < > maurizio.cimadamore at oracle.com> wrote: > >> On 01/03/2019 18:05, Jonathan Gibbons wrote: >>> Maurizio, >>> >>> Sounds good to me. >>> >>> I presume this will subsume the curiously-named "NetBeans Project" >>> Group, that never quite gained any traction. >> Yep - that happens to have a bit of a confusing name, as it's a Group >> with the P-word in it; this new group will eventually subsume the other >> (which will be garbage collected at some point). >> >> Maurizio >> >>> -- Jon >>> >>> >>> On 03/01/2019 08:28 AM, Maurizio Cimadamore wrote: >>>> (This is not a call for votes; it is just a call for discussion.) >>>> >>>> At the last OpenJDK Committer Workshop in Brussels, we agreed to set >>>> up some channel in which to discuss issues related to OpenJDK >>>> tooling, and, more specifically IDE support. We already have pretty >>>> comprehensive support for OpenJDK development in both IntelliJ and >>>> Netbeans, but the main, long standing problem has been one of lack of >>>> adequate communication and coordination between these various >>>> efforts, which often led (frustrated) developers to the path of "I'll >>>> write my own support". >>>> >>>> The goal of this group is, first and foremost, to extensively >>>> document the alternatives that are already available at present, as >>>> well as to capture discussions related to tooling support which are >>>> currently scattered among many mailing list (compiler-dev, jtreg-dev, >>>> build-dev). After some internal discussions, it feels like proposing >>>> a group is the right thing to do because: (i) a group automatically >>>> gets a mailing list and a page on openjdk.java.net - which can be >>>> useful for communicating within the group and also for publishing the >>>> much needed documentation; also (ii) a group is not tied to any >>>> specific set of deliverables (unlike, say, an OpenJDK project), which >>>> feels right in this case, as IDE support is likely to be a recurring >>>> activity. >>>> >>>> We want OpenJDK to be a welcoming place for developers, and I feel >>>> that improving IDE/tooling support plays a crucial role in reducing >>>> the activation energy required to start hacking on the OpenJDK codebase. >>>> >>>> Thoughts? >>>> >>>> Cheers >>>> Maurizio >>>> >>>> From JESPER.WILHELMSSON at ORACLE.COM Tue Mar 5 12:26:38 2019 From: JESPER.WILHELMSSON at ORACLE.COM (Jesper Wilhelmsson) Date: Tue, 5 Mar 2019 13:26:38 +0100 Subject: Group Proposal, for discussion: IDE & Tooling support In-Reply-To: <4b0ef425-096b-cefd-ce5c-2c422cf9702c@oracle.com> References: <0f1a6f83-db25-b1e8-beb3-a6b6b8d84b85@oracle.com> <5d9c6b56-33e8-d20f-c402-6b29696e1054@oracle.com> <41981bd3-b8cb-ff6e-b615-ce80cce716b1@oracle.com> <4b0ef425-096b-cefd-ce5c-2c422cf9702c@oracle.com> Message-ID: <078F62CC-6EAF-4E85-8FFB-169EEA4A83F5@ORACLE.COM> Just to add to the list of IDEs, I used Oracle Developer Studio [1] for JVM development for many years. This is a NetBeans based C++ environment. It works great and the project files are already available in the OpenJDK repository. (/make/nb_native/nbproject) It?s been a couple of years since I used it last so the project files may be missing some of the latest new files, but one good thing about ODS is that it self heals and automatically adds new files and updates the project. /Jesper [1] https://www.oracle.com/technetwork/server-storage/developerstudio/overview/index.html > 5 mars 2019 kl. 12:36 skrev Magnus Ihse Bursie : > > > >> On 2019-03-04 01:40, August Nagro wrote: >> Hi Maurizio, >> >> I think this is a great idea. I personally find things easiest when all >> developer documentation/instructions are aggregated in a single directory, >> or even single file. The big building.html in the jdk is a good example of >> this. Maybe create a doc/development.html? > > Writing down the existing IDE support in doc/development.md seems like a good idea to me, and an excellent start! > > Let me add in some of my documentation from my latest unofficial survey on IDE usage, and the perceived quality of IDE integration in OpenJDK. This is based solely on the replies of my fellow OpenJDK developers in the Stockholm Office, which means it is quite Hotspot-skewed, and it does not have that many data points. Still, I think it is a good starting point, and probably is in the right ballpark. > > List of IDEs used: > > * Eclipse (Java) [3 developers] > * Eclipse (CDT) [3 developers] > * XCode [2 developers] > * Visual Studio [2 developers] > * IntelliJ [1 developer] > * CLion [1 developer] > * Vim [2 developers] > * Emacs [1-2 developers] > * NetBeans [0 developers] > > Some general reflections: > > * OpenJDK is a huge project. None of the IDEs tend to deal well with *all* of the OpenJDK being imported at once, so some kind of selection mechanism seems to be required, and this goes for all IDEs. > * A clear split from the developer perspective is Hotspot/non-Hotspot developers. Hotspot developers cares only (or mostly) about src/hotspot, and is only (or mostly) interested in C++ code. Non-hotspot developers typically focus on certain selected modules from src, and needs to work with either pure Java, or a mix of Java and native code. > * No current IDE solution works well with a mix of native and Java code. It's unclear to me if this is an inherent limitations on the IDEs (might be in some cases, but perhaps not in all) or just in the way we currently interact with them. > * Initial setup for IDE projects, even where generators exist, are perceived as a problem. A general "make -project" initial run was generally considered a reasonable approach, but this should not need to build the full product using make, but needs to be much faster. > * The current situation is a hodgepodge of home brewed solution. Everyone has their own script or methods for setting up new clones with their IDE. > * A comprehensive set of instructions, per IDE, was requested. Good instructions might even go a long way of removing the need for automatic tooling. > * No current IDE solutions deal with test source code in a reasonable way. Opinion differed on whether the amount of tests were so large that they, too, needed to be selectively imported in the IDE. > * A more concrete problem with tests was that the jtreg tests all belong to their own packages, which resulted in an explosion of packages that at least Eclipse had a hard time handling. > > This is my interpretation of the developers' thought of the general quality of the existing integrations : > > * Eclipse (Java) -- works really lousy > * Eclipse (CDT) -- works quite well > * XCode -- works okay (for C++) > * Visual Studio -- works quite well (for C++) > * IntelliJ -- ? (I didn't record any reply) > * CLion -- acceptable, but have some annoying issues > * Vim -- you learn your way around > * Emacs -- as for Vim > * NetBeans -- unclear. One developer tried it but could not get it to work properly. > > /Magnus > > >> >> - August >> >> On Fri, Mar 1, 2019 at 12:14 PM Maurizio Cimadamore < >> maurizio.cimadamore at oracle.com> wrote: >> >>>> On 01/03/2019 18:05, Jonathan Gibbons wrote: >>>> Maurizio, >>>> >>>> Sounds good to me. >>>> >>>> I presume this will subsume the curiously-named "NetBeans Project" >>>> Group, that never quite gained any traction. >>> Yep - that happens to have a bit of a confusing name, as it's a Group >>> with the P-word in it; this new group will eventually subsume the other >>> (which will be garbage collected at some point). >>> >>> Maurizio >>> >>>> -- Jon >>>> >>>> >>>>> On 03/01/2019 08:28 AM, Maurizio Cimadamore wrote: >>>>> (This is not a call for votes; it is just a call for discussion.) >>>>> >>>>> At the last OpenJDK Committer Workshop in Brussels, we agreed to set >>>>> up some channel in which to discuss issues related to OpenJDK >>>>> tooling, and, more specifically IDE support. We already have pretty >>>>> comprehensive support for OpenJDK development in both IntelliJ and >>>>> Netbeans, but the main, long standing problem has been one of lack of >>>>> adequate communication and coordination between these various >>>>> efforts, which often led (frustrated) developers to the path of "I'll >>>>> write my own support". >>>>> >>>>> The goal of this group is, first and foremost, to extensively >>>>> document the alternatives that are already available at present, as >>>>> well as to capture discussions related to tooling support which are >>>>> currently scattered among many mailing list (compiler-dev, jtreg-dev, >>>>> build-dev). After some internal discussions, it feels like proposing >>>>> a group is the right thing to do because: (i) a group automatically >>>>> gets a mailing list and a page on openjdk.java.net - which can be >>>>> useful for communicating within the group and also for publishing the >>>>> much needed documentation; also (ii) a group is not tied to any >>>>> specific set of deliverables (unlike, say, an OpenJDK project), which >>>>> feels right in this case, as IDE support is likely to be a recurring >>>>> activity. >>>>> >>>>> We want OpenJDK to be a welcoming place for developers, and I feel >>>>> that improving IDE/tooling support plays a crucial role in reducing >>>>> the activation energy required to start hacking on the OpenJDK codebase. >>>>> >>>>> Thoughts? >>>>> >>>>> Cheers >>>>> Maurizio >>>>> >>>>> > From maurizio.cimadamore at oracle.com Tue Mar 5 18:04:58 2019 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Tue, 5 Mar 2019 18:04:58 +0000 Subject: Group Proposal, for discussion: IDE & Tooling support In-Reply-To: <3e611669-3f72-54c5-249b-0076664fdd08@oracle.com> References: <0f1a6f83-db25-b1e8-beb3-a6b6b8d84b85@oracle.com> <3e611669-3f72-54c5-249b-0076664fdd08@oracle.com> Message-ID: <0290ef7f-4db9-308f-f20c-7ed1cf0c1241@oracle.com> So, one of the thing that emerged at the OpenJDK Committer Workshop was mainly the need of having a place where to discuss IDE related issues. While build-dev and build-infra in general are all fine places to have these discussions (and we had some of these in the past), there are things that are suboptimal in our current approach: * specificity: build-dev has a lot more traffic on a lot of issues that have nothing to do with IDE support * scattered-ness: somethings, yes, will rely on build support to 'do the right thing' - but most of them don't see the jtreg plugin support in IntelliJ. That lives in code-tools and has nothing to do whatsoever with build-dev or makefiles, even. All discussion related to that is happening on jtreg-dev. So, we need a place for discuss things, and to provide documentation of _what already_ exists. At the moment, honestly, I'm much less interested into adding more features into the various supports we have. Do we need a separate repo to do the documentation part? I don't think so. And that's what led us to consider forming a group. Now, I don't feel too strongly about this - but a Group doesn't strike me as a choice that doesn't make sense either. As a closing comment, of course whatever we do might be affected (or affect!) build system components - so I'm not proposing we discuss things in a vacuum; but I want to stress the importance of centralizing all discussion and documentations in a place that feels 'independent' from compiler-dev, build-dev or jtreg-dev. Maurizio On 05/03/2019 11:10, Magnus Ihse Bursie wrote: > I agree that providing a great IDE experience is a very beneficial > thing, both for existing OpenJDK developers, and for attracting new ones. > > Is this goal is best served by creating a new group? I don't know. I'm > a bit skeptical, and think that this work still fits quite well under > the Build Group umbrella, but if this is not the general perception, I > will not protest against creating a new group. > > Also, an alternative to creating a group is to create a Project. I'm > certain the Build Group could sponsor an IDE Integration Project, or > something like that. A Project can also get mailing lists and repos, > but does not need to have a Group Lead that needs to perform > additional duties like sending a yearly status report, etc. From magnus.ihse.bursie at oracle.com Tue Mar 5 23:58:54 2019 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 6 Mar 2019 00:58:54 +0100 Subject: Group Proposal, for discussion: IDE & Tooling support In-Reply-To: <0290ef7f-4db9-308f-f20c-7ed1cf0c1241@oracle.com> References: <0f1a6f83-db25-b1e8-beb3-a6b6b8d84b85@oracle.com> <3e611669-3f72-54c5-249b-0076664fdd08@oracle.com> <0290ef7f-4db9-308f-f20c-7ed1cf0c1241@oracle.com> Message-ID: > 5 mars 2019 kl. 19:04 skrev Maurizio Cimadamore : > > So, one of the thing that emerged at the OpenJDK Committer Workshop was mainly the need of having a place where to discuss IDE related issues. > > While build-dev and build-infra in general are all fine places to have these discussions (and we had some of these in the past), there are things that are suboptimal in our current approach: > > * specificity: build-dev has a lot more traffic on a lot of issues that have nothing to do with IDE support > * scattered-ness: somethings, yes, will rely on build support to 'do the right thing' - but most of them don't see the jtreg plugin support in IntelliJ. That lives in code-tools and has nothing to do whatsoever with build-dev or makefiles, even. All discussion related to that is happening on jtreg-dev. > > So, we need a place for discuss things, and to provide documentation of _what already_ exists. At the moment, honestly, I'm much less interested into adding more features into the various supports we have. > > Do we need a separate repo to do the documentation part? I don't think so. And that's what led us to consider forming a group. Now, I don't feel too strongly about this - but a Group doesn't strike me as a choice that doesn't make sense either. > > As a closing comment, of course whatever we do might be affected (or affect!) build system components - so I'm not proposing we discuss things in a vacuum; but I want to stress the importance of centralizing all discussion and documentations in a place that feels 'independent' from compiler-dev, build-dev or jtreg-dev. > Sounds like you've thought this through. I'll just have to accept that there'll be yet another list I'll have to subscribe to. ;-) /Magnus > Maurizio > >> On 05/03/2019 11:10, Magnus Ihse Bursie wrote: >> I agree that providing a great IDE experience is a very beneficial thing, both for existing OpenJDK developers, and for attracting new ones. >> >> Is this goal is best served by creating a new group? I don't know. I'm a bit skeptical, and think that this work still fits quite well under the Build Group umbrella, but if this is not the general perception, I will not protest against creating a new group. >> >> Also, an alternative to creating a group is to create a Project. I'm certain the Build Group could sponsor an IDE Integration Project, or something like that. A Project can also get mailing lists and repos, but does not need to have a Group Lead that needs to perform additional duties like sending a yearly status report, etc. From robin.westberg at oracle.com Thu Mar 7 06:42:52 2019 From: robin.westberg at oracle.com (Robin Westberg) Date: Thu, 7 Mar 2019 07:42:52 +0100 Subject: Group Proposal, for discussion: IDE & Tooling support In-Reply-To: <0f1a6f83-db25-b1e8-beb3-a6b6b8d84b85@oracle.com> References: <0f1a6f83-db25-b1e8-beb3-a6b6b8d84b85@oracle.com> Message-ID: <6961032F-C48F-454A-84BF-E045A1AC513E@oracle.com> Hi Maurizio, This sounds like a very good idea! I?ve spent some time on helping to improve the IDE support for the OpenJDK native code, and would certainly be interested in collaboration in that area. And I agree that documenting existing alternatives would be good, it?s possible to get a quite good IDE experience for the native code already, but you have to know where to look.. Best regards, Robin > On 1 Mar 2019, at 17:28, Maurizio Cimadamore wrote: > > (This is not a call for votes; it is just a call for discussion.) > > At the last OpenJDK Committer Workshop in Brussels, we agreed to set up some channel in which to discuss issues related to OpenJDK tooling, and, more specifically IDE support. We already have pretty comprehensive support for OpenJDK development in both IntelliJ and Netbeans, but the main, long standing problem has been one of lack of adequate communication and coordination between these various efforts, which often led (frustrated) developers to the path of "I'll write my own support". > > The goal of this group is, first and foremost, to extensively document the alternatives that are already available at present, as well as to capture discussions related to tooling support which are currently scattered among many mailing list (compiler-dev, jtreg-dev, build-dev). After some internal discussions, it feels like proposing a group is the right thing to do because: (i) a group automatically gets a mailing list and a page on openjdk.java.net - which can be useful for communicating within the group and also for publishing the much needed documentation; also (ii) a group is not tied to any specific set of deliverables (unlike, say, an OpenJDK project), which feels right in this case, as IDE support is likely to be a recurring activity. > > We want OpenJDK to be a welcoming place for developers, and I feel that improving IDE/tooling support plays a crucial role in reducing the activation energy required to start hacking on the OpenJDK codebase. > > Thoughts? > > Cheers > Maurizio > > From christoph.langer at sap.com Thu Mar 7 23:31:26 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 7 Mar 2019 23:31:26 +0000 Subject: Group Proposal, for discussion: IDE & Tooling support In-Reply-To: <6961032F-C48F-454A-84BF-E045A1AC513E@oracle.com> References: <0f1a6f83-db25-b1e8-beb3-a6b6b8d84b85@oracle.com> <6961032F-C48F-454A-84BF-E045A1AC513E@oracle.com> Message-ID: Hi Maurizio, thanks for driving this topic after the discussions in the OpenJDK Committers Workshop. I would really welcome a mailing list that focuses on IDE integration topics and starting a group seems to be a reasonable way to accomplish this. I personally spent some efforts into setting up Eclipse for OpenJDK Java development which is probably not quite state of the art in times of IntelliJ but still not as bad as its reputation ?? I would love to share and discuss my work in this group/mailing list. So, when is it going to open? ?? Best regards Christoph > > On 1 Mar 2019, at 17:28, Maurizio Cimadamore > wrote: > > > > (This is not a call for votes; it is just a call for discussion.) > > > > At the last OpenJDK Committer Workshop in Brussels, we agreed to set up > some channel in which to discuss issues related to OpenJDK tooling, and, > more specifically IDE support. We already have pretty comprehensive > support for OpenJDK development in both IntelliJ and Netbeans, but the > main, long standing problem has been one of lack of adequate > communication and coordination between these various efforts, which often > led (frustrated) developers to the path of "I'll write my own support". > > > > The goal of this group is, first and foremost, to extensively document the > alternatives that are already available at present, as well as to capture > discussions related to tooling support which are currently scattered among > many mailing list (compiler-dev, jtreg-dev, build-dev). After some internal > discussions, it feels like proposing a group is the right thing to do because: (i) > a group automatically gets a mailing list and a page on openjdk.java.net - > which can be useful for communicating within the group and also for > publishing the much needed documentation; also (ii) a group is not tied to > any specific set of deliverables (unlike, say, an OpenJDK project), which feels > right in this case, as IDE support is likely to be a recurring activity. > > > > We want OpenJDK to be a welcoming place for developers, and I feel that > improving IDE/tooling support plays a crucial role in reducing the activation > energy required to start hacking on the OpenJDK codebase. > > > > Thoughts? > > > > Cheers > > Maurizio From thomas.stuefe at gmail.com Fri Mar 8 02:40:11 2019 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Fri, 8 Mar 2019 03:40:11 +0100 Subject: Group Proposal, for discussion: IDE & Tooling support In-Reply-To: <4b0ef425-096b-cefd-ce5c-2c422cf9702c@oracle.com> References: <0f1a6f83-db25-b1e8-beb3-a6b6b8d84b85@oracle.com> <5d9c6b56-33e8-d20f-c402-6b29696e1054@oracle.com> <41981bd3-b8cb-ff6e-b615-ce80cce716b1@oracle.com> <4b0ef425-096b-cefd-ce5c-2c422cf9702c@oracle.com> Message-ID: Hi Magnus, Small additions to your thoughts: IntelliJ community edition works very well for the java parts including jtreg. Maurizios jtreg Plugin works, now even for the hotspot jtreg tests. Project generation works in my experience without a hitch, seems very stable. CDT: Most of the folks at Sap use that for the hotspot parts. Many roll their own setup. I have one which works with gtests too. One of our guys (Richard) has a very elaborate setup allowing him to switch target platforms and it includes system headers for all platforms too, not sure if such a thing could be generated from the make, since by design that would be only for one platform. But perhaps that complexity is only needed for people working regularly on platform dependent code. Cheers, thomas On Tue 5. Mar 2019 at 14:37, Magnus Ihse Bursie < magnus.ihse.bursie at oracle.com> wrote: > > > On 2019-03-04 01:40, August Nagro wrote: > > Hi Maurizio, > > > > I think this is a great idea. I personally find things easiest when all > > developer documentation/instructions are aggregated in a single > directory, > > or even single file. The big building.html in the jdk is a good example > of > > this. Maybe create a doc/development.html? > > Writing down the existing IDE support in doc/development.md seems like a > good idea to me, and an excellent start! > > Let me add in some of my documentation from my latest unofficial survey > on IDE usage, and the perceived quality of IDE integration in OpenJDK. > This is based solely on the replies of my fellow OpenJDK developers in > the Stockholm Office, which means it is quite Hotspot-skewed, and it > does not have that many data points. Still, I think it is a good > starting point, and probably is in the right ballpark. > > List of IDEs used: > > * Eclipse (Java) [3 developers] > * Eclipse (CDT) [3 developers] > * XCode [2 developers] > * Visual Studio [2 developers] > * IntelliJ [1 developer] > * CLion [1 developer] > * Vim [2 developers] > * Emacs [1-2 developers] > * NetBeans [0 developers] > > Some general reflections: > > * OpenJDK is a huge project. None of the IDEs tend to deal well with > *all* of the OpenJDK being imported at once, so some kind of selection > mechanism seems to be required, and this goes for all IDEs. > * A clear split from the developer perspective is Hotspot/non-Hotspot > developers. Hotspot developers cares only (or mostly) about src/hotspot, > and is only (or mostly) interested in C++ code. Non-hotspot developers > typically focus on certain selected modules from src, and needs to work > with either pure Java, or a mix of Java and native code. > * No current IDE solution works well with a mix of native and Java code. > It's unclear to me if this is an inherent limitations on the IDEs (might > be in some cases, but perhaps not in all) or just in the way we > currently interact with them. > * Initial setup for IDE projects, even where generators exist, are > perceived as a problem. A general "make -project" initial run was > generally considered a reasonable approach, but this should not need to > build the full product using make, but needs to be much faster. > * The current situation is a hodgepodge of home brewed solution. > Everyone has their own script or methods for setting up new clones with > their IDE. > * A comprehensive set of instructions, per IDE, was requested. Good > instructions might even go a long way of removing the need for automatic > tooling. > * No current IDE solutions deal with test source code in a reasonable > way. Opinion differed on whether the amount of tests were so large that > they, too, needed to be selectively imported in the IDE. > * A more concrete problem with tests was that the jtreg tests all > belong to their own packages, which resulted in an explosion of packages > that at least Eclipse had a hard time handling. > > This is my interpretation of the developers' thought of the general > quality of the existing integrations : > > * Eclipse (Java) -- works really lousy > * Eclipse (CDT) -- works quite well > * XCode -- works okay (for C++) > * Visual Studio -- works quite well (for C++) > * IntelliJ -- ? (I didn't record any reply) > * CLion -- acceptable, but have some annoying issues > * Vim -- you learn your way around > * Emacs -- as for Vim > * NetBeans -- unclear. One developer tried it but could not get it to > work properly. > > /Magnus > > > > > > - August > > > > On Fri, Mar 1, 2019 at 12:14 PM Maurizio Cimadamore < > > maurizio.cimadamore at oracle.com> wrote: > > > >> On 01/03/2019 18:05, Jonathan Gibbons wrote: > >>> Maurizio, > >>> > >>> Sounds good to me. > >>> > >>> I presume this will subsume the curiously-named "NetBeans Project" > >>> Group, that never quite gained any traction. > >> Yep - that happens to have a bit of a confusing name, as it's a Group > >> with the P-word in it; this new group will eventually subsume the other > >> (which will be garbage collected at some point). > >> > >> Maurizio > >> > >>> -- Jon > >>> > >>> > >>> On 03/01/2019 08:28 AM, Maurizio Cimadamore wrote: > >>>> (This is not a call for votes; it is just a call for discussion.) > >>>> > >>>> At the last OpenJDK Committer Workshop in Brussels, we agreed to set > >>>> up some channel in which to discuss issues related to OpenJDK > >>>> tooling, and, more specifically IDE support. We already have pretty > >>>> comprehensive support for OpenJDK development in both IntelliJ and > >>>> Netbeans, but the main, long standing problem has been one of lack of > >>>> adequate communication and coordination between these various > >>>> efforts, which often led (frustrated) developers to the path of "I'll > >>>> write my own support". > >>>> > >>>> The goal of this group is, first and foremost, to extensively > >>>> document the alternatives that are already available at present, as > >>>> well as to capture discussions related to tooling support which are > >>>> currently scattered among many mailing list (compiler-dev, jtreg-dev, > >>>> build-dev). After some internal discussions, it feels like proposing > >>>> a group is the right thing to do because: (i) a group automatically > >>>> gets a mailing list and a page on openjdk.java.net - which can be > >>>> useful for communicating within the group and also for publishing the > >>>> much needed documentation; also (ii) a group is not tied to any > >>>> specific set of deliverables (unlike, say, an OpenJDK project), which > >>>> feels right in this case, as IDE support is likely to be a recurring > >>>> activity. > >>>> > >>>> We want OpenJDK to be a welcoming place for developers, and I feel > >>>> that improving IDE/tooling support plays a crucial role in reducing > >>>> the activation energy required to start hacking on the OpenJDK > codebase. > >>>> > >>>> Thoughts? > >>>> > >>>> Cheers > >>>> Maurizio > >>>> > >>>> > > From thomas.stuefe at gmail.com Fri Mar 8 02:43:04 2019 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Fri, 8 Mar 2019 03:43:04 +0100 Subject: Group Proposal, for discussion: IDE & Tooling support In-Reply-To: <0f1a6f83-db25-b1e8-beb3-a6b6b8d84b85@oracle.com> References: <0f1a6f83-db25-b1e8-beb3-a6b6b8d84b85@oracle.com> Message-ID: Hi Maurizio, Thank you for doing this, this has been needed for a long time. Cheers, Thomas On Fri 1. Mar 2019 at 17:28, Maurizio Cimadamore < maurizio.cimadamore at oracle.com> wrote: > (This is not a call for votes; it is just a call for discussion.) > > At the last OpenJDK Committer Workshop in Brussels, we agreed to set up > some channel in which to discuss issues related to OpenJDK tooling, and, > more specifically IDE support. We already have pretty comprehensive > support for OpenJDK development in both IntelliJ and Netbeans, but the > main, long standing problem has been one of lack of adequate > communication and coordination between these various efforts, which > often led (frustrated) developers to the path of "I'll write my own > support". > > The goal of this group is, first and foremost, to extensively document > the alternatives that are already available at present, as well as to > capture discussions related to tooling support which are currently > scattered among many mailing list (compiler-dev, jtreg-dev, build-dev). > After some internal discussions, it feels like proposing a group is the > right thing to do because: (i) a group automatically gets a mailing list > and a page on openjdk.java.net - which can be useful for communicating > within the group and also for publishing the much needed documentation; > also (ii) a group is not tied to any specific set of deliverables > (unlike, say, an OpenJDK project), which feels right in this case, as > IDE support is likely to be a recurring activity. > > We want OpenJDK to be a welcoming place for developers, and I feel that > improving IDE/tooling support plays a crucial role in reducing the > activation energy required to start hacking on the OpenJDK codebase. > > Thoughts? > > Cheers > Maurizio > > > From christoph.langer at sap.com Fri Mar 8 08:16:09 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Fri, 8 Mar 2019 08:16:09 +0000 Subject: Group Proposal, for discussion: IDE & Tooling support In-Reply-To: References: <0f1a6f83-db25-b1e8-beb3-a6b6b8d84b85@oracle.com> <6961032F-C48F-454A-84BF-E045A1AC513E@oracle.com> Message-ID: BTW: If anyone is interested in trying Eclipse for OpenJDK Java development, my work can be found here: https://github.com/RealCLanger/OpenJDKEclipseProjects :) I'm open for suggestions & contributions... > -----Original Message----- > From: Langer, Christoph > Sent: Freitag, 8. M?rz 2019 00:31 > To: Maurizio Cimadamore ; > discuss at openjdk.java.net > Subject: RE: Group Proposal, for discussion: IDE & Tooling support > > Hi Maurizio, > > thanks for driving this topic after the discussions in the OpenJDK Committers > Workshop. > > I would really welcome a mailing list that focuses on IDE integration topics > and starting a group seems to be a reasonable way to accomplish this. > > I personally spent some efforts into setting up Eclipse for OpenJDK Java > development which is probably not quite state of the art in times of IntelliJ > but still not as bad as its reputation ?? I would love to share and discuss my > work in this group/mailing list. > > So, when is it going to open? ?? > > Best regards > Christoph > > > > On 1 Mar 2019, at 17:28, Maurizio Cimadamore > > wrote: > > > > > > (This is not a call for votes; it is just a call for discussion.) > > > > > > At the last OpenJDK Committer Workshop in Brussels, we agreed to set > up > > some channel in which to discuss issues related to OpenJDK tooling, and, > > more specifically IDE support. We already have pretty comprehensive > > support for OpenJDK development in both IntelliJ and Netbeans, but the > > main, long standing problem has been one of lack of adequate > > communication and coordination between these various efforts, which > often > > led (frustrated) developers to the path of "I'll write my own support". > > > > > > The goal of this group is, first and foremost, to extensively document the > > alternatives that are already available at present, as well as to capture > > discussions related to tooling support which are currently scattered among > > many mailing list (compiler-dev, jtreg-dev, build-dev). After some internal > > discussions, it feels like proposing a group is the right thing to do because: > (i) > > a group automatically gets a mailing list and a page on openjdk.java.net - > > which can be useful for communicating within the group and also for > > publishing the much needed documentation; also (ii) a group is not tied to > > any specific set of deliverables (unlike, say, an OpenJDK project), which > feels > > right in this case, as IDE support is likely to be a recurring activity. > > > > > > We want OpenJDK to be a welcoming place for developers, and I feel that > > improving IDE/tooling support plays a crucial role in reducing the activation > > energy required to start hacking on the OpenJDK codebase. > > > > > > Thoughts? > > > > > > Cheers > > > Maurizio From adam.farley at uk.ibm.com Wed Mar 13 12:27:06 2019 From: adam.farley at uk.ibm.com (Adam Farley8) Date: Wed, 13 Mar 2019 12:27:06 +0000 Subject: Proposal: Mailing List Cull In-Reply-To: References: Message-ID: (Preface: I may be sending this to the wrong list, so advice on the correct list would be appreciated.) Hey All, There's a lot of mailing lists here, including a few that've been dead for 5 years, and I think it's making it hard for contributors to find the right list. Here's a list of mailing lists seeing no/minimal use, and a set of proposals to go with them. Proposal 1: Cull (archive) one or more of these mailing list groups, with exceptions made for lists anyone still wants, or actively monitors. Why? Because having 151 non-archived mailing lists makes it harder for people to find the right one. Also makes it easier to find black holes (non-monitored lists) to drop valid bugs into. Proposal 2: Hide the archived mailing lists on the primary "mailing lists" view. Why? Because it dilutes the list of active lists and makes finding the right one harder. Proposal 3: Create a short list of the most useful channels to the casual contributor, making it easier to find the primary hotspot, JCL, docs lists, etc. Why? Ease of use. Ability to contribute should be based on knowledge of the code base, not knowledge of the mailing lists, Proposal 4: Hide the mailing lists whose sole purpose is to display automated messages when a project has been committed to. Proposal 4: Make Proposals 2, 3, and 4 the default view when you click on "Mailing lists" from the main page. Why? Ease of use again. One form this could take is: the user clicks on "mailing lists" on the primary openjdk page, and sees a minimal list of mailing lists, with toggles to show the lists hidden by 2, 3, and 4. Constructive opinions welcome. :) Best Regards Adam Farley IBM Runtimes P.S. Spam and "hep please" don't count as emails. -- Appendix list: 1: Lists with no emails in 2 years or more. (Dead) 2: Lists with no emails inside the last 6 months. (Presumed Dead) 3: Lists with less than 2 emails (average) per month for the past year (Rosebud) -- Appendix 1: (Dead) anno-pipeline-dev btrace-dev compiler-grammar-dev cvmi-dev friday-stats-dev graphics-rasterizer-dev guide-discuss icedtea-changes java-se-8-spec-comments java-se-8-spec-experts java-se-8-spec-observers java-se-9-spec-comments java-se-9-spec-experts java-se-mr-spec-comments javadoc-next-dev jep-changes kona-dev lambda-libs-spec-comments lambda-libs-spec-experts lambda-libs-spec-observers penrose-dev penrose-discuss tiered-attrib-dev type-annotations-dev type-annotations-spec-comments type-annotations-spec-experts type-annotations-spec-observers xrender-dev -- Appendix 2: (Presumed Dead) detroit-dev dio-dev duke-dev graal-changes haiku-port-dev harfbuzz-dev icedtea-test java-se-9-spec-observers java-se-spec-comments jdk-hs-changes jmm-dev nb-projects-dev nio-discuss panama-spec-experts sandbox-changes sctp-dev sumatra-dev valhalla-spec-comments -- Appendix 3: (Rosebud) asmtools-dev caciocavallo-dev conformance-discuss doccheck-dev jmx-dev jol-dev lambda-spec-comments lambda-spec-experts lambda-spec-observers macosx-port-dev metropolis-dev mips-port platform-jep-discuss Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From adam.farley at uk.ibm.com Wed Mar 13 12:30:24 2019 From: adam.farley at uk.ibm.com (Adam Farley8) Date: Wed, 13 Mar 2019 12:30:24 +0000 Subject: Proposal: Mailing List Cull In-Reply-To: References: Message-ID: Typo: There are two proposal 4's. Corrected. - Adam ----------------------------- (Preface: I may be sending this to the wrong list, so advice on the correct list would be appreciated.) Hey All, There's a lot of mailing lists here, including a few that've been dead for 5 years, and I think it's making it hard for contributors to find the right list. Here's a list of mailing lists seeing no/minimal use, and a set of proposals to go with them. Proposal 1: Cull (archive) one or more of these mailing list groups, with exceptions made for lists anyone still wants, or actively monitors. Why? Because having 151 non-archived mailing lists makes it harder for people to find the right one. Also makes it easier to find black holes (non-monitored lists) to drop valid bugs into. Proposal 2: Hide the archived mailing lists on the primary "mailing lists" view. Why? Because it dilutes the list of active lists and makes finding the right one harder. Proposal 3: Create a short list of the most useful channels to the casual contributor, making it easier to find the primary hotspot, JCL, docs lists, etc. Why? Ease of use. Ability to contribute should be based on knowledge of the code base, not knowledge of the mailing lists, Proposal 4: Hide the mailing lists whose sole purpose is to display automated messages when a project has been committed to. Proposal 5: Make Proposals 2, 3, and 4 the default view when you click on "Mailing lists" from the main page. Why? Ease of use again. One form this could take is: the user clicks on "mailing lists" on the primary openjdk page, and sees a minimal list of mailing lists, with toggles to show the lists hidden by 2, 3, and 4. Constructive opinions welcome. :) Best Regards Adam Farley IBM Runtimes P.S. Spam and "hep please" don't count as emails. -- Appendix list: 1: Lists with no emails in 2 years or more. (Dead) 2: Lists with no emails inside the last 6 months. (Presumed Dead) 3: Lists with less than 2 emails (average) per month for the past year (Rosebud) -- Appendix 1: (Dead) anno-pipeline-dev btrace-dev compiler-grammar-dev cvmi-dev friday-stats-dev graphics-rasterizer-dev guide-discuss icedtea-changes java-se-8-spec-comments java-se-8-spec-experts java-se-8-spec-observers java-se-9-spec-comments java-se-9-spec-experts java-se-mr-spec-comments javadoc-next-dev jep-changes kona-dev lambda-libs-spec-comments lambda-libs-spec-experts lambda-libs-spec-observers penrose-dev penrose-discuss tiered-attrib-dev type-annotations-dev type-annotations-spec-comments type-annotations-spec-experts type-annotations-spec-observers xrender-dev -- Appendix 2: (Presumed Dead) detroit-dev dio-dev duke-dev graal-changes haiku-port-dev harfbuzz-dev icedtea-test java-se-9-spec-observers java-se-spec-comments jdk-hs-changes jmm-dev nb-projects-dev nio-discuss panama-spec-experts sandbox-changes sctp-dev sumatra-dev valhalla-spec-comments -- Appendix 3: (Rosebud) asmtools-dev caciocavallo-dev conformance-discuss doccheck-dev jmx-dev jol-dev lambda-spec-comments lambda-spec-experts lambda-spec-observers macosx-port-dev metropolis-dev mips-port platform-jep-discuss Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From brian.goetz at oracle.com Wed Mar 13 12:33:18 2019 From: brian.goetz at oracle.com (Brian Goetz) Date: Wed, 13 Mar 2019 08:33:18 -0400 Subject: Proposal: Mailing List Cull In-Reply-To: References: Message-ID: <819F3246-6BA9-4247-A654-6794CD91090F@oracle.com> panama-spec-experts, valhalla-spec-comments, metropolis-dev are associated with active projects, even though they are getting little traffic. lambda-spec-* should go in the first category as this project is complete and its spec is now part of the JLS. > On Mar 13, 2019, at 8:27 AM, Adam Farley8 wrote: > > (Preface: I may be sending this to the wrong list, so advice on the > correct list would be appreciated.) > > Hey All, > > There's a lot of mailing lists here, including a few that've been dead for > 5 years, and I think it's making it hard for contributors to find the > right list. > > Here's a list of mailing lists seeing no/minimal use, and a set of > proposals to go with them. > > Proposal 1: Cull (archive) one or more of these mailing list groups, with > exceptions made for lists anyone still wants, or actively monitors. > Why? Because having 151 non-archived mailing lists makes it harder for > people to find the right one. Also makes it easier to find black holes > (non-monitored lists) to drop valid bugs into. > > Proposal 2: Hide the archived mailing lists on the primary "mailing lists" > view. > Why? Because it dilutes the list of active lists and makes finding the > right one harder. > > Proposal 3: Create a short list of the most useful channels to the casual > contributor, making it easier to find the primary hotspot, JCL, docs > lists, etc. > Why? Ease of use. Ability to contribute should be based on knowledge of > the code base, not knowledge of the mailing lists, > > Proposal 4: Hide the mailing lists whose sole purpose is to display > automated messages when a project has been committed to. > > Proposal 4: Make Proposals 2, 3, and 4 the default view when you click on > "Mailing lists" from the main page. > Why? Ease of use again. One form this could take is: the user clicks on > "mailing lists" on the primary openjdk page, and sees a minimal list of > mailing lists, with toggles to show the lists hidden by 2, 3, and 4. > > Constructive opinions welcome. :) > > Best Regards > > Adam Farley > IBM Runtimes > > P.S. Spam and "hep please" don't count as emails. > > -- Appendix list: > 1: Lists with no emails in 2 years or more. (Dead) > 2: Lists with no emails inside the last 6 months. (Presumed Dead) > 3: Lists with less than 2 emails (average) per month for the past year > (Rosebud) > > -- Appendix 1: (Dead) > anno-pipeline-dev > btrace-dev > compiler-grammar-dev > cvmi-dev > friday-stats-dev > graphics-rasterizer-dev > guide-discuss > icedtea-changes > java-se-8-spec-comments > java-se-8-spec-experts > java-se-8-spec-observers > java-se-9-spec-comments > java-se-9-spec-experts > java-se-mr-spec-comments > javadoc-next-dev > jep-changes > kona-dev > lambda-libs-spec-comments > lambda-libs-spec-experts > lambda-libs-spec-observers > penrose-dev > penrose-discuss > tiered-attrib-dev > type-annotations-dev > type-annotations-spec-comments > type-annotations-spec-experts > type-annotations-spec-observers > xrender-dev > > -- Appendix 2: (Presumed Dead) > detroit-dev > dio-dev > duke-dev > graal-changes > haiku-port-dev > harfbuzz-dev > icedtea-test > java-se-9-spec-observers > java-se-spec-comments > jdk-hs-changes > jmm-dev > nb-projects-dev > nio-discuss > panama-spec-experts > sandbox-changes > sctp-dev > sumatra-dev > valhalla-spec-comments > > -- Appendix 3: (Rosebud) > asmtools-dev > caciocavallo-dev > conformance-discuss > doccheck-dev > jmx-dev > jol-dev > lambda-spec-comments > lambda-spec-experts > lambda-spec-observers > macosx-port-dev > metropolis-dev > mips-port > platform-jep-discuss > > > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From adam.farley at uk.ibm.com Wed Mar 13 13:05:38 2019 From: adam.farley at uk.ibm.com (Adam Farley8) Date: Wed, 13 Mar 2019 13:05:38 +0000 Subject: Proposal: Mailing List Cull In-Reply-To: <819F3246-6BA9-4247-A654-6794CD91090F@oracle.com> References: <819F3246-6BA9-4247-A654-6794CD91090F@oracle.com> Message-ID: Hi Brian, Thanks for the info. I've corrected the lists. lambda-spec-* is now in the new category "project completed" to recognise that these lists are now superfluous, without implying that they lack activity. Best Regards Adam Farley IBM Runtimes Brian Goetz wrote on 13/03/2019 12:33:18: > From: Brian Goetz > To: Adam Farley8 > Cc: discuss at openjdk.java.net > Date: 13/03/2019 12:37 > Subject: Re: Proposal: Mailing List Cull > > panama-spec-experts, valhalla-spec-comments, metropolis-dev are > associated with active projects, even though they are getting littletraffic. > > lambda-spec-* should go in the first category as this project is > complete and its spec is now part of the JLS. > > > On Mar 13, 2019, at 8:27 AM, Adam Farley8 wrote: > > > > (Preface: I may be sending this to the wrong list, so advice on the > > correct list would be appreciated.) > > > > Hey All, > > > > There's a lot of mailing lists here, including a few that've been dead for > > 5 years, and I think it's making it hard for contributors to find the > > right list. > > > > Here's a list of mailing lists seeing no/minimal use, and a set of > > proposals to go with them. > > > > Proposal 1: Cull (archive) one or more of these mailing list groups, with > > exceptions made for lists anyone still wants, or actively monitors. > > Why? Because having 151 non-archived mailing lists makes it harder for > > people to find the right one. Also makes it easier to find black holes > > (non-monitored lists) to drop valid bugs into. > > > > Proposal 2: Hide the archived mailing lists on the primary "mailing lists" > > view. > > Why? Because it dilutes the list of active lists and makes finding the > > right one harder. > > > > Proposal 3: Create a short list of the most useful channels to the casual > > contributor, making it easier to find the primary hotspot, JCL, docs > > lists, etc. > > Why? Ease of use. Ability to contribute should be based on knowledge of > > the code base, not knowledge of the mailing lists, > > > > Proposal 4: Hide the mailing lists whose sole purpose is to display > > automated messages when a project has been committed to. > > > > Proposal 4: Make Proposals 2, 3, and 4 the default view when you click on > > "Mailing lists" from the main page. > > Why? Ease of use again. One form this could take is: the user clicks on > > "mailing lists" on the primary openjdk page, and sees a minimal list of > > mailing lists, with toggles to show the lists hidden by 2, 3, and 4. > > > > Constructive opinions welcome. :) > > > > Best Regards > > > > Adam Farley > > IBM Runtimes > > > > P.S. Spam and "hep please" don't count as emails. > > > > -- Appendix list: > > 1: Lists with no emails in 2 years or more. (Dead) > > 2: Lists with no emails inside the last 6 months. (Presumed Dead) > > 3: Lists with less than 2 emails (average) per month for the past year (Rosebud) > > 4: Lists whose associated project has been completed. (Project Completed) > > > > -- Appendix 1: (Dead) > > anno-pipeline-dev > > btrace-dev > > compiler-grammar-dev > > cvmi-dev > > friday-stats-dev > > graphics-rasterizer-dev > > guide-discuss > > icedtea-changes > > java-se-8-spec-comments > > java-se-8-spec-experts > > java-se-8-spec-observers > > java-se-9-spec-comments > > java-se-9-spec-experts > > java-se-mr-spec-comments > > javadoc-next-dev > > jep-changes > > kona-dev > > lambda-libs-spec-comments > > lambda-libs-spec-experts > > lambda-libs-spec-observers > > penrose-dev > > penrose-discuss > > tiered-attrib-dev > > type-annotations-dev > > type-annotations-spec-comments > > type-annotations-spec-experts > > type-annotations-spec-observers > > xrender-dev > > > > -- Appendix 2: (Presumed Dead) > > detroit-dev > > dio-dev > > duke-dev > > graal-changes > > haiku-port-dev > > harfbuzz-dev > > icedtea-test > > java-se-9-spec-observers > > java-se-spec-comments > > jdk-hs-changes > > jmm-dev > > nb-projects-dev > > nio-discuss > > sandbox-changes > > sctp-dev > > sumatra-dev > > > > -- Appendix 3: (Rosebud) > > asmtools-dev > > caciocavallo-dev > > conformance-discuss > > doccheck-dev > > jmx-dev > > jol-dev > > macosx-port-dev > > mips-port > > platform-jep-discuss > > > > -- Appendix 4: (Project Completed) > > lambda-spec-comments > > lambda-spec-experts > > lambda-spec-observers > > > > > > Unless stated otherwise above: > > IBM United Kingdom Limited - Registered in England and Wales with number > > 741598. > > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From brian.goetz at oracle.com Wed Mar 13 13:18:16 2019 From: brian.goetz at oracle.com (Brian Goetz) Date: Wed, 13 Mar 2019 09:18:16 -0400 Subject: Proposal: Mailing List Cull In-Reply-To: References: Message-ID: Without commenting on the specific proposal, I agree that having a lot of ?dead? mailing lists both (a) could give off the appearance of being a ghost town and (b) makes it harder to find where the active discussion is. Given that many lists are for projects that are no longer active (some just ran off the road, others completed their mission and should be wound down), some move to guide users to the active lists while preserving the history of the inactive lists would be good. Note that Proposal 3 is really a separate question from the ?how do we display mailing lists? question; it is really about creating a ?start here? page, which is orthogonal to how the mailing lists are organized and displayed. The next steps can be taken in parallel: - Determine a course of action for dealing with dead / dormant lists (this is mostly a discussion task); - Determine the actual deadness / dormancy status of the lists that you identified. This is a research task. The place to start here is to go to the project leads for the owning projects or the group leads for the owning groups, and ask them if there is some reason they are more active than they appear. > On Mar 13, 2019, at 8:27 AM, Adam Farley8 wrote: > > (Preface: I may be sending this to the wrong list, so advice on the > correct list would be appreciated.) > > Hey All, > > There's a lot of mailing lists here, including a few that've been dead for > 5 years, and I think it's making it hard for contributors to find the > right list. > > Here's a list of mailing lists seeing no/minimal use, and a set of > proposals to go with them. > > Proposal 1: Cull (archive) one or more of these mailing list groups, with > exceptions made for lists anyone still wants, or actively monitors. > Why? Because having 151 non-archived mailing lists makes it harder for > people to find the right one. Also makes it easier to find black holes > (non-monitored lists) to drop valid bugs into. > > Proposal 2: Hide the archived mailing lists on the primary "mailing lists" > view. > Why? Because it dilutes the list of active lists and makes finding the > right one harder. > > Proposal 3: Create a short list of the most useful channels to the casual > contributor, making it easier to find the primary hotspot, JCL, docs > lists, etc. > Why? Ease of use. Ability to contribute should be based on knowledge of > the code base, not knowledge of the mailing lists, > > Proposal 4: Hide the mailing lists whose sole purpose is to display > automated messages when a project has been committed to. > > Proposal 4: Make Proposals 2, 3, and 4 the default view when you click on > "Mailing lists" from the main page. > Why? Ease of use again. One form this could take is: the user clicks on > "mailing lists" on the primary openjdk page, and sees a minimal list of > mailing lists, with toggles to show the lists hidden by 2, 3, and 4. > > Constructive opinions welcome. :) > > Best Regards > > Adam Farley > IBM Runtimes > > P.S. Spam and "hep please" don't count as emails. > > -- Appendix list: > 1: Lists with no emails in 2 years or more. (Dead) > 2: Lists with no emails inside the last 6 months. (Presumed Dead) > 3: Lists with less than 2 emails (average) per month for the past year > (Rosebud) > > -- Appendix 1: (Dead) > anno-pipeline-dev > btrace-dev > compiler-grammar-dev > cvmi-dev > friday-stats-dev > graphics-rasterizer-dev > guide-discuss > icedtea-changes > java-se-8-spec-comments > java-se-8-spec-experts > java-se-8-spec-observers > java-se-9-spec-comments > java-se-9-spec-experts > java-se-mr-spec-comments > javadoc-next-dev > jep-changes > kona-dev > lambda-libs-spec-comments > lambda-libs-spec-experts > lambda-libs-spec-observers > penrose-dev > penrose-discuss > tiered-attrib-dev > type-annotations-dev > type-annotations-spec-comments > type-annotations-spec-experts > type-annotations-spec-observers > xrender-dev > > -- Appendix 2: (Presumed Dead) > detroit-dev > dio-dev > duke-dev > graal-changes > haiku-port-dev > harfbuzz-dev > icedtea-test > java-se-9-spec-observers > java-se-spec-comments > jdk-hs-changes > jmm-dev > nb-projects-dev > nio-discuss > panama-spec-experts > sandbox-changes > sctp-dev > sumatra-dev > valhalla-spec-comments > > -- Appendix 3: (Rosebud) > asmtools-dev > caciocavallo-dev > conformance-discuss > doccheck-dev > jmx-dev > jol-dev > lambda-spec-comments > lambda-spec-experts > lambda-spec-observers > macosx-port-dev > metropolis-dev > mips-port > platform-jep-discuss > > > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From adam.farley at uk.ibm.com Wed Mar 13 13:53:11 2019 From: adam.farley at uk.ibm.com (Adam Farley8) Date: Wed, 13 Mar 2019 13:53:11 +0000 Subject: Proposal: Mailing List Cull In-Reply-To: References: Message-ID: I agree with all of the points in Brian's email. This initial email chain is to show the problem, and to gather popular support for a large-scale cleanup, prior to approaching the list owners. Plus, this gives people a chance to add/remove lists like Brian has done, and also to identify any "overall list management" group who should be consulted before pursuing this task. Best Regards Adam Farley IBM Runtimes Brian Goetz wrote on 13/03/2019 13:18:16: > From: Brian Goetz > To: Adam Farley8 > Cc: discuss at openjdk.java.net > Date: 13/03/2019 13:23 > Subject: Re: Proposal: Mailing List Cull > > Without commenting on the specific proposal, I agree that having a > lot of ?dead? mailing lists both (a) could give off the appearance > of being a ghost town and (b) makes it harder to find where the > active discussion is. Given that many lists are for projects that > are no longer active (some just ran off the road, others completed > their mission and should be wound down), some move to guide users to > the active lists while preserving the history of the inactive lists > would be good. > > Note that Proposal 3 is really a separate question from the ?how do > we display mailing lists? question; it is really about creating a > ?start here? page, which is orthogonal to how the mailing lists are > organized and displayed. > > The next steps can be taken in parallel: > > - Determine a course of action for dealing with dead / dormant lists > (this is mostly a discussion task); > - Determine the actual deadness / dormancy status of the lists that > you identified. This is a research task. The place to start here > is to go to the project leads for the owning projects or the group > leads for the owning groups, and ask them if there is some reason > they are more active than they appear. > > > On Mar 13, 2019, at 8:27 AM, Adam Farley8 wrote: > > > > (Preface: I may be sending this to the wrong list, so advice on the > > correct list would be appreciated.) > > > > Hey All, > > > > There's a lot of mailing lists here, including a few that've been dead for > > 5 years, and I think it's making it hard for contributors to find the > > right list. > > > > Here's a list of mailing lists seeing no/minimal use, and a set of > > proposals to go with them. > > > > Proposal 1: Cull (archive) one or more of these mailing list groups, with > > exceptions made for lists anyone still wants, or actively monitors. > > Why? Because having 151 non-archived mailing lists makes it harder for > > people to find the right one. Also makes it easier to find black holes > > (non-monitored lists) to drop valid bugs into. > > > > Proposal 2: Hide the archived mailing lists on the primary "mailing lists" > > view. > > Why? Because it dilutes the list of active lists and makes finding the > > right one harder. > > > > Proposal 3: Create a short list of the most useful channels to the casual > > contributor, making it easier to find the primary hotspot, JCL, docs > > lists, etc. > > Why? Ease of use. Ability to contribute should be based on knowledge of > > the code base, not knowledge of the mailing lists, > > > > Proposal 4: Hide the mailing lists whose sole purpose is to display > > automated messages when a project has been committed to. > > > > Proposal 4: Make Proposals 2, 3, and 4 the default view when you click on > > "Mailing lists" from the main page. > > Why? Ease of use again. One form this could take is: the user clicks on > > "mailing lists" on the primary openjdk page, and sees a minimal list of > > mailing lists, with toggles to show the lists hidden by 2, 3, and 4. > > > > Constructive opinions welcome. :) > > > > Best Regards > > > > Adam Farley > > IBM Runtimes > > > > P.S. Spam and "hep please" don't count as emails. > > > > -- Appendix list: > > 1: Lists with no emails in 2 years or more. (Dead) > > 2: Lists with no emails inside the last 6 months. (Presumed Dead) > > 3: Lists with less than 2 emails (average) per month for the past year > > (Rosebud) > > > > -- Appendix 1: (Dead) > > anno-pipeline-dev > > btrace-dev > > compiler-grammar-dev > > cvmi-dev > > friday-stats-dev > > graphics-rasterizer-dev > > guide-discuss > > icedtea-changes > > java-se-8-spec-comments > > java-se-8-spec-experts > > java-se-8-spec-observers > > java-se-9-spec-comments > > java-se-9-spec-experts > > java-se-mr-spec-comments > > javadoc-next-dev > > jep-changes > > kona-dev > > lambda-libs-spec-comments > > lambda-libs-spec-experts > > lambda-libs-spec-observers > > penrose-dev > > penrose-discuss > > tiered-attrib-dev > > type-annotations-dev > > type-annotations-spec-comments > > type-annotations-spec-experts > > type-annotations-spec-observers > > xrender-dev > > > > -- Appendix 2: (Presumed Dead) > > detroit-dev > > dio-dev > > duke-dev > > graal-changes > > haiku-port-dev > > harfbuzz-dev > > icedtea-test > > java-se-9-spec-observers > > java-se-spec-comments > > jdk-hs-changes > > jmm-dev > > nb-projects-dev > > nio-discuss > > panama-spec-experts > > sandbox-changes > > sctp-dev > > sumatra-dev > > valhalla-spec-comments > > > > -- Appendix 3: (Rosebud) > > asmtools-dev > > caciocavallo-dev > > conformance-discuss > > doccheck-dev > > jmx-dev > > jol-dev > > lambda-spec-comments > > lambda-spec-experts > > lambda-spec-observers > > macosx-port-dev > > metropolis-dev > > mips-port > > platform-jep-discuss > > > > > > > > Unless stated otherwise above: > > IBM United Kingdom Limited - Registered in England and Wales with number > > 741598. > > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From chris.hegarty at oracle.com Wed Mar 13 14:20:01 2019 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 13 Mar 2019 14:20:01 +0000 Subject: Proposal: Mailing List Cull In-Reply-To: References: Message-ID: <384941d2-2755-4286-a167-58b4a5b76c32@oracle.com> Adam, On 13/03/2019 12:30, Adam Farley8 wrote: > ... > > -- Appendix 2: (Presumed Dead) > ... > sctp-dev As the owner / administrator of this list, it is effectively dead. ( SCTP was integrated in JDK 7, and as such related discussion can now happen on net-dev ) -Chris. From jonathan.gibbons at oracle.com Wed Mar 13 15:48:14 2019 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 13 Mar 2019 08:48:14 -0700 Subject: Proposal: Mailing List Cull In-Reply-To: References: Message-ID: Mailing lists rarely exist in isolation: they are typically associated with projects and/or repos. Without commenting on the merits of removing any individual mailing list, if a mailing list is to be removed, there should be due diligence to update any references to the mailing list, such as on the OpenJDK website. -- Jon On 3/13/19 5:27 AM, Adam Farley8 wrote: > (Preface: I may be sending this to the wrong list, so advice on the > correct list would be appreciated.) > > Hey All, > > There's a lot of mailing lists here, including a few that've been dead for > 5 years, and I think it's making it hard for contributors to find the > right list. > > Here's a list of mailing lists seeing no/minimal use, and a set of > proposals to go with them. > > Proposal 1: Cull (archive) one or more of these mailing list groups, with > exceptions made for lists anyone still wants, or actively monitors. > Why? Because having 151 non-archived mailing lists makes it harder for > people to find the right one. Also makes it easier to find black holes > (non-monitored lists) to drop valid bugs into. > > Proposal 2: Hide the archived mailing lists on the primary "mailing lists" > view. > Why? Because it dilutes the list of active lists and makes finding the > right one harder. > > Proposal 3: Create a short list of the most useful channels to the casual > contributor, making it easier to find the primary hotspot, JCL, docs > lists, etc. > Why? Ease of use. Ability to contribute should be based on knowledge of > the code base, not knowledge of the mailing lists, > > Proposal 4: Hide the mailing lists whose sole purpose is to display > automated messages when a project has been committed to. > > Proposal 4: Make Proposals 2, 3, and 4 the default view when you click on > "Mailing lists" from the main page. > Why? Ease of use again. One form this could take is: the user clicks on > "mailing lists" on the primary openjdk page, and sees a minimal list of > mailing lists, with toggles to show the lists hidden by 2, 3, and 4. > > Constructive opinions welcome. :) > > Best Regards > > Adam Farley > IBM Runtimes > > P.S. Spam and "hep please" don't count as emails. > > -- Appendix list: > 1: Lists with no emails in 2 years or more. (Dead) > 2: Lists with no emails inside the last 6 months. (Presumed Dead) > 3: Lists with less than 2 emails (average) per month for the past year > (Rosebud) > > -- Appendix 1: (Dead) > anno-pipeline-dev > btrace-dev > compiler-grammar-dev > cvmi-dev > friday-stats-dev > graphics-rasterizer-dev > guide-discuss > icedtea-changes > java-se-8-spec-comments > java-se-8-spec-experts > java-se-8-spec-observers > java-se-9-spec-comments > java-se-9-spec-experts > java-se-mr-spec-comments > javadoc-next-dev > jep-changes > kona-dev > lambda-libs-spec-comments > lambda-libs-spec-experts > lambda-libs-spec-observers > penrose-dev > penrose-discuss > tiered-attrib-dev > type-annotations-dev > type-annotations-spec-comments > type-annotations-spec-experts > type-annotations-spec-observers > xrender-dev > > -- Appendix 2: (Presumed Dead) > detroit-dev > dio-dev > duke-dev > graal-changes > haiku-port-dev > harfbuzz-dev > icedtea-test > java-se-9-spec-observers > java-se-spec-comments > jdk-hs-changes > jmm-dev > nb-projects-dev > nio-discuss > panama-spec-experts > sandbox-changes > sctp-dev > sumatra-dev > valhalla-spec-comments > > -- Appendix 3: (Rosebud) > asmtools-dev > caciocavallo-dev > conformance-discuss > doccheck-dev > jmx-dev > jol-dev > lambda-spec-comments > lambda-spec-experts > lambda-spec-observers > macosx-port-dev > metropolis-dev > mips-port > platform-jep-discuss > > > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From fweimer at redhat.com Wed Mar 13 15:53:08 2019 From: fweimer at redhat.com (Florian Weimer) Date: Wed, 13 Mar 2019 16:53:08 +0100 Subject: Call For Vote: Project Tsan In-Reply-To: (Martin Buchholz's message of "Fri, 15 Feb 2019 15:39:21 -0800") References: <871s4aiims.fsf@oldenburg2.str.redhat.com> <87y36hjmj5.fsf@oldenburg2.str.redhat.com> Message-ID: <87h8c6db4r.fsf@oldenburg2.str.redhat.com> * Martin Buchholz: > There may be a cultural expectations gap. > > Companies (like Google) might make the toolchain a part of their basic > computing infrastructure; build everything from source, and use a tsan > that comes with the one blessed toolchain used to build everything > else. > > Linux distros (like Red Hat) probably also try to build most binaries > with a preferred toolchain, but there is a much wider promise of ABI > compatibility. In particular, part of the value proposition of having > a Linux distro is users not having to rebuild from source, and being > able to combine binaries built by others, using different toolchains. If OpenJDK starts to poke at libc internals, like the sanitizers do today, OpenJDK will potentially need porting to each new libc version. You will not be able to run older OpenJDK versions on newer libcs, as it is possible today. It will likely make it more complicated to build binaries which are compatible with a wide range of systems. This is what we see with the sanitizers in LLVM and GCC today. If you copy a variant of this code into OpenJDK, you will have the same problem. Thanks, Florian From adam.farley at uk.ibm.com Wed Mar 13 16:14:52 2019 From: adam.farley at uk.ibm.com (Adam Farley8) Date: Wed, 13 Mar 2019 16:14:52 +0000 Subject: Proposal: Mailing List Cull In-Reply-To: References: Message-ID: Hi John, Chris, Chris: Thanks for telling us. I've created a bucket for "To Be Archived". John: A reasonable concern. How does this sound for a per-list process? Step 1) Contact the list owner to see if the list is still needed. Step 2) If the owner replies in the negative, or the owner does not reply to subsequent emails after 1 month, move the list into the "to be archived" appendix. Step 3) Post a message to the list, notifying any residual users that the list is to be archived. Step 4) Update all references to the list from the openjdk website. Step 5) Mark the list as Archived (via, I presume, the list owner or the gb in the event of an absent owner). Step 6) Move the list into the "Archived" appendix. Step 7) Cake & Coffee. Best Regards Adam Farley IBM Runtimes "discuss" wrote on 13/03/2019 15:48:14: > From: Jonathan Gibbons > To: discuss at openjdk.java.net > Date: 13/03/2019 15:51 > Subject: Re: Proposal: Mailing List Cull > Sent by: "discuss" > > Mailing lists rarely exist in isolation: they are typically associated with > projects and/or repos. > > Without commenting on the merits of removing any individual mailing > list, if a mailing list is to be removed, there should be due diligence to > update any references to the mailing list, such as on the OpenJDK > website. > > -- Jon > > On 3/13/19 5:27 AM, Adam Farley8 wrote: > > (Preface: I may be sending this to the wrong list, so advice on the > > correct list would be appreciated.) > > > > Hey All, > > > > There's a lot of mailing lists here, including a few that've been dead for > > 5 years, and I think it's making it hard for contributors to find the > > right list. > > > > Here's a list of mailing lists seeing no/minimal use, and a set of > > proposals to go with them. > > > > Proposal 1: Cull (archive) one or more of these mailing list groups, with > > exceptions made for lists anyone still wants, or actively monitors. > > Why? Because having 151 non-archived mailing lists makes it harder for > > people to find the right one. Also makes it easier to find black holes > > (non-monitored lists) to drop valid bugs into. > > > > Proposal 2: Hide the archived mailing lists on the primary "mailing lists" > > view. > > Why? Because it dilutes the list of active lists and makes finding the > > right one harder. > > > > Proposal 3: Create a short list of the most useful channels to the casual > > contributor, making it easier to find the primary hotspot, JCL, docs > > lists, etc. > > Why? Ease of use. Ability to contribute should be based on knowledge of > > the code base, not knowledge of the mailing lists, > > > > Proposal 4: Hide the mailing lists whose sole purpose is to display > > automated messages when a project has been committed to. > > > > Proposal 4: Make Proposals 2, 3, and 4 the default view when you click on > > "Mailing lists" from the main page. > > Why? Ease of use again. One form this could take is: the user clicks on > > "mailing lists" on the primary openjdk page, and sees a minimal list of > > mailing lists, with toggles to show the lists hidden by 2, 3, and 4. > > > > Constructive opinions welcome. :) > > > > Best Regards > > > > Adam Farley > > IBM Runtimes > > > > P.S. Spam and "hep please" don't count as emails. > > > > -- Appendix list: > > 1: Lists with no emails in 2 years or more. (Dead) > > 2: Lists with no emails inside the last 6 months. (Presumed Dead) > > 3: Lists with less than 2 emails (average) per month for the past year (Rosebud) > > 4: Lists whose associated project has been completed. (Project Completed) > > 5: Lists to be archived due to owner response or lack of same. (To Be Archived) > > > > -- Appendix 1: (Dead) > > anno-pipeline-dev > > btrace-dev > > compiler-grammar-dev > > cvmi-dev > > friday-stats-dev > > graphics-rasterizer-dev > > guide-discuss > > icedtea-changes > > java-se-8-spec-comments > > java-se-8-spec-experts > > java-se-8-spec-observers > > java-se-9-spec-comments > > java-se-9-spec-experts > > java-se-mr-spec-comments > > javadoc-next-dev > > jep-changes > > kona-dev > > lambda-libs-spec-comments > > lambda-libs-spec-experts > > lambda-libs-spec-observers > > penrose-dev > > penrose-discuss > > tiered-attrib-dev > > type-annotations-dev > > type-annotations-spec-comments > > type-annotations-spec-experts > > type-annotations-spec-observers > > xrender-dev > > > > -- Appendix 2: (Presumed Dead) > > detroit-dev > > dio-dev > > duke-dev > > graal-changes > > haiku-port-dev > > harfbuzz-dev > > icedtea-test > > java-se-9-spec-observers > > java-se-spec-comments > > jdk-hs-changes > > jmm-dev > > nb-projects-dev > > nio-discuss > > sandbox-changes > > sumatra-dev > > > > -- Appendix 3: (Rosebud) > > asmtools-dev > > caciocavallo-dev > > conformance-discuss > > doccheck-dev > > jmx-dev > > jol-dev > > macosx-port-dev > > mips-port > > platform-jep-discuss > > > > -- Appendix 4: (Project Completed) > > lambda-spec-comments > > lambda-spec-experts > > lambda-spec-observers > > > > -- Appendix 5: (To Be Archived) > > sctp-dev Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From alex.buckley at oracle.com Wed Mar 13 19:28:26 2019 From: alex.buckley at oracle.com (Alex Buckley) Date: Wed, 13 Mar 2019 12:28:26 -0700 Subject: Proposal: Mailing List Cull In-Reply-To: References: Message-ID: <5C8959DA.5050106@oracle.com> Mailing lists are just one kind of artifact associated with a Project. I suggest that what you're really imagining is more aggressive Project dissolution, as described in the OpenJDK Bylaws: http://openjdk.java.net/bylaws#_6 "A Project?s Committers may decide, by Lazy Consensus, to request explicitly that the Project be dissolved. ... When a Project is dissolved its materials are archived." I read this as "ONLY when a Project is dissolved, are its materials archived." People would be confused if a Project's list was archived on the mailing list server, but the Project's page on http://openjdk.java.net/ and its repos at http://hg.openjdk.java.net/ are silent about status. I guess it's possible for a Project to follow the lead of Project Lambda (http://openjdk.java.net/projects/lambda/) by declaring on its page that the Project is "complete" (but not dissolved) and that further communication should use so-and-so channels. But that is work for a Project Lead beyond merely agreeing that their lists can be archived. Alex On 3/13/2019 6:53 AM, Adam Farley8 wrote: > I agree with all of the points in Brian's email. > > This initial email chain is to show the problem, and to gather popular > support for a large-scale cleanup, prior to approaching the list owners. > > Plus, this gives people a chance to add/remove lists like Brian has done, > and also to identify any "overall list management" group who should be > consulted before pursuing this task. > > Best Regards > > Adam Farley > IBM Runtimes > > > Brian Goetz wrote on 13/03/2019 13:18:16: > >> From: Brian Goetz >> To: Adam Farley8 >> Cc: discuss at openjdk.java.net >> Date: 13/03/2019 13:23 >> Subject: Re: Proposal: Mailing List Cull >> >> Without commenting on the specific proposal, I agree that having a >> lot of ?dead? mailing lists both (a) could give off the appearance >> of being a ghost town and (b) makes it harder to find where the >> active discussion is. Given that many lists are for projects that >> are no longer active (some just ran off the road, others completed >> their mission and should be wound down), some move to guide users to >> the active lists while preserving the history of the inactive lists >> would be good. >> >> Note that Proposal 3 is really a separate question from the ?how do >> we display mailing lists? question; it is really about creating a >> ?start here? page, which is orthogonal to how the mailing lists are >> organized and displayed. >> >> The next steps can be taken in parallel: >> >> - Determine a course of action for dealing with dead / dormant lists >> (this is mostly a discussion task); >> - Determine the actual deadness / dormancy status of the lists that >> you identified. This is a research task. The place to start here >> is to go to the project leads for the owning projects or the group >> leads for the owning groups, and ask them if there is some reason >> they are more active than they appear. >> >>> On Mar 13, 2019, at 8:27 AM, Adam Farley8 > wrote: >>> >>> (Preface: I may be sending this to the wrong list, so advice on the >>> correct list would be appreciated.) >>> >>> Hey All, >>> >>> There's a lot of mailing lists here, including a few that've been dead > for >>> 5 years, and I think it's making it hard for contributors to find the >>> right list. >>> >>> Here's a list of mailing lists seeing no/minimal use, and a set of >>> proposals to go with them. >>> >>> Proposal 1: Cull (archive) one or more of these mailing list groups, > with >>> exceptions made for lists anyone still wants, or actively monitors. >>> Why? Because having 151 non-archived mailing lists makes it harder for > >>> people to find the right one. Also makes it easier to find black holes > >>> (non-monitored lists) to drop valid bugs into. >>> >>> Proposal 2: Hide the archived mailing lists on the primary "mailing > lists" >>> view. >>> Why? Because it dilutes the list of active lists and makes finding the > >>> right one harder. >>> >>> Proposal 3: Create a short list of the most useful channels to the > casual >>> contributor, making it easier to find the primary hotspot, JCL, docs >>> lists, etc. >>> Why? Ease of use. Ability to contribute should be based on knowledge > of >>> the code base, not knowledge of the mailing lists, >>> >>> Proposal 4: Hide the mailing lists whose sole purpose is to display >>> automated messages when a project has been committed to. >>> >>> Proposal 4: Make Proposals 2, 3, and 4 the default view when you click > on >>> "Mailing lists" from the main page. >>> Why? Ease of use again. One form this could take is: the user clicks > on >>> "mailing lists" on the primary openjdk page, and sees a minimal list > of >>> mailing lists, with toggles to show the lists hidden by 2, 3, and 4. >>> >>> Constructive opinions welcome. :) >>> >>> Best Regards >>> >>> Adam Farley >>> IBM Runtimes >>> >>> P.S. Spam and "hep please" don't count as emails. >>> >>> -- Appendix list: >>> 1: Lists with no emails in 2 years or more. (Dead) >>> 2: Lists with no emails inside the last 6 months. (Presumed Dead) >>> 3: Lists with less than 2 emails (average) per month for the past year > >>> (Rosebud) >>> >>> -- Appendix 1: (Dead) >>> anno-pipeline-dev >>> btrace-dev >>> compiler-grammar-dev >>> cvmi-dev >>> friday-stats-dev >>> graphics-rasterizer-dev >>> guide-discuss >>> icedtea-changes >>> java-se-8-spec-comments >>> java-se-8-spec-experts >>> java-se-8-spec-observers >>> java-se-9-spec-comments >>> java-se-9-spec-experts >>> java-se-mr-spec-comments >>> javadoc-next-dev >>> jep-changes >>> kona-dev >>> lambda-libs-spec-comments >>> lambda-libs-spec-experts >>> lambda-libs-spec-observers >>> penrose-dev >>> penrose-discuss >>> tiered-attrib-dev >>> type-annotations-dev >>> type-annotations-spec-comments >>> type-annotations-spec-experts >>> type-annotations-spec-observers >>> xrender-dev >>> >>> -- Appendix 2: (Presumed Dead) >>> detroit-dev >>> dio-dev >>> duke-dev >>> graal-changes >>> haiku-port-dev >>> harfbuzz-dev >>> icedtea-test >>> java-se-9-spec-observers >>> java-se-spec-comments >>> jdk-hs-changes >>> jmm-dev >>> nb-projects-dev >>> nio-discuss >>> panama-spec-experts >>> sandbox-changes >>> sctp-dev >>> sumatra-dev >>> valhalla-spec-comments >>> >>> -- Appendix 3: (Rosebud) >>> asmtools-dev >>> caciocavallo-dev >>> conformance-discuss >>> doccheck-dev >>> jmx-dev >>> jol-dev >>> lambda-spec-comments >>> lambda-spec-experts >>> lambda-spec-observers >>> macosx-port-dev >>> metropolis-dev >>> mips-port >>> platform-jep-discuss >>> >>> >>> >>> Unless stated otherwise above: >>> IBM United Kingdom Limited - Registered in England and Wales with > number >>> 741598. >>> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 > 3AU >> > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > From jcbeyler at google.com Wed Mar 13 23:34:20 2019 From: jcbeyler at google.com (Jean Christophe Beyler) Date: Wed, 13 Mar 2019 16:34:20 -0700 Subject: Call For Vote: Project Tsan In-Reply-To: <87h8c6db4r.fsf@oldenburg2.str.redhat.com> References: <871s4aiims.fsf@oldenburg2.str.redhat.com> <87y36hjmj5.fsf@oldenburg2.str.redhat.com> <87h8c6db4r.fsf@oldenburg2.str.redhat.com> Message-ID: Hi Florian, I am not disagreeing with this conversation but could we perhaps wait until the project opens and we have a tsan mailing list where we could debate and talk about it there? Then we could see what kind of solution could be done and have it recorded there? When the mailing thread opens, I'll send an email with the top points and we can go from there. Any objections? Thanks, Jc On Wed, Mar 13, 2019 at 8:53 AM Florian Weimer wrote: > * Martin Buchholz: > > > There may be a cultural expectations gap. > > > > Companies (like Google) might make the toolchain a part of their basic > > computing infrastructure; build everything from source, and use a tsan > > that comes with the one blessed toolchain used to build everything > > else. > > > > Linux distros (like Red Hat) probably also try to build most binaries > > with a preferred toolchain, but there is a much wider promise of ABI > > compatibility. In particular, part of the value proposition of having > > a Linux distro is users not having to rebuild from source, and being > > able to combine binaries built by others, using different toolchains. > > If OpenJDK starts to poke at libc internals, like the sanitizers do > today, OpenJDK will potentially need porting to each new libc version. > > You will not be able to run older OpenJDK versions on newer libcs, as it > is possible today. > > It will likely make it more complicated to build binaries which are > compatible with a wide range of systems. > > This is what we see with the sanitizers in LLVM and GCC today. If you > copy a variant of this code into OpenJDK, you will have the same > problem. > > Thanks, > Florian > -- Thanks, Jc From jcbeyler at google.com Thu Mar 14 03:22:39 2019 From: jcbeyler at google.com (Jean Christophe Beyler) Date: Wed, 13 Mar 2019 20:22:39 -0700 Subject: Call For Vote: Project Tsan In-Reply-To: References: <871s4aiims.fsf@oldenburg2.str.redhat.com> <87y36hjmj5.fsf@oldenburg2.str.redhat.com> <87h8c6db4r.fsf@oldenburg2.str.redhat.com> Message-ID: With the help of Iris Clark (thank you :-)), I've moved this conversation here: https://mail.openjdk.java.net/pipermail/tsan-dev/2019-March/000000.html Feel free to join the mailing list and join the conversation there of how we could figure it out (or strive to). Jc On Wed, Mar 13, 2019 at 4:34 PM Jean Christophe Beyler wrote: > Hi Florian, > > I am not disagreeing with this conversation but could we perhaps wait > until the project opens and we have a tsan mailing list where we could > debate and talk about it there? > > Then we could see what kind of solution could be done and have it recorded > there? When the mailing thread opens, I'll send an email with the top > points and we can go from there. > > Any objections? > > Thanks, > Jc > > On Wed, Mar 13, 2019 at 8:53 AM Florian Weimer wrote: > >> * Martin Buchholz: >> >> > There may be a cultural expectations gap. >> > >> > Companies (like Google) might make the toolchain a part of their basic >> > computing infrastructure; build everything from source, and use a tsan >> > that comes with the one blessed toolchain used to build everything >> > else. >> > >> > Linux distros (like Red Hat) probably also try to build most binaries >> > with a preferred toolchain, but there is a much wider promise of ABI >> > compatibility. In particular, part of the value proposition of having >> > a Linux distro is users not having to rebuild from source, and being >> > able to combine binaries built by others, using different toolchains. >> >> If OpenJDK starts to poke at libc internals, like the sanitizers do >> today, OpenJDK will potentially need porting to each new libc version. >> >> You will not be able to run older OpenJDK versions on newer libcs, as it >> is possible today. >> >> It will likely make it more complicated to build binaries which are >> compatible with a wide range of systems. >> >> This is what we see with the sanitizers in LLVM and GCC today. If you >> copy a variant of this code into OpenJDK, you will have the same >> problem. >> >> Thanks, >> Florian >> > > > -- > > Thanks, > Jc > -- Thanks, Jc From adam.farley at uk.ibm.com Thu Mar 14 11:09:06 2019 From: adam.farley at uk.ibm.com (Adam Farley8) Date: Thu, 14 Mar 2019 11:09:06 +0000 Subject: Proposal: Mailing List Cull In-Reply-To: <5C8959DA.5050106@oracle.com> References: <5C8959DA.5050106@oracle.com> Message-ID: Hi Alex, Jeff, Jeff: Thanks for responding there. Your list has been removed from the appendices, as it's still wanted. Alex: What I'm imagining is a smaller number of active lists. You're right to assert that active projects should have a mailing list, and it is not my intention to imply otherwise. Perhaps less active (read: near-silent), or completed, projects could share a common list, or use one of the more active lists? This would need to be mentioned on the project page, yes. And speaking of common lists, I keep having to copy the Appendices between my emails to ensure changes aren't lost. This invites errors, so here's a JBS Task to store the shared list where everyone can tweak it: https://bugs.openjdk.java.net/browse/JDK-8220662 Unsure if this is a misuse of the bug system. I expect someone will complain if it is. :) Best Regards Adam Farley IBM Runtimes "discuss" wrote on 13/03/2019 19:28:26: > From: Alex Buckley > To: discuss at openjdk.java.net > Date: 13/03/2019 19:50 > Subject: Re: Proposal: Mailing List Cull > Sent by: "discuss" > > Mailing lists are just one kind of artifact associated with a Project. I > suggest that what you're really imagining is more aggressive Project > dissolution, as described in the OpenJDK Bylaws: > > https://urldefense.proofpoint.com/v2/url? > u=http-3A__openjdk.java.net_bylaws-23-5F6&d=DwIFaQ&c=jf_iaSHvJObTbx- > siA1ZOg&r=P5m8KWUXJf- > CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=xHgfLFByqwNSfZ49CIKNKMW0JGEFUA8ZB1N3rw_4G_0&s=ptkTcpz7zHeI- > xE-2gCB-Uned4rtbaMoBaJ4vN9iaMU&e= > > "A Project?s Committers may decide, by Lazy Consensus, > to request explicitly that the Project be dissolved. > ... When a Project is dissolved its materials are archived." > > I read this as "ONLY when a Project is dissolved, are its materials > archived." People would be confused if a Project's list was archived on > the mailing list server, but the Project's page on > https://urldefense.proofpoint.com/v2/url? > u=http-3A__openjdk.java.net_&d=DwIFaQ&c=jf_iaSHvJObTbx- > siA1ZOg&r=P5m8KWUXJf- > CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=xHgfLFByqwNSfZ49CIKNKMW0JGEFUA8ZB1N3rw_4G_0&s=hjSGZG1CMxTw3UAURV9vx8kgTSvLoaJ8zlwVyRVUE0Y&e= > and its repos at https://urldefense.proofpoint.com/v2/url? > u=http-3A__hg.openjdk.java.net_&d=DwIFaQ&c=jf_iaSHvJObTbx- > siA1ZOg&r=P5m8KWUXJf- > CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=xHgfLFByqwNSfZ49CIKNKMW0JGEFUA8ZB1N3rw_4G_0&s=F6mPKb6KGHcmKiegV8UTCL_7oIegTWxkyTJ0TM8dxe8&e= > are silent about status. > > I guess it's possible for a Project to follow the lead of Project Lambda > (https://urldefense.proofpoint.com/v2/url? > u=http-3A__openjdk.java.net_projects_lambda_&d=DwIFaQ&c=jf_iaSHvJObTbx- > siA1ZOg&r=P5m8KWUXJf- > CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=xHgfLFByqwNSfZ49CIKNKMW0JGEFUA8ZB1N3rw_4G_0&s=qaUJuq9tbh_pTfNNbMsRd7I29IuWjGF9TB0SFC0bDxo&e= > ) by declaring on its page that > the Project is "complete" (but not dissolved) and that further > communication should use so-and-so channels. But that is work for a > Project Lead beyond merely agreeing that their lists can be archived. > > Alex > > On 3/13/2019 6:53 AM, Adam Farley8 wrote: > > I agree with all of the points in Brian's email. > > > > This initial email chain is to show the problem, and to gather popular > > support for a large-scale cleanup, prior to approaching the list owners. > > > > Plus, this gives people a chance to add/remove lists like Brian has done, > > and also to identify any "overall list management" group who should be > > consulted before pursuing this task. > > > > Best Regards > > > > Adam Farley > > IBM Runtimes > > > > > > Brian Goetz wrote on 13/03/2019 13:18:16: > > > >> From: Brian Goetz > >> To: Adam Farley8 > >> Cc: discuss at openjdk.java.net > >> Date: 13/03/2019 13:23 > >> Subject: Re: Proposal: Mailing List Cull > >> > >> Without commenting on the specific proposal, I agree that having a > >> lot of ?dead? mailing lists both (a) could give off the appearance > >> of being a ghost town and (b) makes it harder to find where the > >> active discussion is. Given that many lists are for projects that > >> are no longer active (some just ran off the road, others completed > >> their mission and should be wound down), some move to guide users to > >> the active lists while preserving the history of the inactive lists > >> would be good. > >> > >> Note that Proposal 3 is really a separate question from the ?how do > >> we display mailing lists? question; it is really about creating a > >> ?start here? page, which is orthogonal to how the mailing lists are > >> organized and displayed. > >> > >> The next steps can be taken in parallel: > >> > >> - Determine a course of action for dealing with dead / dormant lists > >> (this is mostly a discussion task); > >> - Determine the actual deadness / dormancy status of the lists that > >> you identified. This is a research task. The place to start here > >> is to go to the project leads for the owning projects or the group > >> leads for the owning groups, and ask them if there is some reason > >> they are more active than they appear. > >> > >>> On Mar 13, 2019, at 8:27 AM, Adam Farley8 > > wrote: > >>> > >>> (Preface: I may be sending this to the wrong list, so advice on the > >>> correct list would be appreciated.) > >>> > >>> Hey All, > >>> > >>> There's a lot of mailing lists here, including a few that've been dead > > for > >>> 5 years, and I think it's making it hard for contributors to find the > >>> right list. > >>> > >>> Here's a list of mailing lists seeing no/minimal use, and a set of > >>> proposals to go with them. > >>> > >>> Proposal 1: Cull (archive) one or more of these mailing list groups, > > with > >>> exceptions made for lists anyone still wants, or actively monitors. > >>> Why? Because having 151 non-archived mailing lists makes it harder for > > > >>> people to find the right one. Also makes it easier to find black holes > > > >>> (non-monitored lists) to drop valid bugs into. > >>> > >>> Proposal 2: Hide the archived mailing lists on the primary "mailing > > lists" > >>> view. > >>> Why? Because it dilutes the list of active lists and makes finding the > > > >>> right one harder. > >>> > >>> Proposal 3: Create a short list of the most useful channels to the > > casual > >>> contributor, making it easier to find the primary hotspot, JCL, docs > >>> lists, etc. > >>> Why? Ease of use. Ability to contribute should be based on knowledge > > of > >>> the code base, not knowledge of the mailing lists, > >>> > >>> Proposal 4: Hide the mailing lists whose sole purpose is to display > >>> automated messages when a project has been committed to. > >>> > >>> Proposal 4: Make Proposals 2, 3, and 4 the default view when you click > > on > >>> "Mailing lists" from the main page. > >>> Why? Ease of use again. One form this could take is: the user clicks > > on > >>> "mailing lists" on the primary openjdk page, and sees a minimal list > > of > >>> mailing lists, with toggles to show the lists hidden by 2, 3, and 4. > >>> > >>> Constructive opinions welcome. :) > >>> > >>> Best Regards > >>> > >>> Adam Farley > >>> IBM Runtimes > >>> > >>> P.S. Spam and "hep please" don't count as emails. > >>> > >>> -- Appendix list: > >>> 1: Lists with no emails in 2 years or more. (Dead) > >>> 2: Lists with no emails inside the last 6 months. (Presumed Dead) > >>> 3: Lists with less than 2 emails (average) per month for the past year > > > >>> (Rosebud) > >>> > >>> -- Appendix 1: (Dead) > >>> anno-pipeline-dev > >>> btrace-dev > >>> compiler-grammar-dev > >>> cvmi-dev > >>> friday-stats-dev > >>> graphics-rasterizer-dev > >>> guide-discuss > >>> icedtea-changes > >>> java-se-8-spec-comments > >>> java-se-8-spec-experts > >>> java-se-8-spec-observers > >>> java-se-9-spec-comments > >>> java-se-9-spec-experts > >>> java-se-mr-spec-comments > >>> javadoc-next-dev > >>> jep-changes > >>> kona-dev > >>> lambda-libs-spec-comments > >>> lambda-libs-spec-experts > >>> lambda-libs-spec-observers > >>> penrose-dev > >>> penrose-discuss > >>> tiered-attrib-dev > >>> type-annotations-dev > >>> type-annotations-spec-comments > >>> type-annotations-spec-experts > >>> type-annotations-spec-observers > >>> xrender-dev > >>> > >>> -- Appendix 2: (Presumed Dead) > >>> detroit-dev > >>> dio-dev > >>> duke-dev > >>> graal-changes > >>> haiku-port-dev > >>> harfbuzz-dev > >>> icedtea-test > >>> java-se-9-spec-observers > >>> java-se-spec-comments > >>> jdk-hs-changes > >>> jmm-dev > >>> nb-projects-dev > >>> nio-discuss > >>> panama-spec-experts > >>> sandbox-changes > >>> sctp-dev > >>> sumatra-dev > >>> valhalla-spec-comments > >>> > >>> -- Appendix 3: (Rosebud) > >>> asmtools-dev > >>> caciocavallo-dev > >>> conformance-discuss > >>> doccheck-dev > >>> jmx-dev > >>> jol-dev > >>> lambda-spec-comments > >>> lambda-spec-experts > >>> lambda-spec-observers > >>> macosx-port-dev > >>> metropolis-dev > >>> mips-port > >>> platform-jep-discuss > >>> > >>> > >>> > >>> Unless stated otherwise above: > >>> IBM United Kingdom Limited - Registered in England and Wales with > > number > >>> 741598. > >>> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 > > 3AU > >> > > > > Unless stated otherwise above: > > IBM United Kingdom Limited - Registered in England and Wales with number > > 741598. > > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > > > Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From alex.buckley at oracle.com Thu Mar 14 20:30:50 2019 From: alex.buckley at oracle.com (Alex Buckley) Date: Thu, 14 Mar 2019 13:30:50 -0700 Subject: Proposal: Mailing List Cull In-Reply-To: References: <5C8959DA.5050106@oracle.com> Message-ID: <5C8AB9FA.6000401@oracle.com> On 3/14/2019 4:09 AM, Adam Farley8 wrote: > Alex: What I'm imagining is a smaller number of active lists. > > You're right to assert that active projects should have a mailing list, > and it is not my intention to imply otherwise. > > Perhaps less active (read: near-silent), or completed, projects could > share a common list, or use one of the more active lists? I think that is for each Project to decide, and that the typical decision will be to refer people to the mailing list of the Group which sponsored the Project. For example, when the Build Infrastructure Project voted to dissolve [1], someone updated the mailing list page [2] to refer to the Build Group's list, `build-dev`. It was a similar story when the ThreeTen Project voted to dissolve [3][4]. Looking to the future, I imagine the Annotations Pipeline 2.0 Project would decide to stand down `anno-pipeline-dev` in favor of the sponsoring Compiler Group's list, `compiler-dev`, but that the Penrose Project might want to refer people to the Jigsaw Project's list instead of the Core Libraries Group's list. Separately: Where your JBS issue is recording decisions (e.g. archive sctp-dev), I recommend you link to the thread which actually made the decision. Not sure why java-se-mr-spec-comments or java-se-spec-comments are on your radar. The former clearly has purpose [5] and the latter is clearly associated with the significant java-se-spec-* lists. Alex [1] https://mail.openjdk.java.net/pipermail/build-infra-dev/2017-July/004577.html [2] http://mail.openjdk.java.net/mailman/listinfo/build-infra-dev [3] https://mail.openjdk.java.net/pipermail/threeten-dev/2017-August/001623.html [4] http://mail.openjdk.java.net/mailman/listinfo/threeten-dev [5] http://mail.openjdk.java.net/mailman/listinfo/java-se-mr-spec-comments > This would need to be mentioned on the project page, yes. > > And speaking of common lists, I keep having to copy the Appendices between > my emails to ensure changes aren't lost. > > This invites errors, so here's a JBS Task to store the shared list where > everyone can tweak it: > > https://bugs.openjdk.java.net/browse/JDK-8220662 > > Unsure if this is a misuse of the bug system. I expect someone will > complain if it is. :) > > Best Regards > > Adam Farley > IBM Runtimes From adam.farley at uk.ibm.com Fri Mar 15 11:08:34 2019 From: adam.farley at uk.ibm.com (Adam Farley8) Date: Fri, 15 Mar 2019 11:08:34 +0000 Subject: Proposal: Mailing List Cull In-Reply-To: <5C8AB9FA.6000401@oracle.com> References: <5C8959DA.5050106@oracle.com> <5C8AB9FA.6000401@oracle.com> Message-ID: Hi Alex, "discuss" wrote on 14/03/2019 20:30:50: > From: Alex Buckley > To: discuss at openjdk.java.net > Date: 14/03/2019 20:31 > Subject: Re: Proposal: Mailing List Cull > Sent by: "discuss" > > On 3/14/2019 4:09 AM, Adam Farley8 wrote: > > Alex: What I'm imagining is a smaller number of active lists. > > > > You're right to assert that active projects should have a mailing list, > > and it is not my intention to imply otherwise. > > > > Perhaps less active (read: near-silent), or completed, projects could > > share a common list, or use one of the more active lists? > > I think that is for each Project to decide, and that the typical > decision will be to refer people to the mailing list of the Group which > sponsored the Project. > That's a fair comment. Ideally, all of the contacted list owners will respond once an email has been sent out, and they will decide on the right action. > For example, when the Build Infrastructure Project voted to dissolve > [1], someone updated the mailing list page [2] to refer to the Build > Group's list, `build-dev`. It was a similar story when the ThreeTen > Project voted to dissolve [3][4]. Looking to the future, I imagine the > Annotations Pipeline 2.0 Project would decide to stand down > `anno-pipeline-dev` in favor of the sponsoring Compiler Group's list, > `compiler-dev`, but that the Penrose Project might want to refer people > to the Jigsaw Project's list instead of the Core Libraries Group's list. > > Separately: > > Where your JBS issue is recording decisions (e.g. archive sctp-dev), I > recommend you link to the thread which actually made the decision. > Good idea. Will add a link next to it for transparency. > Not sure why java-se-mr-spec-comments or java-se-spec-comments are on > your radar. The former clearly has purpose [5] and the latter is clearly > associated with the significant java-se-spec-* lists. > > Alex Those did seem important, but they looked associated with work that been resolved. At a glance, the mr one mentions Spring 2019, and the JEP links mention that the last vote is about to finish. Between that and the last email being in 2015, I presumed the list was due for archiving anyway. Not the case? - Adam > > [1] > https://urldefense.proofpoint.com/v2/url? > u=https-3A__mail.openjdk.java.net_pipermail_build-2Dinfra-2Ddev_2017-2DJuly_004577.html&d=DwICaQ&c=jf_iaSHvJObTbx- > siA1ZOg&r=P5m8KWUXJf- > CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=rW9U9Vo8dLTAfQrAZPM_bofVOScDo- > O3WH7QIQMpFzU&s=nDV6gx1hr4RPWYM2J13bsSmhpJiVAn1AugQOYi64TG0&e= > [2] https://urldefense.proofpoint.com/v2/url? > u=http-3A__mail.openjdk.java.net_mailman_listinfo_build-2Dinfra-2Ddev&d=DwICaQ&c=jf_iaSHvJObTbx- > siA1ZOg&r=P5m8KWUXJf- > CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=rW9U9Vo8dLTAfQrAZPM_bofVOScDo- > O3WH7QIQMpFzU&s=O6dw0h3YMboee513VhT-cVOtnk-8irV5sD5P5hpHs_w&e= > > [3] > https://urldefense.proofpoint.com/v2/url? > u=https-3A__mail.openjdk.java.net_pipermail_threeten-2Ddev_2017-2DAugust_001623.html&d=DwICaQ&c=jf_iaSHvJObTbx- > siA1ZOg&r=P5m8KWUXJf- > CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=rW9U9Vo8dLTAfQrAZPM_bofVOScDo- > O3WH7QIQMpFzU&s=VH6xWwRYxYwOYmXqqdcbPHEHOt40i9LCgjDKbltJuYs&e= > [4] https://urldefense.proofpoint.com/v2/url? > u=http-3A__mail.openjdk.java.net_mailman_listinfo_threeten-2Ddev&d=DwICaQ&c=jf_iaSHvJObTbx- > siA1ZOg&r=P5m8KWUXJf- > CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=rW9U9Vo8dLTAfQrAZPM_bofVOScDo- > O3WH7QIQMpFzU&s=8IY1T_CmIVLqZ5HfA_fOgQ9jBpc8p4XcyKm11QRP50A&e= > > [5] https://urldefense.proofpoint.com/v2/url? > u=http-3A__mail.openjdk.java.net_mailman_listinfo_java-2Dse-2Dmr-2Dspec-2Dcomments&d=DwICaQ&c=jf_iaSHvJObTbx- > siA1ZOg&r=P5m8KWUXJf- > CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=rW9U9Vo8dLTAfQrAZPM_bofVOScDo- > O3WH7QIQMpFzU&s=vBi1T53v6RpC7j_9__A-i1AdJIPaBvAGq41bnS-HyNQ&e= > > > This would need to be mentioned on the project page, yes. > > > > And speaking of common lists, I keep having to copy the Appendices between > > my emails to ensure changes aren't lost. > > > > This invites errors, so here's a JBS Task to store the shared list where > > everyone can tweak it: > > > > https://urldefense.proofpoint.com/v2/url? > u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8220662&d=DwICaQ&c=jf_iaSHvJObTbx- > siA1ZOg&r=P5m8KWUXJf- > CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=rW9U9Vo8dLTAfQrAZPM_bofVOScDo- > O3WH7QIQMpFzU&s=jsbg8DjAFJW_LDMTdJOD0PG9B76TXUwFUdL7NE5epkk&e= > > > > Unsure if this is a misuse of the bug system. I expect someone will > > complain if it is. :) > > > > Best Regards > > > > Adam Farley > > IBM Runtimes > Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From alex.buckley at oracle.com Fri Mar 15 19:00:26 2019 From: alex.buckley at oracle.com (Alex Buckley) Date: Fri, 15 Mar 2019 12:00:26 -0700 Subject: Proposal: Mailing List Cull In-Reply-To: References: <5C8959DA.5050106@oracle.com> <5C8AB9FA.6000401@oracle.com> Message-ID: <5C8BF64A.7010107@oracle.com> On 3/15/2019 4:08 AM, Adam Farley8 wrote: > "discuss" wrote on 14/03/2019 20:30:50: >> I think that is for each Project to decide, and that the typical >> decision will be to refer people to the mailing list of the Group which >> sponsored the Project. > > That's a fair comment. Ideally, all of the contacted list owners will > respond once an email has been sent out, > and they will decide on the right action. I guess anyone is free to petition Project Leads to dissolve their allegedly inactive Project. It would helpful for the petition to note the course of action mentioned above (use the sponsoring Group's mailing list). >> Not sure why java-se-mr-spec-comments or java-se-spec-comments are on >> your radar. The former clearly has purpose [5] and the latter is clearly >> associated with the significant java-se-spec-* lists. > > Those did seem important, but they looked associated with work that been > resolved. > > At a glance, the mr one mentions Spring 2019, and the JEP links mention > that the last vote is about to finish. > > Between that and the last email being in 2015, I presumed the list was > due for archiving anyway. > > Not the case? A glance at http://mail.openjdk.java.net/mailman/listinfo shows that some mailing lists are connected with Java SE activities around spec and conformance, rather than OpenJDK activities around implementation and infra. I recommend ignoring the former lists, and focusing on the lists connected directly with OpenJDK Projects. Alex From tobias.gierke at code-sourcery.de Tue Mar 19 08:14:13 2019 From: tobias.gierke at code-sourcery.de (Tobias Gierke) Date: Tue, 19 Mar 2019 09:14:13 +0100 Subject: Why no methods like toList() / toMutableList() / toSet() / toMutableSet() on Java Collection and Stream interfaces ? Message-ID: Hi, This has probably been asked? before but I somehow couldn't find a JEP were this proposal got rejected... adding these methods to me seems like an easy way to get rid of a lot of boilerplate code. Cheers, Tobias From orionllmain at gmail.com Tue Mar 19 08:27:08 2019 From: orionllmain at gmail.com (Zheka Kozlov) Date: Tue, 19 Mar 2019 15:27:08 +0700 Subject: Why no methods like toList() / toMutableList() / toSet() / toMutableSet() on Java Collection and Stream interfaces ? In-Reply-To: References: Message-ID: Stream.toList(): https://bugs.openjdk.java.net/browse/JDK-8180352 ??, 19 ???. 2019 ?. ? 15:14, Tobias Gierke : > Hi, > > This has probably been asked before but I somehow couldn't find a JEP > were this proposal got rejected... adding these methods to me seems like > an easy way to get rid of a lot of boilerplate code. > > > Cheers, > Tobias > > From tobias.gierke at code-sourcery.de Tue Mar 19 09:04:02 2019 From: tobias.gierke at code-sourcery.de (Tobias Gierke) Date: Tue, 19 Mar 2019 10:04:02 +0100 Subject: Why no methods like toList() / toMutableList() / toSet() / toMutableSet() on Java Collection and Stream interfaces ? In-Reply-To: References: Message-ID: <1198344d-d1ae-9226-a38d-3cb3bcd6a658@code-sourcery.de> Hi, Thanks for the pointer ! Is there still no way for mere mortals (read: non-OpenJDK committers) to comment or vote on issues ? I couldn't find any "create account" button and a quick Google search turned up a StackOverflow post from 2015 (https://stackoverflow.com/questions/29379425/where-to-report-issues-of-openjdk-when-youre-not-a-openjdk-developer) that basically says "Not possible". Cheers, Tobias > Stream.toList(): https://bugs.openjdk.java.net/browse/JDK-8180352 > > ??, 19 ???. 2019 ?. ? 15:14, Tobias Gierke > >: > > Hi, > > This has probably been asked? before but I somehow couldn't find a > JEP > were this proposal got rejected... adding these methods to me > seems like > an easy way to get rid of a lot of boilerplate code. > > > Cheers, > Tobias > From adam.farley at uk.ibm.com Tue Mar 19 09:17:09 2019 From: adam.farley at uk.ibm.com (Adam Farley8) Date: Tue, 19 Mar 2019 09:17:09 +0000 Subject: Why no methods like toList() / toMutableList() / toSet() / toMutableSet() on Java Collection and Stream interfaces ? In-Reply-To: <1198344d-d1ae-9226-a38d-3cb3bcd6a658@code-sourcery.de> References: <1198344d-d1ae-9226-a38d-3cb3bcd6a658@code-sourcery.de> Message-ID: Hi Tobias, It might not help you right now, but you get an account (for the issues db) when you become an Author. The criteria for becoming an author is just pair of small commits. Simples! https://openjdk.java.net/projects/#project-author Best Regards Adam Farley IBM Runtimes "discuss" wrote on 19/03/2019 09:04:02: > From: Tobias Gierke > To: Zheka Kozlov > Cc: discuss at openjdk.java.net > Date: 19/03/2019 09:05 > Subject: Re: Why no methods like toList() / toMutableList() / toSet > () / toMutableSet() on Java Collection and Stream interfaces ? > Sent by: "discuss" > > Hi, > > Thanks for the pointer ! Is there still no way for mere mortals (read: > non-OpenJDK committers) to comment or vote on issues ? I couldn't find > any "create account" button and a quick Google search turned up a > StackOverflow post from 2015 > (https://urldefense.proofpoint.com/v2/url? > u=https-3A__stackoverflow.com_questions_29379425_where-2Dto-2Dreport-2Dissues-2Dof-2Dopenjdk-2Dwhen-2Dyoure-2Dnot-2Da-2Dopenjdk-2Ddeveloper&d=DwIFaQ&c=jf_iaSHvJObTbx- > siA1ZOg&r=P5m8KWUXJf- > CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=Mp73d7F8-4tgJKf8MKSKtIjNJ_2XbjZ1XTlGFBa_Yl8&s=DRh50PXARpMMysp2qY6ndnUFCT7slEY-7w6Z_ZKXEsI&e= > ) > that basically says "Not possible". > > Cheers, > Tobias > > > > Stream.toList(): https://urldefense.proofpoint.com/v2/url? > u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8180352&d=DwIFaQ&c=jf_iaSHvJObTbx- > siA1ZOg&r=P5m8KWUXJf- > CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=Mp73d7F8-4tgJKf8MKSKtIjNJ_2XbjZ1XTlGFBa_Yl8&s=RtO7v2Edx4sa5knZWEdbJV05eZZLDf99WLwgw8- > _h_g&e= > > > > ??, 19 ???. 2019 ?. ? 15:14, Tobias Gierke > > >: > > > > Hi, > > > > This has probably been asked before but I somehow couldn't find a > > JEP > > were this proposal got rejected... adding these methods to me > > seems like > > an easy way to get rid of a lot of boilerplate code. > > > > > > Cheers, > > Tobias > > > Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From adam.farley at uk.ibm.com Tue Mar 19 10:08:44 2019 From: adam.farley at uk.ibm.com (Adam Farley8) Date: Tue, 19 Mar 2019 10:08:44 +0000 Subject: Proposal: Mailing List Cull In-Reply-To: <5C8BF64A.7010107@oracle.com> References: <5C8959DA.5050106@oracle.com> <5C8AB9FA.6000401@oracle.com> <5C8BF64A.7010107@oracle.com> Message-ID: Hi Alex, "discuss" wrote on 15/03/2019 19:00:26: > From: Alex Buckley > To: discuss at openjdk.java.net > Date: 15/03/2019 19:01 > Subject: Re: Proposal: Mailing List Cull > Sent by: "discuss" > > On 3/15/2019 4:08 AM, Adam Farley8 wrote: > > "discuss" wrote on 14/03/2019 20:30:50: > >> I think that is for each Project to decide, and that the typical > >> decision will be to refer people to the mailing list of the Group which > >> sponsored the Project. > > > > That's a fair comment. Ideally, all of the contacted list owners will > > respond once an email has been sent out, > > and they will decide on the right action. > > I guess anyone is free to petition Project Leads to dissolve their > allegedly inactive Project. It would helpful for the petition to note > the course of action mentioned above (use the sponsoring Group's mailing > list). > My intention is not to dissolve projects, but rather to thin down the number in inactive, non-archived mailing lists. If Project leads choose to interpret the inactivity of their mailing lists as a sign that the associated project should be shuttered, then that is their decision, as it should be. I want to avoid the implication that I'm trying to end projects here, rather than tidying up the list of lists. > >> Not sure why java-se-mr-spec-comments or java-se-spec-comments are on > >> your radar. The former clearly has purpose [5] and the latter is clearly > >> associated with the significant java-se-spec-* lists. > > > > Those did seem important, but they looked associated with work that been > > resolved. > > > > At a glance, the mr one mentions Spring 2019, and the JEP links mention > > that the last vote is about to finish. > > > > Between that and the last email being in 2015, I presumed the list was > > due for archiving anyway. > > > > Not the case? > > A glance at https://urldefense.proofpoint.com/v2/url? > u=http-3A__mail.openjdk.java.net_mailman_listinfo&d=DwIC- > g&c=jf_iaSHvJObTbx-siA1ZOg&r=P5m8KWUXJf- > CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=bRQjtoyYHdtaiq5gNxQ1St7pk56fOkDnnWmi_D5S_eE&s=P1Y1zCAiANrST4bDkPmVUfsneRl6ebmTuVR5PVmrh9c&e= > shows that > some mailing lists are connected with Java SE activities around spec and > conformance, rather than OpenJDK activities around implementation and > infra. I recommend ignoring the former lists, and focusing on the lists > connected directly with OpenJDK Projects. > > Alex > That's a fair suggestion. Since part of the original idea was a structured hierarchy of lists on the front-end, we could always filter the spec lists later by sticking them into a sub-directory or some such. But that discussion can happen at a later date, once the cull is complete. Best Regards Adam Farley IBM Runtimes Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From adinn at redhat.com Tue Mar 19 11:08:41 2019 From: adinn at redhat.com (Andrew Dinn) Date: Tue, 19 Mar 2019 11:08:41 +0000 Subject: Why no methods like toList() / toMutableList() / toSet() / toMutableSet() on Java Collection and Stream interfaces ? In-Reply-To: <1198344d-d1ae-9226-a38d-3cb3bcd6a658@code-sourcery.de> References: <1198344d-d1ae-9226-a38d-3cb3bcd6a658@code-sourcery.de> Message-ID: Hi Tobias, On 19/03/2019 09:04, Tobias Gierke wrote: > Thanks for the pointer ! Is there still no way for mere mortals (read: > non-OpenJDK committers) to comment or vote on issues ? I couldn't find > any "create account" button and a quick Google search turned up a > StackOverflow post from 2015 > (https://stackoverflow.com/questions/29379425/where-to-report-issues-of-openjdk-when-youre-not-a-openjdk-developer) > that basically says "Not possible". well, I am afraid voting on issues is pretty much ignored even when the votes are cast by OpenJDK committers. The OpenJDK runtime is far too complex an implementation for most, if not all, decisions about what it does to be decided by counting votes. In particular, its maturity means there is a continual balancing act needed to avoid conflicts between adding new function and introducing regressions in performance and reliability. That balancing really requires judgements to be made by seasoned tight-rope walkers. It's not a beauty contest. In consequence, most changes -- even quite small ones -- involve a lot of discussion on OpenJDK mailing lists, usually supported by some experiment with an implementation and testing/verifying of its behaviour. Many such posts are labelled RFC (request for comment) or RFR (request for review). That discussion /is/ where you are able to participate but there are caveats. Comments on the JIRAs are not really relied on because there is no guarantee that all those concerned will see them. This is really a triaging choice. At JIRA create time it is not always straightforward to identify the target audience for a proposed change. So, JIRA creation is followed up by posting an RFR or RFC to a list. Committers and reviewers are all subscribed to the mail lists in areas they know about precisely to be sure they get to see all the relevant discussion. Referrals to incorrect mail lists are redirected by those on list who know where a discussion belongs (including sending to multiple lists in some cases). If you think something would be a good idea you can still, as a non-committer, propose it on a relevant list (make an informed guess if you don't know, check the archives to inform that guess). Of course, you will need to back up that proposal with arguments. If you want anyone here who is in a position to listen and agree your proposal -- maybe, even, to help you implement it -- then those arguments need to be clearly stated and thought through and display at least some knowledge of what it is possible and sensible to implement as part of OpenJDK. That includes an awareness of what might prejudice its current performance and integrity. i.e. you probably need to have looked into (some of) the code and hung around on the target list to understand what is already being worked on/prioritised. You might be wondering: Why the high barrier for entry into the debate? Well, note that in most cases you should just be able to build your own Java library to implement what you need (Java is a Turing complete language). There has to be a good reason to go further and support what you want in the runtime (furthermore, to maintain it). I am afraid you cannot really provide that sort of reasoning without knowing about what is already there and why. It is also important to know what has already been proposed and rejected. OpenJDK devs really don't have time to repeatedly explain the faults in already discarded ideas. So, your original post was actually spot on - a quick check as to whether/why the status quo does not include a specific option. Hope that clarifies things. regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From fw at deneb.enyo.de Thu Mar 21 10:32:50 2019 From: fw at deneb.enyo.de (Florian Weimer) Date: Thu, 21 Mar 2019 11:32:50 +0100 Subject: Code Conventions Message-ID: <87va0cqzzh.fsf@mid.deneb.enyo.de> This page contains only a dead link to: Is this page archived somewhere? Right now, I'm particularly interested in formatting guidelines for exception messages. Should they begin with a capitable letter? Are there rules for producing certain clipped sentences? (Such a rule appears to exist for the first sentence in a method documentation.) From david.holmes at oracle.com Thu Mar 21 23:59:31 2019 From: david.holmes at oracle.com (David Holmes) Date: Fri, 22 Mar 2019 09:59:31 +1000 Subject: Code Conventions In-Reply-To: <87va0cqzzh.fsf@mid.deneb.enyo.de> References: <87va0cqzzh.fsf@mid.deneb.enyo.de> Message-ID: <8efe1ba3-65eb-823d-c5c3-4df2627b9c82@oracle.com> Hi Florian, On 21/03/2019 8:32 pm, Florian Weimer wrote: > This page > > > > contains only a dead link to: > > > > Is this page archived somewhere? > > Right now, I'm particularly interested in formatting guidelines for > exception messages. Should they begin with a capitable letter? Are > there rules for producing certain clipped sentences? (Such a rule > appears to exist for the first sentence in a method documentation.) I don't recall ever seeing the format of exception messages covered in any coding guidelines. Probably best to ask on core-libs-dev at openjdk.java.net. Cheers, David From arbautjc at gmail.com Fri Mar 22 16:13:51 2019 From: arbautjc at gmail.com (Jean-Claude Arbaut) Date: Fri, 22 Mar 2019 17:13:51 +0100 Subject: Code Conventions In-Reply-To: <87va0cqzzh.fsf@mid.deneb.enyo.de> References: <87va0cqzzh.fsf@mid.deneb.enyo.de> Message-ID: https://www.oracle.com/technetwork/java/codeconvtoc-136057.html Le jeu. 21 mars 2019 ? 11:33, Florian Weimer a ?crit : > This page > > > > contains only a dead link to: > > > > Is this page archived somewhere? > > Right now, I'm particularly interested in formatting guidelines for > exception messages. Should they begin with a capitable letter? Are > there rules for producing certain clipped sentences? (Such a rule > appears to exist for the first sentence in a method documentation.) > From linuxhippy at gmail.com Sat Mar 23 10:12:13 2019 From: linuxhippy at gmail.com (Clemens Eisserer) Date: Sat, 23 Mar 2019 11:12:13 +0100 Subject: JLang, a Java-to-LLVM compiler In-Reply-To: <5C740A20.6030405@cs.cornell.edu> References: <5C740A20.6030405@cs.cornell.edu> Message-ID: Hi Andrew, > We are happy to announce an initial release of JLang, a Java-to-LLVM > ahead-of-time compiler, on Github at > https://polyglot-compiler.github.io/JLang/. JLang compiles Java source > code directly to LLVM, allowing a variety of LLVM back ends to be used > to target various architectures. Impressive how complete the implementation seems to be (if there would only be Java8 support ;) ), seems like an awesome project. Would it theoretically possible to feed the generated LLVM-IR through the web-assembly backend - assuming the required runtime-components are ported and the Boehm-GC would support WebAssembly? Br, Clemens From linuxhippy at gmail.com Sat Mar 23 10:27:13 2019 From: linuxhippy at gmail.com (Clemens Eisserer) Date: Sat, 23 Mar 2019 11:27:13 +0100 Subject: How to interpret the Classpath-Exception? Message-ID: Hi, To make it short - lets say someone (not me or anyone I am doing business with) would port OpenJDK to a new embedded OS (not using the Java or OpenJDK trademark) and does not (want to) open-source this new port. The argument against open-sourceing the OS specific code is, that thanks to OpenJDKs fine platform abstraction, the new code required to support the new OS would not touch any existing OpenJDK code but instead extend it in various places (by inheriting from predefined classes like GraphicsEnvironment, Graphics, etc and by implementing "native" functions). Is this actually considered legal by the GPL+classpath exception license? I read the classpath-exception up and down, but didn't come to a conclusion. I guess it all boils down to whether the OS-specific implementations count as "independent modules" as stated by the classpath exception: "permission to link this library with independent modules to produce an executable, regardless of the license terms of these independent modules," Is this point of view valid or misinterpreting the license? Thanks & best regards, Clemens From martijnverburg at gmail.com Sat Mar 23 10:45:26 2019 From: martijnverburg at gmail.com (Martijn Verburg) Date: Sat, 23 Mar 2019 10:45:26 +0000 Subject: How to interpret the Classpath-Exception? In-Reply-To: References: Message-ID: Hi Clemens, This list is not for legal discussions on the GPLv2+CE lincense. I would seek out professional legal advice. Cheers, Martijn On Sat, 23 Mar 2019 at 10:27, Clemens Eisserer wrote: > Hi, > > To make it short - lets say someone (not me or anyone I am doing > business with) would port OpenJDK to a new embedded OS (not using the > Java or OpenJDK trademark) and does not (want to) open-source this new > port. > The argument against open-sourceing the OS specific code is, that > thanks to OpenJDKs fine platform abstraction, the new code required to > support the new OS would not touch any existing OpenJDK code but > instead extend it in various places (by inheriting from predefined > classes like GraphicsEnvironment, Graphics, etc and by implementing > "native" functions). > > Is this actually considered legal by the GPL+classpath exception > license? I read the classpath-exception up and down, but didn't come > to a conclusion. > I guess it all boils down to whether the OS-specific implementations > count as "independent modules" as stated by the classpath exception: > "permission to link this library with independent modules to produce > an executable, regardless of the license terms of these independent > modules," > > Is this point of view valid or misinterpreting the license? > > Thanks & best regards, Clemens > -- Cheers, Martijn (Sent from Gmail Mobile) From linuxhippy at gmail.com Sat Mar 23 11:08:21 2019 From: linuxhippy at gmail.com (Clemens Eisserer) Date: Sat, 23 Mar 2019 12:08:21 +0100 Subject: How to interpret the Classpath-Exception? In-Reply-To: References: Message-ID: Hi Martijn, > This list is not for legal discussions on the GPLv2+CE lincense. Why not - according to the mailing lists info page: "General discussion about the OpenJDK Community, unmoderated and possibly high-traffic" > I would seek out professional legal advice. As stated I don't personally need advice, I am interested in the general opinion. Best regards, Clemens From benjamin.john.evans at gmail.com Sat Mar 23 11:31:37 2019 From: benjamin.john.evans at gmail.com (Ben Evans) Date: Sat, 23 Mar 2019 12:31:37 +0100 Subject: How to interpret the Classpath-Exception? In-Reply-To: References: Message-ID: On Sat, 23 Mar 2019 at 12:09, Clemens Eisserer wrote: > > > This list is not for legal discussions on the GPLv2+CE lincense. > Why not - according to the mailing lists info page: "General > discussion about the OpenJDK Community, unmoderated and possibly > high-traffic" > > > I would seek out professional legal advice. > As stated I don't personally need advice, I am interested in the > general opinion. The ?general opinion? is not legally binding and will therefore consist of the opinions of those who have time to bike-shed. What problem does collecting those opinions solve for you? Ben > > From andru at cs.cornell.edu Sat Mar 23 12:29:50 2019 From: andru at cs.cornell.edu (Andrew Myers) Date: Sat, 23 Mar 2019 08:29:50 -0400 Subject: JLang, a Java-to-LLVM compiler In-Reply-To: References: <5C740A20.6030405@cs.cornell.edu> Message-ID: <5C9626BE.1090100@cs.cornell.edu> Thanks! If anyone wants to help add lambdas, that would be great. ;-) I don't see any fundamental reason why the idea you describe would be infeasible, though I am not very knowledgeable about WebAssembly. A surprisingly large obstacle we faced in this project was the JVM run-time support, because it is a wide interface that is not particularly well specified. Standardizing this would help support projects like the one you propose. Cheers, -- Andrew > Clemens Eisserer > March 23, 2019 at 6:12 AM > Hi Andrew, > > > Impressive how complete the implementation seems to be (if there would > only be Java8 support ;) ), seems like an awesome project. > > Would it theoretically possible to feed the generated LLVM-IR through > the web-assembly backend - assuming the required runtime-components > are ported and the Boehm-GC would support WebAssembly? > > Br, Clemens > Andrew Myers > February 25, 2019 at 10:30 AM > * > > We are happy to announce an initial release of JLang, a Java-to-LLVM > ahead-of-time compiler, on Github at > https://polyglot-compiler.github.io/JLang/. JLang compiles Java source > code directly to LLVM, allowing a variety of LLVM back ends to be used > to target various architectures. The JVM and JNI interfaces are > supported with a shared library whose source code is also distributed > as part of JLang. Support for Java libraries is provided by compiling > the OpenJDK Java source into a shared library with JLang and then > linking the OpenJDK native libraries. JLang is built on top of the > Polyglot extensible compiler framework, so it supports experimentation > with new language features and with new implementation techniques. > > > The current JLang release can be used to compile and run a variety of > Java programs, but it has a number of significant limitations that are > in the process of being addressed: > > * > > JLang implements Java 7, so does not yet support some newer Java > features such as lambdas, default methods, or modules. > > * > > Java concurrency is not supported. > > * > > Some corners of the reflection API need more work. > > > We welcome the involvement of external contributors. Interested > parties can subscribe to the users mailing list from the JLang web site. > > > Credits: Daniel Donenfeld, Matt Gharrity, Daniel Weber, Drew > Zagieboylo, Yizhou Zhang > > > ----- > Andrew Myers > Dept. of Computer Science > Cornell University > > * From david.holmes at oracle.com Sun Mar 24 02:47:59 2019 From: david.holmes at oracle.com (David Holmes) Date: Sun, 24 Mar 2019 12:47:59 +1000 Subject: How to interpret the Classpath-Exception? In-Reply-To: References: Message-ID: <17c21c3b-9cb6-c47c-cd0a-443c6f0b1d28@oracle.com> On 23/03/2019 9:08 pm, Clemens Eisserer wrote: > Hi Martijn, > >> This list is not for legal discussions on the GPLv2+CE lincense. > Why not - according to the mailing lists info page: "General > discussion about the OpenJDK Community, unmoderated and possibly > high-traffic" Because the legal interpretation of the GPLv2+CE license is not "general discussion" about the OpenJDK community. Cheers, David ----- >> I would seek out professional legal advice. > As stated I don't personally need advice, I am interested in the > general opinion. > > Best regards, Clemens > From volker.simonis at gmail.com Mon Mar 25 10:23:41 2019 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 25 Mar 2019 11:23:41 +0100 Subject: How to interpret the Classpath-Exception? In-Reply-To: References: Message-ID: Hi Clemens, from my personal point of view, what you describe is not covered by the GPL+CPE. GPL+CPE is intended to cover the "normal" use cases where you run a Java application (even if it uses JNI code) on the OpenJDK without "infecting" your code with the GPL. That's why all the OpenJDK code a "normal" Java application will interface/interact with are covered by the GPL+CPE (e.g. all the Java sources, most of the native class library code and all the JNI/JVMTI headers). However, most of the HotSpot sources (i.e. all the sources under src/hotspot) are only covered by the GPL (without CPE). I doubt that you can port OpenJDK to a new platform without touching the HotSpot sources. One thing you could do however would be to use an alternative virtual machine implementation like for example OpenJ9 which comes under a less restrictive open source license. OpenJ9 is a clean room JVM implementation which is available under either Eclipse or Apache license [1] and uses the OpenJDK class library (without Hotspot) as standard Java library implementation. Regards, Volker [1] https://www.eclipse.org/openj9/oj9_faq.html On Sat, Mar 23, 2019 at 11:27 AM Clemens Eisserer wrote: > > Hi, > > To make it short - lets say someone (not me or anyone I am doing > business with) would port OpenJDK to a new embedded OS (not using the > Java or OpenJDK trademark) and does not (want to) open-source this new > port. > The argument against open-sourceing the OS specific code is, that > thanks to OpenJDKs fine platform abstraction, the new code required to > support the new OS would not touch any existing OpenJDK code but > instead extend it in various places (by inheriting from predefined > classes like GraphicsEnvironment, Graphics, etc and by implementing > "native" functions). > > Is this actually considered legal by the GPL+classpath exception > license? I read the classpath-exception up and down, but didn't come > to a conclusion. > I guess it all boils down to whether the OS-specific implementations > count as "independent modules" as stated by the classpath exception: > "permission to link this library with independent modules to produce > an executable, regardless of the license terms of these independent > modules," > > Is this point of view valid or misinterpreting the license? > > Thanks & best regards, Clemens From neugens at redhat.com Mon Mar 25 12:02:24 2019 From: neugens at redhat.com (Mario Torre) Date: Mon, 25 Mar 2019 13:02:24 +0100 Subject: How to interpret the Classpath-Exception? In-Reply-To: References: Message-ID: On Mon, Mar 25, 2019 at 11:25 AM Volker Simonis wrote: > > Hi Clemens, > > from my personal point of view, what you describe is not covered by the GPL+CPE. But that's the problem right there ;) "personal point" isn't a legal thingy. I think we should move this discussion elsewhere. Cheers, Mario > GPL+CPE is intended to cover the "normal" use cases where you run a > Java application (even if it uses JNI code) on the OpenJDK without > "infecting" your code with the GPL. That's why all the OpenJDK code a > "normal" Java application will interface/interact with are covered by > the GPL+CPE (e.g. all the Java sources, most of the native class > library code and all the JNI/JVMTI headers). However, most of the > HotSpot sources (i.e. all the sources under src/hotspot) are only > covered by the GPL (without CPE). I doubt that you can port OpenJDK to > a new platform without touching the HotSpot sources. > > One thing you could do however would be to use an alternative virtual > machine implementation like for example OpenJ9 which comes under a > less restrictive open source license. OpenJ9 is a clean room JVM > implementation which is available under either Eclipse or Apache > license [1] and uses the OpenJDK class library (without Hotspot) as > standard Java library implementation. > > Regards, > Volker > > [1] https://www.eclipse.org/openj9/oj9_faq.html > > On Sat, Mar 23, 2019 at 11:27 AM Clemens Eisserer wrote: > > > > Hi, > > > > To make it short - lets say someone (not me or anyone I am doing > > business with) would port OpenJDK to a new embedded OS (not using the > > Java or OpenJDK trademark) and does not (want to) open-source this new > > port. > > The argument against open-sourceing the OS specific code is, that > > thanks to OpenJDKs fine platform abstraction, the new code required to > > support the new OS would not touch any existing OpenJDK code but > > instead extend it in various places (by inheriting from predefined > > classes like GraphicsEnvironment, Graphics, etc and by implementing > > "native" functions). > > > > Is this actually considered legal by the GPL+classpath exception > > license? I read the classpath-exception up and down, but didn't come > > to a conclusion. > > I guess it all boils down to whether the OS-specific implementations > > count as "independent modules" as stated by the classpath exception: > > "permission to link this library with independent modules to produce > > an executable, regardless of the license terms of these independent > > modules," > > > > Is this point of view valid or misinterpreting the license? > > > > Thanks & best regards, Clemens -- Mario Torre Associate Manager, Software Engineering Red Hat GmbH 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From volker.simonis at gmail.com Mon Mar 25 14:24:28 2019 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 25 Mar 2019 15:24:28 +0100 Subject: How to interpret the Classpath-Exception? In-Reply-To: References: Message-ID: On Mon, Mar 25, 2019 at 1:03 PM Mario Torre wrote: > > On Mon, Mar 25, 2019 at 11:25 AM Volker Simonis > wrote: > > > > Hi Clemens, > > > > from my personal point of view, what you describe is not covered by the GPL+CPE. > > But that's the problem right there ;) > > "personal point" isn't a legal thingy. > > I think we should move this discussion elsewhere. > I really can't understand why most people start to hyperventilate over "legal/license" questions on OpenJDK mailing lists. This doesn't usually happen even for the most weird technical questions and a lot of times people answer to such questions without being experts in the corresponding areas or without the ambition of providing the ultimate and single authoritative answer. But for perfectly valid and reasonable legal/licensing questions (at least from my point of view :) the questioner is usually heavily criticized how he could ever dare to ask such a question and he's been told to walk away. If somebody has no answer to a technical question, he simply doesn't answer. For legal questions it seems that a lot of people feel empowered to answer why they (as well as everybody else on the list) will not and can not answer. If legal/licensing questions weren't relevant for the OpenJDK, we would not have the need to provide a legal section right on our home page [1]. But once it's there, I think it's valid to discuss such topics in the same way we discuss every other topic. I'm perfectly aware of the fact that providing "legal advice" [2] may be subject to certain regulations in various countries. But that shouldn't hinder us to "discuss" such topics here. I think it is clear to everybody that nobody should base his business decisions on information/opinions he received from an open source projects mailing list. But that's also true for any other advice you receive here. After all it's just a mailing list where everybody acts in good faith and to his best knowledge. Regards, Volker PS: I don't have the intention to start a indefinite, controversial discussion so I won't answer to this thread any more. But I'll take the liberty of answering to other legal questions on the OpenJDK mailing lists in good faith and to the best of my knowledge :) [1] http://openjdk.java.net/legal/ [2] https://en.wikipedia.org/wiki/Legal_advice > Cheers, > Mario > > > GPL+CPE is intended to cover the "normal" use cases where you run a > > Java application (even if it uses JNI code) on the OpenJDK without > > "infecting" your code with the GPL. That's why all the OpenJDK code a > > "normal" Java application will interface/interact with are covered by > > the GPL+CPE (e.g. all the Java sources, most of the native class > > library code and all the JNI/JVMTI headers). However, most of the > > HotSpot sources (i.e. all the sources under src/hotspot) are only > > covered by the GPL (without CPE). I doubt that you can port OpenJDK to > > a new platform without touching the HotSpot sources. > > > > One thing you could do however would be to use an alternative virtual > > machine implementation like for example OpenJ9 which comes under a > > less restrictive open source license. OpenJ9 is a clean room JVM > > implementation which is available under either Eclipse or Apache > > license [1] and uses the OpenJDK class library (without Hotspot) as > > standard Java library implementation. > > > > Regards, > > Volker > > > > [1] https://www.eclipse.org/openj9/oj9_faq.html > > > > On Sat, Mar 23, 2019 at 11:27 AM Clemens Eisserer wrote: > > > > > > Hi, > > > > > > To make it short - lets say someone (not me or anyone I am doing > > > business with) would port OpenJDK to a new embedded OS (not using the > > > Java or OpenJDK trademark) and does not (want to) open-source this new > > > port. > > > The argument against open-sourceing the OS specific code is, that > > > thanks to OpenJDKs fine platform abstraction, the new code required to > > > support the new OS would not touch any existing OpenJDK code but > > > instead extend it in various places (by inheriting from predefined > > > classes like GraphicsEnvironment, Graphics, etc and by implementing > > > "native" functions). > > > > > > Is this actually considered legal by the GPL+classpath exception > > > license? I read the classpath-exception up and down, but didn't come > > > to a conclusion. > > > I guess it all boils down to whether the OS-specific implementations > > > count as "independent modules" as stated by the classpath exception: > > > "permission to link this library with independent modules to produce > > > an executable, regardless of the license terms of these independent > > > modules," > > > > > > Is this point of view valid or misinterpreting the license? > > > > > > Thanks & best regards, Clemens > > > > -- > Mario Torre > Associate Manager, Software Engineering > Red Hat GmbH > 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From aph at redhat.com Tue Mar 26 09:14:32 2019 From: aph at redhat.com (Andrew Haley) Date: Tue, 26 Mar 2019 09:14:32 +0000 Subject: How to interpret the Classpath-Exception? In-Reply-To: References: Message-ID: On 3/25/19 2:24 PM, Volker Simonis wrote: > I really can't understand why most people start to hyperventilate > over "legal/license" questions on OpenJDK mailing lists. This > doesn't usually happen even for the most weird technical questions > and a lot of times people answer to such questions without being > experts in the corresponding areas or without the ambition of > providing the ultimate and single authoritative answer. Well, yes, but... Partly the problem is that the law can be horribly counter-intuitive, with a mess of confusing and contradictory precedents. But also there has emerged a doctrine of interpretation of free software licence (in)compatibility which is not much questioned and has assumed the status of a quasi-truth even though most of it has never been established in law. That's why a real lawyer is required: they know where the boundary between law and tradition is, and thus they are in a position to provide a truly useful reply. > I'm perfectly aware of the fact that providing "legal advice" [2] > may be subject to certain regulations in various countries. But that > shouldn't hinder us to "discuss" such topics here. That sounds like an excellent reason to me. One other thing: licence questions are often of the form "How can I get around this licence?" They're not usually expressed in a way that is so transparent, but that's what they are. The questioner wants to take advantage of free software but keep their own changes proprietary, denying their own users the same freedoms they enjoy. Some people find such questions immoral, even outrageous. Do you really find that incomprehensible? > PS: I don't have the intention to start a indefinite, controversial > discussion so I won't answer to this thread any more. But I'll take > the liberty of answering to other legal questions on the OpenJDK > mailing lists in good faith and to the best of my knowledge :) An uncharitable reader might interpret this paragarph as "I'll say anything I please but I will refuse to defend it." -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From fw at deneb.enyo.de Tue Mar 26 09:22:11 2019 From: fw at deneb.enyo.de (Florian Weimer) Date: Tue, 26 Mar 2019 10:22:11 +0100 Subject: How to interpret the Classpath-Exception? In-Reply-To: (Andrew Haley's message of "Tue, 26 Mar 2019 09:14:32 +0000") References: Message-ID: <87imw69eik.fsf@mid.deneb.enyo.de> * Andrew Haley: > Partly the problem is that the law can be horribly counter-intuitive, > with a mess of confusing and contradictory precedents. But also there > has emerged a doctrine of interpretation of free software licence > (in)compatibility which is not much questioned and has assumed the > status of a quasi-truth even though most of it has never been > established in law. That's why a real lawyer is required: they know > where the boundary between law and tradition is, and thus they are in > a position to provide a truly useful reply. On the other hand, I don't think it takes a lawyer to observe that the Hotspot source files do not include the classpath exception. Maybe that observation alone makes Clemens' questions moot. > One other thing: licence questions are often of the form "How can I > get around this licence?" They're not usually expressed in a way that > is so transparent, but that's what they are. The questioner wants to > take advantage of free software but keep their own changes > proprietary, denying their own users the same freedoms they enjoy. > Some people find such questions immoral, even outrageous. Do you > really find that incomprehensible? Well, in the context of OpenJDK, we do not have symmetric licensing anyway, so it's not entirely clear what's morally acceptable and what is reprehensible. (For projects with symmetric licensing, I would agree that it is problematic.) From aph at redhat.com Tue Mar 26 09:24:23 2019 From: aph at redhat.com (Andrew Haley) Date: Tue, 26 Mar 2019 09:24:23 +0000 Subject: How to interpret the Classpath-Exception? In-Reply-To: <87imw69eik.fsf@mid.deneb.enyo.de> References: <87imw69eik.fsf@mid.deneb.enyo.de> Message-ID: <473131c1-07eb-7103-6bc1-bef539c2cfcf@redhat.com> On 3/26/19 9:22 AM, Florian Weimer wrote: > Well, in the context of OpenJDK, we do not have symmetric licensing > anyway, so it's not entirely clear what's morally acceptable and what > is reprehensible. (For projects with symmetric licensing, I would > agree that it is problematic.) That lack of clarity that makes the issues *more* problematic and inflammatory IMO. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From neugens at redhat.com Tue Mar 26 09:31:32 2019 From: neugens at redhat.com (Mario Torre) Date: Tue, 26 Mar 2019 10:31:32 +0100 Subject: How to interpret the Classpath-Exception? In-Reply-To: <87imw69eik.fsf@mid.deneb.enyo.de> References: <87imw69eik.fsf@mid.deneb.enyo.de> Message-ID: On Tue, Mar 26, 2019 at 10:22 AM Florian Weimer wrote: > On the other hand, I don't think it takes a lawyer to observe that the > Hotspot source files do not include the classpath exception. Maybe > that observation alone makes Clemens' questions moot. You are subtly right, the only proper answer to Clemen's question other than "ask to a lawyer" is to read the licence ;) Cheers, Mario -- Mario Torre Associate Manager, Software Engineering Red Hat GmbH 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898 From simon at webmink.com Tue Mar 26 14:23:18 2019 From: simon at webmink.com (Simon Phipps) Date: Tue, 26 Mar 2019 14:23:18 +0000 Subject: How to interpret the Classpath-Exception? In-Reply-To: <87imw69eik.fsf@mid.deneb.enyo.de> References: <87imw69eik.fsf@mid.deneb.enyo.de> Message-ID: On Tue, Mar 26, 2019 at 2:32 AM Florian Weimer wrote: > > On the other hand, I don't think it takes a lawyer to observe that the > Hotspot source files do not include the classpath exception. Maybe > that observation alone makes Clemens' questions moot. > Indeed - I have been a bit surprised about the fuss! When we picked GPL+CPE for OpenJDK, it was our intent that in situations like the one Clemens describes the full corresponding source for the new platform would have to be made available, so that others could join in rapidly improving the port. If you want to keep it secret, go buy a license. Obviously there may be some subtlety that a lawyer could exploit in a tricksy lawsuit, but the summary answer to the original question has to be that the CPE does not apply to the implementation "glue" of ports because that "face" of OpenJDK does not have the CPE applied. There, shoot me for stating the obvious and being helpful :-) S.