Estamos no ano de 2020. Java completa 25 anos e permanece como uma das linguagens de programação mais utilizadas do mundo segundo o TIOBE.
Nos últimos anos, a linguagem Java perdeu espaço no mundo de programação back-end para linguagens mais dinâmicas e eficientes como Python, Node.js, Go e C#.
Além da verbosidade, uma das principais reclamações é que o Java é lento e pesado.
É inaceitável em um mundo com FaaS, serveless, conteiners e microsserviços, uma aplicação ocupe mais de 200mB e demore minutos para ficar pronta.
Para tentar resolver esse problema nos últimos tempos surgiu um novo competidor, o Quarkus. Criado para ser usado com containers, com baixo consumo de memória, baseado em especificações e fácil de configurar. O Quarkus busca trazer o de volta o prazer de programar em Java.
Nesse artigo, vamos comparar os tamanhos e tempo de start-up entre o Quarkus com o principal framework de desenvolvimento Java: Spring.
Plano de Ação
Será implementado um microsserviço com um único endpoint que responde com a string "Hello world!". Esse microsserviço rodará num container e será analisado tanto tempo para a aplicação incializar quanto o recurso consumido.
Isso será feito comparando Quarkus com Java 8, Quarkus com Java 11, Quarkus Nativo com Java 8, Quarkus Nativo com Java 11, Spring com Java 8 e Spring com Java 11. Vamos criar as aplicações usando os geradores de código de cada framework e não buscaremos nenhuma otmização nesse código gerado.
Gerando código Spring
O Spring possui seu conhecido gerador de código: https://start.spring.io/. Vamos selecionar a biblioteca Spring Web. A estrutura de classes tem esse formato.
O modelo padrão não vem com nenhum controller, então foi escrito um. O controller ficou com esse formato.
Gerando código Quarkus
Quarkus também possui o seu gerador que pode ser acessado em http://code.quarkus.io. Foi selecionado apenas o plugin para comunicação REST (que é obrigatório ser selecionado). O código foi criado com a seguinte árvore.
O modelo padrão já vem com um controller que faz o hello world e que ficou assim.
Agora que já vimos como eles são, gerar as imagens docker. Foram usadas as imagens base openjdk:8-jre-slim ou openjdk:11-jre-slim nos testes.
Resultado final
Segue abaixo o resumo da execução dos serviços e do quanto de memória foi consumido.
Para facilitar o entendimento, os dados foram colocados em uma tabela.
Quarkus levou a melhor tanto no fato de consumir menos recurso quanto no tempo necessário para ficar pronto para receber as conexões. Notem que quando é usado o modo nativo, o tempo cai de 2.802s para 0.006s.
Considerações
Esse simples teste não serve como estudo, pois muita coisa pode ter atrapalhado a medição, seria necessário rodar várias vezes e testar com outras combinações de bibliotecas.
O objetivo aqui é mostrar que o Quarkus chegou com tudo e ajudará a linguagem Java a se manter competitiva nesse admirável mundo novo.
Top comments (1)
Pretendo em algum momento começar a estudar o Quarkus, depois desse post fiquei mais motivado