Group Proposal, for discussion: IDE & Tooling support

[Thomas Stüfe]

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 <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
> >>>>
> >>>>
>
>