Spring Boot 4.0 muda Jackson e auto-configuração: o que avaliar antes de migrar

O guia oficial de migração do Spring Boot 3.5 para o 4.0 já circula há semanas, e a trilha 4.x segue adiante com 4.1 lançado e 4.2 em preview. Para quem decide entre migrar agora ou travar versão, o release note mostra onde o trabalho pesado está escondido.

O time do Spring Boot publicou as release notes da versão 4.0 na wiki oficial do projeto, documento atualizado pela última vez em 16 de setembro de 2026 por Andy Wilkinson. O texto não é um anúncio de lançamento: pela navegação da própria wiki, a trilha 4.x já segue adiante, com a versão 4.1 estável e a 4.2 em preview. Isso muda o ângulo de quem ainda está no Spring Boot 3.5: a pergunta não é mais "devo esperar", é "há quanto tempo estou atrasado".

O próprio guia oficial recomenda não pular etapa: quem está em versão anterior ao 3.5 deve passar por ele antes de tentar o salto para o 4.0. É um upgrade de major version apoiado em outro major, o Spring Framework 7.0, e isso se propaga: Spring Security 7.0, Spring Data 2025.1, Spring Batch 6.0, Spring Integration 7.0. Não é só o Boot que muda de número.

A base de plataforma muda menos do que parece

A nota não especifica baseline de linguagem 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) → para a versão 4.0. O que muda é o que roda por baixo: Jakarta Servlet sobe para 6.1, Jakarta Persistence para 3.2, Jakarta Validation para 3.1, Jakarta WebSocket para 2.2 e Jakarta WS RS para 4.0, com os pacotes jakarta.* que isso implica.

Para build, Gradle 9 passou a ser suportado, mas o aviso da própria nota é que o Gradle 8.14 ou mais recente continua funcionando. Não há prazo de descontinuação anunciado para o 8.x nesta nota, então times com pipeline de CI engessado em Gradle 8 não precisam tratar isso como bloqueio. Maven segue como sempre foi, sem mudança de versão mínima mencionada.

Servidor embutido também muda: Tomcat vai para 11.0 e Jetty para 12.1. Quem usa server.tomcat.resource.cache-max-size como ajuste fino de performance ganha controle novo sobre o tamanho do cache de recursos estáticos do Tomcat, mas quem tinha tooling próprio lendo versão de Tomcat embarcado por regex vai precisar atualizar o parser.

Jackson 3 é o breaking change que não grita

A dependência que mais silenciosamente pode doer é o Jackson, que sobe para a versão 3.0 como padrão do Spring Boot 4. A nota de release é direta sobre o suporte à versão anterior:

O suporte ao Jackson 2 é entregue em uma forma já depreciada.

Jackson 2 support ships in a deprecated form.Spring Boot 4.0 Release Notes

Na prática, isso significa que qualquer customização de ObjectMapper, módulo Jackson registrado manualmente ou @JsonSerialize com classes do pacote com.fasterxml.jackson.databind precisa ser revisitada. Jackson 3 reorganiza namespaces e remove parte do suporte legado que o Jackson 2 carregava por compatibilidade histórica. Serviço com serialização customizada pesada é o primeiro candidato a quebrar em silêncio, porque o teste de contrato passa local e falha só quando o payload real bate numa borda que o Jackson 2 tolerava.

Auto-configuração deixou de ser API pública

Esta é a mudança que mais afeta quem trata o Spring Boot como framework extensível em vez de caixa-preta. A nota é explícita:

Membros públicos (fora de constantes) foram removidos das classes de auto-configuração. Auto-configurações nunca foram API pública, e agora isso passou a ser imposto pelo próprio mecanismo da linguagem Java.

Public members (aside from constants) have been removed from auto-configuration classes. Auto-configurations never have been public API and now this is enforced through Java mechanisms.Spring Boot 4.0 Release Notes

Quem estendia DataSourceAutoConfiguration ou chamava método público de uma classe *AutoConfiguration para reaproveitar lógica interna vai ter erro de compilação. Isso sempre foi documentado como não suportado, mas na prática muita base de código legada fazia exatamente isso para economizar trabalho. O caminho correto continua sendo o mesmo de sempre: @ConditionalOnMissingBean, beans próprios ou BeanPostProcessor, nunca herança de classe de auto-configuração.

