Pular para o conteúdo

Neste texto

  1. História do Kotlin: por que a linguagem nasceu e qual problema ela resolve
  2. 1. o cenário: a JVM, o Java e as dores conhecidas
  3. 2. a JetBrains e o problema dentro de casa
  4. 3. objetivos de projeto
  5. 4. a linha do tempo
  6. 5. o que a linguagem cobre hoje e o que ela ainda não resolve
  7. 6. amostra de código: a mesma classe em Java e Kotlin
  8. erros comuns e boas práticas
  9. exercícios
  10. glossário
  11. fontes
  12. relacionados

Trilha de Kotlin · parte 1 de 59

História do Kotlin: por que a linguagem nasceu e qual problema ela resolve

Como a JetBrains criou o Kotlin para aliviar dores do Java, quais objetivos guiaram o projeto e onde a linguagem roda hoje, com datas conferidas.

iniciantePublicada em · 24 min de leitura

Tamanho da fonte:
Largura da coluna:
Tom:
Espaço entre linhas:
Fonte:

História do Kotlin: por que a linguagem nasceu e qual problema ela resolve

Imagine uma fabricante de furadeiras que passa o dia inteiro reclamando da furadeira que ela mesma usa na oficina. Um dia ela decide fazer a sua própria, mas com o cuidado de aceitar as brocas que já existem no estoque, para não jogar fora o que tem na prateleira. Guardadas as proporções, foi isso que a JetBrains fez. A empresa vende ferramentas para programadores, como o IntelliJ IDEA, e uma parte grande dessas ferramentas era escrita em Java. O Kotlin nasceu desse atrito do dia a dia. A pergunta desta aula é simples: que problema concreto justificou inventar uma linguagem nova em vez de aguentar a antiga?

Não vamos aprender sintaxe aqui. A ideia é entender o contexto antes de qualquer linha de código, porque as escolhas de design do Kotlin só fazem sentido quando você conhece as dores que elas tentam aliviar.

Antes de seguir, três termos. A JVM é a máquina virtual do Java, um programa que executa outros programas compilados para um formato intermediário chamado bytecode. Java é a linguagem que ocupou esse lugar por mais tempo, e o Kotlin compila para o mesmo bytecode. IDE, sigla de ambiente de desenvolvimento integrado, é o programa onde você escreve, executa e depura código.

A aula segue esta ordem. Primeiro, o cenário da JVM e do Java, com as dores que incomodavam. Depois, a JetBrains e o problema que existia dentro da própria empresa. Em seguida vêm os objetivos declarados do projeto, a linha do tempo até hoje, o que a linguagem cobre atualmente e quem decide os rumos dela. A aula termina com uma amostra pequena de concisão, comparando uma classe escrita em Java com a mesma ideia em Kotlin.

1. o cenário: a JVM, o Java e as dores conhecidas

O Java foi projetado por James Gosling na Sun Microsystems. Segundo a Wikipedia, o projeto começou em junho de 1991 e a primeira versão pública, a Java 1.0, saiu em 1996. Com o tempo, muitos sistemas de empresas passaram a ser escritos em Java e a rodar na JVM. Quando isso acontece, trocar a linguagem de um sistema deixa de ser uma decisão técnica e vira um projeto de anos, com equipe, orçamento e risco de parar a operação.

O que incomodava nesse mundo? Duas dores aparecem sempre. A primeira é a verbosidade. Chamamos de boilerplate o código que se repete em todo lugar sem trazer nenhuma regra de negócio: construtor, getters, equals, hashCode e toString escritos à mão para cada classe que só carrega dados. Você verá um exemplo concreto na seção 6. A segunda dor é o null. Uma referência em Java pode apontar para o nada sem que o tipo avise, e a consequência aparece em tempo de execução como NullPointerException. Tony Hoare, que incluiu referências nulas numa linguagem em 1965, chamou isso de seu “erro de um bilhão de dólares” numa palestra de 2009, segundo a Wikipedia.

