Why can I use `java.lang.*` imports in code written in `src/commonMain/kotlin` ? If that has an inci...

# multiplatform

[Olivier Patry]

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.

[jw]

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

[jw]

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

[Olivier Patry]

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

[jw]

Correct

[Olivier Patry]

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

[jw]

There is no such language

[jw]

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

[jw]

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

[Olivier Patry]

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?

[jw]

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

[Olivier Patry]

Yes

[Olivier Patry]

thanks

[eygraber]

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.

[jw]

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

[eygraber]

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.

[Olivier Patry]

Another way to think about my original concern would be to make explicit the dependency to JDK provided APIs.
For jvmMain & 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

[jw]

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

[eygraber]

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

[jw]

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

[jw]

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.