Spring Boot 4: novedades y migración desde Spring Boot 3

Spring Boot 4 es la versión que acompaña a Spring Framework 7, publicada en noviembre de 2025. Requiere Java 17+, trae @Retryable integrado sin dependencias externas, Virtual Threads activados por defecto en Java 21+ y @HttpServiceClient para clientes HTTP declarativos. Si ya estás en Spring Boot 3, esta guía detalla exactamente qué cambia, por qué importa y cómo planificar la migración sin interrumpir el negocio.

Versiones de Spring Boot: la secuencia correcta

Un punto de confusión frecuente: no existe “Spring Boot 6”. La numeración de Spring Boot y Spring Framework es independiente y no siempre obvia:

Spring Boot	Spring Framework	Java mínimo	Java recomendado	Estado
Spring Boot 2.x	Spring 5.3.x	Java 8	Java 11/17	EOL
Spring Boot 3.x	Spring 6.x	Java 17	Java 21 (LTS)	Mantenimiento
Spring Boot 4.x	Spring 7.x	Java 17	Java 25	Activo

Si alguien te dice que existe “Spring Boot 6”, está confundiendo la numeración de Spring Framework (6, 7) con la de Spring Boot (3, 4). La correspondencia es: Spring Boot 3 usa Spring Framework 6, Spring Boot 4 usa Spring Framework 7.

Novedades principales de Spring Boot 4

Spring Boot 4 hereda todas las novedades de Spring Framework 7 y añade su propia capa de autoconfiguración y gestión de dependencias. Aquí están los cambios con mayor impacto en el día a día del desarrollo.

@Retryable integrado sin dependencias externas

En Spring Boot 3 y anteriores, para añadir reintentos automáticos a un método era obligatorio añadir spring-retry al pom.xml. En Spring Boot 4 (Spring Framework 7), @Retryable es parte del core:

@SpringBootApplication
@EnableRetry   // ← activa el soporte de retry
public class MiApp {
    public static void main(String[] args) {
        SpringApplication.run(MiApp.class, args);
    }
}

@Service
public class PagosService {

    @Retryable(
        retryFor = { TimeoutException.class },
        maxAttempts = 3,
        backoff = @Backoff(delay = 1000, multiplier = 2.0)
    )
    public ResultadoPago procesarPago(Pago pago) {
        return pasarelaExterna.cobrar(pago);  // reintenta en TimeoutException
    }

    @Recover
    public ResultadoPago recuperar(TimeoutException ex, Pago pago) {
        // ejecutado cuando se agotan los 3 intentos
        return ResultadoPago.pendiente(pago.getId());
    }
}

Si ya tenías spring-retry en el pom.xml por esta razón, puedes eliminarlo. Las anotaciones @Retryable, @Recover, @Backoff y @EnableRetry funcionan exactamente igual que antes, pero ahora son parte del framework base.

Para una guía completa con backoff exponencial, testing, RetryTemplate y Actuator, consulta el artículo dedicado: @Retryable en Spring Boot 4.

Virtual Threads nativos con Project Loom

El cambio de rendimiento más significativo de Spring Boot 4 en aplicaciones con alta concurrencia. Los Virtual Threads (hilos virtuales) del Proyecto Loom permiten que la JVM gestione millones de threads con un overhead mínimo, en lugar de depender del SO para cada thread del sistema.

Spring Boot 4 activa el executor de Virtual Threads automáticamente cuando detecta Java 21+:

# application.properties
# Activo por defecto en Java 21+ — no necesitas configurarlo
spring.threads.virtual.enabled=true

¿Qué impacto real tiene? En APIs con mucha I/O (consultas a base de datos, llamadas HTTP a otros microservicios, operaciones de archivo), los threads convencionales pasan la mayor parte del tiempo en espera (bloqueados). Con threads virtuales:

• El hilo virtual se “suspende” durante la espera sin bloquear un thread del SO
• La JVM puede ejecutar miles de threads virtuales concurrentes usando solo decenas de threads del SO
• El resultado: mayor throughput con el mismo hardware sin cambiar el código de negocio

Un microservicio que antes manejaba 200 peticiones concurrentes con 200 threads del SO puede manejar las mismas 200 peticiones con ~10 threads del SO cuando usa Virtual Threads, liberando recursos para otros procesos.

Cuándo NO importan los Virtual Threads: Si tu servicio es CPU-bound (procesamiento de imágenes, cálculos intensivos, algoritmos complejos), los threads virtuales no ayudan — el cuello de botella es la CPU, no la espera de I/O. Tienen máximo impacto en servicios que hacen muchas llamadas externas y esperan las respuestas.

