Can LanguageSupport be generalized to be used for other JVM languages (e.g. Kotlin)

[jimmypoms]

I really like the approach the groovy-eclipse plugin takes in integrating with JDT through a compiler patch. I was wondering whether the compiler patch could be generalized to provide an extension point for other JVM languages, specifically Kotlin.

Thought it is worth to ask for input/directions before giving it a shot by myself ;).

[eric-milles]

The LanguageSupportFactory was certainly designed with this in mind. To get started, you could use the JDT Core patch project as-is. And then you would supply an impl much the same as the GDT Core plug-in does.

[jimmypoms]

This is exactly the answer I was hoping for :)

However, browsing through the code, I do get a little fuzzy about where the implementations are supposed to be switched. It seems like as soon as the groovy plugin is present LanguageSupportFactory will only ever use the GroovyLanguageSupport, having static state and all.

In any case, these are my initial thoughts on going about implementing support other JVM languages:

• Switch implementations in LanguageSupportFactory based on respective arguments caching wherever possible
• Define extension point for additional implementations
• Make the groovy plugin use the extension point

I hope that makes sense.

[eric-milles]

Yes, good observation. LanguageSupportFactory.getLanguageSupport should be selecting from many available LanguageSupport impls. Or there should be one that knows how to handle all supported languages. That is an unfinished part of the design.

You could swap out the fully-qualified name of the Groovy LS impl for your just to see you can handle your content type.

[eric-milles]

Just wanted to note that I think the Language Server Protocol initiative (see also https://github.com/eclipse/eclipse.jdt.ls) is probably where community effort/support is going.

[jimmypoms]

Thank you for the quick reply.

I will check the links and will probably give it a shot with the extension point :).

[felixdo]

Just wanted to note that I think the Language Server Protocol initiative (see also https://github.com/eclipse/eclipse.jdt.ls) is probably where community effort/support is going.

Do you not think that this will change little for groovy-eclipse: Rather than patching the jdt itself, we'd now have to patch the jdt-ls?

[felixdo]

Hmm, maybe not: If the groovy-ls sits on top of the java-ls, like a proxy, maybe things could be much cleaner.

[eric-milles]

From what I have gathered about how JDT-LS is implemented, a thin client-server layer has been inserted between the Java Editor and the JDT backend. To continue to support joint compilation with Java, the Groovy enhancements to JDT will still need to be patched into the backend. If a standalone language server was created for Groovy, I think the Java interoperability would take a big hit.

[mojo2012]

The last days I have been trying to apply the jdt.core patch to jdt-ls - so far without luck. It's far from being a standard maven build (which would make it pretty easy to switch a depencendy).
If someone of you is willing to point me in the right direction/support me, it would be very appreciated.

What I found out so far is that jdt-ls just uses the jdt.core compiler (osgi?) plugin, which in fact is patched by groovy-eclipse. So it should be possible to swap the jdt-ls jdt.core plugin with a patched jdt.core plugin.
I guess there's is some more work to be done, but at least it could be a starting point.