Ambiente e primeiro programa

Ambiente e primeiro programa

Antes do primeiro prato, a cozinha precisa de fogão, panela, bancada e de alguém que leia a receita e separe os ingredientes. Programar em Kotlin pede a mesma preparação. Você instala um programa que sabe executar código (o JDK), uma bancada onde escreve e roda o código sem decorar comandos (o IntelliJ IDEA) e um organizador que sabe a ordem de montar o projeto (o Gradle). Para um “olá, mundo” parece exagero, mas cada peça aparece em projeto real, e entender o papel de cada uma evita a maior parte dos problemas de quem começa.

Esta aula monta esse ambiente do zero, cria um projeto pequeno e roda um programa de verdade. Os trechos de código e as saídas que aparecem aqui foram executados nesta máquina antes de entrar na nota.

o mapa da aula

Vamos responder quatro perguntas, nesta ordem. O que precisa estar instalado e por quê. Como criar um projeto do jeito que o mercado usa, pelo assistente do IntelliJ ou pelo Spring Initializr. Como é o primeiro programa, com variáveis, tipos e textos. E, por fim, quais erros quase todo iniciante encontra e o que as vagas costumam pedir junto com Kotlin, com a fonte de cada afirmação.

A história da linguagem fica na aula da fase 0. Aqui o foco é colocar a mão na massa.

1. o que precisa estar instalado

o JDK e a JVM

O Kotlin não roda direto no processador. O compilador traduz o seu código para bytecode, uma linguagem binária intermediária que também é usada pelo Java. Quem executa esse bytecode é a JVM (Java Virtual Machine), uma máquina virtual que roda em Windows, macOS e Linux. Por isso uma aplicação Kotlin roda na JVM e consegue usar qualquer biblioteca Java sem adaptação.

O JDK (Java Development Kit) é o pacote que reúne a JVM com as ferramentas de compilação. Para escrever e rodar Kotlin, você precisa do JDK. A JVM sozinha executa programas já compilados, mas não compila nada. O compilador do Kotlin roda dentro do JDK, e é por isso que a instalação precisa dele.

A figura abaixo mostra o caminho que o seu código percorre, de Main.kt até a saída no terminal. Ela também mostra o que acontece quando a compilação falha, e esse ramo volta na seção sobre erros.

Na figura, o retângulo do meio é o passo que o Gradle dispara quando você roda ./gradlew run. O compilador transforma o arquivo .kt em MainKt.class, que é bytecode. A JVM carrega essa classe, chama a função main e a saída segue para o terminal. A cor vermelha marca o ramo de falha: quando o código não compila, nenhum .class é gerado e a execução nem começa.

Qual versão escolher? Hoje, a escolha mais segura é o JDK 25. Ele é uma versão LTS (Long-Term Support, com suporte longo), lançada em 16 de setembro de 2025, com suporte premier até 30 de setembro de 2030, segundo a tabela da endoflife.date. O JDK 21, também LTS e lançado em 19 de setembro de 2023, segue como opção segura e aparece com frequência em empresas que ainda não migraram. A documentação do Spring Boot 4.1.2 exige no mínimo Java 17 e declara compatibilidade até a versão 27. Qualquer LTS recente atende, desde que o projeto inteiro use a mesma. Nesta máquina, os exemplos rodaram com o OpenJDK 25: java -version mostrou openjdk version "25" 2025-09-16.

o IntelliJ IDEA

O IntelliJ IDEA é a IDE da JetBrains, a empresa que criou o Kotlin. IDE quer dizer ambiente de desenvolvimento integrado: é um editor que também conhece a linguagem, sugere correções enquanto você digita, mostra os erros antes de você rodar e tem um botão de execução ao lado de cada função main. É a IDE que esta trilha adota como padrão. A edição Community é gratuita e cobre Kotlin e Gradle, que são o que esta trilha usa. Recursos de framework, como o suporte completo ao Spring, costumam ser da edição Ultimate. Não verifiquei nesta data a tabela de recursos por edição, então confirme na página da JetBrains antes de decidir.

