Hi all,
I have unfortunately not much time now for a really comprehensive answer on all the points, so only "short" answer here on main one.
The major point not mentioned: we don't have *active* core compiler developers in JDT anymore, for various reasons.
The core compiler team was already small last years, we've lost some core contributors because of burnouts, job changes etc but also we've lost independent contributors working on compiler in the past. At the end, compiler changes that follow Java language changes were mainly driven by *two* IBM developers till recently.
What I've heard now (and what the git log shows) is that remaining IBM JDT team members aren't working on Eclipse JDT anymore (I won't speculate why).
This means the end of future JDT core compiler development *if we don't act now*.
I wonder if anyone from IBM would like to *officially* shed the light on that topic? I miss an open and clear communication here, as it supposed to happen on an *open* source project.
But let assume the rumors are right, and there are no IBM compiler developers left in the project, who is supposed to drive Java 20+ language changes in JDT compiler?
This is a full time job that requires a decent understanding of complex Java specs and not less complex JDT code.
It can't be driven by occasional JDT contributors like me (I lack both knowledge and time for that job).
Only a dedicated team of professionals can drive JDT compiler changes, and we have to deliver something if we want support Java 20 in March 2023, 21 few months later etc.
With that preconditions, the mail from Eric can be simplified to a simple question: do we want a JDT core fork or not?
Nothing is off the table for our team (except keeping the current state of affairs) for now . So that's one possible outcome although the least preferred one by me personally.
Will Red Hat team (which has no *core compiler* developers yet) be forced to fork JDT in order to drive JDT.LS / VS Code support for Java 20, or will we be able to manage the current situation by adopting JDT project to the changed reality?
Here is the kind of patterns in JDT that we believe are hindering productivity and innovation in the project (
https://github.com/eclipse-jdt/eclipse.jdt.core/issues/529):
https://github.com/eclipse-jdt/eclipse.jdt.core/pull/531 vs
https://github.com/eclipse-jdt/eclipse.jdt.core/pull/530 shows are things are expected to be done with current process vs how people who are not trained to this process would work ad-hoc. There is no clear evidence that the "process" way adds value over the ad-hoc one so maybe the issue is the process being sub-optimal. What we would like is that before enforcing this or that particular process or constraint, we (as in JDT contributors) always challenge whether this process or constraint is desired and helpful, and try to get rid or improve everything that doesn't demonstrate clear benefits, to better allow ad-hoc contributions from ad-hoc contributors who are focused on 1 issue or 1 improvement without more resources to learn all the JDT process or oddities compared to most other projects.
I will not get into details *how* to do so or comment on any of the points raised by Eric (where I disagree with some, but that shouldn't block us to move forward).
Most important point for me is: we should avoid forking the project, as a fork from JDT core by Red Hat (for JDT.LS / VS Code support) will mean immediate end of classic Eclipse IDE as *Java* IDE, or at least make it even less relevant as it is already.
No one and nothing is irreplaceable so I wouldn't put such an implication on our decision. Yes, it may lead to constant decreased involvement and contribution from our side in one of the outcomes but truly FOSS projects stay relevant despite such things.
I personally will try to support JDT / RH team as much as I can *adopting* JDT project to avoid a fork.
Thanks Andrey, much appreciated.
Making the core compiler part development more independent from the JDT UI/JDT IDE development is the first and most important goal we should have.
At the end, ideally compiler will be "just" used by JDT IDE as a library, so compiler might already support Java 21 while IDE still have only support for Java 19. Not nice, but better than other alternative we have. With that, the core compiler can evolve more independently (and faster) from the rest of the IDE, and we could avoid forking / dead of Java support in Eclipse IDE.
Core compiler is one big and immediately needed part of the equation as you pointed out. Another one is "smartness" (aka what distinguishes JDT) spread all over the place without which JDT loses a lot of its importance.
For the rest & detailed discussion how to proceed I would prefer to use github tracker.
Kind regards,
Andrey Loskutov
Спасение утопающих - дело рук самих утопающих
https://www.eclipse.org/user/aloskutov
> Gesendet: Montag, 14. November 2022 um 18:21 Uhr
> Von: "Eric Williams" <ericwill@xxxxxxxxxx>
> An: "Eclipse JDT general developers list." <jdt-dev@xxxxxxxxxxx>
> Betreff: [jdt-dev] Red Hat's Future Java Tooling Plans and JDT
>
> 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
>
> _______________________________________________
> jdt-dev mailing list
> jdt-dev@xxxxxxxxxxx
> To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jdt-dev
>
_______________________________________________
eclipse-ide-wg mailing list
eclipse-ide-wg@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/eclipse-ide-wg
