A modern programming language that makes developers happier.

kotlinlang

am I right assuming that
`implementation(kotlin("stdlib-jdk8"))`
will grab the kotlin version specified by
```plugins {
    kotlin("jvm") version ..
}```

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>)

yes. You could also override version via `kotlin.coreLibrarariesVersion`

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`

that doesn't look quite robust, but anyway

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

Note that `kotlin-stdlib-jdk8` is the same as `kotlin-stdlib` since <https://kotlinlang.org/docs/whatsnew18.html#updated-jvm-compilation-target|Kotlin 1.8.0>

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

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

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

&gt; btw KGP adds stdlib dependency in `api`
sorry, but why was decided that instead of `implementation`?

&gt; 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.

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.

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

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

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

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

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

yes but `api` is also for Kotlin consumers

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

Sounds like a nice rabbit hole of configurations

dont give out strange ideas, Martin :see_no_evil:

`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

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