Nesta máquina está instalada a versão 2025.2.4. Os menus mudam um pouco entre versões, então, se a sua for mais nova, os nomes das telas podem ser outros.

o Gradle

O Gradle organiza o projeto: baixa as bibliotecas, compila, roda os testes e empacota a aplicação. Você não precisa instalá-lo na máquina. Cada projeto traz um wrapper, o arquivo gradlew, que baixa a versão exata do Gradle definida no projeto e a executa. Assim, todo mundo do time usa o mesmo build, mesmo que cada um tenha uma versão diferente instalada, ou nenhuma.

A versão do wrapper fica em gradle/wrapper/gradle-wrapper.properties. Nesta aula ela é a 9.7.0. A versão atual do Gradle é a 9.8.2, mas a página de compatibilidade do Kotlin 2.4.21 lista a 9.7.0 como a mais alta totalmente suportada para o plugin dessa versão. Por isso a aula usa a 9.7.0. Para mudar depois, rode ./gradlew wrapper --gradle-version <versão>, e o próprio wrapper atualiza o arquivo.

resumo das versões

2. criar o projeto

Existem dois caminhos comuns. Para aprender a linguagem sem framework, use o assistente do IntelliJ. Para um serviço de backend, o caminho do mercado é o Spring Initializr, que gera um projeto Spring Boot já configurado.

pelo assistente do IntelliJ

Pelo guia oficial de primeiro app em Kotlin, o caminho é File, New, Project. Na lista da esquerda, escolha Kotlin. Dê um nome ao projeto, escolha Gradle como build system e Kotlin como linguagem do script de build. Essa opção gera o arquivo build.gradle.kts, que usa o Kotlin DSL. Na lista JDK, escolha o JDK 25. Marque Add sample code para que a IDE crie o Main.kt de exemplo, e clique em Create.

Não verifiquei esses cliques nesta máquina. O fluxo vem da lista de opções que o guia oficial descreve, e a tela da sua versão pode trazer nomes diferentes.

pelo Spring Initializr

Kotlin com Spring Boot é o que mais aparece em vagas de backend, e o Spring Initializr, em start.spring.io, é o gerador oficial do Spring. Na página, você escolhe Gradle com Kotlin DSL, a linguagem Kotlin, a versão do Spring Boot, Java 25 e as dependências, como Spring Web, e depois baixa o projeto em ZIP.

Não cliquei na página. Para verificar o resultado, baixei o ZIP pela mesma URL que o formulário usa, com estes parâmetros:

https://start.spring.io/starter.zip?type=gradle-project-kotlin&language=kotlin&bootVersion=4.1.2&javaVersion=25&groupId=com.exemplo&artifactId=demo&name=demo&packageName=com.exemplo.demo&dependencies=web

Esta é a estrutura principal do projeto gerado, sem os arquivos de ajuda e de Git:

demo/
├── build.gradle.kts
├── settings.gradle.kts
├── gradlew
├── gradle/wrapper/
└── src/
    ├── main/kotlin/com/exemplo/demo/DemoApplication.kt
    ├── main/resources/application.properties
    └── test/kotlin/com/exemplo/demo/DemoApplicationTests.kt

O build.gradle.kts desse projeto declara quatro plugins. kotlin("jvm") compila o Kotlin. kotlin("plugin.spring") abre as classes marcadas com anotações do Spring, porque o framework precisa poder estender algumas delas. org.springframework.boot empacota e roda a aplicação. io.spring.dependency-management garante que as versões das bibliotecas do Spring combinem entre si, sem você escrever cada número. Nesta data, o gerador traz o plugin Kotlin 2.3.21, e não a 2.4.21 desta aula. Isso não impede nada, mas a versão aparece no build e pode ser trocada.

Rodei ./gradlew test nesse projeto gerado, com JDK 25. O resultado foi BUILD SUCCESSFUL, e o teste DemoApplicationTests, que sobe o contexto do Spring, passou com 1 teste, 0 falhas e 0 erros. Esta aula não usa o Spring. Ele volta na fase 6.

