skip to content

Kotlin DSL Fundamentals

4 roadmaps5 questions

Writing build.gradle.kts: statically compiled scripts, the implicit Project receiver, and the IDE completion that comes with it. Interviewers ask why Kotlin DSL became the recommended default.

on this pageshow

explore

questions

5

How do you apply plugins in build.gradle.kts using the plugins {} block, and what makes that block special?

level: juniorimportance: must knowfreq 65%

answer

  1. plugins { id("...") version "..." }
  2. core accessors: java, application
  3. kotlin("jvm") helper
  4. resolved early — literals only
  5. apply false for version-only

basics

~10 s

Use the plugins {} block: list plugins by id and version, e.g. id("org.springframework.boot") version "3.x", or use built-in accessors like kotlin("jvm") or java. It applies plugins declaratively at the top of the script.

solid answer

~40 s

The `plugins {}` block is the modern, declarative way to apply plugins. Inside it you write `id("plugin.id") version "x.y.z"` for community plugins, or use shorthand accessors for core plugins like `java`, `application`, or `kotlin("jvm") version "..."`. What makes the block special is that it is **resolved very early**, before the rest of the script is configured, and it must contain only literal declarations — no arbitrary logic, conditionals, or variables. Gradle parses it ahead of compiling the body so it knows which plugins (and thus which type-safe accessors and extensions) to make available. Versions can be centralised in a version catalog (`alias(libs.plugins.spring.boot)`) or the `pluginManagement` block in settings. This is preferred over the legacy `apply(plugin = "...")` because it gives type-safe accessors and better plugin resolution.

code

kotlin · 5 lines
kotlin
plugins {
    java
    kotlin("jvm") version "2.0.0"
    id("org.springframework.boot") version "3.3.0" apply false
}

go deeper

for a junior

Show the basic id(...) version "..." form and a core accessor like java.

for a middle

Explain early resolution, the literals-only restriction, kotlin("jvm"), and apply false.

for a senior

Connect early plugin resolution to type-safe accessor generation; discuss version catalogs and pluginManagement.

for a principal

Standardise plugin/version governance across a multi-module org via catalogs and convention plugins, minimising drift.

## The plugins {} block Plugins add capabilities to a build — the `java` plugin adds compile/test/jar tasks, the `application` plugin adds a `run` task, and so on. The `plugins {}` block is the **declarative** mechanism for applying them in the Kotlin DSL. ### Forms inside the block ```kotlin plugins { java // core plugin, accessor form application // another core plugin kotlin("jvm") version "2.0.0" // kotlin("...") helper id("org.springframework.boot") version "3.3.0" // community plugin by id id("io.spring.dependency-management") // version inherited / from catalog } ``` - `id("...")` — applies a plugin by its published id; `version "..."` pins it. - `kotlin("jvm")` — a helper that expands to `id("org.jetbrains.kotlin.jvm")`. - Bare accessors like `java` / `application` — generated for **core** Gradle plugins. - `apply false` — declares a plugin's version without applying it here (useful in a root script to set versions for subprojects). ### Why the block is special / restricted Gradle evaluates `plugins {}` **before** it compiles and runs the rest of the script. To do that it must be able to read the block statically, so the block accepts only **constant, literal** declarations — you cannot put `if` statements, loops, local variables, or calls to other functions inside it. This early resolution is exactly what lets Gradle generate **type-safe accessors**: once it knows the `application` plugin is applied, it can expose the `application { }` extension with full typing in the IDE. ### Versions and catalogs Versions can live inline, in `settings.gradle.kts`'s `pluginManagement { }`, or in a version catalog: ```kotlin plugins { alias(libs.plugins.spring.boot) } ``` ### Legacy alternative The old `apply(plugin = "java")` (or `buildscript {}` + `apply`) still works for edge cases (e.g. applying a plugin conditionally), but it does **not** yield type-safe accessors and is discouraged for normal use.

  • Why can't you put an if-statement inside the plugins {} block?
    Gradle resolves the block statically and very early, before compiling the script body, so it only accepts literal declarations — no logic, variables, or conditionals.
  • What does `apply false` do in a plugins block?
    It declares (and resolves the version of) the plugin without applying it in the current script, typically in a root build so subprojects can apply it without repeating the version.
  • How does plugins {} differ from the legacy apply(plugin = "...")?
    plugins {} resolves declaratively, enables type-safe accessors, and integrates with plugin resolution; apply(...) is imperative and gives no typed accessors.

saying these in an interview costs you the question

  • Putting conditionals or variables inside plugins {} and expecting it to work.
  • Confusing apply false (don't apply now) with not declaring the plugin at all.

context

resolving links…

open as a page

What is build.gradle.kts, and how does it differ from build.gradle when describing a Gradle project?

level: juniorimportance: must knowfreq 70%

basics

~20 s

build.gradle.kts is a Gradle build script written in Kotlin (the Kotlin DSL), instead of build.gradle which uses the Groovy DSL. Both configure the same project; the .kts file is Kotlin source compiled before the build runs.

open as a page

How do you declare dependencies in build.gradle.kts, and what is the role of configurations like implementation and api?

level: middleimportance: must knowfreq 60%

basics

~10 s

Inside dependencies {}, attach coordinates to a configuration: implementation("group:name:version"), testImplementation(...), api(...). The configuration name decides the scope and whether the dependency leaks to consumers.

open as a page

Why does the Kotlin DSL give better IDE autocompletion than the Groovy DSL, and what is the cost of the statically-compiled-script design?

level: middleimportance: should knowfreq 40%

basics

~10 s

Kotlin DSL scripts are statically typed and compiled, so the IDE knows real types and offers accurate autocompletion and error checking. The cost is slower first-time configuration because scripts must be compiled (then cached).

open as a page

In a build.gradle.kts script, what is the implicit receiver, and why can you call things like dependencies {} or repositories {} without any qualifier?

level: seniorimportance: should knowfreq 35%

basics

~10 s

The script body runs with an implicit receiver of type Project (a KotlinBuildScript). Calls like dependencies {} or repositories {} are member functions on that Project receiver, so you can call them unqualified.

open as a page