Publish Kotlin class outputs as Gradle SourceSet outputs so that VSCode (jdt.ls) resolves Java -> Kotlin imports

[pekkanikander]

First time contributor checklist

• I have read how to contribute to this project
• I have signed the Contributor License Agreement

Contributor checklist

• I am following the Code Style Guidelines
• I have tested my contribution on these devices:

• Virtual device sdk_gphone64_amd64, Android 12.

• My contribution is fully baked and ready to be merged as is
• I ensure that all the open issues my contribution fixes are mentioned in the commit message of my first commit using the Fixes #1234 syntax

• I was not able to find any issues related to this

---

VSCode + Gradle + jdt.ls: Publish Kotlin class outputs for IntelliSense analysis

Summary

This patch teaches Gradle to publish Kotlin class output directories as part of each source set’s outputs.
That enables the Eclipse Buildship model, consumed by VSCode’s Java Language Server (jdt.ls),
to include build/classes/kotlin/{main,test} on the Java classpath.

As a result, Java files can resolve symbols defined in Kotlin files within the same module when working in VSCode.
This is a build‑metadata change only; it does not affect runtime behavior, packaging, or Android build artifacts.

Background

When building Signal-Android with VSCode or derivatives, IntelliSense does not find the compiled
Kotlin classes, resulting in thousands of IntelliSense error messages, while the Gradle builds compile just fine.

The reason for this is that VSCode Java uses jdt.ls with Buildship to import Gradle projects. The imported classpath is derived from Gradle source set outputs. By default, these outputs include the Java classes dir (e.g., build/classes/java/main) but not the Kotlin classes dir (build/classes/kotlin/main). When Kotlin outputs aren’t surfaced, jdt.ls can’t type‑check Java references to Kotlin, leading to false IntelliSense errors and broken navigation. Publishing the Kotlin outputs via SourceSetOutput.output.dir(...) fixes this at the model level and works across cleans.

What this patch does

In each affected JVM module (libsignal-service and core-util-jvm), we declare the Kotlin class directories as additional outputs of the main and test source sets, and mark them builtBy the corresponding Kotlin compile tasks:

import org.gradle.api.tasks.SourceSetContainer

val sourceSets = extensions.getByName("sourceSets") as SourceSetContainer

sourceSets.named("main") {
  output.dir(mapOf("builtBy" to tasks.named("compileKotlin")),     "$buildDir/classes/kotlin/main")
}
sourceSets.named("test") {
  output.dir(mapOf("builtBy" to tasks.named("compileTestKotlin")), "$buildDir/classes/kotlin/test")
}

Scope & impact

• Build‑time metadata only; no change to app behavior, artifacts, or packaging.
• IDE‑agnostic (doesn’t commit Eclipse/VSCode files); improves the Gradle Tooling API model
  so any importer that respects source set outputs benefits.
• Android Studio/IntelliJ remain unaffected.

---

VSCode setup

Extensions

• Extension Pack for Java (includes Language Support for Java by Red Hat and Gradle for Java)
• Kotlin extension (language server)

Workspace settings (typical)

{
  "java.import.gradle.enabled": true,
  "java.import.gradle.wrapper.enabled": true,
  "java.import.gradle.offline.enabled": false,
  "java.import.gradle.buildTasks": ["compileKotlin", "classes"],
  "java.configuration.updateBuildConfiguration": "automatic",
  "java.compile.nullAnalysis.mode": "disabled"
}

Repro/verification steps

1. ./gradlew :libsignal-service:clean :libsignal-service:compileKotlin.
2. In VSCode: Java: Clean Java Language Server Workspace → reload; let Gradle import complete.
3. Open a Java file that references a Kotlin type in the same module. With this patch, the thousands of false errors reported by IntelliSense disappear, leaving some 60 warnings and notes, at least many of which appear factual.

Note

This patch was created with the help of ChatGPT-5. I have carefully reviewed all the generated code and documentation and do understand the function and purpose of everything in this patch. However, I am not a Gradle expert myself. Hence, I would have never been able to find this solution by myself and cannot determine if this is the most desirable way to do this. There may be better ways to approach this issue.

References

• Long‑standing VSCode Java issue about unresolved Kotlin types from Java:
  kotlin imports into Java file are unresolved redhat-developer/vscode-java#531
• Gradle SourceSetOutput (publish additional output dirs):
  https://docs.gradle.org/current/dsl/org.gradle.api.tasks.SourceSetOutput.html
• Eclipse newsletter (Buildship & source set/classpath modeling):
  https://www.eclipse.org/community/eclipse_newsletter/2018/february/buildship.php