Java: separe correção de segurança de promessa para o JDK 28

O resumo semanal da InfoQ reúne propostas para o JDK 28 e atualizações de manutenção no ecossistema Java.[8] Entre elas, Micronaut Framework 5.2.2 atualiza para Netty 4.2.19.Final, resolvendo 16 CVEs, e Open Liberty 26.0.0.10 corrige sete CVEs e acrescenta suporte ao JDK 27.[8]

Para quem mantém aplicações, a primeira decisão não deveria ser experimentar todas as novidades. Deveria ser identificar quais mudanças eliminam riscos de componentes realmente presentes no sistema.

O que muda para quem desenvolve

As JEPs 546 e 545 propõem, respectivamente, dimensionamento adaptativo do heap e melhorias de inicialização e aquecimento do ZGC.[8] A JEP 543 propõe finalizar concorrência estruturada, tratando tarefas relacionadas como uma unidade para facilitar cancelamento, erros e observabilidade.[8] As três chegaram a “Proposed to Target”, estágio que ainda não confirma inclusão ou disponibilidade final.[8]

Minha recomendação é manter duas filas de decisão. A primeira trata de correções em dependências usadas hoje. A segunda investiga capacidades futuras, com um problema mensurável que justifique o experimento. Misturar as filas favorece a novidade enquanto o risco existente permanece.

Há também uma mudança de runtime relevante: a reportagem destaca G1 como GC padrão no Java 27 em todos os ambientes, inclusive os restritos em CPU ou memória.[8] Trocar o runtime merece observação própria, separada de atualizar uma biblioteca.

Como aplicar

Gere um inventário com dependências diretas e transitivas, versão efetiva e aplicação responsável. Verifique se Netty ou Open Liberty estão presentes antes de tratar os alertas como urgência local. Priorize correções conforme exposição e impacto, sem presumir que toda CVE seja explorável em qualquer configuração.

Em homologação, valide inicialização, tráfego representativo, tratamento de requisições inválidas e consumo sob os limites reais do contêiner. Para uma mudança de GC, compare pausas, latência de cauda, memória e comportamento sob pressão. Mantenha uma forma de voltar à versão anterior e critérios claros para interromper a promoção.

Para concorrência estruturada, um pequeno laboratório pode compor chamadas a dois serviços simulados, provocar uma falha e observar cancelamento e propagação de erro. Defina o comportamento esperado antes de escolher a API. Não adote um recurso de acesso antecipado como dependência operacional só porque o exemplo ficou menor.

Se houver interesse em IA na aplicação, LangChain4j 1.22.0 acrescenta inferência em lote no Bedrock e integração com a Decisions API da OpenAI.[8] Avalie essas opções em uma tarefa delimitada, com custo e tratamento de falha explícitos.

Cuidados e limites

O JDK 28 citado está no build 19 de acesso antecipado, não em uma versão estável para atualizar produção.[8] Propostas, previews e lançamentos de manutenção devem permanecer identificados como categorias diferentes.

Apache Grails 8.0.0 estabelece JDK 21 e Gradle 9.7 como mínimos e altera aspectos de controllers e execução de promises.[8] Uma atualização desse tipo exige revisar ambiente e comportamento, não somente editar o número de uma dependência.

O ganho operacional vem de promover mudanças com evidência. Um runtime mais recente ou uma API nova não compensa uma correção de segurança esquecida no inventário.

Fonte

[8] Fonte: InfoQ