O que há de novo e interessante no JDK 26

Com o lançamento do JDK 26, que chegou em 17 de março, já vimos 17 versões do Java entregues na cadência de lançamento de seis meses baseada no tempo. Ninguém pode chamar isso de outra coisa senão um grande sucesso para Java. Nos últimos oito anos, vimos a plataforma Java avançar mais rápido do que em qualquer momento da sua história. Além disso, a cadência de lançamento mais rápida tornou os recursos de visualização e os módulos da incubadora uma realidade prática. Isso permite que recursos totalmente desenvolvidos sejam testados pelos desenvolvedores, com feedback incorporado antes da finalização do recurso. Dentro dos limites práticos, os desenvolvedores Java obtêm exatamente o que desejam em novos recursos.

Como uma observação interessante, JDK 26 é a primeira versão Java em que nenhum recurso de visualização foi finalizado. O que então o JDK 26 oferece?

Existem 10 JDK Enhancement Proposals (JEPs), que são o mecanismo para definir novos recursos no projeto OpenJDK. Isso está um pouco abaixo da média, mas é importante notar que não é uma versão de suporte de longo prazo (LTS). As versões LTS do Java são aquelas para as quais as distribuições OpenJDK se comprometem a fornecer manutenção e suporte estendidos, portanto, é mais provável que sejam usadas na produção. Isso não significa que o JDK 26 não seja de qualidade de produção; se você usar um pipeline de CI/CD com implantações frequentes, o JDK 26 será ótimo para executar seus aplicativos.

Vamos dividir os novos recursos por categoria: a linguagem Java, as bibliotecas e o tempo de execução.

Melhorias na linguagem Java

A única característica específica da linguagem é o desenvolvimento contínuo de tipos primitivos em padrões, instanceofe switch (JEP 530), que está em sua quarta prévia. Embora Java seja uma linguagem orientada a objetos, Java não trata tudo como um objeto; possui valores primitivos para melhorar o desempenho. Este JEP permite que tipos primitivos sejam usados em locais onde anteriormente você precisaria de um tipo de referência. Foram feitas alterações para resolver problemas encontrados ao combinar tipos primitivos (como int) com tipos de referência (como a classe wrapper Integer).

Melhorias nas bibliotecas Java

A maior parte das mudanças no JDK 26 está nas bibliotecas.

JEP 517: HTTP/3 para a API do cliente HTTP. A API do cliente HTTP foi aprimorada para incluir suporte para o protocolo HTTP/3 mais recente. Em vez de usar o TCP, do qual o HTTP/2 e versões anteriores dependem, o HTTP/3 usa o protocolo QUIC baseado em UDP. Isso proporciona melhor desempenho sem exigir nenhuma alteração de código, além da especificação do protocolo ao criar a conexão.
JEP 524: Codificação PEM para objetos criptográficos. Objetos criptográficos como chaves públicas, chaves privadas, certificados e listas de certificados revogados são frequentemente transmitidos por e-mail, e o formato Privacy-Enhanced Mail (PEM) é ideal para isso. Este JEP adiciona uma API concisa para conversão entre texto PEM e objetos criptográficos e vice-versa.
JEP 525: Simultaneidade Estruturada. Escrever código multithread cooperativo é notoriamente difícil de acertar. Ao longo de sua história, Java adicionou muitos recursos para facilitar isso, desde as APIs de Concurrency Utilities até a estrutura ForkJoin e, mais recentemente, Virtual Threads. A simultaneidade estruturada aumenta essa caixa de ferramentas, tratando grupos de tarefas relacionadas executadas em diferentes threads como unidades únicas de trabalho. Isso permite tratamento e cancelamento simplificados de erros, melhorando a confiabilidade e melhorando a observabilidade. Os desenvolvedores estarão familiarizados com a abordagem, pois é como a sintaxe try-with-resources.
JEP 526: Constantes preguiçosas. Anteriormente, isso era chamado de “valores estáveis”, mas o novo nome reflete melhor o objetivo desse recurso: fornecer objetos que contenham dados não modificáveis. Embora Java possua campos finais, Lazy Constants oferecem maior flexibilidade no tempo de sua inicialização.
JEP 529: A API vetorial. Este PEC está agora em incubação pela décima primeira vez, o que constitui um recorde para um PEC. Como esta API faz parte do Projeto Valhalla maior, ela não será finalizada até que mais desse projeto seja incorporado à plataforma Java. Nesta API, os vetores referem-se aos registros muito amplos disponíveis nos processadores modernos. Instruções específicas permitem que vários valores tenham a mesma operação aplicada a eles nesses registros em um único ciclo de clock, melhorando muito o desempenho para operações numericamente intensivas (como IA). Embora o compilador JIT vetorize automaticamente o código que reconhece, ele não é capaz de fazer isso em todas as situações em que vetores podem ser usados. Com a API Vector, um desenvolvedor pode especificar explicitamente como deseja que as operações vetoriais sejam usadas pelo compilador JIT.
JEP 504: Remova a API do miniaplicativo. Os miniaplicativos foram o que realmente colocou o Java no caminho do sucesso quando foi lançado. No entanto, os navegadores (onde os miniaplicativos eram usados) já mudaram há muito tempo e nenhum navegador convencional suporta o plug-in Java necessário para executar miniaplicativos. O Java Plugin foi removido do Oracle JDK 11, não faz parte do projeto OpenJDK e permanece de código fechado. A API Applet é o componente final restante e está obsoleta para remoção desde o JDK 17.

