Gradle Kotlin DSL vs Groovy DSL: configuracao de build em 2026

O Gradle suporta dois DSLs para configuracao de build: Groovy (historico, arquivos .gradle) e Kotlin (moderno, arquivos .gradle.kts). Em 2026, o Kotlin DSL e a escolha padrao para novos projetos, mas muitos projetos legados ainda usam Groovy. Este artigo compara as duas opcoes em detalhes praticos.

Visao geral

CaracteristicaKotlin DSL (.gradle.kts)Groovy DSL (.gradle)
Extensao.gradle.kts.gradle
TipagemEstaticaDinamica
Autocompletar IDECompletoLimitado
Navegacao ao codigo fonteSimParcial
Documentacao inlineSim (KDoc)Limitada
RefatoracaoSuportadaLimitada
Performance de compilacaoMais lenta (primeiro build)Mais rapida
Cache de scriptsEficiente (apos primeiro build)Eficiente
Padrao novos projetosSim (desde Gradle 8+)Legado

Sintaxe comparada

Configuracao basica 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 diferencas visuais sao sutis: Kotlin usa parenteses e aspas duplas consistentemente, enquanto Groovy permite aspas simples e omissao de parenteses.

Configuracao 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 pratica 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 metodos do Gradle
  • Navegacao ao codigo fonte de plugins e extensoes (Ctrl+Click)
  • Verificacao de erros em tempo real (sublinhado vermelho para erros)
  • Refatoracao automatica (renomear, mover)
  • Documentacao inline ao passar o mouse sobre propriedades

Groovy DSL oferece:

  • Autocompletar basico (menos confiavel)
  • Navegacao limitada ao codigo fonte
  • Verificacao de erros minima (muitos erros so aparecem no build)
  • Refatoracao limitada

Na pratica, essa diferenca e enorme. Com Groovy, voce frequentemente consulta documentacao externa para saber quais propriedades estao disponiveis. Com Kotlin DSL, a IDE mostra tudo diretamente.

Seguranca de tipos

Kotlin DSL verifica tipos em tempo de compilacao 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 seguranca previne erros comuns como atribuir tipos errados, usar nomes de propriedade inexistentes ou chamar metodos com parametros incorretos.

Performance de build

A performance de compilacao dos scripts e frequentemente citada como desvantagem do Kotlin DSL:

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

Na pratica, a diferenca e perceptivel apenas no primeiro build ou apos alterar scripts de build. Para builds incrementais do codigo da aplicacao (o cenario mais frequente), nao ha diferenca.

Version Catalogs

Ambos os DSLs suportam Version Catalogs (arquivo libs.versions.toml), que e a abordagem recomendada para gerenciar versoes de dependencias:

# 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 dependencias disponiveis. Groovy tambem suporta, mas sem o mesmo nivel de integracao IDE.

Convention Plugins

Para projetos multi-modulo, convention plugins permitem compartilhar configuracao 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")
}

Migracao de Groovy para Kotlin DSL

A migracao 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:

  • Voce inicia um projeto novo
  • A equipe trabalha com Kotlin e valoriza seguranca de tipos
  • O projeto e multi-modulo com configuracao compartilhada
  • Voce quer autocompletar e navegacao confiavel na IDE
  • Voce esta migrando gradualmente um projeto existente

Mantenha Groovy DSL quando:

  • O projeto legado funciona bem e nao ha tempo para migrar
  • A equipe esta mais confortavel com Groovy
  • Voce usa plugins que tem documentacao apenas em Groovy
  • A performance do primeiro build e critica no CI

Veredito

Em 2026, o Kotlin DSL e a escolha padrao e recomendada para projetos Gradle com Kotlin. O suporte superior da IDE, seguranca 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 voce esta comecando, va direto para Kotlin DSL. Se tem um projeto Groovy existente, planeje a migracao gradual quando houver oportunidade.