Gradle Kotlin DSL vs Groovy DSL: configuração de build em 2026

O Gradle suporta dois DSLs para configuração de build: Groovy (histórico, arquivos .gradle) e Kotlin (moderno, arquivos .gradle.kts). Em 2026, o Kotlin DSL é a escolha padrão para novos projetos, mas muitos projetos legados ainda usam Groovy. Este artigo compara as duas opções em detalhes práticos.

Visao geral

CaracteristicaKotlin DSL (.gradle.kts)Groovy DSL (.gradle)
Extensao.gradle.kts.gradle
TipagemEstáticaDinamica
Autocompletar IDECompletoLimitado
Navegação ao código fonteSimParcial
Documentação inlineSim (KDoc)Limitada
RefatoraçãoSuportadaLimitada
Performance de compilaçãoMais lenta (primeiro build)Mais rápida
Cache de scriptsEficiente (apos primeiro build)Eficiente
Padrao novos projetosSim (desde Gradle 8+)Legado

Sintaxe comparada

Configuração básica do projeto

Kotlin DSL:

// build.gradle.kts
plugins {
    id("org.jetbrains.kotlin.jvm") version "2.1.0"
    id("application")
}

group = "com.exemplo"
version = "1.0.0"

repositories {
    mavenCentral()
}

dependencies {
    implementation("org.jetbrains.kotlinx:kotlinx-coroutines-core:1.9.0")
    implementation("io.ktor:ktor-server-core:3.0.0")
    testImplementation("io.kotest:kotest-runner-junit5:5.9.0")
}

application {
    mainClass.set("com.exemplo.MainKt")
}

tasks.test {
    useJUnitPlatform()
}

Groovy DSL:

// build.gradle
plugins {
    id 'org.jetbrains.kotlin.jvm' version '2.1.0'
    id 'application'
}

group = 'com.exemplo'
version = '1.0.0'

repositories {
    mavenCentral()
}

dependencies {
    implementation 'org.jetbrains.kotlinx:kotlinx-coroutines-core:1.9.0'
    implementation 'io.ktor:ktor-server-core:3.0.0'
    testImplementation 'io.kotest:kotest-runner-junit5:5.9.0'
}

application {
    mainClass = 'com.exemplo.MainKt'
}

test {
    useJUnitPlatform()
}

As diferenças visuais são sutis: Kotlin usa parenteses e aspas duplas consistentemente, enquanto Groovy permite aspas simples e omissao de parenteses.

Configuração Android

Kotlin DSL:

// build.gradle.kts (modulo app)
plugins {
    id("com.android.application")
    id("org.jetbrains.kotlin.android")
    id("org.jetbrains.kotlin.plugin.compose")
}

android {
    namespace = "com.exemplo.app"
    compileSdk = 35

    defaultConfig {
        applicationId = "com.exemplo.app"
        minSdk = 24
        targetSdk = 35
        versionCode = 1
        versionName = "1.0.0"
    }

    buildTypes {
        release {
            isMinifyEnabled = true
            proguardFiles(
                getDefaultProguardFile("proguard-android-optimize.txt"),
                "proguard-rules.pro"
            )
        }
        debug {
            isMinifyEnabled = false
            applicationIdSuffix = ".debug"
        }
    }

    compileOptions {
        sourceCompatibility = JavaVersion.VERSION_17
        targetCompatibility = JavaVersion.VERSION_17
    }
}

dependencies {
    implementation(libs.androidx.core.ktx)
    implementation(libs.androidx.compose.ui)
    implementation(libs.androidx.compose.material3)
    debugImplementation(libs.androidx.compose.ui.tooling)
}

Groovy DSL:

// build.gradle (modulo app)
plugins {
    id 'com.android.application'
    id 'org.jetbrains.kotlin.android'
    id 'org.jetbrains.kotlin.plugin.compose'
}

android {
    namespace 'com.exemplo.app'
    compileSdk 35

    defaultConfig {
        applicationId 'com.exemplo.app'
        minSdk 24
        targetSdk 35
        versionCode 1
        versionName '1.0.0'
    }

    buildTypes {
        release {
            minifyEnabled true
            proguardFiles getDefaultProguardFile('proguard-android-optimize.txt'), 'proguard-rules.pro'
        }
        debug {
            minifyEnabled false
            applicationIdSuffix '.debug'
        }
    }

    compileOptions {
        sourceCompatibility JavaVersion.VERSION_17
        targetCompatibility JavaVersion.VERSION_17
    }
}

dependencies {
    implementation libs.androidx.core.ktx
    implementation libs.androidx.compose.ui
    implementation libs.androidx.compose.material3
    debugImplementation libs.androidx.compose.ui.tooling
}

Autocompletar e suporte da IDE

A maior vantagem prática do Kotlin DSL e o suporte completo da IDE. No IntelliJ IDEA e Android Studio:

Kotlin DSL oferece:

  • Autocompletar completo para todas as propriedades e métodos do Gradle
  • Navegação ao código fonte de plugins e extensoes (Ctrl+Click)
  • verificação de erros em tempo real (sublinhado vermelho para erros)
  • Refatoração automatica (renomear, mover)
  • Documentação inline ao passar o mouse sobre propriedades

Groovy DSL oferece:

  • Autocompletar básico (menos confiavel)
  • Navegação limitada ao código fonte
  • verificação de erros minima (muitos erros só aparecem no build)
  • Refatoração limitada

