A modern programming language that makes developers happier.

kotlinlang

Why can I use `java.lang.*` imports in code written in `src/commonMain/kotlin` ?
If that has an incidence, my module currently uses `multiplatform`  plugin and adds `jvm()` and `androidTarget()`  targets.

Because the Java APIs are _common_ to all of your targets.

That is why it's called "common" main, after all.

So, if I add iOS targets, it will start to fail compiling?

I get the idea, but conceptually, I want to build something with "Kotlin" KMP code, strictly in `commonMain`, maybe TODAY, I do not have any non Jvm target, but tomorrow I will

Kotlin exists solely in the context of each target and what language features that target supports

There is no specification for a variant of Kotlin that is agnostic to all existing and future targets

that's not what I meant, I just assume that anything in `commonMain` has the potential to be executed on any target (defined or not)
so, whatever the target I add in my project, this code should compile (from my perspective)

I understand I can't achieve that, right?

You cannot, because as I said no such language specification for that exists

It would be nice though if Kotlin allowed you to specify that it should use all targets for determining what is common, but only require you to supply actual implementations for a subset of them.

Sure. All _current_ targets, at least. You can't know what restrictions a future target will impose, though.

Yes, but ideally you'd be able to control it. So a list of targets to commonize against, and a list of targets that you support.

Another way to think about my original concern would be to make explicit the dependency to JDK provided APIs.
For `jvmMain` &amp; `androidMain`, you have it by default, for `commonMain`, you have to opt-in..

Other dependencies are all explicit AFAIK, JDK types are the only explicit ones for Jvm compatible targets, don't know for JS runtime on other targets

<@U3K6VQZLJ> Right. I'm saying that if a CLR backend gets added in a few years we can't know what restrictions that would impose onto the language so you can only limit things by today's available targets. There is no specification of a target-agnostic Kotlin language or stdlib.

Right, I was just clarifying that making the user specify the list explicitly would prevent situations where there are new targets and code breaks.

<@UAT0QKY1K> It's not just the Java APIs which behaves that way, though. The stdlib does, too. You can reference things in the stdlib which are commonly available between the two targets but not those which are exclusive to native or JS. Any third-party dependencies would behave the same way. You could reference `runBlocking` from kotlinx.coroutines in common, for example, but when you add a JS target that will now fail to compile.

Moreover, some libraries might not publish their common metadata in a way that's compatible with all possible targets. Compose UI has a common artifact but it doesn't support every possible target of the language. Its common API is the set of APIs common to its targets only.