JDK 27 chega em setembro com G1 padrão e nove JEPs; JDK 28 já tem API de JSON no radar
Segunda versão non-LTS depois do Java 25 entra em release candidate com foco em garbage collector, headers compactos e criptografia pós-quântica. JDK 28, previsto para março de 2027, começa a ganhar forma.

O JDK 27 atingiu seu primeiro release candidate, segundo anúncio de Mark Reinhold, arquiteto-chefe do Java↳Java42 conteúdosNovidades do Java 26 (para desenvolvedores)Dev (Back & Front) · mar 2026Visual Studio Code para Java: o guia completo (dicas, configuração e extensões)Dev (Back & Front) · out 2025Quarkus: Modernizando a linguagem Java para a era da nuvemDev (Back & Front) · nov 2020Ver tudo em Dev (Back & Front) → Platform Group na 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 →. É a segunda versão non-LTS desde o JDK 25, e o conjunto de recursos já está congelado: o repositório principal foi bifurcado para o repositório de estabilização no início de junho de 2026 (Rampdown Phase One). A partir daí, só entram correções de bugs críticos aprovadas via processo de Fix-Request. O lançamento formal está marcado para 15 de setembro de 2026, com o JDK 28 previsto para março de 2027.
Para quem constrói e mantém sistemas Java em produção no Brasil, o ponto prático é o ritmo de seis meses entre releases. Como JDK 27 é non-LTS, a maior parte das empresas vai continuar no JDK 25 (LTS) em produção, mas a lista de features indica com bastante antecedência o que estará consolidado na próxima LTS. Vale acompanhar o roadmap para não ser pego de surpresa em migração.
O que entra no JDK 27
São nove JEPs no total, distribuídas em quatro categorias. Duas mudanças de HotSpot são as que mais afetam quem já roda Java em produção, porque valem por padrão, sem flag.
JEP 523: G1 como garbage collector padrão em todos os ambientes. Até agora, o G1 era o default apenas em ambientes de servidor. Com a mudança, se nenhum GC for especificado na linha de comando, o HotSpot sempre escolhe o G1, inclusive em ambientes menores. Na prática, é uma padronização de comportamento que reduz surpresas de tuning entre máquinas diferentes.
JEP 534: Compact Object Headers por padrão. O recurso de headers compactos foi entregue no JDK 25 (JEP 519) como opção; agora vira o layout padrão de header de objeto na JVM. Cabeçalhos menores significam menor consumo de memória por objeto, o que se traduz em pegada de heap menor em aplicações com muitos objetos vivos, cenário comum em serviços de alto throughput.
JEP 536: JFR In-Process Data Redaction. O JDK Flight Recorder passa a poder redigir informações sensíveis antes de finalizar a gravação, como argumentos de linha de comando, valores iniciais de variáveis de ambiente e propriedades de sistema. É relevante para quem coleta gravações de JFR em produção e precisa evitar vazar segredos em artefatos de diagnóstico.
Previews que continuam avançando
Boa parte das novidades ainda está em preview ou incubação, ligada aos grandes projetos do OpenJDK:
- JEP 532 (Project Amber), Primitive Types in Patterns, instanceof, and switch (quinto preview): estende pattern matching a tipos primitivos em todos os contextos de padrão, e amplia
instanceofeswitchpara trabalhar com todos os primitivos. Este preview traz definição refinada de "unconditional exactness" e checagens de dominância mais estritas emswitch. - JEP 533 (Project Loom), Structured Concurrency (sétimo preview): trata grupos de tarefas relacionadas rodando em threads diferentes como uma única unidade de trabalho, simplificando tratamento de erro, cancelamento e 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 →.
- JEP 537 (Project Panama), Vector API (12º incubator): sem mudanças substanciais de implementação desde o JDK 25. A API continuará em incubação até que os recursos necessários do Project Valhalla estejam disponíveis como preview.
- JEP 531, Lazy Constants (terceiro preview) e JEP 538, PEM Encodings of Cryptographic Objects (terceiro preview).
Um destaque de segurança é a JEP 527: Post-Quantum Hybrid Key Exchange for TLS 1.3, que adiciona troca de chaves híbrida resistente a computação quântica no TLS 1.3. Para times brasileiros que operam sob exigências regulatórias de criptografia (setor financeiro, saúde, governo), é sinal de que a plataforma já está se movendo na direção pós-quântica.
O que já está no radar do JDK 28
O JDK 28, com GA previsto para março de 2027, já conta com seis JEPs (cinco Targeted e uma Proposed to Target). Alguns pontos que valem atenção para planejamento:
- JEP 540, Simple JSON API (Incubator): define uma API padrão para parsear e gerar documentos JSON sem depender de biblioteca externa, implementando o RFC 8259. Substitui a antiga JEP 198 (Light-Weight JSON API), agora fechada. Para o ecossistema brasileiro, muito dependente de Jackson e Gson, é um movimento a acompanhar, ainda em incubação, mas com potencial de reduzir dependências em casos simples.
- JEP 401, Value Objects (Preview): parte do Project Valhalla, propõe objetos de valor, definidos como objetos que só contêm campos
final, não têm identidade e são distinguidos apenas pelos valores de seus campos. É uma das mudanças estruturais mais aguardadas da plataforma. - JEP 539, Strict Field Initialization in the JVM (Preview): introduz campos estritamente inicializados na JVM, que precisam ser inicializados antes de serem lidos, de modo que valores default como
0ounullnunca sejam observados. - JEP 535, Shenandoah GC: Generational Mode by Default: torna o modo geracional o padrão do Shenandoah, com deprecação do modo não geracional.
- JEP 541, Deprecate the macOS/x64 Port for Removal: deprecia a porta macOS/x64 para remoção futura, já que a Apple não suporta mais essa arquitetura, seguindo a lógica de corte de custos de manutenção já aplicada à porta Windows 32-bit x86 (JEP 449).
- JEP 542, PEM Encodings of Cryptographic Objects: proposta para finalizar o recurso após três rounds de preview (JDK 25 a 27).
Entre os drafts que ainda podem entrar, estão a Lazy Constants (quarto preview) e a Faster Startup and Warmup with ZGC, que propõe alocar memória de forma mais eficiente conforme a necessidade da aplicação, criando um heap inicial pequeno para reduzir overhead do sistema operacional e melhorar tempo de startup.
O que fica em aberto
JEPs em draft, como lembra a InfoQ, podem mudar a qualquer momento, e a Oracle deve mirar JEPs adicionais para o JDK 28 em breve. Ou seja, a lista do JDK 28 ainda não está fechada. Já o JDK 27, por estar em release candidate, tem seu conjunto de features praticamente definido, restando apenas correções críticas até 15 de setembro. Para equipes que planejam upgrades, o recado é claro: o G1 e os compact headers viram padrão agora, e as apostas de arquitetura de médio prazo (value objects, structured concurrency, Vector API) continuam maturando release após release.
Fonte: InfoQ
Este artigo foi escrito por Redação iMasters, um agente de inteligência artificial com revisão editorial humana. Publicado sob revisão editorial de Rafael Chinaglia - iMasters. Saiba como produzimos no expediente.









Comentários
Ninguém comentou ainda. Começa a conversa?