Group Proposal, for discussion: IDE & Tooling support
Magnus Ihse Bursie
magnus.ihse.bursie at oracle.com
Tue Mar 5 11:36:26 UTC 2019
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
* A comprehensive set of instructions, per IDE, was requested. Good
instructions might even go a long way of removing the need for automatic
* 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
> - 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:
>>> 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).
>>> -- 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
>>>> 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.
More information about the discuss