Por que não bastava usar outra linguagem que já rodava na JVM? Em julho de 2011, a InfoWorld ouviu Dmitry Jemerov, da JetBrains, que respondeu: “We’ve looked at all of the existing JVM languages, and none of them meet our needs.” (tradução livre: analisamos todas as linguagens existentes da JVM, e nenhuma atende às nossas necessidades). Sobre o Scala, ele disse: “Scala has the right features, but its most obvious deficiency is very slow compilation” (tradução livre: o Scala tem os recursos certos, mas sua deficiência mais óbvia é a compilação muito lenta). O Scala começou a ser projetado em 2001 no EPFL, sob a liderança de Martin Odersky, e foi lançado publicamente em 2004. É uma linguagem poderosa, mas um projeto grande espera muito para compilar, e um time que itera o dia inteiro sente isso.

Groovy costuma aparecer nessa conversa também. Ela surgiu em 2003. A fonte que consultei não diz por que a JetBrains a descartou, então esta aula não atribui a Groovy nenhum motivo específico.

Java, Scala e Groovy antes do Kotlin: Java é compatível, Scala trava pela compilação lenta, e o requisito de compatibilidade aponta para o Kotlin.
figura 1 · Linguagens da JVM antes do Kotlin

A figura resume o cenário. Java tem a compatibilidade e a dor de sempre. Scala tem os recursos, mas a compilação lenta aparece como bloqueio. Groovy fica ao lado, sem seta, porque não encontrei uma justificativa documentada para ela. O requisito que liga tudo é funcionar com o código Java que já existe, e esse requisito puxa o Kotlin para o lado do Java e não para o do Scala.

2. a JetBrains e o problema dentro de casa

A JetBrains é uma empresa de ferramentas, com sede na República Tcheca. Segundo a Wikipedia, foi fundada em 2000 em Praga e desenvolve IDEs como o IntelliJ IDEA, o PyCharm e o WebStorm. Uma empresa assim tem uma relação curiosa com linguagens de programação, porque ela mesma precisa escrever um código enorme em alguma delas.

O prefácio do livro Kotlin in Action (Manning), escrito em nome da própria JetBrains, descreve o problema interno com franqueza. As IDEs construídas sobre a plataforma IntelliJ eram desenvolvidas em Java, enquanto outras equipes da empresa trabalhavam com C#, e o texto admite que a equipe tinha certa inveja disso. A frase sobre a manutenção é direta: “We don’t know any other way to develop a multimillion-line codebase over many years without going crazy” (tradução livre: não conhecemos outra forma de desenvolver, por muitos anos, uma base de código de milhões de linhas sem enlouquecer). O mesmo prefácio diz que a compatibilidade total com o código Java existente era um requisito, e não um detalhe.

Essa combinação explica o desenho do projeto. A JetBrains não podia reescrever uma base enorme de uma vez. Precisava de uma linguagem que convivesse com o Java, permitisse migração gradual e deixasse os programadores mais produtivos no dia a dia.

E quem tocou o projeto? O anúncio de 19 de julho de 2011, publicado no blog oficial da JetBrains, é assinado por Dmitry Jemerov e foi feito durante a JVM Language Summit. Nele a empresa diz que trabalhava no projeto havia quase um ano e que pretendia uma linguagem “productive enough for today’s environment and at the same time simple enough for every programmer to learn” (tradução livre: produtiva o bastante para o ambiente de hoje e, ao mesmo tempo, simples o bastante para qualquer programador aprender). Andrey Breslav é o outro nome central. A Wikipedia o descreve como ex-líder de design da linguagem, e o FAQ oficial atual indica Michail Zarečenskij como lead language designer. Não consegui confirmar em fonte primária a linha de sucessão entre os dois, então esta aula não a detalha.

O nome vem da ilha de Kotlin, uma ilha pequena no golfo da Finlândia, a cerca de 32 km a oeste de São Petersburgo, segundo a Wikipedia. Uma fonte secundária atribui a escolha a Breslav e diz que a equipe seguiu o exemplo do Java, cujo nome também vem de uma ilha. Não encontrei essa declaração numa fonte primária, então trate a explicação do nome como provável, e não como confirmada.

3. objetivos de projeto

