Artigo sobre Spring Boot EOL.
Por que o EOL do Spring Boot 3.5 é diferente do que você imagina
Primeiro, um ajuste de expectativa. EOL não significa que o Spring Boot 3.5 vai parar de funcionar no dia 30/06. Seu servidor não vai cair na virada da meia-noite. O problema é mais silencioso, e por isso mais perigoso.
Depois do EOL, a equipe do Spring não vai mais emitir CVE advisories oficiais para o Spring Boot 3.5. Eles continuam monitorando vulnerabilidades, sim, mas as comunicações, os patches e as correções vão exclusivamente para as versões ativas. E o que acontece com as vulnerabilidades que aparecem depois? Ficam sem nota oficial, sem patch, sem nada.
Isso já aconteceu antes. O Spring Boot 2.7 entrou em EOL em novembro de 2023. Em 2024, surgiu o CVE-2024-38807, uma vulnerabilidade de path traversal em apps Boot 2.7 usando arquivos de propriedades externos. Resultado: sem patch open-source. Quem ainda rodava Boot 2.7 teve que lidar com isso na raça, seja migrando na pressa, seja pagando suporte comercial.
O seu scanner de dependências (Snyk, OWASP Dependency Check, Trivy) vai continuar apontando vulnerabilidades na sua biblioteca de dependências, mas sem o advisory oficial do Spring, o severity score pode aparecer incorreto ou incompleto. Você fica dependendo de fontes externas para saber se está exposto.
No meu último projeto como Tech Leader, uma app legada ficou 4 meses além do EOL de uma lib porque estava funcionando. Foram 4 meses de risco desconhecido, e a descoberta de um CVE crítico foi o que forçou uma migração de emergência, no pior momento possível: na véspera de um release importante. Não repita isso.
A lição é simples: o EOL não é um alarme que dispara. É um silêncio que começa. E silêncio em segurança é o pior tipo de sinal.
O que muda do Spring Boot 3.5 para o 4: o checklist real de breaking changes
Agora sim a parte prática. O Spring Boot 4 traz mudanças em 4 áreas principais. Veja cada uma e avalie o impacto no seu projeto.
1. Jackson 2 vira Jackson 3: mudança de pacote
Essa é a que mais pega de surpresa. O Jackson 3 (incluído no Spring Boot 4) mudou o pacote base de com.fasterxml.jackson para tools.jackson. Qualquer import direto de Jackson no seu código vai quebrar na compilação.
// ANTES: Jackson 2 com Spring Boot 3.x
import com.fasterxml.jackson.databind.ObjectMapper;
import com.fasterxml.jackson.databind.SerializationFeature;
import com.fasterxml.jackson.datatype.jsr310.JavaTimeModule;
@Configuration
public class JacksonConfig {
@Bean
public ObjectMapper objectMapper() {
ObjectMapper mapper = new ObjectMapper();
mapper.configure(SerializationFeature.WRITE_DATES_AS_TIMESTAMPS, false);
mapper.registerModule(new JavaTimeModule());
return mapper;
}
}
// DEPOIS: Jackson 3 com Spring Boot 4.x
import tools.jackson.databind.ObjectMapper;
import tools.jackson.databind.json.JsonMapper;
// JavaTimeModule é incluído automaticamente no Jackson 3
@Configuration
public class JacksonConfig {
@Bean
public ObjectMapper objectMapper() {
return JsonMapper.builder()
.findAndAddModules()
.build();
}
}
Script de busca rápida para descobrir quantas classes precisam ser atualizadas:
grep -r "com.fasterxml.jackson" src/ --include="*.java" | wc -l
2. Propriedades renomeadas e removidas
O Spring Boot 4 removeu todas as propriedades deprecated das versões 2.x e 3.x. Se você usava compatibilidade legada com spring.mvc.servlet.path ou spring.datasource.initialization-mode, elas simplesmente param de funcionar sem erro explícito.
./mvnw spring-boot:run -Dspring.jmx.enabled=true 2&1 | grep "was deprecated"
3. Tomcat 11 e Jakarta EE 11
O Spring Boot 4 usa Tomcat 11. A maioria das apps que já migrou para Boot 3 não vai sentir impacto. Mas se você usa classes internas do Tomcat em projetos legados, vai precisar revisar.
4. Spring Security: configuração SecurityFilterChain
No Spring Boot 3, a configuração via WebSecurityConfigurerAdapter já estava deprecated. No Boot 4, foi removida de vez.
// JEITO ERRADO: funciona no Boot 3, quebra no Boot 4
@Configuration
public class SecurityConfig extends WebSecurityConfigurerAdapter {
@Override
protected void configure(HttpSecurity http) throws Exception {
http.authorizeRequests()
.antMatchers("/public/**").permitAll()
.anyRequest().authenticated();
}
}
// JEITO CERTO: SecurityFilterChain (funciona no Boot 3.x e 4.x)
@Configuration
@EnableWebSecurity
public class SecurityConfig {
@Bean
public SecurityFilterChain filterChain(HttpSecurity http) throws Exception {
http
.authorizeHttpRequests(auth -> auth
.requestMatchers("/public/**").permitAll()
.anyRequest().authenticated()
)
.httpBasic(Customizer.withDefaults());
return http.build();
}
}
Migração por fases: como evitar o big bang
Fase 1 (nesse sprint): eliminar os deprecated warnings
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<configuration>
<compilerArgs>
<arg>-Xlint:deprecation</arg>
</compilerArgs>
</configuration>
</plugin>
Fase 2 (próximo sprint): centralizar o ObjectMapper
Antes de migrar o Jackson 2 para 3, centraliza todo uso de ObjectMapper em um único bean. Isso reduz o esforço da migração real de N classes para 1.
Fase 3 (antes do merge): bump para Spring Boot 4
<parent>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-parent</artifactId>
<version>4.0.0</version>
</parent>
Fase 4 (pós-merge): validação em homologação
Roda a suite de testes completa em homologação com Boot 4. Esse processo, feito em paralelo com o desenvolvimento normal, costuma levar 2 a 3 sprints.
O que ajustar no CI/CD e nas dependências
Verifica se todas as suas libs de terceiros têm versão compatível com Spring Boot 4. Use o BOM oficial do Spring Boot 4 como referência. O Migration Guide oficial tem a lista completa de propriedades removidas. Temos um guia completo sobre CI/CD com Spring Boot, Docker e Kubernetes.
Java 21 ainda está bom para o Boot 4?
Sim. O Spring Boot 4 suporta Java 17, 21 e 25. Faz o bump do Spring Boot primeiro, estabiliza, depois avalia o upgrade de Java separadamente. Temos um artigo sobre Virtual Threads no Java 21 com Spring Boot quando você chegar lá.
Conclusão: 31 dias para agir, não para esperar
- Hoje: roda o projeto com
-Xlint:deprecatione mapeia o que precisa ser atualizado - Esse sprint: elimina os deprecated warnings e centraliza o ObjectMapper
- Próximo sprint: faz o bump para Spring Boot 4.0.0 e resolve os erros de compilação
Você já está planejando essa migração na sua empresa? Sua stack ainda está no Boot 3 por algum motivo específico? Conta nos comentários, quero saber em qual fase do ciclo de migração a galera está.
Na próxima semana: como lidar com o Spring AI 2.0 que acabou de sair do milestone e agora exige Spring Boot 4 como base.
FAQ: Dúvidas frequentes sobre o EOL do Spring Boot 3.5
O Spring Boot 3.5 vai continuar funcionando depois de junho de 2026?
Sim, vai continuar funcionando. EOL não significa que o software para de executar. Significa que a equipe do Spring não vai mais lançar patches de segurança, correções de bug ou atualizações para essa versão.
O que acontece com os CVEs descobertos depois do EOL?
Você pode ter CVEs ativos no sistema sem saber, porque o canal de comunicação oficial seca. O precedente do Boot 2.7 com o CVE-2024-38807 mostra exatamente esse cenário.
Preciso migrar para Java 25 junto com o Spring Boot 4?
Não. O Spring Boot 4 suporta Java 17, 21 e 25. Faz o upgrade de Java em etapa separada, quando a equipe estiver pronta.
O Spring AI 2.0 realmente exige Spring Boot 4?
Sim. O Spring AI 2.0 GA, lançado em 28/05/2026, requer Spring Boot 4.0 e Java 17+.