JDK 27: G1 GC vira padrão universal e Java ganha defesa pós-quântica

JDK 27: G1 GC vira padrão universal e Java ganha defesa pós-quântica

A Oracle disponibilizou as notas de lançamento da versão Early-Access do JDK 27, detalhando as implementações que formarão a próxima versão do Java. A atualização foca em otimização de infraestrutura, com mudanças profundas no gerenciamento de memória por padrão, e antecipa defesas criptográficas essenciais para aplicações de rede.

Além das melhorias estruturais, a versão avança com recursos de linguagem em estágio de preview e conclui a remoção de mecanismos considerados obsoletos ou inseguros, especialmente em ambientes Linux.

O que isso muda na prática

Para empresas que mantêm infraestrutura baseada em Java, o JDK 27 traz ganhos automáticos de desempenho e segurança. Ao atualizar, as aplicações passarão a consumir menos espaço de memória graças à redução no tamanho dos cabeçalhos dos objetos e ao uso do G1 Garbage Collector em todos os cenários.

Do lado da segurança, sistemas que utilizam as APIs nativas do Java para comunicação de rede herdarão defesas contra ataques de computação quântica no TLS 1.3, tudo isso sem exigir que os desenvolvedores reescrevam o código-fonte das aplicações.

Eficiência de memória: G1 e headers compactos

JHkISu7s jdk 27 novidades g1 gc padrao criptografia pos quantica 2
JDK 27: G1 GC vira padrão universal e Java ganha defesa pós-quântica 16

A alteração com maior impacto imediato na implantação de aplicações é a promoção do Garbage-First (G1) como coletor de lixo padrão em todos os ambientes. Até então, o G1 era o padrão apenas em ambientes de servidor. A mudança padroniza o comportamento de coleta e as expectativas de latência independentemente do porte do dispositivo executando a JVM.

Em paralelo, o HotSpot JVM adota cabeçalhos de objetos compactos (Compact Object Headers) por padrão. A estrutura, que tradicionalmente ocupava 96 bits em arquiteturas de 64 bits, foi reduzida para 64 bits. Essa compressão resulta em menor tamanho de heap, melhor localidade de dados e maior densidade de implantação em servidores.

Criptografia pós-quântica e privacidade de telemetria

Antecipando o avanço da computação quântica e o risco de descriptografia retroativa de tráfego capturado, o JDK 27 implementa troca de chaves híbrida pós-quântica para o protocolo TLS 1.3. A solução combina algoritmos resistentes a ataques quânticos com criptografia tradicional. As aplicações baseadas no pacote javax.net.ssl utilizarão os novos métodos por padrão.

A telemetria do Java também recebeu uma camada extra de proteção. O JDK Flight Recorder (JFR) agora edita e oculta automaticamente dados sensíveis, como argumentos de linha de comando, variáveis de ambiente e propriedades do sistema, antes que os registros saiam do processo da aplicação.

Evolução da linguagem e ferramentas

O JDK 27 avança com diversos recursos em estágio de preview e incubação voltados à simplificação do desenvolvimento e melhoria de performance em cálculo:

  • Structured Concurrency (Sétimo Preview): Trata grupos de tarefas em diferentes threads como uma unidade única de trabalho, simplificando o tratamento de erros e o cancelamento de rotinas.
  • Primitive Types in Patterns e switch (Quinto Preview): Permite o uso de tipos primitivos em todos os contextos de correspondência de padrões, estendendo as instruções instanceof e switch.
  • Lazy Constants (Terceiro Preview): Nova API para constantes avaliadas de forma tardia, oferecendo as mesmas otimizações de campos final na JVM, mas com maior flexibilidade no momento de inicialização.
  • Vector API (Décimo Segundo Incubator): Expressa computações vetoriais que compilam em tempo de execução para instruções ótimas nas CPUs suportadas, superando os cálculos escalares tradicionais.

Limpeza no ecossistema e remoções no Linux

A manutenção do ecossistema continua com o encerramento de APIs e recursos antigos. No Linux, a Oracle removeu o mecanismo de inicialização VFORK na implementação de processos, uma vez que a abordagem é considerada perigosa para a estabilidade. Desenvolvedores devem confiar no padrão POSIX_SPAWN ou no mecanismo FORK convencional.

O recurso experimental JVM Compiler Interface (JVMCI) foi completamente removido do HotSpot JVM. O método ThreadPoolExecutor.finalize(), que não realizava ações desde o JDK 11 e estava marcado para remoção, também foi eliminado. Desenvolvedores que sobrepunham este método em suas extensões de classe poderão enfrentar erros de compilação.

Por fim, a propriedade java.locale.useOldISOCodes, que permitia reverter para códigos de idiomas ISO 639 antigos (como iw para hebraico ou in para indonésio), perdeu o efeito prático e agora gerará um alerta no tempo de execução, exigindo a transição definitiva para os padrões atuais.