[jdt-dev] Red Hat's Future Java Tooling Plans and JDT

[Eric Williams <ericwill@xxxxxxxxxx>]

Hello members of the JDT community:

I am the manager of the Eclipse team at Red Hat -- some of you may know 
me from my days working on SWT-GTK. I am writing to you today to give an 
update on Red Hat's future plans with respect to Java tooling and JDT.

The age of language support tooling specifically built for one IDE is 
long gone. This has made us, the Eclipse team at Red Hat, adjust our 
strategy around Java tooling development over time. Years ago, we became 
heavily involved in Eclipse JDT.LS, which relies on the Eclipse JDT 
project to provide most of the compiler and language functionality 
underneath. Our contributions to this piece of the ecosystem have worked 
well for years but are no longer sufficient due to considerably reduced 
involvement in the JDT project overall.

A significant cause of the decrease in contributions is the lack of 
velocity in JDT development, which forces dependent projects, and 
potential contributors to stack workarounds in their own projects 
instead of contributing the improvements back to JDT. Contributing 
JDT.LS specific fixes and improvements upstream to JDT has been part of 
our team duties for the last few years. Unfortunately, this is not the 
default behavior across the board, which leads us to ask each of you for 
some fundamental changes in both JDT and its dependent project’s practices.


Here is a list of things that from our POV are hard requirements for the 
projects to continue to thrive:

A) Releng Improvements
- Reorganize the JDT codebase, decouple it from Eclipse specific 
concepts (workspaces, resource model, etc.). This is already WIP. [1]

- Move the jdt.core.manipulation project to the eclipse.jdt.core 
repository, enabling a separate releng procedure that allows the release 
of JDT core bits on demand, easing its consumption by non-Eclipse 
projects to consume it.

B) Refactorings
- A big percentage of the Java functionality is tightly coupled with the 
Eclipse UI which makes it unusable for JDT.LS (recent thread [2] on the 
topic).

- JDT developers should think of core/UI separation from the very 
beginning of the implementation of a new feature, instead of 
implementing things coupled to UI, and expect to later refactor to JDT core.

C) Project Rules
Many project rules prevent contributions from people not deeply involved 
in development of the Eclipse IDE, while the overall project’s focus 
should be adjusting rules towards better community engagement. For 
example: “mass changes” and refactorings being accepted only for M1 
means that integrators have to wait 2 out of every 3 months for the next 
opportunity to have changes merged. Furthermore, the development period 
of the Eclipse release cycle falls twice per year during vacation 
periods  (summer and Christmas), when many committers are not around to 
review changes.

D) Code Modernization
In order to attract new contributors, we must make things easier for 
newcomers to join. Changes that help newcomers not feel lost in the 
codebase, regardless of their immediate technical benefit, must be as 
important as changes that technically improve the project.


We (the Eclipse team at Red Hat) would like to ask all of you JDT 
committers if we can count on you to work together with us on the above 
changes to modernize the project for its continued success. We 
appreciate your answers and discussions of the above recommendations. 
Every piece of this conversation will help us adjust our team’s strategy 
around Java IDE tooling. It will also help guide our decisions about 
what projects to invest in, which areas will be a pain-point for our 
team, and whether better opportunities should be pursued.


1: https://github.com/eclipse-jdt/eclipse.jdt.core/pull/182

2: https://www.eclipse.org/lists/jdt-dev/msg02169.html


Sincerely,


--
Eric Williams
Associate Manager - Eclipse, Che Plugins/Editors, Podman Desktop
Red Hat
Toronto, Canada