Um projeto de linguagem sem objetivos claros vira uma lista de desejos. Os objetivos abaixo vêm de fontes oficiais, e onde a fonte não confirma algo, a aula diz isso.

A interoperabilidade é o objetivo mais concreto. A documentação oficial diz que o Kotlin é “100% interoperable” com Java, e que dá para chamar código Kotlin a partir do Java e o contrário. Na prática, isso permite trocar um arquivo de cada vez, sem reescrever o sistema inteiro. O IDE também traz um conversor automático de Java para Kotlin.

O pragmatismo aparece na página de princípios de evolução da linguagem, que a descreve como “a pragmatic tool for programmers” (tradução livre: uma ferramenta pragmática para programadores). Essa escolha tem consequências práticas. A linguagem evolui com cuidado para não quebrar código existente, e mudanças incompatíveis passam por um comitê antes de entrar em componentes estáveis. A seção 5 volta a isso.

A segurança contra null é o objetivo que mais interessa a quem já sofreu com NullPointerException. O FAQ oficial diz que o suporte a tipos não nuláveis torna as aplicações “less prone to NPE’s”, ou seja, menos sujeitas a exceções de ponteiro nulo. A aula sobre null safety mostra como isso funciona na prática.

A concisão aparece no FAQ com uma estimativa cautelosa: “Rough estimates indicate approximately a 40% cut in the number of lines of code” (tradução livre: estimativas grosseiras apontam um corte de cerca de 40% no número de linhas). Trate o número como ordem de grandeza. Ele depende do código e não foi medido num experimento controlado.

As ferramentas de primeira classe eram o objetivo que a JetBrains tinha de sobra. O anúncio de 2011 diz que a empresa construía suporte de IDE de primeira classe “in parallel with the language itself” (tradução livre: em paralelo com a própria linguagem).

Por último, a compilação rápida. A crítica de Jemerov ao Scala mostra que a velocidade era uma preocupação real. Não encontrei, porém, uma declaração oficial da JetBrains que liste a compilação rápida como objetivo formal da linguagem. Uma fonte secundária cita uma intenção da empresa num fórum próprio. Trate essa informação como intenção reportada, e não como requisito documentado.

4. a linha do tempo

A figura mostra os marcos em ordem. O texto abaixo explica os que pedem contexto, porque algumas datas têm mais de uma história.

Linha do tempo vertical do Kotlin, de 2010 a 2026: início na JetBrains, anúncio de 2011, Kotlin 1.0, suporte no Android, coroutines estáveis e Kotlin 2.0.
figura 2 · Linha do tempo do Kotlin, de 2010 a 2026

O FAQ oficial diz que o projeto começou em 2010 e que a versão 1.0 saiu em fevereiro de 2016. A Wikipedia cita o primeiro commit no repositório em 8 de novembro de 2010, mas não consegui confirmar essa data numa fonte primária. O anúncio público veio em 19 de julho de 2011, e o código foi aberto em fevereiro de 2012, sob a licença Apache 2.0, segundo a Wikipedia. O anúncio de 2011 já falava nessa licença como plano.

O salto para o mundo Android começou em 17 de maio de 2017, quando o time do Android escreveu no blog oficial que estava “officially adding support for the Kotlin programming language” (tradução livre: adicionando oficialmente suporte à linguagem Kotlin). O post não menciona o Google I/O, e a associação com esse evento vem da Wikipedia. Mais tarde, o Spring Framework 5.0, lançado em 28 de setembro de 2017, trouxe integração com Kotlin, segundo o post oficial da versão. Hoje a documentação do Spring descreve o Kotlin como suporte de primeira classe.

A Google diz que cofundou a Kotlin Foundation, na página Kotlin-first do Android, e a fundação é uma organização sem fins lucrativos criada para cuidar da linguagem junto com a JetBrains. As fontes que consultei divergem sobre o ano. Uma situa o anúncio em 2017, e uma fonte secundária fala do KotlinConf de 2018 como o momento do anúncio formal. Não consegui confirmar a data oficial.