o projeto desta aula

Para o primeiro programa, criei um projeto mínimo, sem Spring. Esta é a estrutura, com os arquivos que o Gradle gera quando roda:

ola-kotlin/
├── build.gradle.kts
├── settings.gradle.kts
├── gradlew
├── gradlew.bat
├── gradle/wrapper/
│   ├── gradle-wrapper.jar
│   └── gradle-wrapper.properties
├── src/
│   ├── main/kotlin/
│   │   ├── Main.kt
│   │   └── Saudacao.kt
│   └── test/kotlin/
│       └── SaudacaoTest.kt
├── build/        (gerado: classes, jars e relatórios)
└── .gradle/      (gerado: cache do Gradle)

Cada arquivo tem um papel. O settings.gradle.kts dá o nome do projeto e lista os módulos. Aqui ele tem uma linha, porque há um só módulo. Projetos com vários módulos ficam para a fase 6. O build.gradle.kts descreve o que o projeto usa e como construí-lo. Os arquivos gradlew e gradlew.bat são o wrapper para macOS e Linux e para Windows. Você sempre roda o wrapper do projeto, nunca um Gradle instalado globalmente, porque é ele que garante a versão. A pasta gradle/wrapper/ guarda o programa que o wrapper usa e o arquivo com a versão. Em src/main/kotlin ficam os arquivos que entram no programa final, e em src/test/kotlin ficam os testes, que não vão para o programa final. As pastas build/ e .gradle/ são geradas. Não as edite e, se o projeto for para o Git, ignore as duas. O wrapper, ao contrário, deve entrar no repositório.

O build.gradle.kts do projeto tem poucas linhas, e cada uma tem um motivo:

plugins {
    kotlin("jvm") version "2.4.21"
    application
}

repositories {
    mavenCentral()
}

dependencies {
    testImplementation(kotlin("test"))
}

kotlin {
    jvmToolchain(25)
}

application {
    mainClass.set("MainKt")
}

tasks.test {
    useJUnitPlatform()
}

O plugin kotlin("jvm") ensina o Gradle a compilar Kotlin. Na versão, a documentação do Kotlin pede um número literal nesse bloco, sem variável. O plugin application cria a tarefa run, que é a que você chama com ./gradlew run. repositories diz de onde baixar as bibliotecas, e o Maven Central é o repositório público padrão do ecossistema Java. testImplementation(kotlin("test")) traz as asserções usadas nos testes. jvmToolchain(25) manda o Gradle compilar com o JDK 25. Se esse JDK não existir na máquina, o build para com erro, e a seção 5 mostra essa mensagem. mainClass.set("MainKt") diz qual classe tem o main. O nome MainKt vem do arquivo Main.kt: o compilador acrescenta Kt ao nome de um arquivo que tem funções de topo. useJUnitPlatform() manda o Gradle usar o JUnit 5 para rodar os testes.

O settings.gradle.kts tem uma linha:

rootProject.name = "ola-kotlin"

3. o primeiro programa

O código abaixo tem tudo o que esta aula precisa: uma função main, variáveis, tipos básicos, textos com interpolação e comentários.

// Comentário de linha: o compilador ignora tudo depois das barras.

/* Comentário de bloco
   pode ocupar várias linhas. */

fun main() {
    val nome = "Ana"          // val: a referência não pode ser trocada depois
    var visitas = 0           // var: pode ser reatribuída
    visitas = visitas + 1

    val idade: Int = 30       // tipo declarado explicitamente
    val altura = 1.72         // inferido como Double
    val estudante = true      // inferido como Boolean
    val inicial = 'A'         // Char usa aspas simples

    println(saudacao(nome))
    println("Idade daqui a um ano: ${idade + 1}")
    println("Altura: $altura m, estudante: $estudante, inicial: $inicial")
    println("Visitas: $visitas")
}

A função que o main chama fica em outro arquivo, Saudacao.kt:

fun saudacao(nome: String): String = "Olá, $nome!"

a função main

