Modernização Java: tornando upgrades enterprise viáveis

Entre em qualquer grande empresa — um banco, uma companhia aérea, uma telecom — e o Java geralmente está fazendo o trabalho pesado. Sistemas bancários centrais, pipelines de detecção de fraude, gerenciamento de pedidos, batch jobs noturnos que reconciliam milhões de transações antes do amanhecer. Funciona, escala — e é exatamente por isso que boa parte ainda roda no Java 8, ou mais antigo.

Funcionar não é o mesmo que ser saudável. Os frameworks estão em versões que não recebem mais patches de segurança. Os autores originais foram embora há muito tempo. "Não mexa, está funcionando" virou um princípio arquitetural. E a lacuna continua crescendo: records, sealed classes, pattern matching, virtual threads, os collectors G1/ZGC, melhor suporte a containers e inicialização mais rápida — tudo isso está do outro lado de um upgrade que ninguém quer agendar.

Este post é sobre fechar essa lacuna. Explica por que essas aplicações ficam presas, depois percorre as cinco capacidades do Premium Package for Java — upgrades de versão do JDK, re-platforming para Liberty, modernização de UI, geração de testes unitários e remediação de segurança — e como cada uma divide o trabalho entre automação determinística e IA. Encerra com o que seu repositório precisa ter para aproveitar ao máximo, como obter acesso e como começar.

Por que tantos apps Java estão uma década atrás

Se a modernização é tão claramente valiosa, por que tantos apps Java enterprise ainda parecem congelados em 2014? As causas são estruturais: inércia organizacional e risco de engenharia real.

• Crescimento orgânico, não planejado. Esses sistemas cresceram funcionalidade por funcionalidade, aquisição por aquisição. Camadas de código se acumularam sobre camadas mais antigas, cada uma escrita sob prazos e convenções diferentes. O que você herda hoje se parece com sedimento geológico: decisões tomadas por dezenas de equipes ao longo de uma década.
• Os engenheiros que escreveram os módulos centrais foram embora, e o conhecimento tácito foi junto. O que resta é documentação escassa e alguns engenheiros seniores que "mais ou menos lembram como aquele módulo funciona".
• Atualizar o Java significa auditorias de dependências, upgrades de frameworks (Spring, Hibernate, migrações de namespace do Jakarta EE), remoção de APIs obsoletas e revalidação em cada ambiente — meses de esforço, budget real e custo de oportunidade real, difícil de justificar quando o sistema já funciona.
• Até um salto de Java 8 → 17 ou 21 pode revelar conflitos no sistema de módulos, APIs internas removidas (sun.misc.Unsafe), avisos de reflection virando erros graves e mudanças sutis no comportamento do garbage collector. Um bump de versão no papel vira uma investigação de semanas na prática.
• Os ciclos de regressão são longos. Suites de testes extensas — unitários, integração, performance, UAT, às vezes aprovações manuais — significam que um único upgrade pode desencadear semanas de testes antes de ir a produção.
• Por baixo de tudo: o medo de quebrar o que funciona. Quando um app move milhões de reais por dia, o custo de um deploy ruim supera muito o custo de não atualizar — então a conversa sobre o upgrade escorrega para o próximo trimestre. E para o seguinte.

A saída é incremental, não uma reescrita. Com as ferramentas certas, você pode pagar a dívida técnica em passos pequenos o suficiente para que cada um seja seguro de entregar.

O Premium Package for Java

O Premium Package for Java é um conjunto de cinco workflows para modernização Java enterprise. Cada um é construído na mesma divisão de trabalho: deixa a automação determinística fazer o trabalho previsível e mecânico, e a IA lidar com as decisões contextuais que receitas não conseguem codificar.

Engines baseadas em regras como OpenRewrite são confiáveis para refactoring mecânico em milhares de arquivos. A IA é melhor para as partes complicadas — interpretar erros de build, raciocinar sobre lógica de negócio, escolher entre trade-offs. Bob orquestra os dois em um workflow passo a passo com um humano aprovando as etapas consequentes.

A expertise por trás disso importa. Os workflows são moldados por engenheiros da IBM e Red Hat que construíram compiladores JIT, entregaram WebSphere e Open Liberty, ajudaram a pioneirar o Quarkus e contribuíram para OpenJDK, Jakarta EE e MicroProfile. O tooling codifica como esses times abordam uma migração — conhecimento que um modelo não consegue reconstruir a partir do código na sua frente.

Veja como a divisão funciona nas cinco capacidades.

Capacidade 1: Upgrades de versão do JDK — Java 8 para 11, 17, 21 ou 25

Atualizar o JDK é a tarefa de modernização mais comum e a mais subestimada. Bob trata isso como uma jornada em múltiplas etapas baseada em evidências, não como um único comando.