Em 29 de outubro de 2018, o Kotlin 1.3 tornou as coroutines estáveis. A nota de lançamento diz que, a partir dessa versão, “the language support and the API are fully stable” (tradução livre: o suporte da linguagem e a API estão totalmente estáveis). A biblioteca kotlinx-coroutines, segundo a página de estabilidade, também está estável desde a 1.3.0.

No Google I/O de 2019, o Google anunciou que o desenvolvimento Android passaria a ser “increasingly Kotlin-first” (tradução livre: cada vez mais com o Kotlin em primeiro lugar), e a empresa afirmou em dezembro de 2019 que manteve esse compromisso.

Em 21 de maio de 2024, o Kotlin 2.0 trouxe o compilador K2 como estável e padrão para JVM, Native, Wasm e JS, segundo a documentação oficial. Essa mudança trata do compilador, e não de uma linguagem nova: o código existente continua valendo, a menos que alguma regra específica tenha mudado.

O Kotlin Multiplatform aparece como estável desde a versão 1.9.20 na página de estabilidade. A página não informa a data dessa versão, então a aula não a inventa.

Por fim, a página de releases lista a versão 2.4.21 como a estável atual, com data de 8 de outubro de 2026. Esse número foi lido na consulta de 4 de novembro de 2026. O rodapé da mesma página traz outra data, de 6 de outubro, então a data de 8 de outubro é a que a página indica, e não uma data que confirmei em outra fonte.

5. o que a linguagem cobre hoje e o que ela ainda não resolve

A linguagem hoje tem quatro frentes principais, e elas não estão no mesmo estágio. A figura mostra cada alvo com o selo de status que a documentação oficial atribui.

Kotlin ligado a JVM, Android, JS, Wasm, Native, interop com C e Objective-C e Multiplatform, com selo de estável ou beta em cada alvo.
figura 3 · Onde o Kotlin roda hoje e com que status

O Kotlin no servidor roda na JVM, e é aí que entra o Spring. Kotlin/JVM está estável desde a versão 1.0.0, e o Spring oferece suporte de primeira classe a ele. A trilha de Kotlin deste vault usa Spring Boot, então essa frente é a que mais aparece nas próximas aulas.

No Android, a Google diz que o Kotlin é suportado como linguagem de primeira classe, e que em projetos novos criados no Android Studio ele é a escolha padrão. A mesma página do FAQ responde a uma dúvida comum com uma frase curta: “You don’t have to pick! You can use both.” (tradução livre: você não precisa escolher, pode usar as duas). O Kotlin-first não remove o suporte ao Java, e isso é importante para quem tem um app antigo.

Nos alvos de multiplataforma, o runtime do Kotlin/Native e o Kotlin Multiplatform estão estáveis desde 1.9.20. O WebAssembly ainda é beta desde a versão 2.2.20, e a interoperabilidade com C e Objective-C está em beta desde a versão 1.3.0. Quem for usar esses alvos em produção precisa aceitar que parte do caminho ainda muda.

Os limites da linguagem são os trade-offs que não somem com a sintaxe. Kotlin roda na JVM e herda os custos dela, como tempo de partida, consumo de memória e coleta de lixo. O FAQ do Android diz que Kotlin “doesn’t have a direct performance impact” (tradução livre: não tem impacto direto de desempenho), mas lembra que copiar coleções repetidamente pode pesar no GC. A linguagem não elimina essa conta, e a fase 3 da trilha trata dela. Além disso, a compatibilidade com Java faz com que alguns hábitos do Java continuem aparecendo no código Kotlin, e nem sempre eles são o jeito idiomático de escrever. Por fim, as coroutines são poderosas, mas exigem entender cancelamento e escopo, como a fase 4 mostrará.

quem mantém a linguagem

A figura mostra quem cria, governa e adota o Kotlin. Ela parece burocrática, mas explica por que uma mudança incompatível não entra de uma hora para outra.

JetBrains cria o Kotlin, a Google diz ser cofundadora da fundação, que designa o comitê de linguagem, e Android e Spring adotam a linguagem.
figura 4 · Quem cria, governa e adota o Kotlin

