Group Proposal, for discussion: IDE & Tooling support

[Jesper Wilhelmsson]

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 <magnus.ihse.bursie at 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 <ide>-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
>>>>> 
>>>>> 
>