Do Java 8 para o Kotlin: A Hello World Experience

4 minutos de leitura

Depois de muitos anos programando ocasionalmente em Python e Ruby, nos últimos tempos eu voltei a estudar Java, com um foco em Spring Boot, dado que é uma das melhores opções alternativas ao JavaEE. Eu gosto do Spring Boot por causa do seu foco em permitir a criação rápida de aplicações que você literalmente já pode rodar logo depois de fazer o carregamento inicial do projeto. Ele possui muito do Ruby on Rails no quesito “Convenção em vez de Configuração” mas, por no fim do dia estarmos falando de Java, eu meio que perdi um pouco do espírito do Ruby (e do Python em um nível menor) no desenvolvimento em Java. Mesmo o Java 8 provendo significantes mudanças e melhoramentos em relação ao Java 7, eu quero descobrir se eu consigo esse prazer de desenvolver de forma ágil usando Kotlin para escrever aplicações Spring Boot…

Bom, Kotlin é uma nova linguagem criada pelos caras da JetBrains, os mesmos criadores das IDEs IntelliJ IDEA (para Java) e PyCharm (para Python), e foi criada como um substituto ao Java no desenvolvimento dos seus produtos. Seu objetivo foi criar uma linguagem - baseada na JVM - mais concisa e que ajuda no aumento da produtividade do programador, evitando alguns problemas comuns no desenvolvimento Java, mas se mantendo 100% compatível com aplicativos Java existentes. Ele usa o Java 6 como base enquanto adiciona vários benefícios de linguagem, o que o tornou excelente para desenvolvimento Android.

Voltando ao tema do post, nós iremos usar como base uma aplicação simples em Java 8/Spring Boot. Isso permitirá que eu possa fazer comparações diretas entre características das duas linguagens.

Primeiramente, nós iremos precisar de uma aplicação Spring Boot, que pode ser baixada do Spring Initializr. Em nosso exemplo, a classe da aplicação deverá ter o seguinte formato:

Nenhuma surpresa até aqui. Nós criamos um método main() estático que carrega o Spring Boot.

Agora, no Kotlin, temos a mesma classe, definida abaixo:

A primeira diferença que podemos notar é a falta do ;. SIM PESSOAS LINDAS DESSE MUNDO, não existe ponto-e-vírgula na linguagem! Apesar de isso não ser assim algo tãããão importante, eu considero como um passo em direção à uma linguagem mais limpa e expressiva.

A próxima diferença que notamos é a palavra open na frente da definição da classe. Classes em Kotlin são final por padrão, como descreve o excelente texto da Oracle - Effective Java - Design and document for inheritance or else prohibit it. Esta é minha primeira experiência com a característica de “forçar boas práticas” da linguagem, e com um pouco de trabalho, descobri que a anotação @SpringBootApplication têm um problema com essa característica final das classes no Kotlin. No caso da anotação, ela é composta pelas anotações @Configuration, @EnableAutoConfiguration e @ComponentScan. No caso, é a anotação @Configuration que necessita que a classe anotada não seja final. Remover a palavra open da classe causa um erro de execução quando a aplicação tenta iniciar:

org.springframework.beans.factory.parsing.BeanDefinitionParsingException: Configuration problem: @Configuration class 'Application' may not be final. Remove the final modifier to continue.

Neste caso, é fácil resolver esse problema, é só utilizarmos as anotações @EnableAutoConfiguration e @ComponentScan diretamente em ves da anotação @SpringBootApplication, conforme exemplo abaixo:

A diferença final que notamos é na definição do método main(). Kotlin têm um conceito de companion objects, que são usados de forma similar a métodos estáticos do Java, mas não exatamente da mesma forma. E é por esse motivo que existe a anotação @JvmStatic, que diz para o Kotlin gerar um método estático no lugar do “quase” método estático padrão da linguagem. Essa anotação é um belo exemplo do investimento em compatilibidade com a JVM (e com o Java).

Também falta no método main() o modificador public, mas isso é devido ao fato de métodos são públicos por padrão em Kotlin, o que reduz um bocado de código “encheção de linguiça”, presente nas aplicações Java.

Classe de Aplicação alternativa

Adicionalmente, o Kotlin permite que funções sejam definidas fora das classes que a acompanham, da seguinte forma:

A questão aqui é que se fizermos isso, o método main() será definido em uma classe gerada pelo Kotlin, chamada ApplicationKt, nomeada baseada no nome do arquivo (no caso Application.kt). É importante salientar isso, pois podemos precisar em algum momento referenciar classes que possuam métodos definidos dessa forma.

Eu não sei qual eu prefiro. Usar um companion object parece mais explícito sobre a classe que contém o main() mas a definição de baixo é mais resumida. Aqui entendo que a segunda abordagem troca a quantidade de código pelo entendimento implícito da classe ApplicationKt. Nesse ponto, o Zen of Python sempre fala mais alto para mim: Explicit is better than implicit.

Conclusão

Na minha humilde opinião, o Kotlin está indo na direção certa de uma evolução natural da linguagem Java. Parece para mim que os designers da linguagem fizeram com que a linguagem se mantivesse compatível com aplicações existentes enquanto não ficaram travados ao legado do Java. A falta do ponto-e-virgula não é algo tão importante pois várias linguagens já não têm mais esse empecilho (Javascript, Python, Ruby).

Fora isso, não notamos diferença em rodar uma aplicação simples em Kotlin e em Java, com o Spring Boot. Nos próximos posts sobre esse tema iremos abordar mais questões do Spring Boot, já que estou aproveitando a oportunidade para rever Spring e aprender Kotlin no processo.

:(){ :|:& };:

Deixe um comentário