Is there any difference between a Kotlin/JVM libra...
# multiplatform
e
Is there any difference between a Kotlin/JVM library, and a MPP library with only JVM enabled? - beside build.gradle.kts and source folder
c
The task names are a bit different, etc If you mean whether the generated JARs are different, I think Kotlin multiplatform adds a bit of metadata but apart from that it should be the same
b
You get two jars in MPP jvm. One for common and another for actual jvm
e
When consuming the library, say from a normal Kotlin/JVM project would there be any noticeable difference?
b
Nope, common jar is added to jvm jar dependencies. The jar name will be suffixed with -jvm though.
e
Cool, thanks. Difficult to see a reason not to create new libs as MPP then, even though they might be a bit JVM-specific
b
The only one I can think of is that overall it'll produce more maven outputs, but that's rarely a concern for library consumer.
Even better yet, thanks to gradle metadata, you can't even distinguish jvm lib from mpp lib when consuming them in gradle
i.e. you can depend on mpp lib in gradle without -jvm suffix (it's only needed on maven)
e
Nice. We have moved most stuff over to Gradle
c
Well, if you create it as multiplatform but then only write code is
jvmMain
, it's just wasted configuration If you can manage to write most of your code is
commonMain
that's really good, but that also means that you don't have access to normal Java APIs (like File & co) so in many projects that's not convenient As an example though, I have a project that uses a Kotlin/JS frontend, and the full API is written in a Multiplatform module with only JS enabled, it only has a single
expect
method. That means that if the client ever wants a desktop app or whatever, the whole API can be used pretty much as is by the JVM or native
👍 2
r
And eventually (it's at least tentatively planed), users would be able to depend on a multiplatform library that does that, and specify the
actual
themselves for any unsupported platforms