Todo programa Kotlin que roda como aplicação começa numa função chamada main. Quando você executa o projeto, a JVM procura essa função e a chama. Em Kotlin, a função não precisa estar dentro de uma classe. Ela pode ser uma função de topo do arquivo, como main e saudacao nos exemplos. Isso faz diferença para quem vem de Java, onde todo código fica dentro de uma classe.

println escreve uma linha no terminal e pula para a seguinte. Os comentários começam com // e vão até o fim da linha, ou ficam entre /* e */ quando ocupam várias linhas. O compilador os ignora, e eles existem para quem lê o código.

Kotlin não exige ponto e vírgula no fim da linha. Quem vem de Java costuma escrever o ; por reflexo, e o código compila assim, mas o estilo da linguagem dispensa.

val e var

val cria uma referência que não pode ser trocada depois de criada. var cria uma referência que aceita nova atribuição. A linha visitas = visitas + 1 funciona porque visitas é var. Se você escrevesse nome = "Bia", o compilador recusaria, com a mesma mensagem mostrada na seção 5.

A convenção do Kotlin é preferir val e recorrer a var só quando a variável precisa mudar, como um contador. A razão é prática: quanto menos coisas mudam, menos lugares você precisa conferir para entender um valor. Há uma pegadinha. val impede trocar a referência, mas não torna o objeto imutável. Uma val lista = mutableListOf(1) ainda aceita lista.add(2). A imutabilidade do conteúdo é assunto da aula de coleções.

tipos básicos

Os cinco tipos que aparecem no programa são os mais usados no começo.

Int guarda números inteiros, como a idade. Double guarda números com casas decimais, como a altura. Boolean guarda apenas true ou false. String guarda texto e usa aspas duplas. Char guarda um único caractere e usa aspas simples, por isso 'A' é um Char e "A" é uma String. Os nomes dos tipos começam com letra maiúscula, e a linha val idade: Int = 30 mostra a forma explícita de declarar um tipo, com dois-pontos depois do nome.

inferência de tipos

Na linha val altura = 1.72, o tipo não foi escrito, e o compilador deduziu Double a partir do valor. Isso se chama inferência. Ela deixa o código mais limpo quando o valor deixa claro o tipo. Quando o tipo não é óbvio ou você quer que um número seja de um tipo específico, declare-o. A regra prática é esta: deixe a inferência trabalhar, mas declare quando o leitor precisar de uma pista.

string templates

Dentro de aspas, $nome é substituído pelo valor da variável. Se a conta for mais que um nome, como idade + 1, use chaves: ${idade + 1}. O resultado é Idade daqui a um ano: 31. Esse recurso, chamado de string template, evita a concatenação com + que você veria em muitas linguagens e torna a frase mais fácil de ler.

rodar pela IDE

No IntelliJ, ao lado da linha fun main() aparece um ícone verde de execução na margem do editor. Clique nele e escolha a opção Run para MainKt, como descreve o guia oficial. A saída aparece na janela Run. Não verifiquei esse clique nesta máquina.

rodar pelo terminal

No terminal, entre na pasta do projeto e rode o wrapper:

cd ola-kotlin
./gradlew run

Esta é a saída real, com as linhas de tarefas que não interessam para a leitura cortadas:

> Task :run
Olá, Ana!
Idade daqui a um ano: 31
Altura: 1.72 m, estudante: true, inicial: A
Visitas: 1

BUILD SUCCESSFUL in 38s

A primeira execução mostra Fetching distribution e baixa o Gradle 9.7.0 uma vez. As execuções seguintes reaproveitam o que ficou no cache, e os tempos mudam de uma máquina para outra. O comando ./gradlew run faz três coisas em sequência: compila o Kotlin, prepara a classe MainKt e a entrega para a JVM executar.

Você pode conferir a versão do bytecode gerado. O comando abaixo mostra a versão no arquivo .class:

javap -v build/classes/kotlin/main/MainKt.class | grep "major version"

Nesta máquina, a saída foi major version: 69. O número é 44 somado à versão do Java, então 69 corresponde ao Java 25. Com jvmToolchain(21), o número esperado é 65. O exercício 4 pede para conferir.

