Setup JDT LS extension to provide Java + Kotlin interoperability #334

daplf · 2022-03-06T17:13:17Z

Fixes #192

Sets up a VSCode extension to allow Java code to see Kotlin code. The extension depends on both vscode-java and vscode-kotlin. It uses the JDT LS extension mechanism, through a custom JDT LS extension that provides kotlin project importers for maven and gradle.

This seems to work reasonably well for small projects at least. I don't know how well it performs on bigger projects, but I think the concept looks valid and we can always improve that later.

Some notes:

The VSCode extension uses the javaExtensions contribution point to provide vscode-java with the JAR for the JDT LS extension. The JDT LS uses the jar to find the kotlin project importers. The importers have higher priority than the default ones provided by the JDT LS itself.
The JDT LS extension was built with Maven and Java since it would have been much harder to do it with Gradle and Kotlin (due to lack of documentation and editor support).
The importers actually extend MavenProjectImporter and GradleProjectImporter provided by the JDT LS. As such, pretty much all the importing logic is done by the JDT LS. Once the core java project is imported (by MavenProjectImporter or GradleProjectImporter) we add the compiled kotlin files to the project's classpath. This is how the java code is then able to see the kotlin code.
At the moment, the kotlin language server does not generate any bytecode (at least as far as I could tell). This PR also introduces this, since it is required for the JDT LS extension to work. The bytecode generated by the kotlin language server is written to a folder called kls at the root of the workspace. I chose this because the JDT LS messes with the default maven and gradle output paths (and we should try to isolate the language servers as much as possible). The code generation is only triggered on file save for performance reasons.
Some language features are not supported yet (e.g., go to definition from java to kotlin doesn't work as you would expect it to), but the projects should no longer complain about missing symbols when referencing kotlin classes, etc.

How to test this for now:

On the vscode-java-kotlin folder, run the build.sh script to build the JDT LS extension. Afterwards, run npm install to install the VSCode extension dependencies. Once this is done, you can either debug it (using F5 on VSCode), or package it and install it from a VSIX.
Important: The JDT LS extension will only work with the latest kotlin language server code (i.e, the one in this PR), so you should install the language server locally and setup your vscode-kotlin to use that (through the kotlin.languageServer.pathconfiguration property)

This is very experimental (I cannot stress this enough). This is literally the first thing I wrote involving Eclipse PDE and the JDT LS API. With that said, I think the concept at least seems to work, so I'm guessing we can improve this more over time.

Feedback welcome :)

fwcd · 2022-03-07T03:45:08Z

Very nice, thanks a lot for tackling this issue and the writeup, looks pretty good at first glance! I hope to find some time to review this in detail soon.

Similar to vscode-kotlin, I would move vscode-java-kotlin to its own repo, wdyt? (though we could leave it here at least until the PR is merged for easier reviewability)

daplf · 2022-03-07T10:55:21Z

@fwcd Sure, I'm fine either way. If you want, you can create the new repo and I can make a separate PR there with the vscode + JDT part. And we can keep this PR for the changes to the KLS only. Whatever you prefer.

daplf · 2022-03-11T23:57:55Z

@fwcd FYI, I found some more time and added gradle support as well.

From fwcd/kotlin-language-server#334

See https://github.com/fwcd/vscode-java-kotlin

fwcd · 2022-03-17T15:40:39Z

I have moved the vscode-java-kotlin extension to its own repository (under MIT license like vscode-kotlin), to which I've given you write access, so feel free to tinker around on the main branch for now (though keeping the PR workflow would still be great in the future). I hope to find some time to take a closer look at this PR and the extension soon.

fwcd · 2022-03-17T20:52:12Z

server/src/main/kotlin/org/javacs/kt/CompilerClassPath.kt

