What is the current state of sharing code between ...

# multiplatform

[Michael Paus]

What is the current state of sharing code between JVM (desktop) and Android. They are both Java, so sharing some code between these two platforms just seems to be natural but according to the documentation this is still not possible. See: https://kotlinlang.org/docs/multiplatform-hierarchy.html

[Jeff Lockhart]

See this thread. In summary, it should mostly work thanks to @Sebastian Sellmair [JB]'s efforts. But it's still not officially supported by the Kotlin team. I'm personally using a jvm+android source set myself successfully in my library.

[tylerwilson]

I also have my KMP module set up like so:
• common
◦ jvm
▪︎ android
especially for custom date time handling, etc. it works very well using the desugaring library.
I have only experimented a little with desktop, but when I did it appeared to work fine.

[Michael Paus]

@Jeff Lockhart I just tested the code sharing between Android and JVM and it seems to work. I just had to create a new source folder jvmCommonMain with the same structure as the other source folders and add this

@OptIn(ExperimentalKotlinGradlePluginApi::class)
applyDefaultHierarchyTemplate {
    common {
        group("jvmCommon") {
            withAndroidTarget()
            withJvm()
        }
    }
}

at the start of the kotlin section in the build.gradle.kts file.
Thanks for the help.

[Jeff Lockhart]

For the most part, as long as you're using Java APIs that are compatible with Android, which most are, it should just work.

The only trouble I've run into is with different dependency artifacts for JVM and Android, that share common API I use in the jvmCommon source set. There's no commonizer like Kotlin/Native has. I work around this by adding the JVM dependency artifact to the jvmCommon source set as compileOnly and use some Gradle tricks to remove the JVM artifact from the Android target compilation.

[Michael Paus]

I hate having to use Gradle tricks. I’ll come back to you once I stumble over such a case 😉.

[Jeff Lockhart]

Luckily this should only be a problem when using non-KMP libraries, as KMP libraries will work seamlessly with the embedded Gradle module metadata.

This is the Gradle trick I need in my library, applied here, which essentially injects this Gradle module metadata for the non-KMP artifacts.