Language-server-protocol: [Question] cross language communication

[blackdrag]

normally I would not ask this in a github issue, but I did not find any forum or mailing list...

Let us assume we have two language server implementations, each for a different language. Is it then possible that those have code dependencies on each other? Example. Let us say class G1 is written in Groovy, class J1 in Java and extends G1. Class G2 is written in Groovy and extends J1. And finally clas J2 extends G2. As you can see, you cannot compile only the Groovy or only the Java part, since they have dependencies onto each other. This means the language implementations for Java and Groovy need to talk to each other.

And it does not have to be actual compilation. I mean I did not find an error code for a missing class as well, but for example I want to have J1 and J2 as completion options when working in G1 or G2 and the other way around. Which means the language servers have to have shared knowledge of some kind. If this kind of scenario is currently not possible, I would like to make this a feature request. If it is possible it would be nice to have a description of the communication that has to happen to realize this.

[bruno-medeiros]

This issue should be agnostic to the protocol. If one wants cross-language integration, there would have to be a "meta-LS" of some sorts, but that would handled internally. See also: https://github.com/Microsoft/language-server-protocol/issues/76#issuecomment-253751326

[akosyakov]

Agreed with @bruno-medeiros. Groovy LS could be an extension of Java LS or just make use of JDT compiler inside, so it would register for groovy and java files to provide services for both. Or there could be a cross server communication protocol that Java LS and Groovy LS could talk to each other.

But tools should not care about this concern. They are protected by the protocol from such invasive dependencies.

[blackdrag]

Since JDT was mentioned. The Groovy Eclipse plugin suffers a lot from it requiring a patched JDT. A patched JDT means for example a problem if you combine it with other components requiring that as well, like AspectJ. Having one component that then speaks with another through the means of the API of a shared library is exactly what I want to avoid. Imagine further, that you add Kotlin and Scala to the mix. Internally handling this means you have to write a plugin that handles 5 languages/aspects. A meta-LS might be a better idea, but how can I do a meta-LS that depends on standard LS, if the LS don´t provide the means of communication to handled those mixed language usages. Which means those LS would have to speak an extended LS protocol, which then can be used by the meta-LS - with the simple problem that there won´t be a specification of such an extension. And if there is no such specification, it is likely not to happen.

[akosyakov]

Servers could communicate to each other via messages instead of shared libraries. It is a typical solution for distributed systems. E.g. Java server publishes that a class Foo has been changed and Xtend, Groovy, Kotlin, Scala servers get notified.

You are right whether we go for messaging between distributed servers or a composite server, we need another protocol. I don't think it should be in a scope of the LSP (tool-server communication protocol).

[mickaelistria]

Since JDT was mentioned. The Groovy Eclipse plugin suffers a lot from
it requiring a patched JDT. A patched JDT means for example a problem
if you combine it with other components requiring that as well, like
AspectJ.

Please remind that to the JDT mailing-list, and consider helping them to
move forward on this topic ;)

[blackdrag]

We are getting offtopic here I guess, but the JDT problem exists since 2009. Don't think that hasn't been tried before. Maybe we could try again, but I am the wrong person for this, since I have almost zero JDT knwoledge

[dbaeumer]

I agree that this shouldn't be speced in the LSP since there are different use cases that need different implementations. Besides the one that is listed in this issue there is the one of having embedded languages (for example JS in HTML). Whether a server directly uses another server or requests a feature from another server via the tool client is not directly bound to the protocol.

IMO we should have a guidelines how this is best achieved but we shouldn't limit this to one way or the other.

[vscodebot[bot]]

We closed this issue because we don't plan to address it in the foreseeable future. You can find more detailed information about our decision-making process here. If you disagree and feel that this issue is crucial: We are happy to listen and to reconsider.

If you wonder what we are up to, please see our roadmap and issue reporting guidelines.

Thanks for your understanding and happy coding!

[Jack-Works]

I'm working on a markup language and I need to contribute some cross-language code reference, completion, and definitions. It seems like it is not impossible to implement it in the LSP way.