A página de princípios diz que a JetBrains é a criadora original do Kotlin e segue dirigindo o progresso junto da comunidade e da Kotlin Foundation. As mudanças incompatíveis em componentes totalmente estáveis precisam ser aprovadas por um comitê de linguagem, que a página indica como designado pela fundação. Na data da consulta, o comitê era formado por Jeffrey van Gogh, Werner Dietl e Michail Zarečenskij. A Google afirma, na página Kotlin-first do Android, que cofundou a fundação, e também aparece como adotante. A própria fundação lista JetBrains e Google como membros fundadores no seu FAQ. O FAQ acrescenta que há mais de 250 contribuidores externos no GitHub, o que mostra que o projeto não depende só da empresa criadora.

6. amostra de código: a mesma classe em Java e Kotlin

Esta é a única amostra de código da aula, e ela serve para ver o volume de texto que cada versão exige para representar a mesma ideia: uma classe com dois campos, igualdade por valor e uma representação em texto. Cada pedaço será explicado nas próximas aulas, então não se preocupe em entender tudo agora.

A versão Java foi escrita no estilo antigo, sem record, e compilada com --release 8. A classe fica no arquivo Usuario.java:

import java.util.Objects;

public class Usuario {
    private final String nome;
    private final String email;

    public Usuario(String nome, String email) {
        this.nome = nome;
        this.email = email;
    }

    public String getNome() { return nome; }

    public String getEmail() { return email; }

    @Override
    public boolean equals(Object o) {
        if (this == o) return true;
        if (o == null || getClass() != o.getClass()) return false;
        Usuario outro = (Usuario) o;
        return Objects.equals(nome, outro.nome) && Objects.equals(email, outro.email);
    }

    @Override
    public int hashCode() {
        return Objects.hash(nome, email);
    }

    @Override
    public String toString() {
        return "Usuario{nome='" + nome + "', email='" + email + "'}";
    }
}

O programa de demonstração fica em Demo.java:

public class Demo {
    public static void main(String[] args) {
        Usuario a = new Usuario("Ana", "ana@exemplo.com");
        Usuario b = new Usuario("Ana", "ana@exemplo.com");
        System.out.println(a.equals(b));
        System.out.println(a);
    }
}

A versão Kotlin, no arquivo Usuario.kt, tem a classe em uma linha e uma demonstração equivalente:

data class Usuario(val nome: String, val email: String)

fun main() {
    val a = Usuario("Ana", "ana@exemplo.com")
    val b = Usuario("Ana", "ana@exemplo.com")
    println(a == b)
    println(a)
}

Os comandos usados foram javac -Xlint:-options --release 8 Usuario.java Demo.java seguido de java -cp . Demo, e kotlinc Usuario.kt -include-runtime -d usuario.jar seguido de java -jar usuario.jar. O Kotlin foi compilado com o kotlinc 2.1.21, que vem com o plugin do IntelliJ IDEA instalado na máquina de teste. A versão 2.4.21, atual nesta data, não foi testada. A saída real da execução foi esta:

true
Usuario{nome='Ana', email='ana@exemplo.com'}
true
Usuario(nome=Ana, email=ana@exemplo.com)

As duas primeiras linhas vêm do Java e as duas últimas do Kotlin. A classe Java tem 33 linhas, incluindo imports, e a Kotlin tem uma linha para a própria classe. Quando você declara propriedades no construtor, o compilador Kotlin gera equals e hashCode a partir delas, além de toString, copy e as funções componentN, conforme a documentação de data classes. A diferença de formato na última linha também ensina algo: na versão Java eu escrevi o texto do toString à mão, e a versão Kotlin usa o formato que o compilador gera. Quando a saída de um código gerado for importante para você, confira o formato, e não presuma.

erros comuns e boas práticas

Equívocos sobre a história do Kotlin são comuns, e alguns aparecem até em conversas de corredor. Vale desmontar os mais frequentes.

kotlin substitui o java

Essa é a confusão mais cara. O Kotlin não surgiu para acabar com o Java. Surgiu para conviver com ele, e a própria documentação diz que a interoperabilidade é total. O Android é o exemplo mais visível: a Google adotou o Kotlin como prioridade, mas continua dando suporte à API em Java e afirma que você pode usar as duas linguagens no mesmo projeto. Quem planeja uma troca total de linguagem costuma perder tempo com uma migração que não precisa acontecer. O caminho realista é migrar arquivo por arquivo, medindo o resultado em cada etapa.

