PODEMOS ter coisas legais: atualizar para Java 21 vale a pena

Chegou aquela época do ano novamente – os resultados da pesquisa anual “Estado do Ecossistema Java” da New Relic foram divulgados e, como sempre, eu investiguei-os. E embora eu ache que o relatório está bem feito e faz ótimas perguntas, fiquei desanimado com a quantidade de desenvolvedores Java que estão usando versões arcaicas.

Você está usando Java 21? Você deveria estar.

Antes de entrar na pesquisa, como amante de Java, quero falar sobre algumas das minhas coisas favoritas sobre Java 21.

Começarei dizendo que Spring Boot 3.x, a geração atual da pilha do lado do servidor mais popular na máquina virtual Java (JVM), requer pelo menos Java 17. Ele não suporta Java 8, que é o segundo versão mais utilizada, segundo a pesquisa.

Estou animado em ver que a adoção do Java 17 está avançando relativamente rápido, mas você realmente deveria usar o Java 21. O Java 21 é infinitamente melhor que o Java 8. É tecnicamente superior em todas as frentes. É mais rápido, mais seguro, mais fácil de operar, mais performático e mais eficiente em termos de memória.

Também é moralmente superior. Você não vai gostar da expressão de vergonha e tristeza nos olhos de seus filhos quando eles descobrirem que você está usando Java 8 em produção.

Faça a coisa certa e seja a mudança que você deseja ver no mundo: use o Java 21. É repleto de coisas boas, basicamente uma linguagem totalmente nova desde o Java 7: Lambdas. Sequências multilinhas. Expressões de troca inteligente. var. Correspondência de padrões. Tuplas nomeadas (elas são chamadas records em Java).

E, claro, a majestade, a maior conquista que são os fios virtuais. Threads virtuais são um grande negócio. Eles fornecem os mesmos benefícios de async/await ou suspensões, mas sem a verbosidade infinita do código em outras linguagens.

Sim, você me ouviu direito. Os threads virtuais do Java fornecem uma solução melhor e fazem isso com menos código do que outras linguagens.

Se você não sabe do que estou falando e usa essas outras linguagens, então você está vendo agora. Java? Menos detalhado do que seu idioma favorito? Impossível! Mas não estou errado.

Por que os threads virtuais são importantes

Para entender os threads virtuais, você precisa entender o problema para o qual eles foram criados. Se você ainda não experimentou threads virtuais, eles são meio difíceis de descrever. Vou tentar.

Java tem operações de bloqueio – coisas como Thread.sleep(long), InputStream.reade OutputStream.write. Se você invocar um desses métodos, o programa não avançará para a próxima linha até que esses métodos terminem de fazer o que estão fazendo e retornem.

A maioria dos serviços de rede são vinculados a E/S, o que significa que eles passam a maior parte do tempo em métodos de entrada e saída como InputStream.read e OutputStream.write.

É muito comum efetuar login em um serviço que não possui mais threads no pool de threads e ainda assim não consegue retornar uma resposta porque todos os threads existentes estão aguardando a ocorrência de alguma operação de E/S, como E/S no Limite HTTP, E/S para o banco de dados ou para a fila de mensagens.

Existem maneiras de desbloquear a E/S. Você poderia usar java.nio, que é complexo e indutor de ansiedade. Você poderia usar programação reativa, que funciona paradigmaticamente, mas é uma refatoração completa de toda a base de código.

Então, o pensamento é: não seria bom se o compilador soubesse quando você fez algo potencialmente bloqueador (como InputStream.read) e reordenou a execução do código? Portanto, quando você faz um bloqueio, o código em espera é movido para fora do thread de execução atual até que o bloqueio termine e, em seguida, é colocado de volta em outro thread quando estiver pronto para retomar a execução.

Dessa forma, você pode continuar a usar a semântica de bloqueio. A linha um é executada antes da linha dois. Isso promove depuração e escalabilidade. Você não está mais monopolizando tópicos apenas para desperdiçá-los enquanto espera que algo termine. Seria o melhor dos dois mundos: a escalabilidade da E/S sem bloqueio com a aparente simplicidade, capacidade de depuração e manutenção da E/S com bloqueio mais simples.

Muitas outras linguagens, como Rust, Python, C#, TypeScript e JavaScript, suportam async/await. Kotlin suporta suspend. Essas palavras-chave indicam ao tempo de execução que você fará algo que bloqueia e que deve reordenar a execução. Aqui está um exemplo em JavaScript:

O problema é que invocar async funções, você também deve estar em um async funções:

A palavra-chave é viral. Ele se espalha. Eventualmente, seu código acaba em um atoleiro de async/await– porque por que você não usaria async/await em todos os lugares que você pudesse? Portanto, é melhor do que usar E/S sem bloqueio de baixo nível ou programação reativa, mas pouco.

Java oferece uma maneira muito melhor. Basta usar um método de fábrica diferente para seus threads.

Se você estiver usando um ExecutorService para criar novos threads, use a nova versão que cria threads virtuais.

Se você estiver criando threads diretamente, em um nível baixo, use o novo método de fábrica:

