You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In a project, there are some interfaces set up in Kotlin, also config files, that are imported into the main Java file. These aren't recognized as valid imports, support for this would be useful. Attempting to move out of IntelliJ to VS Code, this is the only problem with the project.
Reacted by ralshammrei, Matheus Canon, Paolo Gavocanov, ScriptedAdventure, Jianbing Fang, David Koerdt, Ryan Sobol, josduj, Jakub Korzeniowski, Samuel Volin and 53 more
While I can appreciate the problem, Kotlin support is kinda out of scope of our Java support at the moment. We'll need to assess if/how we can help improve the situation. It might come from a companion extension eventually.
In a mixed Kotlin-Java Gradle project both languages do recognize dependencies properly. They fail when trying to use classes from the other language though.
An approach to this problem might be to add compiled JVM classes located in the other languages build directory to the classpath.
@fwcd do you have any suggestions on how to implement this either here or in the kotlin language server? you mentioned copying the classfiles around but I'm not sure how to do that manually, let alone code it up.
@coffeepac Implementing that in KotlinLanguageServer first might be easier, because the KLS repo has a smaller codebase and is pretty easy to setup.
Copying any classfiles might not even be necessary, the language server would just have to know where they are located. The Java language server uses the Eclipse project model whilst the Kotlin language server entirely relies on Gradle/Maven, thus placing the classfiles in different locations each.
When scanning the classpath from the Kotlin language server, it would have to search through the directory that the Java language server/the Eclipse project model places the compiled files in.
This also seems like the last piece for me as well to make VS Code viable for development. I am unable to run Java Junit classes that reference a Kotlin class as it is not able to find the class.
Reacted by Jakub Korzeniowski, Brett Fernandes, Charles Harris, James Taylor, Matheus Canon, Eric Aubourg, Jonathan Barronville, Djamshid Ildarov, AnthonyMillerSF, sberka-jama and 21 more
Hey, just in case anyone might have missed it, I built a prototype companion extension that attempts to solve this issue: https://github.com/fwcd/vscode-java-kotlin
We haven't released it yet, but if you really need this you can build it yourself for now.
Reacted by Sabrina Beck Angelini, Sam El-Borai and rubiconvvv
Every big project (including mine) that is going to move from Java to Kotlin will do so incrementally rather than as a total rewrite so the need for having Kotlin recognized in in the VSCode IDE is a pretty big deal breaker, and will stop people from adopting Kotlin.
Jetbrains benefits HUGELY from leaving this flaw unfixed, because it's literally the only thing stopping Kotlin & Java from being mixed in VSCode projects, and forces people to stay on IntelliJ.
Reacted by Olivier Teulière, Cesar Guzman, Gabriel Florio, CEbbinghaus, Ryan Williams, Klevis, Bazinga, Seán Barry, ArmoredPony, 이재진 and 7 more
@fbricon@fwcd this issue prevents vscode-java users from being able to see docs-on-hover or jump-to-definition from the openai and anthropic Java SDKs, which are implemented in Kotlin.
Would you be open to sponsorship or know of a trusted contributor we could sponsor to move this forward? (email in profile)
I don't really have the capacity to maintain the language server more actively these days, but feel free to ask some of the other contributors. @daplf wrote an extension for this a while ago: https://github.com/daplf/vscode-java-kotlin
Would love to see better Kotlin/Java interop in VSCode too.
@fwcd do you know if this issue is the same or different from importing a Kotlin library into Java? Versus importing a Kotlin file in the same project into Java?
I ask because it sounds like in the latter case the import is completely unresolved while in the former case the import is resolved, but you don't get docs-on-hover or jump-to-definition.
@TomerAberbach It's been a while since I've dug into the classpath logic so I'm probably not the right person to ask 😄 That said, I remember it being a bit fiddly, since it very much depends on how your project is built and structured. The idea was definitely to support mixed Java/Kotlin codebases, not sure how far we got with that.
Your use case is one I hadn't really considered and it's not really what my extension was made for. However, the issue is fairly similar.
In a nutshell, my extension allows Kotlin source files used in mixed Java/Kotlin codebases to be added to the project classpath, so that the Java Language Server doesn't complaint about missing symbols (defined in Kotlin).
However, my extension merely adds the compiled bytecode to the project classpath in JDT LS. This means we have the same problem. Any additional language support, such as jump-to-definition or docs-on-hover is missing, because JDT LS only knows about the bytecode (and even if it knew about the source files, it wouldn't be able to understand them, since they are written in Kotlin).
So there needs to be a companion extension that advertises Java language support and is thus able to provide hovers and definitions for Kotlin symbols used in Java source files. This extension would likely need to connect to some other language server that is capable of rendering docs for the Kotlin symbols and provide definition results. Since the actual project is managed by JDT LS, this separate language server would potentially need to make requests to JDT LS (via the delegateCommandHandler pattern) to fetch any information necessary to resolve the symbols.
I don't have a lot of experience with JDT LS and their extensions apart from the one I built, so I'm not entirely sure this would actually work, but it seems to me like this is how some similar use cases are currently being done (e.g., vscode-microprofile, see eclipse-jdtls/eclipse.jdt.ls#1731)
Regarding upstreaming any of this to vscode-java, I can't speak on behalf of the extension maintainers, but as far as I understand, this extension is meant only for Java support. Kotlin (in any shape or form) is out of scope. Therefore, I suspect you will always require a companion extension.
I can't speak on behalf of the extension maintainers, but as far as I understand, this extension is meant only for Java support. Kotlin (in any shape or form) is out of scope.
I am curious whether maintainers share this view. Should a Java developer installing a package like openai-java get intellisense if that package is written with (some) Kotlin?
So @snjeza came up with something that might help here (#4313 and eclipse-jdtls/eclipse.jdt.ls#3682), and we need to check if it works on real life projects. Can anyone share a project that mixes java and kotlin sources?
Activity
[-]kotlin imports[/-][+]kotlin imports into Java file are unresolved[/+]fbricon commentedon May 22, 2018
While I can appreciate the problem, Kotlin support is kinda out of scope of our Java support at the moment. We'll need to assess if/how we can help improve the situation. It might come from a companion extension eventually.
fwcd commentedon Jun 2, 2018
Currently developing a language server and an extension for Kotlin, I have thought about this.
In a mixed Kotlin-Java Gradle project both languages do recognize dependencies properly. They fail when trying to use classes from the other language though.
An approach to this problem might be to add compiled JVM classes located in the other languages build directory to the classpath.
mrjones2014 commentedon Jul 6, 2018
Any updates on this?
coffeepac commentedon Jul 11, 2018
@fwcd do you have any suggestions on how to implement this either here or in the kotlin language server? you mentioned copying the classfiles around but I'm not sure how to do that manually, let alone code it up.
fwcd commentedon Jul 12, 2018
@coffeepac Implementing that in KotlinLanguageServer first might be easier, because the KLS repo has a smaller codebase and is pretty easy to setup.
Copying any classfiles might not even be necessary, the language server would just have to know where they are located. The Java language server uses the Eclipse project model whilst the Kotlin language server entirely relies on Gradle/Maven, thus placing the classfiles in different locations each.
When scanning the classpath from the Kotlin language server, it would have to search through the directory that the Java language server/the Eclipse project model places the compiled files in.
icelove82 commentedon Apr 29, 2019
Can't wait for using kotlin in VSCode. When can we use kotlin in VSCode?
osaaka commentedon Oct 11, 2019
Any updates or news?
hitoshisatow commentedon Jan 28, 2020
This also seems like the last piece for me as well to make VS Code viable for development. I am unable to run Java Junit classes that reference a Kotlin class as it is not able to find the class.
daplf commentedon Jun 27, 2022
Hey, just in case anyone might have missed it, I built a prototype companion extension that attempts to solve this issue: https://github.com/fwcd/vscode-java-kotlin
We haven't released it yet, but if you really need this you can build it yourself for now.
major7x commentedon Dec 15, 2022
Any updates on this issue?
8 remaining items
crummy commentedon May 31, 2024
Agreed, but I suggest telling that to Jetbrains.
Clay-Ferguson commentedon Jun 1, 2024
Jetbrains benefits HUGELY from leaving this flaw unfixed, because it's literally the only thing stopping Kotlin & Java from being mixed in VSCode projects, and forces people to stay on IntelliJ.
rattrayalex commentedon Apr 18, 2025
@fbricon @fwcd this issue prevents
vscode-javausers from being able to see docs-on-hover or jump-to-definition from theopenaiandanthropicJava SDKs, which are implemented in Kotlin.Would you be open to sponsorship or know of a trusted contributor we could sponsor to move this forward? (email in profile)
fwcd commentedon Apr 18, 2025
I don't really have the capacity to maintain the language server more actively these days, but feel free to ask some of the other contributors. @daplf wrote an extension for this a while ago: https://github.com/daplf/vscode-java-kotlin
Would love to see better Kotlin/Java interop in VSCode too.
TomerAberbach commentedon Apr 18, 2025
@fwcd do you know if this issue is the same or different from importing a Kotlin library into Java? Versus importing a Kotlin file in the same project into Java?
I ask because it sounds like in the latter case the import is completely unresolved while in the former case the import is resolved, but you don't get docs-on-hover or jump-to-definition.
rattrayalex commentedon Apr 18, 2025
Thanks @fwcd ! Do you have a sense of whether that extension could feasibly be merged into this one?
Ideally Java users would not have to install a Kotlin-related extension just to use a library that happens to be built with Kotlin.
fwcd commentedon Apr 18, 2025
@TomerAberbach It's been a while since I've dug into the classpath logic so I'm probably not the right person to ask 😄 That said, I remember it being a bit fiddly, since it very much depends on how your project is built and structured. The idea was definitely to support mixed Java/Kotlin codebases, not sure how far we got with that.
daplf commentedon Apr 19, 2025
@rattrayalex @TomerAberbach Hey 👋
Your use case is one I hadn't really considered and it's not really what my extension was made for. However, the issue is fairly similar.
In a nutshell, my extension allows Kotlin source files used in mixed Java/Kotlin codebases to be added to the project classpath, so that the Java Language Server doesn't complaint about missing symbols (defined in Kotlin).
However, my extension merely adds the compiled bytecode to the project classpath in JDT LS. This means we have the same problem. Any additional language support, such as
jump-to-definitionordocs-on-hoveris missing, because JDT LS only knows about the bytecode (and even if it knew about the source files, it wouldn't be able to understand them, since they are written in Kotlin).The solution to this will likely be something along these lines: eclipse-jdtls/eclipse.jdt.ls#2583 (comment)
So there needs to be a companion extension that advertises Java language support and is thus able to provide hovers and definitions for Kotlin symbols used in Java source files. This extension would likely need to connect to some other language server that is capable of rendering docs for the Kotlin symbols and provide definition results. Since the actual project is managed by JDT LS, this separate language server would potentially need to make requests to JDT LS (via the
delegateCommandHandlerpattern) to fetch any information necessary to resolve the symbols.I don't have a lot of experience with JDT LS and their extensions apart from the one I built, so I'm not entirely sure this would actually work, but it seems to me like this is how some similar use cases are currently being done (e.g.,
vscode-microprofile, see eclipse-jdtls/eclipse.jdt.ls#1731)Regarding upstreaming any of this to
vscode-java, I can't speak on behalf of the extension maintainers, but as far as I understand, this extension is meant only for Java support. Kotlin (in any shape or form) is out of scope. Therefore, I suspect you will always require a companion extension.rattrayalex commentedon Apr 19, 2025
Thanks for the note @daplf !
I am curious whether maintainers share this view. Should a Java developer installing a package like
openai-javaget intellisense if that package is written with (some) Kotlin?fbricon commentedon Jan 21, 2026
So @snjeza came up with something that might help here (#4313 and eclipse-jdtls/eclipse.jdt.ls#3682), and we need to check if it works on real life projects. Can anyone share a project that mixes java and kotlin sources?
fbricon commentedon Feb 24, 2026
So we merged some partial support for Kotlin, thanks to @snjeza's work. Java files now see kotlin classes.
It comes with a bunch of caveats though:
feat: support for Qute ALternative expression syntax
Emily1799 commentedon Jul 16, 2026
What would be involved with removing this limitation? Is it a total rethinking, or just something like a few more steps, or support in vscode-gradle?