When you create a Kotlin multiplatform project and only configure a JVM target for it then you can happily use any Java class directly inside the commonMain source set. IntelliJ even gives you code completion hints and everything. Doesn’t this completely undermine the whole purpose of splitting things up into common and non-common parts? I could add more targets later and then my common part would be broken.

It seems like that’s intentional. For example, JS has a lot of random differences, and it’s nice to not have to worry about that when making mobile apps. I usually add linuxX64 as a target for commonMain to force me to avoid this.

@Landry Norris I just can’t/don’t want to believe that. IMHO this would spoil the whole concept completely. I really hope that this turns out to just be a bug. 🙏

Hey @Michael Paus 👋 This is expected and not a bug. What you are missing here is a feature that would tell the tooling, that you would like to later add certain targets. There should be a YouTrack ticket floating somewhere, but it is certainly not a priority, right now. We are focusing on making mpp tooling more stable. Maybe, if this is irritating to more people, I could think of potential workarounds for you to configure tooling in a different way!

Hey @Sebastian Sellmair [JB] Many thanks for the clarification. Irritating is probably the best term for this behaviour especially as I haven’t seen this mentioned in any documents. In essence this means that the allowed content in ‘commonMain’ is not strictly restricted to pure Kotlin. It could be anything as long as the dependent targets can cope with it. E.g. JVM and Android, like in my actual scenario.

Exactly! This mechanism is called ‘precise platforms importing’ and it will see that common main is [jvm, androidJvm] and therefore provides you tooling for that. In the future you might want to tell tooling, that you would like to also have additional targets, that you do not compile right now! (Similar to the approach mentioned above, that just adds a linux target)