@@ -95,6 +98,10 @@ class CompilerClassPath(private val config: CompilerConfiguration) : Closeable {
        workspaceRoots.add(root)
        javaSourcePath.addAll(findJavaSourceFiles(root))

+        val outputDir = Paths.get(root.toString(), "kls").toFile()


I would prefix that directory with a dot, e.g. .kls, also perhaps a less generic name? Alternatively, could we perhaps use the storagePath introduced in #337, so we don't have to put custom build outputs into the user's project?

Your second suggestion would be perfect, but unfortunately it'll be tricky to implement (although doable).

The problem is that the JDT LS extension needs to know where to find the build outputs. A directory inside the user's project is an easy solution, because the JDT LS extension can know about this without any help. If we use a different directory, we will need to establish communication between the JDT LS extension and the kotlin language server. This is obviously doable and ideal, but it is trickier to implement.

I would suggest using .kls for now (your first suggestion) and in a later PR we could implement the other approach. What do you think?

Hey. So I thought a little more about this and I think I might have an alternative approach to this that would make things a lot cleaner.

Instead of using custom project importers on the JDT LS extension, we could have a delegateCommandHandler that adds the build output location to the java project classpath. With this approach, the java project would be imported using the normal JDT project importers but we would change the classpath as soon as the KLS is setup. In order for this to work, the KLS would need to be able to call the delegateCommandHandler once it knows where it will store the build outputs. This call would probably need to go through the vscode extensions, since a direct communication between the language servers is tricky. The cool thing about this approach is that the JDT LS would just work normally at first and as soon as the KLS starts, it would be notified to update its project. This approach would also allow us to use temp directories as a default build output location, which is a lot cleaner (especially for people who are not even working on a Java + Kotlin project)

fwcd · 2022-03-17T20:53:17Z

server/src/main/kotlin/org/javacs/kt/KotlinTextDocumentService.kt

@@ -263,6 +266,7 @@ class KotlinTextDocumentService(
    fun lintAll() {
        debounceLint.submitImmediately {
            sp.compileAllFiles()
+            sp.saveAllFiles()


Does separately emitting compilation outputs have a non-negligible performance impact?

Well, the tests I've done were fine, but they were not exhaustive. With that said, this particular part of the code is done async, so I don't think it should be too problematic. I suggest you check it yourself just in case.

Besides this, the only other time we emit code is on file save (which doesn't happen that often, and only for one file at once).

daplf · 2022-03-23T15:41:26Z

@fwcd I updated the PR to use the approach I described in a previous comment (i.e., use a delegateCommandHandler). It requires changes on the vscode and JDT side as well:

fwcd/vscode-kotlin#89
https://github.com/fwcd/vscode-java-kotlin/pull/2

This approach is now a lot cleaner, since it uses temp directories for the build outputs (thus no longer polluting the user workspace)

…tup-jdt-ls-extension

daplf · 2022-04-15T15:57:44Z

Hey @fwcd
Do you think you'll have the time to take a look at this and the other PRs soon? This seems to be a fairly requested feature so it would be cool if we could ship it soon.

fwcd

Sure, looks mostly good, just some minor things.

server/src/main/kotlin/org/javacs/kt/SourcePath.kt

server/src/main/kotlin/org/javacs/kt/KotlinProtocolExtensions.kt

server/src/main/kotlin/org/javacs/kt/CompilerClassPath.kt

server/src/test/kotlin/org/javacs/kt/CompiledFileTest.kt

server/src/test/kotlin/org/javacs/kt/CompilerTest.kt

fwcd · 2022-04-23T17:25:43Z

Thank you!

Setup JDT LS extension

c17d2b7

daplf changed the title ~~Setup JDT LS extension to provide Kotlin + Java interoperability~~ Setup JDT LS extension to provide Java + Kotlin interoperability Mar 6, 2022

daplf marked this pull request as ready for review March 6, 2022 17:13

fwcd added enhancement New feature or request java interop Interoperability with Java/JDT.LS maven Related to the language server's support for Maven projects labels Mar 7, 2022

Added gradle support

2446de8

Update README.md

84196d3

fwcd pushed a commit to daplf/vscode-java-kotlin that referenced this pull request Mar 17, 2022

Set up JDT.LS extension for Java-Kotlin interop

1bc5aa4

From fwcd/kotlin-language-server#334

Move vscode-java-kotlin to its own repository

db5ba9f

See https://github.com/fwcd/vscode-java-kotlin

fwcd reviewed Mar 17, 2022

View reviewed changes

Setup custom KotlinLanguageClient

1cd8d67

daplf mentioned this pull request Mar 23, 2022

Expose extension API fwcd/vscode-kotlin#89

Merged

daplf added 3 commits March 23, 2022 17:08

Catch UnsupportedOperationException on client extensions

d5d7ab3

Use a request instead of a notification

5a38c51

Merge branch 'main' of github.com:fwcd/kotlin-language-server into se…

55e9271

…tup-jdt-ls-extension

fwcd reviewed Apr 16, 2022

View reviewed changes

PR improvements

dd3bd4b

daplf requested a review from fwcd April 22, 2022 20:47

fwcd merged commit 4aa8456 into fwcd:main Apr 23, 2022

daplf deleted the setup-jdt-ls-extension branch April 23, 2022 18:35

daplf mentioned this pull request May 21, 2022

Error: Unsupported request method: kotlin/buildOutputLocation daplf/vscode-java-kotlin#7

Closed

fwcd mentioned this pull request Jul 28, 2024

Make code generation (for Java interoperability) opt-in #585

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Setup JDT LS extension to provide Java + Kotlin interoperability #334

Setup JDT LS extension to provide Java + Kotlin interoperability #334

daplf commented Mar 6, 2022 •

edited

Loading

fwcd commented Mar 7, 2022 •

edited

Loading

daplf commented Mar 7, 2022

daplf commented Mar 11, 2022 •

edited

Loading

fwcd commented Mar 17, 2022

fwcd Mar 17, 2022

daplf Mar 17, 2022

daplf Mar 22, 2022

fwcd Mar 17, 2022

daplf Mar 17, 2022

daplf commented Mar 23, 2022

daplf commented Apr 15, 2022

fwcd left a comment

fwcd commented Apr 23, 2022

Setup JDT LS extension to provide Java + Kotlin interoperability #334

Setup JDT LS extension to provide Java + Kotlin interoperability #334

Conversation

daplf commented Mar 6, 2022 • edited Loading

Some notes:

How to test this for now:

fwcd commented Mar 7, 2022 • edited Loading

daplf commented Mar 7, 2022

daplf commented Mar 11, 2022 • edited Loading

fwcd commented Mar 17, 2022

fwcd Mar 17, 2022

Choose a reason for hiding this comment

daplf Mar 17, 2022

Choose a reason for hiding this comment

daplf Mar 22, 2022

Choose a reason for hiding this comment

fwcd Mar 17, 2022

Choose a reason for hiding this comment

daplf Mar 17, 2022

Choose a reason for hiding this comment

daplf commented Mar 23, 2022

daplf commented Apr 15, 2022

fwcd left a comment

Choose a reason for hiding this comment

fwcd commented Apr 23, 2022

daplf commented Mar 6, 2022 •

edited

Loading

fwcd commented Mar 7, 2022 •

edited

Loading

daplf commented Mar 11, 2022 •

edited

Loading