am I right assuming that `implementation(kotlin("stdlib-jdk8"))` will grab the kotlin version specif...

# gradle

[elect]

am I right assuming that
implementation(kotlin("stdlib-jdk8"))
will grab the kotlin version specified by

plugins {
    kotlin("jvm") version ..
}

[Adam S]

short answer: effectively, yes

(if no explicit version is set in other dependencies
https://kotlinlang.org/docs/gradle-configure-project.html#versions-alignment-of-transitive-dependencies)

[tapchicoma]

yes. You could also override version via kotlin.coreLibrarariesVersion

[ephemient]

what actually happens under the hood is that https://gradle.github.io/kotlin-dsl-docs/api/org.gradle.kotlin.dsl/org.gradle.api.artifacts.dsl.-dependency-handler/kotlin.html adds the dependency with a null version, then https://github.com/Jetbrains/kotlin/blob/master/libraries/tools/kotlin-gradle-plugin/src/common/kotlin/org/jetbrains/kotlin/gradle/internal/KotlinDependenciesManagement.kt#L61 replaces null versions in the org.jetbrains.kotlin package with kotlin.coreLibrariesVersion

[ephemient]

but basically yes

[elect]

that doesn't look quite robust, but anyway

[ephemient]

I believe it's done this way because kotlin-dsl in Gradle shouldn't know particulars about the Kotlin Gradle plugin, which is external

[mbonnin]

Note that kotlin-stdlib-jdk8 is the same as kotlin-stdlib since Kotlin 1.8.0

[elect]

yeah, I recalled it once I read about it again in the docs

[mbonnin]

Also implementation(kotlin("stdlib")) is actually the same as doing nothing because KGP will add it for you by default

[mbonnin]

You can change this default by doing this: https://kotlinlang.org/docs/gradle-configure-project.html#dependency-on-the-standard-library

[tapchicoma]

btw KGP adds stdlib dependency in api

[mbonnin]

Ah right!!

[mbonnin]

So it's not exactly the same

[elect]

btw KGP adds stdlib dependency in api

sorry, but why was decided that instead of implementation?

[Adam S]

sorry, but why was decided that instead of implementation?

Just guessing: to be more compatible with Maven consumers. I half-remember something about the API scope being more akin to how Maven dependencies are exposed between projects.

[mbonnin]

I'd vote that it's what you want in 99.99% of the cases. It's really hard to hide all kotlin-stdlib symbols from it's public API.

[mbonnin]

Stuff like kotlin.Unit and kotlin.collections.List is pretty hard to hide to consumers

[ephemient]

kotlin.Unit doesn't usually show up unless you're exposing () -> Unit lambdas (in which case you're definitely using kotlin.Function* function types so it is part of your API regardless of Unit)

[ephemient]

kotlin.collections.List doesn't exist at runtime, it becomes java.util.List in the Java signatures

[mbonnin]

doesn't the Kotlin compiiler see kotlin.collections.List though?

[ephemient]

in the kotlin.Metadata yes, but that's opaque to Java (and annotation classes do not need to exist at runtime)

[mbonnin]

yes but api is also for Kotlin consumers

[mbonnin]

So we'd technically need both javaApi and kotlinApi blob upside down

[mbonnin]

Sounds like a nice rabbit hole of configurations

[elect]

dont give out strange ideas, Martin 🙈

[ephemient]

kotlinApi(stdlib) is not useful at all. either it's a compatible version of stdlib, in which case the consumer already has it, or it isn't compatible with the consumer's compiler, in which case it'll fail regardless of declared transitive dependencies

[ephemient]

we don't declare api(java.base version) either

[mbonnin]

fair enough