Skip to content

kotlin imports into Java file are unresolved #531

Closed

Description

@viral-p

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.

Activity

  1. changed the title [-]kotlin imports[/-] [+]kotlin imports into Java file are unresolved[/+] on May 10, 2018
  2. fbricon commented on May 22, 2018

    @fbricon
    Collaborator

    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.

  3. fwcd commented on Jun 2, 2018

    @fwcd
    Contributor

    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.

  4. mrjones2014 commented on Jul 6, 2018

    @mrjones2014

    Any updates on this?

  5. coffeepac commented on Jul 11, 2018

    @coffeepac

    @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.

  6. fwcd commented on Jul 12, 2018

    @fwcd
    Contributor

    @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.

  7. icelove82 commented on Apr 29, 2019

    @icelove82

    Can't wait for using kotlin in VSCode. When can we use kotlin in VSCode?

  8. osaaka commented on Oct 11, 2019

    @osaaka

    Any updates or news?

  9. hitoshisatow commented on Jan 28, 2020

    @hitoshisatow

    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.

  10. daplf commented on Jun 27, 2022

    @daplf

    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.

  11. major7x commented on Dec 15, 2022

    @major7x

    Any updates on this issue?

  12. 8 remaining items

  13. crummy commented on May 31, 2024

    @crummy

    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.

    Agreed, but I suggest telling that to Jetbrains.

  14. Clay-Ferguson commented on Jun 1, 2024

    @Clay-Ferguson

    Agreed, but I suggest telling that to Jetbrains.

    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.

  15. rattrayalex commented on Apr 18, 2025

    @rattrayalex

    @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)

  16. fwcd commented on Apr 18, 2025

    @fwcd
    Contributor

    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.

  17. TomerAberbach commented on Apr 18, 2025

    @TomerAberbach

    @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.

  18. rattrayalex commented on Apr 18, 2025

    @rattrayalex

    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.

  19. fwcd commented on Apr 18, 2025

    @fwcd
    Contributor

    @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.

  20. daplf commented on Apr 19, 2025

    @daplf

    @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-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).

    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 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.

  21. rattrayalex commented on Apr 19, 2025

    @rattrayalex

    Thanks for the note @daplf !

    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?

  22. fbricon commented on Jan 21, 2026

    @fbricon
    Collaborator

    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?

  23. fbricon commented on Feb 24, 2026

    @fbricon
    Collaborator

    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:

    • it's only supported with Gradle projects imported via the Buildship plugin (i.e not via vscode-gradle, or any Maven projects)
    • It does not provide any Kotlin intelligence (no completion, hover, references ... in kotlin files). Though kotlin errors are reported in .kt files
    • it's fairly slow on large projects ( a gradle build is triggered under the hood when a kotlin file is saved)
    • Navigating to kotlin classes open the decompiled kotlin file, instead of the actual source one. We might be able to fix that though (Navigating to a kotlin class opens the decompiled code, instead of the actual source #4345).
  24. added this to the End February 2026 milestone on Feb 24, 2026
  25. Emily1799 commented on Jul 16, 2026

    @Emily1799

    it's only supported with Gradle projects imported via the Buildship plugin (i.e not via vscode-gradle, or any Maven projects)

    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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions