Allow to use JDT language server functionality as alternative to regular JDT UI

[vogella]

To me it looks that most development for JDT will go into the JDT language server integration instead of enhancing JDT UI directly.
It would be great if the Eclipse IDE would also provide a standard way to using this. Maybe you can connect the Java language server with the generic editor and if the user gives priority to this editor the Java language server would be used.

This way we would at least be able to provide the same functionality as VsCode for Java. Currently JDT UI might be more powerful but this may change giving the development resources moving to Java language server support.

[vogella]

cc @mickaelistria @akurtakov @gayanper

[mickaelistria]

Some experiments are happening at https://github.com/rgrunber/eclipse.jdt.ls.client and https://github.com/mickaelistria/eclipse.jdt.ls.client . While it was already proven that JDT-LS can be used as an external process just like it's done for all other language servers; it immediately seems much weaker than plain JDT: missing preferences, missing discovery of JVM, and many other missing operations.
So we're progressively trying to run JDT-LS in the same process as JDT UI, using the same workspace and the same everything. This is a bit less easy and JDT-LS needs to be refactored here and there to behave more like a "slave" than a "master" of some lower-level Eclipse bits, but it's doable and some pieces are already working. I hope I'll soon report that the experiment is actually usable and that we can start planning the next steps (ie identify bits of JDT-UI that we can remove if JDT-LS is present).

[mickaelistria]

See also this mailing-list thread: https://www.eclipse.org/lists/platform-dev/msg03695.html

[mickaelistria]

Note that at the moment, once the current prototype is a minimum viable product, my plan is to keep it in a personal or a Red Hat repo and publish it on Marketplace. We won't try to push force this editor into JDT.
However, this repo will be maintained the Eclipse way, with IP tracking and so on, so whenever there is possible benefit (eg capability to attract more contributor?) to move the code to some Eclipse project, it will be easy. I suspect discussing the replacement of the editor will naturally happen if JDT-UI starts to lag behind JDT-LS and if one day the JDT-LS based editor gets superior in some vital aspects; then it would be in the best interest of JDT-UI itself to adopt it. But we're not there yet.
If everything goes as I foresee, the minimum viable product will be available on Marketplace within a couple of weeks. Our team at Red Hat will most likely start using it as primary editor, for dogfooding, thus allowing also to better consolidate other parts of the stack (eg LSP4E, JDT-LS...).

[vogella]

I would like to start using it, once you think it is consumable for test users. Let me know. One first step into this direction would be to make the JDT UI feature a root level feature in the SDK to be able to uninstall it after getting the new stuff.

[mickaelistria]

One first step into this direction would be to make the JDT UI feature a root level feature in the SDK to be able to uninstall it after getting the new stuff.

Actually, I think for some time, the best is to have both the JDT-LS based editor and the full JDT UI editors installed and usable in the same IDE to allow to comparing them and also to have a good failback to workaround some limitations of the JDT-LS editor that will take some time to fix.

[iloveeclipse]

All that remembers me the story with e4 introduction, at least the fun part of it (before it became default).

Shouldn't we aim to produce two official SDK builds with either JDT UI version being installed?
I believe a "mix" of both in same SDK would be extremely confusing, also for "testers".

[akurtakov]

Note that jdt.ls right now has dependencies on bundles from m2e, xtext, buildship, etc. While these dependencies are optional this could be a major hurdle from releng POV and I don't see anyone jumping up for even daily official builds/tests/etc. so speaking for second SDK build is jumping ahead of ourselves right now.

[mickaelistria]

Shouldn't we aim to produce two official SDK builds with either JDT UI version being installed?

I think what to aim as delivery is still too early to be settled. Fortunately the Eclipse Platform allows to delay and change such decision until very late without risk and without impacting the first steps; so let's leverage this opportunity and dodge the delivery debate until things start to work.

[mickaelistria]

Interested people can look at https://github.com/mickaelistria/eclipse.jdt.ls.client and install it from https://marketplace.eclipse.org/content/jdt-language-server-client-eclipse-ide . It's still immature, but it works and allows to get the generic editor working with JDT-LS in the Eclipse IDE, with or without JDT-UI.

[akurtakov]

Closing this one as the project is not top priority and interested people should step up to help at https://github.com/redhat-developer/eclipseide-jdtls