skip to content

What is the kotlin {} extension that KGP adds, and what do you typically configure in it for a JVM project?

level: juniorimportance: should knowfreq 50%

answer

  1. kotlin {} = KotlinJvmProjectExtension
  2. single config entry point
  3. jvmToolchain(n) for the JDK
  4. compilerOptions {} project-wide defaults
  5. freeCompilerArgs e.g. -Xjsr305=strict

basics

~10 s

It's the project extension KGP registers as the single entry point for Kotlin configuration. In a JVM module you commonly set jvmToolchain(...) and compilerOptions { … } (jvmTarget, languageVersion, freeCompilerArgs).

solid answer

~30 s

Applying `org.jetbrains.kotlin.jvm` registers a `kotlin {}` extension on the project (a `KotlinJvmProjectExtension`). It's the central place to configure how Kotlin builds: `jvmToolchain(17)` to pick the JDK, `compilerOptions { … }` to set `jvmTarget`, `languageVersion`/`apiVersion`, and `freeCompilerArgs`, and `sourceSets` if you need to tweak Kotlin source directories or per-source-set settings. The `compilerOptions` here apply project-wide to all Kotlin compilations (main and test) as a convenient default; you can still override per task via `tasks.withType<KotlinCompile>()`. For a typical backend module, setting the toolchain plus a couple of compiler args (like `-Xjsr305=strict` for nullability from Java) is the whole story.

code

kotlin · 6 lines
kotlin
kotlin {
    jvmToolchain(17)
    compilerOptions {
        freeCompilerArgs.add("-Xjsr305=strict")
    }
}

go deeper

for a junior

Know kotlin {} is where Kotlin config goes and that jvmToolchain/compilerOptions live there.

for a middle

List the common settings (toolchain, jvmTarget, languageVersion, freeCompilerArgs) and that they apply project-wide.

for a senior

Explain extension-level vs per-task configuration and practical args like -Xjsr305=strict.

for a principal

Centralize the kotlin {} block in a convention plugin so all modules share toolchain/compiler policy.

## The extension as the configuration hub A Gradle *extension* is an object a plugin attaches to the project to expose its configuration DSL. KGP's extension is `kotlin {}`. For a JVM module it is specifically a `KotlinJvmProjectExtension`, and it is your one-stop surface for Kotlin settings. ## What you configure there ```kotlin import org.jetbrains.kotlin.gradle.dsl.JvmTarget import org.jetbrains.kotlin.gradle.dsl.KotlinVersion kotlin { // 1. Which JDK compiles/runs jvmToolchain(17) // 2. Compiler behavior (applies to all Kotlin compilations) compilerOptions { jvmTarget.set(JvmTarget.JVM_17) languageVersion.set(KotlinVersion.KOTLIN_2_0) freeCompilerArgs.add("-Xjsr305=strict") } } ``` - **`jvmToolchain(n)`** selects (and can auto-provision) the JDK for compile/test/run. - **`compilerOptions { … }`** is the project-wide default for the Kotlin compiler: `jvmTarget`, `languageVersion`, `apiVersion`, and `freeCompilerArgs` (raw flags like `-Xjsr305=strict`, which makes JSR-305 nullability annotations from Java strict so Kotlin treats annotated Java types as nullable/non-null). - **`sourceSets`** lets you adjust Kotlin source directories or attach per-source-set settings if the defaults (`src/main/kotlin`, `src/test/kotlin`) aren't enough. ## Project-wide vs per-task The `compilerOptions` on the extension is a convenience: it seeds the defaults for every Kotlin compile task. When you need a compile task to differ (extra flag only on tests, say), drop down to `tasks.withType<KotlinCompile>().configureEach { compilerOptions { … } }`. ## Practical default for backends Most server modules need very little here: pick a toolchain, optionally pin `jvmTarget`, and add nullability-strictness args. The extension keeps all of that in one readable block rather than scattered task configuration.

  • Do compilerOptions in the kotlin {} block apply to test compilation too?
    Yes — the extension-level compilerOptions seed defaults for all Kotlin compilations including compileTestKotlin. Override per task with tasks.withType<KotlinCompile>() if a compilation needs to differ.
  • What does -Xjsr305=strict do?
    It makes Kotlin honor JSR-305 nullability annotations on Java APIs strictly, so annotated Java types are treated as nullable/non-null instead of platform types, catching NPEs at compile time.

saying these in an interview costs you the question

  • Treating kotlin {} as just a dependency block — it's the compiler/toolchain configuration surface.
  • Assuming extension-level compilerOptions don't reach test compilation.

context

resolving links…