• Inteligência do projeto primeiro. Bob analisa a ferramenta de build (Maven ou Gradle), a topologia de módulos, a versão atual do Java e o footprint dos frameworks, depois propõe caminhos de upgrade viáveis (8→17, 8→21, com ou sem Jakarta EE), cada um anotado com uma avaliação de dificuldade e os desafios técnicos esperados.
• Para o alvo escolhido, receitas curadas do OpenRewrite tratam as transformações mecânicas de forma segura e em escala.
• As receitas te levam parte do caminho; na prática, 40–50%. O resto — conflitos de dependências exóticos, APIs internas removidas, quebras específicas de bibliotecas — é onde o loop agentivo entra. Bob compila o projeto, faz o parsing dos logs de build do Maven/Gradle, agrupa as exceções por causa raiz e pede à IA correções direcionadas, módulo por módulo.
• Guardrails que respeitam a intenção. A IA é instruída para nunca trocar silenciosamente entre os namespaces javax e jakarta, nunca comentar código ou mover arquivos para "fazer compilar", e solicitar aprovação explícita antes de qualquer mudança de pacote ou dependência.

Você tem um upgrade que é rápido onde pode ser automatizado e cuidadoso onde não pode, com um audit trail completo no final.

Capacidade 2: Re-platforming para Liberty — WebSphere tradicional para Liberty

Migrar do WebSphere Application Server tradicional para WebSphere Liberty ou Open Liberty traz menor footprint de memória, packaging amigável a containers, inicialização mais rápida e suporte moderno ao Jakarta EE. Também é uma das migrações mais intrincadas para tentar à mão.

• Assessment conduzido pelo AMA. Bob ingere a saída do Application Modernization Accelerator da IBM, parseando seus relatórios em problemas de migração específicos ao nível de arquivo com orientação de remediação baseada em regras.
• Cada regra AMA carrega orientação prescritiva — "substitua com.ibm.websphere.* pelo equivalente padrão Jakarta EE", "migre a configuração ibm-web-ext.xml para server.xml". Bob alimenta esses problemas, agrupados por causa raiz, para a IA junto com o texto de ajuda da regra, para que o modelo aplique a correção conhecida em vez de adivinhar.
• Onde a migração envolve um salto para o Jakarta, a mesma biblioteca de receitas do OpenRewrite trata a mecânica do namespace de forma determinística.
• Build, deploy, verificar. Bob constrói o WAR/EAR, faz deploy via liberty-maven-plugin ou liberty-gradle-plugin, acompanha os logs do servidor em busca de falhas de inicialização e carregamento de classes, e as resolve iterativamente. Verificação funcional com curl contra endpoints REST faz parte do fluxo padrão.

O workflow codifica como os engenheiros do Liberty abordam a migração, em vez de deixar isso para um prompt genérico.

Capacidade 3: Modernização de UI — JSP/Struts para um SPA moderno

A maioria dos apps Java legados ainda conduz suas UIs via JSP, Struts ou servlets. Bob divide isso em um pipeline de cinco fases.

• Extração de arquitetura. Antes de qualquer código ser reescrito, Bob analisa a aplicação e produz um architecture.md catalogando cada controller, action, servlet, página, formulário, regra de validação e caminho de fluxo de dados. Esse documento é a fonte da verdade para o restante da migração.
• A camada de apresentação legada (Struts actions, servlets, controllers JSP) é convertida em endpoints REST em um backend moderno — Spring Boot, Quarkus ou Liberty — com os DAOs originais e classes de modelo intocados para proteger a integridade do banco de dados.
• Scaffolding de frontend. Um novo projeto TypeScript (Angular, React ou outro framework) é conectado a um design system escolhido — Carbon, Material UI ou shadcn/ui — com cliente HTTP, theming, routing, gerenciamento de estado, error boundaries e CORS configurados antes de qualquer trabalho em features começar.
• Formulários e tabelas JSP são então mapeados para equivalentes do design system — DataTables, Cards, DatePickers, formulários validados — com as regras de negócio originais mantidas.
• Gates de validação em cada etapa. Bob nunca inicia a aplicação em si. Após cada fase, pede ao desenvolvedor para executar o comando de build/start e confirmar, mantendo a verificação nas mãos humanas.

A IA trata a tradução contextual da sopa de tags JSP para componentes modernos; a automação trata o scaffolding, as dependências e a verificação do build.

Capacidade 4: Testes unitários — estratégia primeiro, depois geração

A cobertura de testes é frequentemente o maior bloqueador da modernização: você não consegue atualizar com segurança o que não consegue verificar com segurança. Bob gera uma estratégia de testes antes de gerar os testes.