kotlin é só para android

O Android foi a alavanca de adoção mais visível, mas existem outros destinos. A JVM e o Spring cobrem o servidor, e o Kotlin Multiplatform leva código compartilhado a outras plataformas. Limitar a linguagem ao celular faz quem trabalha com backend pular a parte da JVM, que é justamente a que mais pesa no dia a dia de um serviço.

kotlin é mais rápido que java

Essa frase mistura dois assuntos. A velocidade de compilação é uma preocupação de projeto, e a crítica de Jemerov ao Scala mostra isso. Já a velocidade de execução depende do bytecode gerado e da própria JVM, e o FAQ do Android diz explicitamente que a linguagem não tem impacto direto de desempenho. Qualquer comparação de velocidade precisa de medição no seu código, não de uma regra geral.

kotlin 2.0 é outra linguagem

O Kotlin 2.0 trouxe o compilador K2 como padrão. Isso mudou muito como o código é analisado e compilado, mas a linguagem continua compatível com o código que já existia, salvo exceções anunciadas com antecedência. Esse é justamente o motivo de existir uma política de mudanças incompatíveis com comitê. Quem migra uma base para o Kotlin 2.x deve olhar a documentação de mudanças, e não assumir que nada mudou nem que tudo mudou.

a jetbrains criou o kotlin para vender ides

A JetBrains tem interesse comercial, e isso é natural para uma empresa de ferramentas. Uma fonte secundária chega a dizer que a empresa esperava que o Kotlin ajudasse a vender o IntelliJ IDEA, mas a fonte primária que consultei fala em produtividade, interoperabilidade e ferramentas de primeira classe. Tratar o interesse comercial como única explicação deixa de lado o problema técnico real, que era a base de código Java da própria empresa.

exercícios

O primeiro exercício é ler o anúncio de 2011 no blog da JetBrains e listar três objetivos declarados pelo time. Depois compare essa lista com a seção 3 e veja o que mudou e o que continua igual.

Resposta esperada: o anúncio, publicado em 19 de julho de 2011, declara três objetivos. A linguagem deve ser produtiva o bastante para o ambiente de hoje, simples o bastante para qualquer programador aprender, e a JetBrains estava construindo suporte de IDE de primeira classe em paralelo com a linguagem. O texto também anuncia um plano: liberar o compilador e as ferramentas como código aberto sob a licença Apache 2 quando a linguagem chegar à fase beta, prevista para o fim de 2011. Na comparação com a seção 3, só o item de ferramentas de primeira classe aparece no anúncio. Interoperabilidade, segurança contra null, concisão, pragmatismo e compilação rápida não estão nele. A seção 3 os tira do FAQ, dos princípios de evolução e de fontes secundárias, e a compilação rápida ficou marcada como intenção reportada, não como objetivo formal.

O segundo exercício é abrir a página de releases do Kotlin, anotar a versão estável atual e a data, e comparar com a versão 2.1.21 usada nesta aula. Explique por que a documentação de um projeto deve sempre indicar a versão do compilador.

Resposta esperada: a página de releases do Kotlin, consultada em 4 de novembro de 2026, indica a versão 2.4.21 como estável, lançada em 8 de outubro de 2026. O rodapé da mesma página traz 6 de outubro, mas a FAQ oficial também diz 8 de outubro, e por isso esta é a data que a documentação repete. A versão 2.1.21, usada nesta aula, saiu em 10 de outubro de 2024, segundo a mesma página, e três versões menores (2.2, 2.3 e 2.4) separam as duas. A versão precisa ser escrita porque o mesmo código pode ser analisado e compilado de outra forma entre versões. A troca para o K2, no Kotlin 2.0, mudou justamente isso, como a seção 4 explica. Uma afirmação como “o código compila” só tem valor junto com o compilador que a testou.

