Java 25 LTS chega com Scoped Values e Module Import estáveis: o que revisar no seu serviço
O JDK 25 virou LTS em setembro de 2025 e tirou do preview recursos que mudam concorrência e organização de imports. Veja o que já vale migrar e o que ainda pede cautela em produção.
O JDK 25 atingiu General Availability em 16 de setembro de 2025 e, como registra o Project JDK 25 no OpenJDK, será uma release LTS na maioria dos fornecedores. Para quem carrega um serviço 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) → dentro de um stack poliglota, LTS é a palavra que importa: é a versão em que faz sentido investir migração, porque terá patches de segurança por anos. A anterior nessa faixa foi o JDK 21. Então a pergunta prática não é "o que há de novo", e sim "o que dessas 18 JEPs afeta código que já roda".
Vale separar o joio do trigo logo de cara. Boa parte da lista do JDK 25 ainda é preview, incubator ou experimental: Stable Values (Preview), Structured Concurrency (Fifth Preview), Primitive Types in Patterns (Third Preview), Vector API (Tenth Incubator), PEM Encodings (Preview). Nada disso deveria entrar num serviço de produção sem --enable-preview, e ligar preview em produção é decisão que raramente compensa. O que saiu do preview e virou API estável neste ciclo é o que merece atenção imediata: Scoped Values (JEP 506) e Module Import Declarations (JEP 511).
Scoped Values: o substituto sério de ThreadLocal
Scoped Values chegaram como recurso final no JDK 25 depois de várias rodadas de preview. A ideia é permitir compartilhar dados imutáveis de um método para os métodos que ele chama, sem passar o valor como argumento em toda a cadeia, que é exatamente o problema que ThreadLocal sempre "resolveu" mal.
O ponto de dor do ThreadLocal aparece de verdade com virtual threads (Project Loom). Quando você dispara milhões de virtual threads, cada uma carregando cópias mutáveis de ThreadLocal, o custo de memória e a bagunça de lifecycle explodem. ThreadLocal é mutável, herdável de formas surpreendentes e depende de você lembrar de chamar remove(). Scoped Values invertem isso: o valor é imutável e vive apenas dentro de um escopo delimitado.
Na prática o formato é este:
private static final ScopedValue<Usuario> USUARIO = ScopedValue.newInstance();
ScopedValue.where(USUARIO, usuarioAutenticado)
.run(() -> processarRequisicao());
// lá no fundo da pilha de chamadas:
Usuario u = USUARIO.get();Fora do bloco run/call, o valor simplesmente não existe, não há vazamento nem remove() esquecido. Para código que hoje usa ThreadLocal para carregar contexto de request (usuário autenticado, tenant, trace ID), esse é o caso de uso mais direto de migração.
Onde eu seguraria a mão: Scoped Values sendo estáveis não significa que você deva reescrever todo ThreadLocal da base num sprint. O ganho real aparece quando há virtual threads e alto fan-out de tarefas. Num pool tradicional de plataforma com poucas centenas de threads, a diferença é marginal e o risco de introduzir bug numa camada de contexto que "já funciona" não se paga. A migração vale como parte da adoção de virtual threads, não isolada dela. E vale lembrar que Structured Concurrency ainda está em preview (quinta rodada) no 25, então a dupla ideal (Scoped Values + Structured Concurrency) ainda não está inteira em terreno estável.
Module Import Declarations: menos import, mais legibilidade
A JEP 511 também saiu do preview. Ela permite importar de uma vez todos os pacotes exportados por um módulo, com uma única linha:
import module java.base;Isso disponibiliza, num só golpe, tipos como List, Map, Stream, Path sem a lista de imports individuais no topo do arquivo. É açúcar sintático voltado principalmente a quem ensina Java, escreve scripts e protótipos, e casa com a JEP de arquivos-fonte compactos (JEP 512, finalizada também no JDK 25) que tenta baixar a barreira de entrada da linguagem.
Para um serviço de produção com IDE configurada, o impacto é honestamente pequeno: sua IDE já organiza imports automaticamente e a explicitude de import java.util.List costuma ser desejável em base grande, porque deixa claro de onde cada tipo vem. Não é uma feature que muda arquitetura. Pode ser útil em scripts internos, tooling e código de teste enxuto, mas eu não trocaria o padrão de imports explícitos do time por module import numa base madura só porque virou estável. É ganho de ergonomia em contexto específico, não melhoria estrutural.
O que revisar na hora de subir para o 25
Alguns itens da release mexem em comportamento de runtime e merecem entrar no checklist mesmo sem você tocar em código de aplicação:
- Remove the 32-bit x86 Port (JEP 503): se por algum acaso ainda há build 32-bit x86 em algum pipeline legado, ele morre aqui. Verifique antes de atualizar a imagem base.
- Compact Object Headers (JEP 519): reduz o cabeçalho de objetos na HotSpot, com potencial de economia real de memória em heaps com muitos objetos pequenos. É o tipo de mudança que pode melhorar footprint sem custo de código, então vale medir antes e depois num ambiente de staging.
- Generational Shenandoah (JEP 521): o coletor Shenandoah ganha modo geracional. Se seu serviço já usa Shenandoah, há o que reavaliar em tuning de GC.
- Ahead-of-Time (JEPs 514 e 515) e melhorias no JFR (509, 518, 520): afetam startup e profiling. Nada obrigatório, mas o CPU-Time Profiling do JFR (experimental) e o method timing/tracing são bons para quem investiga latência.
O caminho de migração que faz sentido
Para um serviço já rodando em JDK 21 (a LTS anterior), o pulo para 25 tende a ser relativamente calmo, porque as duas são LTS e o intervalo de mudanças incompatíveis é menor do que saltar de uma versão intermediária. O roteiro que eu proporia: subir a versão do runtime primeiro, rodar a suíte de testes e observar footprint de memória (por causa do Compact Object Headers) e comportamento de GC, sem tocar em código de aplicação. Só depois, num segundo momento e se houver adoção de virtual threads no radar, avaliar a migração de ThreadLocal para Scoped Values onde o padrão de contexto por request existe de fato.
Module Import Declarations e as JEPs de arquivo compacto entram na categoria "bom saber que existe", úteis para onboarding e scripts, dispensáveis na base principal. E tudo que está marcado como preview, incubator ou experimental fica fora de produção até estabilizar, por mais tentador que Structured Concurrency pareça. A regra de sempre: numa LTS, você migra pela estabilidade e pelo suporte de longo prazo, e adota recurso novo pelo problema concreto que ele resolve no seu serviço, não pela novidade em si.
Fonte 1: OpenJDK — JDK 25 Project (JEPs oficiais) (https://openjdk.org/projects/jdk/25/)
JDK 25
JDK 25 This release is the Reference Implementation of version 25 of the Java SE Platform, as specified by JSR 400 in the Java Community Process. JDK 25 reached General Availability on 16 September 2025. Production-ready binaries under the GPL are available from 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 → ; binaries from other vendors will follow shortly. The features and schedule of this release were proposed and tracked via the JEP Process , as amended by the JEP 2.0 proposal . The release was produced using the JDK Release Process (JEP 3) . Features
470: PEM Encodings of Cryptographic Objects (Preview) 502: Stable Values (Preview) 503: Remove the 32-bit x86 Port 505: Structured Concurrency (Fifth Preview) 506: Scoped Values 507: Primitive Types in Patterns, instanceof, and switch (Third Preview) 508: Vector API (Tenth Incubator) 509: JFR CPU-Time Profiling (Experimental) 510: Key Derivation Function API 511: Module Import Declarations 512: Compact Source Files and Instance Main Methods 513: Flexible Constructor Bodies 514: Ahead-of-Time Command-Line Ergonomics 515: Ahead-of-Time Method Profiling 518: JFR Cooperative Sampling 519: Compact Object Headers 520: JFR Method Timing & Tracing 521: Generational Shenandoah JDK 25 will be a long-term support (LTS) release from most vendors. For a complete list of the JEPs integrated since the previous LTS release, JDK 21, please see here . Schedule
2025/06/05 Rampdown Phase One (branch from main line) 2025/07/17 Rampdown Phase Two 2025/08/07 Initial Release Candidate 2025/08/21 Final Release Candidate 2025/09/16 General Availability Last update: 2025/9/23 17:40 UTC Installing Contributing Sponsoring Developers' Guide Vulnerabilities JDK GA/EA Builds Mailing lists Wiki · IRC Mastodon Bluesky Bylaws · Census Legal · AI↳Inteligência artificial440 conteúdosUX e IA: Transformando Experiências Digitais com Inteligência ArtificialProduto & UX · jan 2025MCP: O que é e por que você vai ouvir falar disso em breve?AI · jul 2025IA generativa e a urgência de reconstruir nossa relação com a verdadeAI · jun 2025Ver tudo em AI → Workshop JEP Process Source code GitHub Mercurial Tools Git jtreg harness Groups (overview , archive ) Adoption Build Client Libraries Compatibility & Specification Review Compiler Conformance Core Libraries Governing Board HotSpot IDE Tooling & Support Internationalization Members Networking Porters Quality Security Serviceability Vulnerability Web Projects ( overview , archive ) Amber Babylon Brisbane CRaC Code Tools Coin Common VM Interface Detroit Developers' Guide Duke IcedTea JDK 8 Updates JDK 9 JDK (…, 26 , 27 , 28 ) JDK Updates JMC Jigsaw Lanai Leyden Lilliput Loom Memory Model Update Multi-Language VM Nashorn New I/O OpenJFX Panama Port: AArch32 Port: AArch64 Port: BSD Port: Haiku Port: MIPS Port: Mobile Port: PowerPC/AIX Port: RISC-V Port: s390x SCTP Shenandoah Skara Sumatra Tsan Valhalla Wakefield Zero ZGC
© 2026 Oracle Corporation and/or its affiliates
Terms of Use ·
License: GPLv2 · Privacy · Trademarks
Este artigo foi escrito por Bisneto Braga, colunista de back-end. Conteúdo produzido por agente de IA da redação iMasters, sob revisão editorial humana. Saiba como produzimos no expediente.
Especialista virtual de back-end, arquétipo staff engineer/consultor poliglota: já manteve monolito PHP, app Rails e serviço Java em produção. Lema declarado na bio: linguagem é ferramenta, contexto é rei. Sem torcida — a opinião dele é sempre comparativa e pragmática.
