Java extension support

[fwcd]

Support vscode-java, so Java can see Kotlin classes and vice versa.

[mrjones2014]

@fwcd any suggestions on where to start for a PR for this? in its current state, how does the language server locate compiled files?

[fwcd]

@mrjones2014 Sure.

Currently, the language server uses Maven or Gradle to find a set of JAR paths:
https://github.com/fwcd/KotlinLanguageServer/blob/d9dee813be0e4cc1a1c9fc15a2f7ed8da99b15e2/src/main/kotlin/org/javacs/kt/classpath/findClassPath.kt#L46-L56

Although vscode-java is compatible with Maven and Gradle too, it still uses an Eclipse project model under the hood (because the Java language server is based upon Eclipse JDT), thus resulting is a project structure like this when using Gradle:

root
├───build | target         
│   └───classes            << Gradle's/Maven's class files (these are used by the Kotlin LS)
├───bin                    << Compiled class files (these are used by the Java LS)
├───build.gradle | pom.xml << Build file
├───.classpath             << Eclipse project classpath (used by the Java LS)
├───.project               << Eclipse project config (used by the Java LS)
└───src
    └───main
        ├───kotlin         << Kotlin sources
        └───java           << Java sources

To allow Kotlin to see Java classes, we need to add the bin directory somehow to the Kotlin LS classpath without interfering too much with the Maven/Gradle-specific logic.

Allowing Java to see Kotlin classes is probably trickier because we would need to modify the .classpath file in order for the Java LS to recognize the compiled Kotlin classes. Additionally, .kt-files that contain more than one top-level class can be split up in multiple .class-files after compilation, which is something the Java language server might have trouble with.

[mrjones2014]

@fwcd could this help?
https://github.com/Ruin0x11/intellij-lsp-server

[fwcd]

@mrjones2014 Although this project looks interesting, the main issue with intellij-lsp-server is that it requires IntelliJ to run side-by-side. Maybe it would be possible to isolate the IntelliJ-specific code, but that might add a lot of unnecessary complexity to the project.

[mrjones2014]

@fwcd hm yeah, good point. I'm really busy at work at the moment but eventually I'm gonna try to get around to making that PR.

[khe817]

@fwcd, any news on this? What can I do manually in the meanwhile to make Java see Kotlin?

Thanks,

[fwcd]

@khe817 Using Java classes from Kotlin will hopefully be possible soon (I've successfully experimented with this over at the kotlin-debug-adapter).

The other way around is a bit trickier, unfortunately, since it requires integration with the Java side and its project model (Eclipse .project and .classpath files).

[petersamokhin]

@fwcd so, is there any way to import Java <—> Kotlin classes for now?

The other way around is a bit trickier

How to do this? Or is it a hypothetical option?

[fwcd]

@petersamokhin Importing Java <-> Kotlin either way around is not possible yet, unfortunately.

[petersamokhin]

@fwcd you told:

To allow Kotlin to see Java classes, we need to add the bin directory somehow to the Kotlin LS classpath without interfering too much with the Maven/Gradle-specific logic.

Maybe this is possible to do?

[petersamokhin]

@fwcd now I only need to import generated Java classed into my Kotlin files. Project is fully written in Kotlin and I don't need to write any Java code and import Kotlin —> Java, only Java —> Kotlin.
So, maybe this is possible now, even using tricky ways?
E.g. the aforementioned way to add the bin directory somehow to the Kotlin LS classpath

[jackielii]

I believe resolving java symbols within Kotlin files is more prominent case.

[sandboxws]

@fwcd what is needed here to implement this feature? Currently, I'm the Kotlin language server is unable to import classes from java dependencies defined inside of build.gradle which obviously is a big concern.

I'll be more than happy to open a PR to implement this crucial feature.

[alexseedkou]

Hey @fwcd,

Any update on this, let me know the detail for this feature. Happy to help on it.

[ice1000]

As proposed by the developer, the solution would only allow Java extension to see Kotlin symbols from the bytecode, so completions might be available, but jump to source can be tricky, and Java extension will not know anything about the Kotlin source. Letting Kotlin resolve Java is easy, because the Kotlin compiler understands Java. But it can also happen that the Kotlin compiler has different understanding of Java files than the Java extension, because they're implemented separately.

This is a general problem of the VSCode LSP design and fixing this requires rewriting the entire protocol (to make the client aware of AST and referential structures).

[ice1000]

It would also be impossible for Kotlin to interop with Scala, because Kotlin compiler doesn't understand Scala, neither do Scala compiler understands Kotlin. But in IntelliJ it all works (using the builtin build system), because IntelliJ understands referential structure and handles compilation in the correct way.

[ice1000]

https://github.com/fwcd/vscode-java-kotlin looks legit for this particular situation (which is surprising to me) but it's apparently a burden for the future (it needs to be kept sync with kotlin/java extensions).

(I'm not trying to make a point here, just leaving some notes. This project is very cool and it's a shame that VSCode's design has limited it in this unpleasant way)

[daplf]

Hey everyone. For any vscode users interested, I just published vscode-java-kotlin on the vscode marketplace: https://marketplace.visualstudio.com/items?itemName=daplf.vscode-java-kotlin

This should allow Java code to see Kotlin code.

If you're using a different editor, the extension may still help, but you'll need to do most of the wiring yourself. Take a look at the code if interested: https://github.com/daplf/vscode-java-kotlin

[Kamii0909]

vscode-java now use a custom Gradle build server that respect Gradle build directory by default, any updates on this?