O terceiro exercício é escolher uma classe Java que você tenha escrito (ou que esteja num projeto seu), contar as linhas de boilerplate e prever, a partir da seção 6, o que uma data class equivalente geraria. Depois confira a previsão com a documentação de data classes.

Resposta esperada: a classe Java da seção 6 tem 33 linhas com imports, e o que se repete ali é o construtor, os dois getters e os métodos equals, hashCode e toString, escritos à mão. A previsão é que uma data class com as mesmas propriedades gere equals e hashCode, toString no formato Usuario(nome=…, email=…), componentN (component1 e component2, na ordem da declaração) e copy. A documentação de data classes confirma essa lista. Ela também diz que, se a própria classe já declarar equals, hashCode ou toString, o compilador não gera a versão dele. Além disso, o construtor primário precisa de pelo menos um parâmetro, e data classes não podem ser abstract, open, sealed ou inner.

O quarto exercício é consultar a página de estabilidade do Kotlin e escrever, em um parágrafo, qual alvo você escolheria hoje para um serviço de backend e qual escolheria para compartilhar lógica com um app iOS, justificando cada escolha pelo status de cada componente.

Resposta esperada: para o backend, a escolha é Kotlin/JVM, estável desde a versão 1.0.0 segundo a página de estabilidade, com o Spring como suporte de primeira classe. Para compartilhar lógica com um app iOS, a escolha é Kotlin Multiplatform, com o runtime do Kotlin/Native estável desde 1.9.20. A mesma página marca a interoperabilidade com C e Objective-C como beta desde 1.3.0, e essa interoperabilidade é o caminho para chamar APIs da Apple a partir do Kotlin. Por isso a justificativa precisa separar as duas partes: a lógica compartilhada está em componente estável, e a ponte com Objective-C não está, o que pede um teste de integração no iOS antes de comprometer o projeto.

glossário

JVM: máquina virtual que executa programas compilados para bytecode, usada pelo Java e pelo Kotlin.

Bytecode: formato intermediário que o compilador gera e a JVM executa.

Boilerplate: código repetitivo que não traz regra de negócio, mas precisa existir para a linguagem funcionar.

IDE: ambiente de desenvolvimento integrado, o programa onde se escreve, executa e depura código.

Null: valor que representa a ausência de um objeto. Em Java, uma referência pode ser nula sem que o tipo avise.

Interoperabilidade: capacidade de código de uma linguagem usar código de outra, aqui o Kotlin e o Java.

Kotlin Foundation: organização sem fins lucrativos que cuida da linguagem. Segundo o FAQ dela, JetBrains e Google são os membros fundadores.

Kotlin-first: estratégia de dar prioridade ao Kotlin em novas ferramentas e documentação, mantendo o suporte ao Java.

K2: nome do compilador do Kotlin usado por padrão desde o Kotlin 2.0.

Kotlin Multiplatform: recurso para compartilhar código entre alvos diferentes da linguagem.

Coroutines: forma de escrever código assíncrono como se fosse sequencial. Serão estudadas na fase 4 da trilha.

Data class: classe que o compilador Kotlin gera com equals, hashCode, toString e copy a partir das propriedades do construtor. Será explicada em aula própria.

fontes

Consultadas em 04/11/2026. As fontes primárias são as da JetBrains, do Kotlin, da Kotlin Foundation, do Google e do Spring. As secundárias são a Wikipedia, usada para datas de origem e para citações que não consegui verificar em fonte primária, e a InfoWorld, usada para a citação de Jemerov de 22 de julho de 2011.

Primárias:

Secundárias:

Não consegui abrir, na consulta, a entrevista de Andrey Breslav publicada pela Oracle nem a reportagem da ADTmag sobre a abertura do código em 2012. Por isso elas não são citadas, e os pontos que dependiam delas estão marcados no texto. O site da Kotlin Foundation abriu, e as páginas dele estão listadas acima.

Traduções de citações em inglês são livres e estão marcadas no texto.

relacionados

↑ Voltar ao topo

Atalhos de teclado

Abrir busca
/
Alternar tema claro/escuro
t
Aula anterior na série
←
Próxima aula na série
→
Lista de atalhos
?