Melhorias no tempo de execução Java

Finalmente, temos mudanças no tempo de execução:

JEP 500: Prepare-se para fazer final significa final. Como mencionado anteriormente, Java tem o conceito de final campos, cujo valor pode ser definido apenas uma vez. Embora um final campo não pode ser modificado simplesmente atribuindo-lhe um novo valor, ainda é possível alterar seu valor em certos casos através de um recurso chamado reflexão profunda. Isto limita o que a JVM pode fazer para otimizar o desempenho, uma vez que ainda precisa acomodar a possibilidade de uma mudança. Este JEP deixa claro aos desenvolvedores que em uma versão futura, eles não poderão mais usar a reflexão profunda dessa forma e deverão alterar seu código em preparação.
JEP 516: Cache de objeto Ahead-of-time (AOT) com qualquer GC. Isso faz parte do projeto OpenJDK Leyden, cujo objetivo é reduzir o tempo que um aplicativo leva para atingir seu nível de desempenho ideal. A necessidade de identificar o código usado com frequência e compilá-lo enquanto o aplicativo está em execução é o motivo pelo qual o desempenho não inicia em velocidade total. Este JEP permite que o cache AOT, que consiste em dados sobre classes carregadas e inicializadas, funcione com qualquer coletor de lixo. Isso foi necessário porque o coletor ZGC não funcionava com o cache AOT.
JEP 522: G1 GC melhora o rendimento reduzindo a sincronização. G1 é o coletor de lixo padrão na VM HotSpot e funciona bem em muitas situações. Este JEP melhora a eficiência deste coletor, reduzindo a quantidade de sincronização necessária entre o GC e os threads do aplicativo. Isso é transparente para o código do aplicativo.

Concluindo, apesar de não incluir tantos JEPs quanto algumas versões, ainda existem novas adições úteis e interessantes à plataforma Java. Embora o JDK 26 não seja uma versão LTS, os desenvolvedores ainda devem testar seus aplicativos com esta versão para evitar problemas acumulados quando o JDK 29, a próxima versão LTS, for lançado no próximo ano.

–

Fórum de Nova Tecnologia oferece um local para líderes de tecnologia — incluindo fornecedores e outros colaboradores externos — explorarem e discutirem tecnologias empresariais emergentes com profundidade e amplitude sem precedentes. A seleção é subjetiva, baseada na escolha das tecnologias que acreditamos serem importantes e de maior interesse para os leitores do InfoWorld. A InfoWorld não aceita material de marketing para publicação e reserva-se o direito de editar todo o conteúdo contribuído. Enviar tudo consultas para [email protected].