Curious to know how, in a java+kotlin(+other jvm l...

# compiler

[Strum355]

Curious to know how, in a java+kotlin(+other jvm lang) source project, how are the types resolved from the non kotlin source code?

[raulraja]

In the current compiler frontend 3rd party symbols incoming from jars and other places in the class path result into descriptors that contains the type info. If those binaries were generated by the Kotlin compiler they include the Kotlin metadata attached to the binaries in annotations that the compiler can then read when compiling a local project. Still jars created with Scala, Clojure and others are seen by the compiler as Javac would. Potentially they create and persist their own metadata too.

[Strum355]

So does that mean the compiler expects the projects' Java sources to be compiled before the Kotlin sources are?

[ephemient]

mixed Java + Kotlin is fine, the Kotlin compiler can use the Java tooling API to compile both at the same time

[ephemient]

mixed (non-Java JVM language) + (other non-Java JVM language) within the same module will be problematic though

[udalov]

We use intellij-core (a part of IntelliJ Community Edition) to resolve Java source code. In a mixed Kotlin+Java project, Kotlin sources are compiled first, with the Kotlin compiler reading Java sources if necessary. Then Java sources are compiled with javac against the .class files generated by Kotlin.

Mixed modules with other languages will therefore not work in this scheme, unless you ensure that there are no circular dependencies between sources of different languages (but in that case, it makes sense to extract parts in different languages to different modules anyway).

[Strum355]

with the Kotlin compiler reading Java sources if necessary.

Am I right in saying this is how the Kotlin compiler can type-check constructs from Java sources used in Kotlin sources? And how much of this functionality is in kotlin-compiler-embeddable?

[Strum355]

(on a side note, https://javadoc.io/doc/org.jetbrains.kotlin/kotlin-compiler-embeddable/ and possibly others are very out of date, Im not sure if this is something handled on the jetbrains side of things or if these are community submitted)

[udalov]

There’s no type checking of Java sources involved because all types are explicit in Java. We do need to parse the Java source and resolve types in the signatures. It’s far easier than to type-check function bodies in Java sources, which the Kotlin compiler doesn’t need since they can’t affect call sites. kotlin-compiler-embeddable is in fact the full Kotlin compiler with shadow-jared dependencies.

[udalov]

I’m not sure what that site’s referring to. Here’s the latest release on the Maven central: https://search.maven.org/artifact/org.jetbrains.kotlin/kotlin-compiler-embeddable/1.4.10/jar

[Strum355]

Was looking for hosted javadoc for various org.jetbrains.kotlin packages, javadoc.io were the first I could find but they were very much behind in releases