testes

O arquivo de teste fica em src/test/kotlin:

import kotlin.test.Test
import kotlin.test.assertEquals

class SaudacaoTest {
    @Test
    fun cumprimentaPeloNome() {
        assertEquals("Olá, Ana!", saudacao("Ana"))
    }
}

A anotação @Test marca um método como teste. assertEquals recebe o valor esperado e o valor produzido pelo código, e falha se forem diferentes. Esse é o teste automatizado mais simples que existe, e a fase 1 da trilha escreve testes assim antes de chegar ao Spring.

Rode os testes com:

./gradlew test

A saída real termina assim, com as tarefas intermediárias omitidas:

> Task :test

BUILD SUCCESSFUL in 12s

O resultado detalhado fica em build/test-results/test/. No arquivo TEST-SaudacaoTest.xml, a contagem foi tests="1" skipped="0" failures="0" errors="0".

4. o que as vagas costumam pedir junto com Kotlin

Não contei vagas. Tentei abrir os anúncios que a busca mostrou, e as páginas responderam com 404, 410 ou 403 nesta data, então não uso o conteúdo deles como dado. O que segue vem de relatórios e de pesquisas com metodologia publicada. Quando a fonte não diz algo, eu digo.

o que os relatórios mostram

O relatório State of Kotlin 2026, da JetBrains, tem os dados de backend mais úteis para quem está começando. Segundo o relatório, cerca de metade dos desenvolvedores de Kotlin trabalha em projetos de backend na JVM (53%, com base na pesquisa de 2025 que a própria JetBrains conduziu). Desses, 78% dizem usar Kotlin em produção. Sobre frameworks, cerca de 61% dos desenvolvedores de backend em Kotlin trabalham com Spring ou Spring Boot, e o Ktor aparece com 51%. O relatório também diz que as vagas de backend com Kotlin costumam ser anunciadas como “Java/Kotlin”, e que o primeiro projeto Kotlin mais comum numa equipe é um serviço no framework que ela já conhece, com Spring Boot como exemplo típico. Esses números vêm do próprio relatório, e a pesquisa mede quem usa a linguagem, não quem contrata.

A pesquisa Stack Overflow Developer Survey 2025 mede uso geral de tecnologias. A tabela abaixo traz os números da seção de linguagens e de ferramentas, com todos os respondentes e com desenvolvedores profissionais:

Os números mostram duas coisas. Kotlin tem uma fatia menor que Java entre os desenvolvedores em geral. E o relatório da JetBrains diz que a maioria dos desenvolvedores de backend em Kotlin também escreve Java, o que explica por que as vagas costumam pedir as duas linguagens. A pesquisa não mede vagas, então ela não diz qual peso cada item tem no anúncio.

o que eu observaria nas vagas

Sem contagem de anúncios, a combinação que mais se repete nos relatórios e nos resumos de vagas que a busca mostrou é Java, Spring Boot, Gradle ou Maven, SQL, Docker, testes automatizados e, às vezes, uma nuvem pública. Trate isso como impressão de quem leu relatórios, não como estatística. Git não aparece com número nas fontes que consultei, mas em qualquer time ele é pré-requisito de trabalho em equipe.

A tabela abaixo liga cada item à aula da trilha. Quando a aula ainda não está escrita, a tabela diz isso.

5. erros comuns e boas práticas

Quase todo iniciante bate nos mesmos problemas. Os dois primeiros abaixo eu reproduzi nesta máquina, e a mensagem que você vê é a real.

JDK errado no projeto

Se o build.gradle.kts pede um JDK que não está instalado, o Gradle para com esta mensagem. Eu troquei jvmToolchain(25) por jvmToolchain(17) numa cópia, sem JDK 17 na máquina:

