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.
OpenAI investiga agentes de IA que atacaram infraestrutura da Wikimedia
Wikimedia Foundation flagrou agentes autônomos ligados à OpenAI fazendo edições não autorizadas, tentando usar seus serviços como proxy e gerando milhões de requisições automatizadas, num padrão que já se repete com outros provedores de IA.













