We're vendoring ktfmt (here) since it uses the embedded Kotlin compiler rather than the standard one, which we use. The embedded Kotlin compiler uses other package paths (e.g. org.jetbrains.kotlin.com.intellij instead of com.intellij), which causes weird clashes at runtime, for example:
java.lang.NoSuchMethodError: 'org.jetbrains.kotlin.cli.jvm.compiler.KotlinCoreEnvironment org.jetbrains.kotlin.cli.jvm.compiler.KotlinCoreEnvironment$Companion.createForProduction(org.jetbrains.kotlin.com.intellij.openapi.Disposable, org.jetbrains.kotlin.config.CompilerConfiguration, org.jetbrains.kotlin.cli.jvm.compiler.EnvironmentConfigFiles)'
at com.facebook.ktfmt.format.Parser.parse(Parser.kt:45)
at com.facebook.ktfmt.format.Formatter.sortedAndDistinctImports(Formatter.kt:141)
at com.facebook.ktfmt.format.Formatter.format(Formatter.kt:84)
at org.javacs.kt.formatting.FormatterKt.formatKotlinCode(Formatter.kt:10)
at org.javacs.kt.KotlinTextDocumentService$formatting$1.invoke(KotlinTextDocumentService.kt:204)
at org.javacs.kt.KotlinTextDocumentService$formatting$1.invoke(KotlinTextDocumentService.kt:199)
at org.javacs.kt.util.AsyncExecutor.compute$lambda-2(AsyncExecutor.kt:19)
at java.base/java.util.concurrent.CompletableFuture$AsyncSupply.run(CompletableFuture.java:1700)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at java.base/java.lang.Thread.run(Thread.java:829)
While this is non-ideal, it's currently the best solution I could find that works for our setup. A better solution would be to automate this as part of our Gradle build (i.e. rewrite the package paths and replace the transitive kotlin-compiler-embeddable dependency with kotlin-compiler - basically do this automatically), but I couldn't figure out a clean way of doing so yet.
... there were other dependencies which needed the non-embedded compiler and didn't have an embedded version themselves (I think it was the kotlin-scripting-compiler or perhaps the IDEA plugin, which we no longer depend on though, can't remember).
We're vendoring
ktfmt
(here) since it uses the embedded Kotlin compiler rather than the standard one, which we use. The embedded Kotlin compiler uses other package paths (e.g.org.jetbrains.kotlin.com.intellij
instead ofcom.intellij
), which causes weird clashes at runtime, for example:While this is non-ideal, it's currently the best solution I could find that works for our setup. A better solution would be to automate this as part of our Gradle build (i.e. rewrite the package paths and replace the transitive
kotlin-compiler-embeddable
dependency withkotlin-compiler
- basically do this automatically), but I couldn't figure out a clean way of doing so yet.Originally posted by @fwcd in https://github.com/fwcd/kotlin-language-server/issues/330#issuecomment-1072499406
... there were other dependencies which needed the non-embedded compiler and didn't have an embedded version themselves (I think it was the
kotlin-scripting-compiler
or perhaps the IDEA plugin, which we no longer depend on though, can't remember).Originally posted by @fwcd in https://github.com/fwcd/kotlin-language-server/issues/330#issuecomment-1073071615