Hello, I found the commonMain module can import ja...

# multiplatform

[Ayla]

Hello, I found the commonMain module can import java-specified classes in the IDE, is it a known issue or is there some configuration I missed？

[Adam S]

commonMain is only as restrictive as the current targets. So if you only have a JVM target, then you’re allowed to use Java code in commonMain.

If you add a JS target, then commonMain will be more restrictive: it must only contain Kotlin code that works in JS and JVM targets. So if you try to add a class that’s only available in Native, then it will fail.

(although weirdly if you JS + JVM targets, and commonMain contains some Java class like java.util.Optional, and then you run the JVM tests - they’ll pass, even though running the JS tests will fail)

[Ayla]

Oh, thanks!

[wwalkingg]

Common is supposed to be universal, but now it seems to be problematic

[Sebastian Sellmair [JB]]

@Adam S is correct here.
Source Sets in Kotlin will allow you to share as much code as possible.
Therefore if you only share code across jvm platforms, you will be able to write JDK specific code.

The name ‘commonMain’ is just a predefined name. It does not carry any special semantics.

[Michael Paus]

This is at least a badly chosen name because it conflicts with the meaning of “common” as used here: https://kotlinlang.org/api/latest/jvm/stdlib/ and even worse I am not aware of any reasonable method to ensure that a piece of code that you write actually only uses common code from the standard library.

[Sebastian Sellmair [JB]]

I am aware of the criticism! If you want to also make your code compile for other targets, I would really advise you to register those targets soon.
There are plenty of thoughts on how multiplatform tooling should change in order to not break this intuition. I have written a pretty big proposal called ‘Semantic Source Set Analysis Context’ which is doing exactly this: Attaching ’semantics (such as ‘generically common’)' to your Source Set.
However, the current version of the proposal still contradicts itself and its pretty challenging to find a good solution.

We expect this to be the Kotlin 2.2 era.
Until then the IDE tries to be the most useful it can be: Whatever code will compile will also be highlighted as green!

[ephemient]

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

[Sebastian Sellmair [JB]]

Yes, this was the original thoughts 4 years ago!

[Michael Paus]

The IDE is not really helpful in this regard. E.g., I currently have to use this

@file:Suppress("INLINE_FROM_HIGHER_PLATFORM") // Remove once KTIJ-20816 is fixed.

to fix some IDE errors and make it usable at all but I am wondering why there isn’t something like, e.g.,

@file:Assert("ONLY_COMMON_DEPENDENCIES")

to make sure that a given piece of code has only common dependencies (in the sense of the Kotlin standard library) or dependencies on code from another file with the same flag.

[Sebastian Sellmair [JB]]

Sorry to hear you’re suffering hard from KTIJ-20816. I will promise to fix this right after my vacation roughly in three weeks. OK?
As this question around commonMain and its IDE analysis comes up a lot, please try to carry on this message as the current statement from the multiplatform team:

• Yes, we hear you, we know the current idioms do not often match your expectations
• We are working on a proposal making it better for every one
• It is just very difficult to design, as it might look trivial for individuals in the context of a given project (or style of using multiplatform). But it has to be noted, that multiplatform can be used in pretty different styles with different expectations and the current tooling idiom tires to maximise helpfulness.
Regarding KTIJ-20816:
Please note, that you’re sharing code across jvm targets. This was never officially supported. This mode (as well as sharing code across jvm+android) was mostly done by me on a best effort basis. One engineer in the team that tried to help you based upon your feedback. Yes this is not inline with the idiom of ‘the ide should be as helpful as possible’, but its also therefore classified as bug!

[Sebastian Sellmair [JB]]

I can however offer you folks to share design documents once in roughly good shape of what I called the ‘Semantic Source Sets Analysis Context’ (which will be abbreviated as S3AC in commits)

[Michael Paus]

Just a clarification on KTIJ-20816. (I do not want to conquer this thread with that)
IntelliJ IDEA 2023.2 EAP (Community Edition)
Build #IC-232.6734.9, built on June 1, 2023
already seems to fix this problem for me but it is completely unusable because it freezes the GUI several times a day. So I had to switch back to the latest stable version.