Am I correct that when I create a multiplatform project with only a JVM target that the `commonMain`...

# multiplatform

[Arjan van Wieringen]

Am I correct that when I create a multiplatform project with only a JVM target that the commonMain module is able to resolve java dependencies? That seems really weird to me.

[hfhbd]

Yes. Actually, this is a weird feature.

[Arjan van Wieringen]

Well not only weird, but it can cause a lot of issues. You falsely believe you are working with platform-independent API's and when you add an extra target your original code might not compile anymore.

Escpecially since the module is called commonMain.

[hfhbd]

I would also like to disable this "feature". https://youtrack.jetbrains.com/issue/KT-52664/Multiplatform-projects-with-a-single-target is a parent issue for different related issues

[Paul Woitaschek]

It is absolutely not a weird feature, the feature absolutely makes sense!
The point of commonMain is that it's the parent sources set of all source sets.
Therefore it's api is the api, that all targets have in common.

[hfhbd]

I think, it depends on the use case: eg a shared jvm lib for desktop and android: sure, jvm imports should be allowed.
Use case 2 kmp lib: prototype with jvm and add more targets later: I want to disable this feature

[ephemient]

https://youtrack.jetbrains.com/issue/KT-34453

[Paul Woitaschek]

It would be very strange if commonMain behaved differently.
How would you find out it's api? Let's say we add a new target in the future. Let's call it spaceShipOs. That one doesn't have an implementation of println. How would you know what is common in that case?

[ephemient]

it could work. println is `expect`ed in kotlin-stdlib-common, which commonMain implicitly depends on. there cannot be a kotlin-stdlib-spaceShipOs that doesn't `actual`ize that expectation

[ephemient]

it just doesn't work quite right for single-target multiplatform projects now, there's tooling and IDE bugs you can follow around that

[hfhbd]

One possibility: use a flag to opt-out and allow only kotlin common code in common main. But on the other hand, what is the use case to use a single platform with the multiplatform plugin instead the platform-specific plugins?

[Arjan van Wieringen]

@hfhbd Because you'll have more targets in the future but not now? Like I want to wait until WASM is stable but I want to prepare my common code already.