Na prática, essa diferenca e enorme. Com Groovy, você frequentemente consulta documentação externa para saber quais propriedades estao disponiveis. Com Kotlin DSL, a IDE mostra tudo diretamente.

Segurança de tipos

Kotlin DSL verifica tipos em tempo de compilação do script:

// Kotlin DSL: erro detectado pela IDE
android {
    compileSdk = "35" // ERRO: esperado Int, recebido String
    minSdk = 24       // OK
}

// Groovy DSL: compila sem erro, falha em runtime
android {
    compileSdk = "35" // Nenhum erro no editor, falha no build
    minSdk = 24
}

Essa segurança previne erros comuns como atribuir tipos errados, usar nomes de propriedade inexistentes ou chamar métodos com parametros incorretos.

Performance de build

A performance de compilação dos scripts e frequentemente citada como desvantagem do Kotlin DSL:

CenarioKotlin DSLGroovy DSL
Primeiro build (cold)Mais lento (~20-30% mais)Mais rápido
Builds subsequentes (cache)EquivalenteEquivalente
Mudanca no scriptRe-compila scriptRe-interpreta script
Sync do projeto na IDEMais lento inicialmenteMais rápido

Na prática, a diferenca e perceptivel apenas no primeiro build ou apos alterar scripts de build. Para builds incrementais do código da aplicação (o cenário mais frequente), não há diferenca.

Version Catalogs

Ambos os DSLs suportam Version Catalogs (arquivo libs.versions.toml), que e a abordagem recomendada para gerenciar versões de dependências:

# gradle/libs.versions.toml
[versions]
kotlin = "2.1.0"
ktor = "3.0.0"
coroutines = "1.9.0"
kotest = "5.9.0"

[libraries]
ktor-server-core = { module = "io.ktor:ktor-server-core", version.ref = "ktor" }
ktor-server-netty = { module = "io.ktor:ktor-server-netty", version.ref = "ktor" }
coroutines-core = { module = "org.jetbrains.kotlinx:kotlinx-coroutines-core", version.ref = "coroutines" }
kotest-runner = { module = "io.kotest:kotest-runner-junit5", version.ref = "kotest" }

[plugins]
kotlin-jvm = { id = "org.jetbrains.kotlin.jvm", version.ref = "kotlin" }

// Kotlin DSL com version catalog
plugins {
    alias(libs.plugins.kotlin.jvm)
}

dependencies {
    implementation(libs.ktor.server.core)
    implementation(libs.coroutines.core)
    testImplementation(libs.kotest.runner)
}

Com version catalogs, o Kotlin DSL oferece autocompletar para libs. que mostra todas as dependências disponiveis. Groovy também suporta, mas sem o mesmo nível de integração IDE.

Convention Plugins

Para projetos multi-modulo, convention plugins permitem compartilhar configuração entre modulos. O Kotlin DSL brilha aqui:

// buildSrc/src/main/kotlin/kotlin-library-conventions.gradle.kts
plugins {
    id("org.jetbrains.kotlin.jvm")
}

group = "com.exemplo"

repositories {
    mavenCentral()
}

dependencies {
    testImplementation("io.kotest:kotest-runner-junit5:5.9.0")
}

tasks.test {
    useJUnitPlatform()
}

kotlin {
    jvmToolchain(17)
}

// modulo/build.gradle.kts
plugins {
    id("kotlin-library-conventions") // aplica toda a configuracao
}

dependencies {
    implementation("org.jetbrains.kotlinx:kotlinx-coroutines-core:1.9.0")
}

Migração de Groovy para Kotlin DSL

A migração pode ser feita arquivo por arquivo:

  1. Renomear settings.gradle para settings.gradle.kts e ajustar a sintaxe
  2. Migrar build.gradle do projeto raiz para build.gradle.kts
  3. Migrar cada modulo individualmente

Principais mudancas na sintaxe:

// Groovy -> Kotlin DSL
// Aspas simples -> aspas duplas
'texto' --> "texto"

// Atribuicao sem = -> com =
compileSdk 35 --> compileSdk = 35

// Strings sem parenteses -> com parenteses
implementation 'lib:1.0' --> implementation("lib:1.0")

// Property access -> metodo set
mainClass = 'Main' --> mainClass.set("Main")

// Boolean properties
minifyEnabled true --> isMinifyEnabled = true

Quando usar cada um

Escolha Kotlin DSL quando:

  • Você inicia um projeto novo
  • A equipe trabalha com Kotlin e valoriza segurança de tipos
  • O projeto e multi-modulo com configuração compartilhada
  • Você quer autocompletar e navegação confiavel na IDE
  • Você esta migrando gradualmente um projeto existente

Mantenha Groovy DSL quando:

  • O projeto legado funciona bem e não há tempo para migrar
  • A equipe esta mais confortavel com Groovy
  • Você usa plugins que tem documentação apenas em Groovy
  • A performance do primeiro build e crítica no CI

Veredito

Em 2026, o Kotlin DSL e a escolha padrão e recomendada para projetos Gradle com Kotlin. O suporte superior da IDE, segurança de tipos e a tendencia do ecossistema (novos templates do Google e JetBrains usam Kotlin DSL) tornam a migacao inevitavel para a maioria dos projetos. O Groovy DSL permanece funcional e suportado, mas seu uso em novos projetos e cada vez mais raro. Se você esta comecando, va direto para Kotlin DSL. Se tem um projeto Groovy existente, planeje a migração gradual quando houver oportunidade.