Is there any difference between a Kotlin/JVM library, and a MPP library with only JVM enabled? - bes...

# multiplatform

[eirikb]

Is there any difference between a Kotlin/JVM library, and a MPP library with only JVM enabled? - beside build.gradle.kts and source folder

[CLOVIS]

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

[Big Chungus]

You get two jars in MPP jvm. One for common and another for actual jvm

[eirikb]

When consuming the library, say from a normal Kotlin/JVM project would there be any noticeable difference?

[Big Chungus]

Nope, common jar is added to jvm jar dependencies. The jar name will be suffixed with -jvm though.

[eirikb]

Cool, thanks.
Difficult to see a reason not to create new libs as MPP then, even though they might be a bit JVM-specific

[Big Chungus]

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.

[Big Chungus]

Even better yet, thanks to gradle metadata, you can't even distinguish jvm lib from mpp lib when consuming them in gradle

[Big Chungus]

i.e. you can depend on mpp lib in gradle without -jvm suffix (it's only needed on maven)

[eirikb]

Nice. We have moved most stuff over to Gradle

[CLOVIS]

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

[rnett]

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