Was it already considered by JetBrains to publish ...

# stdlib

[Fleshgrinder]

Was it already considered by JetBrains to publish dedicated artifacts for all (major) Java versions with Gradle metadata so that Gradle can automatically select the correct one for the Java that is used by a consumer? Today we still have stdlib compiled for Java 1.6 even if we use it in Java 17 and we have to add -jdk7 and -jdk8 to the dependencies (some build tools can do this automatically). Considering that there are a few nice features like indy that could be enabled also for the stdlib if it were to be compiled for newer versions. Or could this create issues for transitive dependencies that were compiled against a different Kotlin dependency where they expect it to be Java 1.6 ABI?

[ephemient]

Kotlin Gradle Plugin (since 1.6.0) defaults to Java 8 compatibility, and the Gradle plugin also uses the Java target to default to a kotlin-stdlib-jdk8 dependency

[Fleshgrinder]

Sure, I know, but this is about the target byte code of the Kotlin stdlib artifact published to central.

[ephemient]

ah, so you're thinking about a JDK8-targeted kotlin-stdlib(-jdk6)?

[ephemient]

https://youtrack.jetbrains.com/issue/KT-35003 would be a good start but I'm not sure how much of a difference targeting jdk8 would be for stdlib

[Fleshgrinder]

I’m thinking about a single stdlib artifact that gets compiled into multiple variants for the different major Java versions (today that would probably be 6, 7, 8, and 9+ given the features available in Kotlin). Each making use of the different additional features that are available (e.g. 8+ can use -Xlambdas=indy, -Xsam-conversions=indy, and -Xemit-jvm-type-annotations, 9+ can also use -Xstring-concat=indy). So these would end up being totally different artifacts for each. Gradle would automatically use the correct version depending on the current builds requirements (see https://docs.gradle.org/current/userguide/variant_model.html#sec:variant-aware-matching).

The only thing unclear to me is in regards to ABI compatibility of transitive dependencies that compiled against a different Kotin ABI. I’m no expert when it comes to ABI compatibility in Java.

[ephemient]

the real changes I can think of are 1. codegen for default impls in interfaces, can't be used for back-compat reasons; 2. indy for lambdas, probably not much impact in stdlib because the heavy usages (e.g. colletions extensions) are all inline; 3. indy for string concat, may have some impact but doesn't happen often on non-error paths

[Fleshgrinder]

Those were just examples, and maybe today there’s not so much to gain from it; there might be things others know of who are more authoritative on this matter. But, I’m looking at things to come like Loom and Valhalla. Given that many (closed source) projects have no need for support of older Java versions, the fact that Oracle continues to push new releases fast (👍) makes me wonder “why hold back” if build tools like Gradle can automatically take care of things.

[ilya.gorbunov]

We plan to merge the stdlib contents into the single artifact kotlin-stdlib after we drop support for JDK 1.6 in Kotlin compiler.
But we don't plan to provide different variants for different JDKs, as it may complicate things significantly for non-variant-aware dependency clients.

[Fleshgrinder]

Would it matter for them? They could use the default (as it's forward compatible) or reference directly the one they want via the classifier.