Java 27 chega com criptografia pós-quântica nativa no TLS 1.3
Segundo release não LTS depois do JDK 25 traz nove JEPs, foco em segurança de longo prazo e estreia do Java Verified Portfolio com Helidon 27 e JavaFX 27.
A 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 → liberou o Java 27, segundo release não LTS desde o JDK 25. O conjunto final traz nove JEPs, cinco delas ainda em estágio de preview ou incubadora. O eixo do release é claro: segurança de longo prazo, com destaque para a criptografia pós-quântica ganhando espaço direto no TLS.
Para quem mantém aplicação enterprise em 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) →, o recado prático é que a proteção contra o cenário "colher agora, decifrar depois" (harvest now, decrypt later) começa a vir de fábrica, sem depender de biblioteca externa ou provedor de segurança customizado.
Criptografia pós-quântica no handshake
O destaque é a JEP 527, Post-Quantum Hybrid Key Exchange for TLS 1.3. Ela aprimora a implementação do RFC 8446 (TLS 1.3) usando a especificação de troca de chaves híbrida que o IETF ainda está rascunhando, em conjunto com a JEP 496 (Module-Lattice-Based Key Encapsulation Mechanism), entregue lá no JDK 24.
O termo híbrido importa: o handshake combina um algoritmo clássico com um resistente a computadores quânticos. Assim, mesmo que um dos dois seja quebrado no futuro, a sessão continua protegida pelo outro. É uma abordagem conservadora, pensada justamente para quem não pode arriscar a compatibilidade de conexões TLS em produção.
Esse movimento não é isolado. Desde o JDK 24, a Oracle vem empilhando peças de PQC. Segundo o blog da Oracle, a estratégia é levar algoritmos padronizados e TLS habilitado para pós-quântico também para os releases LTS, reduzindo o atrito de adoção para empresas que não acompanham cada versão de seis meses. As peças já entregues ou em andamento incluem:
- JEP 496: Key Encapsulation Mechanism baseado em reticulados (JDK 24)
- JEP 497: algoritmo de assinatura digital resistente a quântica
- JEP 510: Key Derivation Function API
- JEP 527: troca de chaves híbrida no TLS 1.3 (JDK 27)
- JEP 542: PEM Encodings, previsto para finalizar no JDK 28
PEM sai da gaveta
A JEP 538, PEM Encodings of Cryptographic Objects, entra em terceiro preview, depois de duas rodadas no JDK 25 e no JDK 26. A API cuida de codificar e decodificar chaves, certificados e listas de revogação para o formato PEM, aquele texto Base64 delimitado por -----BEGIN...----- que todo mundo que já mexeu com OpenSSL conhece. A conversão cobre os formatos binários PKCS #8 e X.509.
Duas mudanças nesta rodada valem atenção de quem for encostar na API: a classe PEMRecord deixou de ser record e virou classe comum, para oferecer construtores que aceitam conteúdo Base64 em arrays de bytes; e a interface DEREncodable foi renomeada para BinaryEncodable, descrevendo melhor o dado binário guardado no texto PEM. Não é detalhe cosmético: quem já usava o preview vai precisar ajustar imports e chamadas.
Além da segurança: performance e linguagem
O release mexe em pontos que afetam qualquer aplicação, mesmo quem não vai tocar em criptografia tão cedo:
- JEP 523: torna o G1 o coletor de lixo padrão em todos os ambientes
- JEP 534: Compact Object Headers por padrão, reduzindo o overhead de memória por objeto (relevante para heaps grandes com muitos objetos pequenos)
- JEP 536: redação de dados in-process no JFR (JDK Flight Recorder), útil para não vazar informação sensível em gravações de diagnóstico
Na frente de linguagem, seguem em preview a JEP 531 (Lazy Constants, terceiro preview), a JEP 532 (Primitive Types in Patterns, instanceof e switch, quinto preview) e a JEP 533 (Structured Concurrency, sétimo preview). A Structured Concurrency, em particular, já vai longe em iterações e mira simplificar o controle de tarefas concorrentes tratando um grupo de subtarefas como uma unidade. A JEP 537 (Vector API) chega ao décimo segundo incubador, sem mudanças substanciais de implementação desde o JDK 25.
Java Verified Portfolio: Helidon 27 e JavaFX 27
Apresentado na JavaOne 2026, o Java Verified Portfolio (JVP) é um ecossistema de tecnologias com suporte Oracle. Com o Java 27 estreiam no portfólio o Helidon 27, o JavaFX 27, o Jipher 20 e uma extensão do JVP para o VS Code.
O Helidon 27 passa a seguir o versionamento do OpenJDK e é o primeiro release sob o modelo Tip & Tail da Oracle: o Helidon 27 é o Tip (ponta, com novidades), enquanto o Helidon 4.5.5, ainda em versionamento semântico, funciona como Tail, servindo de baseline de produção mais longevo para times que não querem correr atrás de cada versão nova. É uma decisão que muda o planejamento de quem já roda Helidon em produção: dá para ficar no Tail com mais previsibilidade.
O JavaFX 27 traz um pipeline de renderização Metal no macOS, para desempenho melhor em hardware Apple recente, além de controles de edição de texto aprimorados e avanços de acessibilidade↳Acessibilidade11 conteúdosO que é Acessibilidade Web e como tornar seu site mais acessívelDev (Back & Front) · mar 2019Design para veteranos digitais: acessibilidade para nós mesmosProduto & UX · jan 2020Dicas de Front-End para usabilidade, acessibilidade, performance e responsividadeProduto & UX · fev 2025Ver tudo em Produto & UX →. Já o Jipher 20, provedor criptográfico Java compatível com FIPS 140-3, amplia suporte para JDK 17, 21, 25 e 27 e incorpora as novas features de segurança.
O que vem no JDK 28
A data formal do JDK 28 é esperada para março de 2027, com feature freeze previsto para o começo de dezembro de 2026. Seis JEPs já estão mirando esse release, incluindo peças há muito aguardadas do Project Valhalla:
- JEP 539, Strict Field Initialization (Preview): campos que precisam ser inicializados antes de serem lidos, de modo que valores default como
0ounullnunca sejam observados - JEP 401, Value Classes and Objects (Preview): objetos-valor, que só têm campos
final, não possuem identidade e são distinguidos apenas pelos valores de seus campos
A integração dessas duas features no mainline é descrita como um marco significativo para o Valhalla, e é o que deve finalmente permitir a Vector API sair da incubadora para preview.
O que muda para quem constrói aqui
Para equipes brasileiras que mantêm sistemas Java de longa duração (bancário, governo, saúde, qualquer coisa com dado que precisa continuar secreto por uma década), a chegada de PQC nativo no TLS baixa a barreira de entrada: dá para começar a mapear onde o handshake híbrido entra sem depender de fornecedor terceiro. O Java 27 não é LTS, então o caminho mais seguro para produção continua sendo aguardar essas features chegarem a um release de suporte estendido, mas testar agora, em ambiente de homologação, é o jeito de não ser pego de surpresa quando o LTS chegar.
O JDK 27 já está disponível para download na Oracle, com binários de outros fornecedores previstos para os dias seguintes.
Fonte: InfoQ
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.
