skip to content

What does `--dsl` control in `gradle init`, and how would you decide between `kotlin` and `groovy`?

level: middleimportance: should knowfreq 40%

answer

  1. kotlin → .kts, groovy → .gradle
  2. DSL ≠ app language
  3. Kotlin = type-safe, IDE completion
  4. Groovy = dynamic, terse, legacy examples
  5. Kotlin is the recommended default

basics

~10 s

--dsl selects the build-script language for the generated scripts: kotlin produces *.gradle.kts files, groovy produces *.gradle files. Kotlin DSL gives type-safe, IDE-friendly scripts and is now the recommended default.

solid answer

~40 s

`--dsl` chooses the language of the generated build and settings scripts. `--dsl kotlin` emits `settings.gradle.kts` and `build.gradle.kts`; `--dsl groovy` emits `settings.gradle` and `build.gradle`. The choice is about the **build-script DSL**, not your application's language—you can write a Java app with the Kotlin DSL. Kotlin DSL is statically typed, so you get IDE autocompletion, refactoring, and compile-time errors on typos in the build logic; it's Gradle's recommended default for new projects since it surfaces mistakes earlier. Groovy DSL is more dynamic/concise and has a longer history of examples online, but its dynamic typing means many errors only appear at configuration time. When `--dsl` is omitted, `init` prompts (defaulting to Kotlin in recent Gradle versions). For most new builds, prefer `kotlin` unless you're matching an existing Groovy codebase or rely on Groovy-only metaprogramming.

code

bash · 5 lines
bash
# Kotlin DSL (recommended)
gradle init --type java-library --dsl kotlin

# Groovy DSL (match an existing build)
gradle init --type java-library --dsl groovy

go deeper

for a junior

Know --dsl picks Kotlin (.kts) or Groovy (.gradle) build scripts.

for a middle

Contrast the two DSLs (typing, tooling, errors) and that DSL is independent of the app language.

for a senior

Advise a default (Kotlin) and articulate migration/consistency trade-offs and compilation cost.

for a principal

Set an org-wide DSL standard, weighing tooling benefits against migration cost across many repos.

## What `--dsl` selects Gradle build scripts can be written in two DSLs: **Groovy** (`build.gradle`, `settings.gradle`) or **Kotlin** (`build.gradle.kts`, `settings.gradle.kts`). `--dsl` tells `init` which file flavor to generate. It is orthogonal to `--type`/implementation language: a `java-application` can be scaffolded with either DSL. ## Kotlin DSL - **Statically typed.** Plugin extensions, task properties, and accessors are typed, so the IDE offers completion and flags typos at edit/compile time. - Files end in `.kts` and are compiled as Kotlin scripts. - Recommended default for new projects in modern Gradle because of the better tooling and earlier error detection. - Type-safe accessors (e.g. `implementation(...)`, `tasks.named<Test>("test")`) require correct plugin application order. ## Groovy DSL - **Dynamically typed.** More forgiving, terser, and historically the most common in online examples. - Errors in unknown methods/properties typically surface only when the build is configured. - Still fully supported; good when matching an existing Groovy build or using Groovy metaprogramming. ## Choosing | Concern | Kotlin DSL | Groovy DSL | |---|---|---| | IDE completion / refactor | Strong | Weaker | | Error detection | Compile-time | Mostly runtime | | Conciseness | Slightly more verbose | Terse | | Online examples | Growing | Abundant/legacy | | First-build script compilation | Slower (compiled) | Faster to parse | For greenfield builds, **prefer Kotlin** unless you have a strong reason. For a repo already full of `.gradle` files, stay Groovy for consistency. ```bash gradle init --type java-application --dsl kotlin # generates build.gradle.kts / settings.gradle.kts ``` ## Note on omission With no `--dsl`, `init` prompts; recent Gradle versions default the prompt to Kotlin.

  • Does choosing `--dsl kotlin` mean my application must be written in Kotlin?
    No. The DSL is only the build-script language. You can build a Java, Groovy, or Scala application with the Kotlin DSL.
  • What's a practical downside of the Kotlin DSL?
    Kotlin scripts are compiled, so the first build (or after script changes) can be slower than Groovy parsing, and type-safe accessors depend on correct plugin application order.

saying these in an interview costs you the question

  • Saying `--dsl kotlin` forces the project's source language to Kotlin.
  • Claiming Groovy DSL is unsupported or deprecated—it remains fully supported.

context

resolving links…