A maior parte do seu código permanece completamente inalterada, mas agora você obtém uma escalabilidade muito melhorada. O tempo de execução não será prejudicado se você criar milhões de threads. Não posso prever quais serão seus resultados, mas há uma chance real de você não precisar mais executar tantas instâncias de um determinado serviço para lidar com a carga.

Se você estiver usando o Spring Boot 3.2 (você está, não é?), então você nem precisa fazer nada disso. Basta especificar spring.threads.virtual.enabled=true na tua application.properties — e depois peça um aumento à sua administração, pago pela redução drástica dos custos de infraestrutura em nuvem.

Se você não estiver usando o Spring 3.2, veja como é fácil atualizar neste vídeo de 9 minutos apresentado por meu colega defensor do Spring, DaShaun Carter.

Nem todos os aplicativos podem tecnicamente dar o salto ainda, mas a grande maioria deles pode e deve.

Canalizando Shakespeare

O que, finalmente, me traz de volta ao relatório da New Relic. Não me interpretem mal: é muito bem feito e vale a pena ler. Como uma tragédia de Shakespeare, é bem escrito e conta uma história triste.

Há uma seção inteira que confirma o óbvio: o céu está azul e as nuvens estão por toda parte. A implantação de cargas de trabalho em contêineres parece ser o padrão dominante, com os entrevistados relatando que 70% das cargas de trabalho Java usam contêineres. Francamente, estou surpreso que seja tão baixo.

Também é interessante a tendência de mudar para configurações multicore em vez de configurações single-core. Segundo a pesquisa, 30% das aplicações conteinerizadas estão usando Java 9 -XX:MaxRAMPercentage sinalizador, que limita o uso de RAM. E o G1 é o coletor de lixo mais popular em uso. Tudo muito bem.

O relatório toma um rumo trágico quando se trata de versões Java. Mais da metade dos aplicativos – 56% – estão usando Java 11 em produção, contra 48% em 2022. Java 8 – que foi lançado há uma década em 2014 – está em segundo lugar, com quase 33% dos aplicativos usando-o em produção . De acordo com a pesquisa, um terço dos aplicativos ainda usa uma versão do Java que estreou no mesmo ano em que o jogo Flappy Bird foi retirado do ar, o Ice Bucket Challenge varreu o Vine e a selfie do Oscar de Ellen DeGeneres se tornou viral.

A maioria dos usuários está na distribuição do OpenJDK da Amazon. O relatório sugere que isso ocorre porque a Oracle introduziu temporariamente um licenciamento mais restritivo para sua distribuição. Mas eu me pergunto até que ponto isso é apenas uma função da distribuição ser o padrão para cargas de trabalho Java na Amazon Web Services, o fornecedor mais prolífico de infraestrutura como serviço (IaaS). A distribuição teve uma aceitação massiva desde sua estreia, há alguns anos. Em 2020, tinha 2,18% do mercado e agora tem 31%. Uau! Se tantas pessoas podem migrar tão rapidamente para uma distribuição completamente diferente, então elas deveriam poder usar novas versões da mesma distribuição, não?

Há um pouco de esperança, suponho, nas tendências. A adoção do Java 17 pelos usuários cresceu 430% em um ano. Então, talvez veremos números semelhantes para o Java 21 – que está em disponibilidade geral há quase seis meses.

Então, o que você está esperando?

Como eu disse em minha palestra no Voxxed Days, acredito que nunca houve melhor momento para ser um desenvolvedor Java e Spring Boot. Os desenvolvedores Java e Spring têm os melhores brinquedos para brincar. E nem mencionei as imagens nativas do GraalVM, que melhoram drasticamente o tempo de inicialização e reduzem o consumo de memória para um determinado aplicativo Java. E isso já funciona perfeitamente com Java 21.

Essas coisas estão aqui e são incríveis. Cabe a nós dar o salto. E não é difícil. Experimente.

Instale o SDKMan, execute sdk install java 21.0.2-graalce e então corra sdk default java 21.0.2-graalce. Isso lhe dará o Java 21 e o compilador de imagem nativo GraalVM. Visite o Spring Initializr, que é meu segundo lugar favorito na web (depois da produção), em start.spring.io. Configure um novo projeto. Selecione Java 21 (é claro!). Adicionar GraalVM Native Support. Adicionar Web. Acerte o Generate botão e carregue-o em seu IDE. Especificamos spring.threads.virtual.enabled=true na tua application.properties. Crie um controlador HTTP simples:

Compile-o em uma imagem nativa do GraalVM: ./gradlew nativeCompile. Execute o binário no build pasta.

Agora você tem um aplicativo que ocupa uma pequena fração da RAM que uma imagem nativa não GraalVM ocuparia e também é capaz de escalar para muitas vezes mais solicitações por segundo. Fácil e incrível.

Chegar à produção nunca foi tão fácil

Nós podemos fazer isso. Vamos tentar fazer com que o Java 21 (ou Java 22?) tenha 99% de adoção até o momento em que a New Relic fizer seu próximo relatório – quem está comigo?

A postagem PODEMOS ter coisas legais: vale a pena atualizar para Java 21 apareceu pela primeira vez em The New Stack.