@HttpServiceClient: clientes HTTP declarativos con autoconfiguración

Spring Framework 6 introdujo HTTP Interfaces: podías declarar un cliente HTTP como una interfaz de Java con anotaciones @GetExchange, @PostExchange, etc. El problema es que en Spring Boot 3 tenías que construir el proxy manualmente con HttpServiceProxyFactory.

Spring Boot 4 autoconfigura el cliente directamente si anotas la interfaz con @HttpServiceClient:

// Spring Boot 4: Spring autoconfigura el cliente automáticamente
@HttpServiceClient(url = "${api.inventario.url}")
public interface InventarioClient {

    @GetExchange("/productos/{id}")
    Producto obtenerProducto(@PathVariable String id);

    @PostExchange("/reservas")
    Reserva crearReserva(@RequestBody NuevaReserva reserva);

    @PutExchange("/stock/{id}")
    void actualizarStock(@PathVariable String id, @RequestBody StockUpdate update);

    @DeleteExchange("/reservas/{id}")
    void cancelarReserva(@PathVariable String id);
}

Spring Boot 4 crea automáticamente el bean inventarioClient disponible para inyección en cualquier servicio. No necesitas @Configuration ni HttpServiceProxyFactory. Si necesitas configuración personalizada (timeouts, autenticación, interceptores), puedes proporcionar tu propio WebClient o RestClient con el nombre correcto en el contexto.

// Para configuración avanzada: proporciona tu propio WebClient
@Configuration
public class ClientesConfig {

    @Bean
    public WebClient inventarioWebClient() {
        return WebClient.builder()
            .baseUrl("${api.inventario.url}")
            .defaultHeader("Authorization", "Bearer ${api.inventario.token}")
            .connectTimeout(Duration.ofSeconds(5))
            .build();
    }
}
// Spring Boot 4 usará este WebClient para construir el InventarioClient

Modularización completa y null-safety con JSpecify

Spring Boot 4 adopta JSpecify para anotaciones de null-safety en toda la API pública del framework. El compilador (con herramientas como NullAway o IntelliJ IDEA) puede detectar NullPointerException potenciales en tiempo de compilación sin necesidad de instrumentación en runtime.

// Con JSpecify, el compilador puede advertir sobre este código:
@NullMarked
public class ServicioUsuarios {

    public Usuario buscarUsuario(String email) {
        return repositorio.findByEmail(email);  // puede devolver null
        // ⚠️ El compilador puede advertir si quien llama no verifica null
    }

    public @Nullable Usuario buscarUsuarioOpcional(String email) {
        // @Nullable indica explícitamente que puede devolver null
        return repositorio.findByEmail(email);
    }
}

Para código de aplicación, JSpecify no requiere ninguna acción inmediata. Las APIs públicas del framework están anotadas, lo que mejora la experiencia en IDEs modernos con inspección de null.

Actuator: nuevos endpoints para Virtual Threads y métricas de retry

Spring Boot 4 añade nuevos endpoints de Actuator para introspección del estado de los Virtual Threads y las métricas de retry:

# Verificar si Virtual Threads están activos
curl http://localhost:8080/actuator/info | jq '.java'
# {
#   "version": "21.0.3",
#   "vendor": "Eclipse Adoptium",
#   "runtime": { "name": "OpenJDK Runtime Environment", "version": "21.0.3+9" },
#   "jvm": { "name": "OpenJDK 64-Bit Server VM", "version": "21.0.3+9" }
# }

# Métricas de retry automáticas
curl http://localhost:8080/actuator/metrics/spring.retry.attempts
# {
#   "name": "spring.retry.attempts",
#   "measurements": [{ "statistic": "COUNT", "value": 47.0 }],
#   "availableTags": [
#     { "tag": "class", "values": ["PagosService"] },
#     { "tag": "method", "values": ["procesarPago"] },
#     { "tag": "recovered", "values": ["true", "false"] }
#   ]
# }

Con las métricas de retry puedes construir alertas en Prometheus: si el ratio de recovered=false supera un umbral, puede indicar que el servicio externo está degradado de forma sostenida.

Comparativa Spring Boot 3 vs Spring Boot 4

Área	Spring Boot 3.x	Spring Boot 4.x
Spring Framework	6.x	7.x
Servidor embebido	Tomcat 10.1	Tomcat 11
Servlet API	5.0 (jakarta.*)	6.1 (jakarta.*)
@Retryable	Requiere spring-retry externo	Integrado en el core
Virtual Threads	Manual (spring.threads.virtual.enabled=true)	Activado por defecto en Java 21+
Clientes HTTP	HTTP Interfaces + builder manual	@HttpServiceClient (autoconfigurado)
Null-safety	Sin estándar	JSpecify integrado
Spring Security	6.x	7.x (métodos deprecated eliminados)
Spring Data JPA	3.x + Hibernate 6	4.x + Hibernate 7
Spring Batch	5.x	6.x
@MockBean en tests	@MockBean	@MockitoBean
Namespace	jakarta.*	jakarta.* (sin cambios)

