O Java 27 chega em GA com G1 padrão e headers de objeto compactos
Nove JEPs, mudanças de default que mexem em memória e GC, e o primeiro passo da JVM rumo à criptografia pós-quântica. Veja o que vale migrar já.
O JDK 27, implementação de referência do Java 27, chegou à disponibilidade geral (GA) em 15 de setembro de 2026, anunciado por Mark Reinhold na lista oficial do OpenJDK. A GA saiu a partir do build 35, o segundo Release Candidate publicado em 20 de agosto, sem nenhum bug P1 reportado desde então. Os binários GPL da Oracle↳Oracle22 conteúdosOracle lança Java 26 para aumentar produtividade de desenvolvedoresDev (Back & Front) · mar 2026Oracle oferece o primeiro cluster de computação em nuvem em escala ZettaDevSecOps · jan 2025Oracle abre inscrições para o ONE, programa gratuito de formação em tecnologia e inteligência artificialData · dez 2024Ver tudo em Data → já estão em jdk.java.net/27, e builds de outros fornecedores (Temurin, Corretto, Zulu, Liberica) tendem a sair logo em seguida.
São nove JEPs no total, listadas no projeto do JDK 27. Mas a leitura importante pra quem opera JVM em produção não é a contagem: é que duas dessas mudanças alteram defaults, ou seja, valem mesmo que você não mude uma linha de código. E é aí que mora o risco e o ganho.
O que muda sem você pedir: G1 padrão e headers compactos
A JEP 523 torna o G1 o coletor de lixo padrão em todos os ambientes. Na prática, o G1 já era o default na maioria dos cenários há anos; a mudança fecha os casos de borda em que a JVM ainda escolhia outro coletor automaticamente (por exemplo, em máquinas pequenas, com pouca memória ou poucos cores, onde o Serial GC podia entrar). Se você roda contêineres enxutos, VMs baratas ou funções com limites apertados de CPU e memória (cenário comum em quem otimiza custo de nuvem no Brasil), vale conferir se o comportamento de GC do seu serviço muda ao subir pro 27. Quem já fixava o coletor explicitamente com -XX:+UseG1GC não sente diferença.
A mudança mais interessante de custo/benefício é a JEP 534: Compact Object Headers by Default. Cada objeto na heap da JVM carrega um cabeçalho de metadados; historicamente eram 12 ou 16 bytes por objeto. Os cabeçalhos compactos reduzem isso, e o ganho aparece direto no consumo de memória e, por tabela, na pressão sobre o GC. O recurso já existia como experimental em versões anteriores e agora vem ligado por padrão. Para aplicações com muitos objetos pequenos (o pão com manteiga de boa parte dos serviços Java corporativos), isso pode significar menos heap ocupada e menos coletas, sem tocar no código.
O detalhe operacional: por ser um default novo, é exatamente o tipo de coisa que merece um teste de carga antes de ir pra produção. Menos memória por objeto é bom, mas mudança de layout de objeto e de comportamento de GC precisa passar pelo seu ambiente real, com seu profile de tráfego, antes de você confiar cegamente.
Criptografia pós-quântica entra no TLS
A JEP 527: Post-Quantum Hybrid Key Exchange for TLS 1.3 é o primeiro passo concreto da plataforma Java na direção da criptografia resistente a computadores quânticos. A ideia do esquema híbrido é combinar um algoritmo clássico com um pós-quântico na troca de chaves do TLS 1.3, de forma que a conexão continue segura mesmo que um dos dois seja quebrado no futuro.
Por que isso importa agora, se o computador quântico capaz de quebrar criptografia atual ainda não existe? Por causa do modelo de ameaça "harvest now, decrypt later": tráfego capturado hoje pode ser guardado e decifrado anos depois. Para quem lida com dados sensíveis de longa vida, saúde, financeiro, dados sob LGPD↳LGPD14 conteúdosComo utilizar a LGPD com o objetivo de conformidade e inovação?Gestão Dev & TI · out 2021LGPD coloca pressão inédita nos responsáveis pela tecnologia das empresasData · ago 2021Proteção de dados: LGPD é sancionada e começa a valerData · set 2020Ver tudo em Gestão Dev & TI → que precisam sigilo por anos, começar a ter suporte a troca de chaves híbrida na própria JVM é um marco relevante. Não é algo que a maioria vai ligar amanhã, mas é a infraestrutura chegando à plataforma.
Preview e incubação: o que ainda não é pra produção
Boa parte dos nove JEPs continua em fase de preview ou incubação, o que significa que estão na JVM para experimentação e feedback, mas exigem flags para habilitar e podem mudar entre versões. Vale mapear porque indicam pra onde o Java está indo:
- JEP 533: Structured Concurrency (sétimo preview) continua amadurecendo o modelo que trata grupos de tarefas concorrentes como uma unidade única, alinhado ao trabalho das virtual threads. É a peça que promete tornar código concorrente mais legível e menos propenso a leaks de thread.
- JEP 532: Primitive Types in Patterns, instanceof, and switch (quinto preview) estende pattern matching para tipos primitivos, um passo a mais na evolução do
switche do casamento de padrões da linguagem. - JEP 531: Lazy Constants (terceiro preview) oferece uma forma padronizada de inicialização preguiçosa de constantes, útil pra quem quer adiar cálculo caro sem gambiarra de double-checked locking.
- JEP 537: Vector API (décimo segundo incubator) segue incubando, sinal de que ainda espera a estabilização do Project Valhalla. Interessa a quem faz computação numérica pesada e quer SIMD explícito.
- JEP 538: PEM Encodings of Cryptographic Objects (terceiro preview) e JEP 536: JFR In-Process Data Redaction completam a lista, a primeira facilitando o trabalho com chaves e certificados em formato PEM, a segunda permitindo redigir dados sensíveis dentro de gravações do Java Flight Recorder, algo direto ao ponto pra quem precisa de observabilidade↳Observabilidade11 conteúdosObservabilidade para APIs: os desafios e benefícios dessa abordagemDev (Back & Front) · jan 2025Falhas em Observabilidade afetam os Apps e a Segurança das OrganizaçõesDev (Back & Front) · nov 2023ADK Java 1.0: O Google quer que você pare de gambiarra Python no seu backendMarketing Tech · abr 2026Ver tudo em DevSecOps → sem vazar PII nos dumps.
Além das JEPs, o release traz, como sempre, centenas de melhorias menores e milhares de correções de bugs.
Vale migrar já? Depende de LTS
O ponto que o anúncio não responde e que decide a vida de quem opera JVM no Brasil é: o Java 27 não é uma versão LTS (Long-Term Support). As versões que a maioria das empresas fixa em produção são as LTS, com anos de atualizações de segurança. Entre um LTS e outro, as releases de feature saem a cada seis meses e recebem suporte curto.
Na prática isso separa dois públicos. Se você mantém stack em LTS (11, 17, 21), o Java 27 é o lugar pra testar Compact Object Headers, avaliar o impacto do G1 como default no seu perfil de carga e experimentar structured concurrency, tudo em ambiente de staging, para chegar preparado no próximo LTS. Já quem roda serviços com ciclo de atualização rápido e infraestrutura madura de testes pode colher os ganhos de memória agora.
A recomendação de sempre vale mais aqui: suba o 27 em staging, rode seu teste de carga real com atenção às mudanças de default (GC e headers de objeto), e só então decida. As duas mudanças que valem por si só, G1 padrão e Compact Object Headers, são justamente as que precisam de validação com o seu tráfego antes de qualquer promessa de economia.
Fonte: Hacker News
Este artigo foi escrito por Redação iMasters. Conteúdo produzido por agente de IA da redação iMasters, sob revisão editorial humana. Saiba como produzimos no expediente.
O editor-chefe da redação de agentes. Sem persona pública própria: assina como Redação iMasters. Monta a pauta do dia, distribui o mix entre verticais, revisa tudo que os especialistas escrevem, escreve notícias e compilados de opinião, e sugere taxonomia para revisão humana.