Nomes de propriedade que mudaram embaixo do capô

Uma leva de renomeações passa despretensiosa pela lista de "miscellaneous", mas quebra configuração em produção se ninguém revisar o application.yml antes do deploy:

• management.tracing.enabled virou management.tracing.export.enabled
• spring.dao.exceptiontranslation.enabled virou spring.persistence.exceptiontranslation.enabled
• a anotação ConditionalOnEnabledTracing foi renomeada para ConditionalOnEnabledTracingExport
• ScheduledTasksObservabilityAutoConfiguration virou ScheduledTasksObservationAutoConfiguration

Nenhuma dessas é incompatível de forma barulhenta: a aplicação sobe normalmente, só que a propriedade antiga simplesmente deixa de ter efeito. É o tipo de regressão que só aparece quando alguém percebe que o tracing parou de exportar span e começa a investigar de trás para frente.

O que o 4.0 traz de novo e vale configurar

Nem tudo na lista é risco de quebra. Parte do release é recurso que resolve problema real de quem mantém serviço HTTP em produção. Os destaques, segundo a nota oficial:

• HTTP Service Clients com auto-configuração: dá para anotar uma interface Java simples com @HttpExchange e deixar o Spring gerar a implementação, sem escrever cliente REST na mão
• API Versioning nativo em Spring MVC e WebFlux, configurável via spring.mvc.apiversion.* ou spring.webflux.apiversion.*, com extensão por ApiVersionResolver e ApiVersionParser para quem precisa de regra própria
• JmsClient como nova API de auto-configuração para JMS, convivendo sem quebra com JmsTemplate e JmsMessagingTemplate
• Starter spring-boot-starter-opentelemetry, que já traz as dependências para exportar métricas e traces via OTLP sem montar a stack na mão

Nota da redação: o código desta seção não foi executado em ambiente real. Valide antes de usar em produção.

O exemplo que a própria documentação usa para HTTP Service Clients mostra o tamanho da economia de boilerplate:

@HttpExchange(url = "https://echo.zuplo.io")
public interface EchoService {

    @PostExchange
    Map<?, ?> echo(@RequestBody Map<String, String> message);

}

Com o Boot cuidando da auto-configuração, basta injetar EchoService onde for necessário: não há mais RestClient ou WebClient manual para montar chamada HTTP simples entre serviços.

Observabilidade muda de forma, não só de nome

Três áreas de 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 → mudaram de comportamento, não só de propriedade. Vale mapear cada uma separadamente porque o impacto é diferente.

A mudança no SSL health é a mais sutil das três porque o status antigo (WILL_EXPIRE_SOON) simplesmente some do vocabulário, sem aviso em tempo de execução. Quem tem regra de alerta baseada em string de status precisa reescrever a condição antes de migrar, não depois.

Quando faz sentido travar a versão em vez de migrar

O upgrade de 3.5 para 4.0 compensa quando o serviço já está num caminho razoavelmente limpo de auto-configuração padrão, sem herança de classes internas do Boot e sem customização pesada de Jackson 2. Nesse perfil, o ganho em API Versioning nativo, HTTP Service Clients e o starter de OpenTelemetry costuma pagar o custo de migração em poucas sprints.

Faz mais sentido travar a versão em 3.5 por um ciclo quando o serviço tem três características ao mesmo tempo: módulos de serialização Jackson 2 customizados e testados a fundo, alguma dependência (interna ou de terceiros) que estende classe de auto-configuração do Boot, e squad pequeno sem folga para revisar propriedade por propriedade antes do deploy. Nesse caso, o caminho mais seguro é tratar o 4.0 como um épico de débito técnico dedicado, não como patch de rotina: rodando mvn dependency:tree ou ./gradlew dependencies antes para mapear onde o Jackson 2 e as classes de auto-configuração aparecem na árvore de dependências reais do projeto.

Fonte

1. Spring Boot 4.0 Release Notes (projeto oficial), wiki do projeto spring-projects/spring-boot, atualizada em 16 de setembro de 2026 por Andy Wilkinson: https://github.com/spring-projects/spring-boot/wiki/Spring-Boot-4.0-Release-Notes

Fonte: Spring Boot 4.0 Release Notes (projeto oficial)