Move Groovy tooling to the Language Server Protocol allowing consumption in Eclipse and Visual Studio Code

[vogella]

We are currently building language server protocol based support for Dart in the https://github.com/vogellacompany/eclipse-dart project.

Do you have plans to move also to a language server protocol based approach? The big advantage is that the server implementation can be in Groovy and that the editor support in Eclipse requires only ~50 lines of code.

[SimonScholz]

Also see: https://github.com/palantir/language-servers/tree/develop/groovy-language-server

[eric-milles]

Related discussion at #807

[vogella]

I don't understand the tag. What question is asked here?

[eric-milles]

"Do you have plans to move also to a language server protocol based approach?"

[vogella]

Ah, sorry I fought your were asking me something. In the Eclipse project we usually tag user bugs with a similar flag if we are waiting for the user to answer. Thanks, Lars

[eric-milles]

I have been laying back, watching the LS/LSP mature a bit. I see that Spring Tools has moved to using this approach.

Based on what I have seen and understood so far, I can see 3 options for Groovy:

1. implement a standalone language server
2. implement a proxy server for the Java LS
3. patch the JDT within the Java LS

My concern is the support for joint compilation with Java. That is, Java and Groovy sources that are co-located and may have bi-directional dependencies. This is what the current tooling provides and the main reason why JDT Core is patched.

I am leaning towards providing a patch to the Java Language Server since it is based heavily on JDT. However, I don't want to have to support another patch. I was asked about this some time back, but have not heard if the effort to use the Groovy JDT patch actually was tried in the Java LS.

[mauromol]

Maybe it is worth to ask the Groovy devs what they think about the LSP and how they would implement it for Groovy if they were to?

[aeisenberg]

• What sorts of features would you need to give up if you moved groovy-eclipse to LSP?
• What sorts of new features would you get (almost) for free?
• How much code would you be able to deprecate?

If the answers are: not much, lots, and lots, then I'd say that it's a great idea. If the answers are different, though, then more thought needs to go into any potential switch in order to enumerate the advantages.

[mauromol]

From a Greclipse user point of view, having a Groovy LSP would be great because if Eric for any reason won't be able to work on Greclipse any more, the risk for Greclipse to be abandoned again (and, with it, proper Groovy support in Eclipse) is very high, like it happened in the past after Pivotal decided to cease supporting Greclipse development. If I understand it well, with a Groovy LSP, instead, the chance that other devs will work on it (given the fact that it's IDE agnostic) is probably higher and the Eclipse-specific part to get proper Groovy support would be extremely reduced. Correct me if I'm wrong.

Also, #396 could probably finally become reality! :-)

[vogella]

If Groovy would provide a language server support in Eclipse is trivial. We recently integrate a Dart language server into Eclipse within 30 min.

[eric-milles]

Thoughts:

1. implement a standalone language server
   pro: simpler to implement
   con: lesser functionality -- no joint compilation
   pro: could be its own project disconnected from groovy-eclipse with community support
2. implement a proxy server for the Java LS
   pro/con: possibly simple extension to Java LSP, maybe not
   con: relies/depends on Java LSP
   pro: could provide (one-way) joint compilation support
3. patch the JDT within the Java LS
   pro: provide bi-directional joint compilation support
   con: definitely depends on Java JDT and LSP

[vogella]

JDT-ls and JDT are very open these days, its not like in "the bad old" Eclipse days in which patches were not reviewed or well received.

So if you have a patch for JDT or JDT-ls please create a Gerrit for it and let me know. I can ask one of the new committers to review it. JDT-LS is mainly Redhat these days so we should be fine here.

If you need help with Gerrit let me know, setup usually takes 5-10 minutes and I'm happy to help you.

[eric-milles]

Thanks for that. Would you have time to review the GDT architecture and say if the approach would be acceptable for general JVM language support? https://spring.io/blog/2009/07/30/a-groovier-eclipse-experience

I've had questions from Kotlin developers about using this approach for Kotlin support. I don't want to get into a protracted process of trying to get the JDT patches merged back to JDT Core if the general approach was not going to work for any other languages.