• Geração de estratégia. Bob analisa o projeto e produz um UNITTEST.md cobrindo arquitetura, módulos que precisam de cobertura, frameworks recomendados (JUnit 5, Mockito, AssertJ), convenções de nomenclatura, limites de cobertura e os comandos exatos para rodar os testes com e sem relatório de cobertura.
• A seleção de candidatos funciona em múltiplas granularidades — pacotes inteiros, classes específicas, métodos individuais — e pode rodar sobre git diffs para focar o esforço em código modificado recentemente.
• Gerar, rodar, corrigir. Cada prompt de teste termina com a mesma instrução: rode os testes, corrija as falhas. A IA executa, observa as falhas e itera até a suite ficar verde em vez de parar na geração de código.
• Bob integra com JaCoCo para que o loop mire na cobertura medida em vez de apenas um test run verde.

A automação roda os testes; a IA os escreve e raciocina sobre as falhas. A cobertura resultante é o que desbloqueia os outros quatro workflows.

Capacidade 5: Remediação de segurança — CVEs como parte do mesmo loop

Um app modernizado que ainda entrega dependências cheias de CVEs está apenas pela metade. A remediação de segurança reutiliza a mesma arquitetura do upgrade do JDK, apontada para vulnerabilidades.

• Detecção orientada pelo build. Bob reutiliza os analisadores de log do Maven e Gradle do workflow de upgrade, ajustados para detectar advisories de dependências, avisos de depreciação e dependências transitivas com vulnerabilidades conhecidas da saída do build, plugins de dependency-check e ferramentas SBOM.
• Quando uma correção não é um simples bump de versão — digamos que a biblioteca patchada mudou assinaturas e os call sites precisam ser migrados — o loop agentivo agrupa as quebras por causa raiz, aplica a remediação nos módulos e reconstrói para verificar.
• Os mesmos guardrails se aplicam. Sem mudanças de dependências sem aprovação explícita, sem código comentado, sem surpresas de namespace. As correções são apresentadas, explicadas e confirmadas antes de serem aplicadas.

O endurecimento de segurança roda no mesmo track que o restante do trabalho de modernização, não como um roadmap separado.

O fio condutor

Nas cinco capacidades, a mesma divisão de trabalho vale:

A automação trata o que é determinístico, a IA trata o que é contextual, e um humano aprova o que é consequente — apoiado pelos engenheiros da IBM e Red Hat que construíram a plataforma por baixo.

Prepare seu repositório

Esses workflows vão mais longe em uma codebase que já é legível — e o que ajuda o Bob é o mesmo que ajuda qualquer engenheiro que herda o código:

• Um build verde e razoavelmente rápido. Cada loop aqui é ancorado na saída de compilação e testes. Quanto mais rápido e confiável for seu build mvn/gradle, mais justo é o ciclo gerar-rodar-corrigir.
• Testes existentes, mesmo que parciais. A cobertura é tanto uma rede de segurança para upgrades quanto um sinal que o Bob lê. Se você tem pouco, comece com a Capacidade 4 antes de tentar um salto de versão.
• Uma árvore de dependências declarada e fixada. Versões claras no pom.xml/build.gradle e um lock de dependências atualizado fazem a diferença entre um run de receita limpo e uma caça a conflitos de vários dias.
• Tooling de build que o Bob consegue conduzir. Os workflows do Liberty e de segurança dependem de plugins padrão (liberty-maven-plugin, dependency-check, tooling SBOM); tê-los configurados deixa a metade de automação fazer seu trabalho.

Como obter acesso

O Premium Package for Java é um add-on ao plano base do Bob, não um download separado.

Como você é habilitado depende do seu plano:

• Planos individuais (Pro, Pro+, Ultra). Acesse a página de preços em bob.ibm.com, escolha um plano e adicione o add-on do Java durante o checkout. Depois de concluir o pedido e instalar o Bob IDE, a habilitação é detectada no login. Você gerencia seats e add-ons pela sua assinatura em bob.ibm.com.
• Planos Enterprise. Seu administrador Bob atribui seats do plano base e o add-on do Java pelo Bob Admin UI. Quando um seat é atribuído a você, a mesma detecção automática se aplica — faça login e os workflows aparecem.

Duas coisas que vale deixar explícitas:

• Você precisa selecionar o add-on do Java no checkout. Ele não faz parte do plano base por padrão. Se você pulá-lo durante a compra, os workflows não vão aparecer, mesmo em um plano pago.
• Planos Trial não podem usar add-ons. O Premium Package for Java exige um plano pago Pro, Pro+, Ultra ou Enterprise.

Começar

Quando seu plano inclui o add-on e você está logado no Bob IDE:

• Rode o assessment de upgrade do JDK em um único módulo primeiro para ver os caminhos propostos e as avaliações de dificuldade antes de se comprometer com um alvo.
• Se a cobertura for baixa, gere uma estratégia UNITTEST.md e construa uma rede de segurança antes de qualquer salto de versão.
• Aprove as mudanças módulo por módulo — os guardrails estão lá para manter as mudanças de namespace e dependências nas suas mãos.

Veja os casos de uso em bob.ibm.com para ver como os times conduziram essas migrações do início ao fim.