* What went wrong:
Could not determine the dependencies of task ':run'.
> Could not resolve all dependencies for configuration ':runtimeClasspath'.
   > Failed to calculate the value of task ':compileJava' property 'javaCompiler'.
      > Cannot find a Java installation on your machine (Mac OS X 27.0.1 aarch64) matching: {languageVersion=17, vendor=any vendor, implementation=vendor-specific, nativeImageCapable=false}.

A saída completa tinha mais linhas de ajuda, e o trecho acima traz a parte que importa: não há Java 17 instalado. A correção é instalar o JDK pedido ou trocar o número por uma versão que já existe. Use o mesmo JDK na IDE e no terminal, para não depender de qual estiver ativo em cada um.

confundir val com var

É um tropeço comum para quem vem de Java, onde a variável pode ser reatribuída a menos que você escreva final. Eu criei um arquivo com val x = 1 e depois x = 2, rodei ./gradlew compileKotlin e recebi:

e: file:///.../src/main/kotlin/Erro.kt:3:5 'val' cannot be reassigned.

O caminho foi cortado. A mensagem aponta a linha e a coluna exatas, e a correção é trocar val por var, se a variável precisa mudar, ou criar uma nova variável com outro nome. Depois da correção, o arquivo Erro.kt foi removido, para o projeto ficar limpo.

achar que precisa de ponto e vírgula

Kotlin dispensa ; no fim da linha, e o código desta aula não tem nenhum. Escrever ; não causa erro, o compilador aceita. É só um hábito de Java que vale trocar cedo, porque o código fica com cara de Java.

esquecer de recarregar o Gradle

Quando você edita o build.gradle.kts pela IDE, ela precisa reler o arquivo para resolver as bibliotecas novas. Se a dependência não aparece ou o plugin não é reconhecido, a IDE costuma sugerir recarregar o projeto Gradle, e é nessa sugestão que está a solução. Não verifiquei a tela exata nesta máquina. Como alternativa, o terminal sempre lê o arquivo na hora de rodar, então ./gradlew run mostra a verdade quando a IDE está confusa.

boas práticas que valem desde o primeiro dia

Use val por padrão e var só quando a mudança for necessária. Use sempre o ./gradlew do projeto, nunca um Gradle instalado globalmente, para o build ser o mesmo para todo o time. Mantenha uma versão de JDK por projeto e escreva o número no jvmToolchain, em vez de depender do que está instalado por acaso. E versione o wrapper, o build.gradle.kts e o settings.gradle.kts, deixando build/ e .gradle/ de fora.

6. exercícios

Faça estes exercícios no projeto ola-kotlin, sem pular a parte de ler a saída.

1. Crie uma variável val cidade = "Recife" em Main.kt e imprima Você mora em $cidade. Rode com ./gradlew run e confira a linha na saída.
2. Escreva em Saudacao.kt a função fun dobro(x: Int): Int = x * 2, adicione um teste em SaudacaoTest.kt que verifica dobro(4) contra 8, e rode ./gradlew test. Depois, troque o valor esperado por 9 e leia a mensagem de falha.
3. Reproduza o erro de val da seção 5 num arquivo temporário, leia a linha e a coluna que o compilador mostra e remova o arquivo.
4. Troque jvmToolchain(25) por jvmToolchain(21), rode ./gradlew run e depois o comando javap da seção 3. Anote a versão do bytecode que aparece e explique a diferença com 69.

Respostas:

1. A linha impressa é Você mora em Recife. Como cidade é val, o valor não pode ser trocado depois de criado.
2. Com dobro(4) igual a 8, o teste passa. Com 9 no lugar de 8, a falha mostra o valor esperado, 9, e o obtido, 8.
3. O compilador aponta a linha e a coluna da atribuição x = 2, como na seção 5.
4. Com jvmToolchain(21), o major version esperado é 65, porque 44 mais 21 dá 65. O 69 da seção 3 vem do JDK 25.

7. glossário