Cómo migrar de Spring Boot 3 a Spring Boot 4

La migración de Spring Boot 3 a Spring Boot 4 es menos traumática que la de Boot 2 a Boot 3 porque no hay cambio de namespace. El principal esfuerzo está en eliminar APIs deprecated de Spring Security y actualizar Tomcat.

Preparación previa (no saltarse este paso)

Antes de cambiar la versión, actualiza a Spring Boot 3.3.x o 3.4.x y activa los warnings de deprecación:

<!-- En maven-compiler-plugin -->
<compilerArgs>
    <arg>-Xlint:deprecation</arg>
</compilerArgs>

Resuelve todos los warnings antes de subir a Boot 4. Cada warning es una API que Spring 7 elimina definitivamente.

Paso 1: Actualizar el parent y Java

<parent>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-parent</artifactId>
    <version>4.0.0</version>
    <relativePath/>
</parent>

<properties>
    <java.version>21</java.version>  <!-- mínimo 17, recomendado 21 para Virtual Threads -->
</properties>

Paso 2: Eliminar spring-retry (si procede)

<!-- ELIMINAR si solo lo usabas para @Retryable -->
<dependency>
    <groupId>org.springframework.retry</groupId>
    <artifactId>spring-retry</artifactId>
</dependency>

Paso 3: Actualizar Spring Security

Spring Security 7 elimina varios métodos deprecated de la versión 5.x. Los cambios más frecuentes:

// ❌ Deprecated en Spring Security 6, eliminado en 7
http.csrf().disable();
http.cors().and();

// ✅ Spring Security 7
http.csrf(csrf -> csrf.disable());
http.cors(cors -> cors.configurationSource(corsSource()));

Paso 4: Actualizar @MockBean en tests

// Spring Boot 3
@MockBean
private ServicioExterno mockServicio;

// Spring Boot 4
@MockitoBean
private ServicioExterno mockServicio;

Cuándo migrar según el estado del proyecto

Situación	Recomendación
Proyecto nuevo	Empieza directamente con Spring Boot 4
Proyecto en Boot 3 activo en producción	Migra en un sprint de infraestructura dedicado; no lo mezcles con features
Proyecto en Boot 3 con Spring Security complejo	Dedica un paso separado solo a Security, con tests de autenticación exhaustivos
Proyecto en Boot 2	Migra primero a Boot 3 (cambio de namespace), luego a Boot 4 en dos fases
Proyecto en Boot 2 con javax.* sin migrar	Prioriza Jakarta EE antes de pensar en Boot 4

Para los pasos detallados con breaking changes de Hibernate, Spring Batch y propiedades renombradas, consulta la guía completa de migración Spring 6 a Spring 7.

Preguntas frecuentes

¿Qué versión de Tomcat trae Spring Boot 4?

Spring Boot 4 incluye Tomcat 11 como servidor embebido predeterminado. Tomcat 11 implementa Servlet API 6.1 con jakarta.*. Si usas Tomcat externo (no embebido), debes actualizar a Tomcat 11 antes o al mismo tiempo que migras a Spring Boot 4.

¿Spring Boot 4 es compatible con Kotlin?

Sí. Spring Boot 4 soporta Kotlin 2.x. Actualiza la versión del plugin de Kotlin en tu build.gradle.kts a 2.1.x o superior cuando migres. Las extensiones de Spring para Kotlin (extensiones de tipo, funciones de extensión) siguen funcionando.

¿Necesito actualizar mis tests al migrar a Boot 4?

El cambio más habitual en tests es reemplazar @MockBean por @MockitoBean. Spring Boot 4 depreca @MockBean a favor de la nomenclatura más explícita de Mockito. El resto de la API de tests (@SpringBootTest, @WebMvcTest, @DataJpaTest, etc.) funciona igual que en Boot 3.

---

Para profundizar en las novedades del framework base: Spring Framework 7 vs Spring 6 — guía comparativa.

¿Necesitas los pasos concretos de migración con checklist y código? Consulta la guía de migración Spring 6 a Spring 7.

---

¿Migras a Spring Boot 4? Si gestionas microservicios Spring en producción y quieres una hoja de ruta que minimice el riesgo operativo, cuéntame tu proyecto — como consultor IT en Mallorca, es mi especialidad.