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.

Yes. Actually, this is a weird feature.

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

.

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

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.

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

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?

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

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?

@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.