• IDE: ambiente de desenvolvimento integrado, um editor que também entende a linguagem, mostra erros e roda o programa.
• JDK: Java Development Kit, o pacote com a JVM e as ferramentas de compilação. Você precisa dele para compilar Kotlin.
• JVM: Java Virtual Machine, a máquina virtual que executa bytecode em qualquer sistema operacional.
• Bytecode: código intermediário gerado pelo compilador, que a JVM executa. O arquivo MainKt.class é um exemplo.
• LTS: Long-Term Support, uma versão que recebe correções por um período longo. JDK 21 e 25 são LTS.
• Gradle: ferramenta de build que baixa bibliotecas, compila, testa e empacota o projeto.
• Wrapper: o script gradlew e os arquivos em gradle/wrapper/, que fixam a versão do Gradle usada pelo projeto.
• Kotlin DSL: a forma de escrever o build em Kotlin, com arquivos .gradle.kts, em vez de Groovy.
• Função de topo: função declarada fora de qualquer classe, no nível do arquivo.
• val: variável cuja referência não pode ser reatribuída. Não torna o objeto imutável.
• var: variável que aceita nova atribuição.
• Inferência de tipos: o compilador deduz o tipo a partir do valor, como Double em val altura = 1.72.
• String template: texto com $variavel ou ${expressao} dentro das aspas, que é substituído pelo valor.
• Interpolação: outro nome comum para o string template.

Fontes

Consultadas em 04/11/2026.

• Kotlin, página de releases, com a versão 2.4.21 como estável: https://kotlinlang.org/docs/releases.html. A página indica outubro de 2026 como data do lançamento, mas o rodapé traz outra data, então não cito o dia.
• Kotlin, configuração de projeto Gradle, com o bloco kotlin("jvm"), jvmToolchain e a faixa de Gradle suportada para as versões 2.4.20 e 2.4.21 (máximo 9.7.0): https://kotlinlang.org/docs/gradle-configure-project.html
• Kotlin, guia de primeiro app no IntelliJ, com as opções do assistente de novo projeto: https://kotlinlang.org/docs/jvm-get-started.html
• Kotlin, guia de compatibilidade 2.4, consultado para JDK e Gradle. A página não menciona JDK nem versões de Gradle: https://kotlinlang.org/docs/compatibility-guide-24.html
• Spring Boot, requisitos do sistema, com Java 17 como mínimo, compatibilidade até Java 27 e Gradle 8.14 ou superior: https://docs.spring.io/spring-boot/system-requirements.html
• Maven Central, metadados do spring-boot-dependencies. A versão 4.1.2 aparece na lista, e o campo release aponta para o candidato 4.2.0-RC1: https://repo1.maven.org/maven2/org/springframework/boot/spring-boot-dependencies/maven-metadata.xml
• Gradle, versão atual publicada no endpoint oficial de versões, que retornou 9.8.2 com current true: https://services.gradle.org/versions/current
• endoflife.date, tabela do Oracle JDK com as datas de LTS, premier e extended support para Java 21 e 25: https://endoflife.date/oracle-jdk
• Spring Initializr, URL de geração usada para baixar o projeto de verificação: https://start.spring.io
• JetBrains, State of Kotlin 2026, PDF, com os dados de backend, Spring e Ktor que a seção 4 cita: https://kotlinlang.org/assets/state-of-kotlin-2026.pdf. Os percentuais são da pesquisa de 2025 que o relatório apresenta.
• Stack Overflow, Developer Survey 2025, seção de tecnologias, com os percentuais da tabela da seção 4: https://survey.stackoverflow.co/2025/technology/

Os exemplos foram executados em macOS com Apple Silicon. O Gradle usado foi o 9.7.0 pelo wrapper, e o JDK, o OpenJDK 25. O projeto Spring verificado usou o wrapper gerado pelo Initializr (Gradle 9.8.2, Kotlin 2.3.21). Não verifiquei nesta máquina os cliques do assistente do IntelliJ nem a tela do Spring Initializr.

Relacionados

• Trilha de Kotlin
• Nova ordem da trilha de Kotlin
• Curriculo de um Desenvolvedor Kotlin
• Null safety e tipos nuláveis
• Gradle Kotlin DSL e multi-módulo
• Testes com Kotest, MockK e Testcontainers
• Git
• Docker