Día 12 de 30 Fase 3: El Salto a Spring Boot 3 y APIs REST

El Contenedor de Beans de Spring Boot 3 e Inyección Idiomática

ApplicationContext, Component Scanning, Requisitos de Java 17 y Compatibilidad con Java 21

Para dominar. Al terminar deberías poder hacerlo sin ayuda.

3.5h de estudio
5 conceptos
3 preguntas
1 katas

Java 17 LTSJava 21 LTSSpring Boot 3ApplicationContextBeans@Service@ConfigurationProperties

Al terminar este día sabrás 4

Explicar por qué Spring Boot 3 exige Java 17 y qué cambió con Jakarta EE.
Describir el ciclo de vida de un bean, desde el escaneo hasta su destrucción.
Declarar beans propios y de terceros con inyección por constructor idiomática.
Leer configuración tipada e inmutable con @ConfigurationProperties y records.

Concepto 1 de 5

Spring Boot 3 Exige Java 17 LTS como Base Mínima

Spring Boot 3 abandonó Java 8 y 11. El estándar empresarial mínimo de Spring hoy es Java 17, permitiendo usar records y características modernas en todo el framework.

En una línea En pom.xml: <java.version>17</java.version> o <java.version>21</java.version>.

Comprobar versiones en arranque java

@SpringBootApplication
public class TaskFlowApplication {

    public static void main(String[] args) {
        SpringApplication.run(TaskFlowApplication.class, args);
    }

    @Bean
    ApplicationRunner informarVersiones(Environment env) {
        return args -> {
            System.out.println("Java " + Runtime.version());
            System.out.println("Spring Boot " + SpringBootVersion.getVersion());
            System.out.println("Hilos virtuales: " + env.getProperty("spring.threads.virtual.enabled", "false"));
        };
    }
}

Cómo funciona por dentro

Spring Boot 3 está construido sobre Spring Framework 6, que fijó Java 17 como versión mínima. No es un capricho: el código del framework usa records, sealed, text blocks y otras APIs del JDK 17, y se compila a bytecode de versión 61. Una JVM 11 no puede ni cargar esas clases.

Esa base permitió otros cambios de fondo: el salto a Jakarta EE 9+ (paquetes jakarta.*), la compilación anticipada (AOT) para generar imágenes nativas con GraalVM, la observabilidad con Micrometer integrada y, a partir de Spring Boot 3.2 con Java 21, el soporte de Virtual Threads.

En la práctica, en un proyecto nuevo se elige Java 21 (la LTS más reciente con soporte amplio) y Spring Boot 3.x. Java 17 sigue siendo el mínimo y es lo habitual en empresas que aún no han migrado.

Si aplicas a un puesto de Spring Boot 3, debes dominar como mínimo Java 17.

Intentar compilar Spring Boot 3 con Java 11 o paquetes antiguos javax.* en lugar de jakarta.*.

Se conecta con Jakarta EESpring Framework 6Migración

El ApplicationContext y el Ciclo de Vida de los Beans

El contenedor de Spring gestiona la creación, configuración y destrucción de tus objetos (Beans). Por defecto crea una única instancia por bean (Singleton Scope).

En una línea @Service public class TareaServicio { ... } administrado automáticamente.

Ganchos del ciclo de vida java

@Component
public class CatalogoEtiquetas {
    private final EtiquetaRepository repo;
    private volatile Set<String> etiquetas = Set.of();   // estado global, no de petición

    CatalogoEtiquetas(EtiquetaRepository repo) {          // 1. instanciación con dependencias
        this.repo = repo;
        System.out.println("constructor");
    }

    @PostConstruct                                        // 2. dependencias ya inyectadas
    void cargar() {
        etiquetas = Set.copyOf(repo.todas());
        System.out.println("cargadas " + etiquetas.size() + " etiquetas");
    }

    @EventListener(ApplicationReadyEvent.class)           // 3. la aplicación ya acepta tráfico
    void listo() {
        System.out.println("aplicación lista");
    }

    @PreDestroy                                           // 4. al cerrar el contexto
    void liberar() {
        System.out.println("liberando recursos");
    }
}

Cómo funciona por dentro

Al arrancar, Spring Boot crea un ApplicationContext. Primero registra definiciones de beans: las clases anotadas que encuentra al escanear el paquete de tu clase principal (@Component, @Service, @Repository, @Controller, @Configuration), los métodos @Bean y las autoconfiguraciones que se activan según lo que haya en el classpath.

Después, para cada bean singleton: lo instancia (llamando al constructor con sus dependencias ya resueltas), aplica los BeanPostProcessor (aquí es donde Spring envuelve tu objeto en un proxy si tiene @Transactional, @Async o @Cacheable), ejecuta los métodos @PostConstruct y lo deja listo. Al cerrar el contexto, ejecuta los @PreDestroy en orden inverso.

El ámbito por defecto es singleton: una sola instancia por contexto, compartida por todos. Por eso un bean no debe guardar estado de una petición concreta en sus campos: varias peticiones lo usan a la vez desde hilos distintos.

Automatiza todo el cableado manual que hicimos en el Día 6 en el método main().

Se conecta con IoCInyección por ConstructorSpring Core

Inyección por Constructor sin Anotaciones Innecesarias

En Spring moderno, si una clase tiene un solo constructor, Spring inyecta las dependencias automáticamente sin necesidad de @Autowired.

En una línea public MiClase(Dependencia dep) { this.dep = dep; }

Beans propios y de terceros java

@Service
public class TareaService {                       // sin @Autowired: un único constructor
    private final TareaRepository repo;
    private final Notificador notificador;
    private final Clock reloj;

    TareaService(TareaRepository repo, Notificador notificador, Clock reloj) {
        this.repo = repo;
        this.notificador = notificador;
        this.reloj = reloj;
    }
}

@Configuration
class InfraestructuraConfig {

    @Bean
    Clock reloj() {                               // clase del JDK: no se puede anotar
        return Clock.systemUTC();
    }

    @Bean
    RestClient githubClient(RestClient.Builder builder) {   // el builder lo autoconfigura Boot
        return builder.baseUrl("https://api.github.com").build();
    }

    @Bean
    @Primary
    Notificador notificadorEmail(JavaMailSender mail) { return new NotificadorEmail(mail); }

    @Bean
    Notificador notificadorSlack(RestClient.Builder b) { return new NotificadorSlack(b); }
}

Cómo funciona por dentro

Desde Spring 4.3, si una clase tiene un único constructor, Spring lo usa para inyectar sin necesidad de @Autowired. Combinado con campos final, el resultado es una clase que no depende de Spring en absoluto salvo por la anotación de estereotipo, y que puedes crear con new en un test.

Cuando la clase que quieres convertir en bean no es tuya (un cliente HTTP, un Clock, un ObjectMapper personalizado), no puedes anotarla. Para eso existen los métodos @Bean dentro de una clase @Configuration: el método construye el objeto y Spring lo registra. Los parámetros del método también se inyectan.

Si hay varias implementaciones de la misma interfaz, Spring no sabe cuál elegir y falla al arrancar. Se resuelve con @Primary en la implementación por defecto, con @Qualifier en el punto de inyección, o inyectando List<Interfaz> para recibirlas todas.

Mantiene el código desacoplado de anotaciones de Spring en la firma de la clase.

Llenar los atributos con @Autowired private Servicio s; por inercia.

Se conecta con InmutabilidadClean ArchitectureTesting

Configuración Tipada con @ConfigurationProperties y Records

Spring Boot 3 permite vincular propiedades de application.yml directamente a un record Java inmutable.

En una línea @ConfigurationProperties(prefix = "app.mail") public record MailConfig(String host, int port) {}

Configuración tipada, inmutable y validada java

@ConfigurationProperties(prefix = "taskflow")
@Validated
public record TaskFlowProperties(
        @Min(1) @Max(500) int maxTareasPorProyecto,
        @NotNull Duration expiracionToken,
        @NotEmpty List<String> dominiosPermitidos,
        Notificaciones notificaciones) {

    public record Notificaciones(boolean email, @Email String remitente) {}
}

@SpringBootApplication
@ConfigurationPropertiesScan          // registra los records anotados
public class TaskFlowApplication { }

// application.yml
// taskflow:
//   max-tareas-por-proyecto: 200
//   expiracion-token: 30m
//   dominios-permitidos: [acme.com, acme.es]
//   notificaciones:
//     email: true
//     remitente: no-reply@acme.com

Cómo funciona por dentro

@Value("${...}") lee propiedades sueltas como cadenas y las convierte, pero dispersa la configuración por el código, no se valida y no tiene autocompletado. @ConfigurationProperties agrupa un prefijo de configuración en un tipo Java. Con un record, el binding se hace por constructor y el objeto resultante es inmutable.

Spring Boot aplica binding relajado: taskflow.max-tareas-por-proyecto, TASKFLOW_MAXTAREASPORPROYECTO como variable de entorno o taskflow.maxTareasPorProyecto acaban en el mismo componente. Convierte tipos útiles como Duration (30s, 5m), DataSize (10MB), listas y mapas.

Con @Validated y anotaciones de Bean Validation en los componentes, la aplicación no arranca si la configuración es inválida: es mucho mejor fallar al desplegar que a las tres de la mañana cuando se usa el valor por primera vez.

Elimina anotaciones sueltas @Value("${prop}") y valida la configuración al arrancar la app.

Usar @Value con nombres de propiedades con erratas que fallan silenciosamente en producción.

Se conecta con application.ymlRecordsValidación

Paquetes `jakarta.` frente al antiguo `javax.`

En Spring Boot 3 y Java 17+, todos los paquetes de Java EE pasaron a llamarse Jakarta (jakarta.persistence.*, jakarta.validation.*).

En una línea import jakarta.annotation.PostConstruct;

Qué cambia y qué no java

// Spring Boot 2.x (Java EE 8)          // Spring Boot 3.x (Jakarta EE 10)
// import javax.persistence.Entity;     import jakarta.persistence.Entity;
// import javax.validation.Valid;       import jakarta.validation.Valid;
// import javax.servlet.Filter;         import jakarta.servlet.Filter;

// Siguen en javax porque pertenecen al JDK, no a Java EE:
import javax.sql.DataSource;
import javax.crypto.Cipher;
import javax.net.ssl.SSLContext;

/*
  Migración automática con OpenRewrite:
  ./mvnw -U org.openrewrite.maven:rewrite-maven-plugin:run \
    -Drewrite.recipeArtifactCoordinates=org.openrewrite.recipe:rewrite-spring:RELEASE \
    -Drewrite.activeRecipes=org.openrewrite.java.spring.boot3.UpgradeSpringBoot_3_3
*/

Cómo funciona por dentro

Java EE (Servlet, JPA, Bean Validation, JAX-RS...) pasó de Oracle a la Fundación Eclipse con el nombre Jakarta EE. Por motivos de marca registrada, Oracle no permitió seguir evolucionando el espacio de nombres javax, así que Jakarta EE 9 renombró todos los paquetes de javax.* a jakarta.*. Funcionalmente las APIs eran las mismas; solo cambió el nombre.

Spring Boot 3 usa Jakarta EE 10. Eso implica que cualquier import javax.persistence.Entity o javax.validation.constraints.NotNull debe pasar a jakarta.*, y que las librerías de terceros tienen que tener una versión compatible con Jakarta. Ojo: no todo javax cambió. Lo que forma parte del JDK (javax.sql.DataSource, javax.crypto, javax.net.ssl) sigue igual.

Para migrar proyectos grandes, OpenRewrite tiene recetas que hacen el cambio de imports, dependencias y propiedades automáticamente.

Cualquier código o tutorial antiguo que use javax.persistence fallará al compilar en Spring Boot 3.

Importar javax.validation.constraints.NotNull en vez de jakarta.validation.constraints.NotNull.

Se conecta con Jakarta EE 10Spring Boot 3Hibernate 6

Cuatro bloques cronometrados. No pases al siguiente sin tener el resultado esperado.

Bloque 1: Arquitectura Spring Boot 3 (0 - 25 min)

Qué estudiar. ApplicationContext, Bean lifecycle, y el requisito de Java 17/21.

Pregunta a responder. ¿Por qué @SpringBootApplication agrupa 3 anotaciones clave?

Resultado esperado. Proyecto en start.spring.io con Spring Boot 3.2+ y Java 17 o 21 verificado.
Bloque 2: Inyección por Constructor Idiomática (25 - 50 min)

Qué estudiar. Creación de capas Controller -> Service -> Repository sin un solo @Autowired.

Pregunta a responder. ¿Cómo resuelve Spring las dependencias cuando hay una única interfaz y dos implementaciones (@Primary, @Qualifier)?

Resultado esperado. Servicio inyectado limpiamente con variables final.
Bloque 3: Configuración con Records (50 - 80 min)

Qué estudiar. Uso de @ConfigurationProperties vinculado a un record.

Pregunta a responder. ¿Cómo leer propiedades de application.yml de forma inmutable y fuertemente tipada?

Resultado esperado. Record de configuración tipado y validado en el arranque.
Cierre y Consolidación (80 - 90 min)

Qué estudiar. Repaso activo del ciclo de vida de los beans.

Pregunta a responder. Explicar qué hace @PostConstruct y @PreDestroy.

Resultado esperado. Notas de estudio registradas en la app local.

Tres formas de comprobar si lo has entendido, de menos a más exigente: explicarlo con tus palabras, responder preguntas trampa y resolver el reto del tutor.

Explícalo desde cero

Lee cada ficha y explícala en voz alta antes de seguir: si puedes contárselo a alguien que empieza, lo has entendido.

Cómo encuentra Spring tus Beans (@ComponentScan)

Lo que debes entender

@SpringBootApplication contiene @ComponentScan. Al arrancar, escanea el paquete actual hacia abajo buscando @Component, @Service, @Repository y @RestController para registrarlos en el grafo de dependencias.

Analogía para contarlo

Un radar que solo barre el piso en el que está colocado y los pisos inferiores del edificio; si pones un objeto en la terraza superior, no lo detecta.

Lo que suele explicarse mal

Pensar que Spring "adivina" o busca en todo el disco duro. Si creas una clase en un paquete superior fuera de la jerarquía de la clase Application, Spring no la verá.

Señal de que aún no lo dominas

Si no sabes por qué Spring lanza NoSuchBeanDefinitionException al mover una clase de paquete.

Preguntas trampa

Responde de memoria, en voz alta o por escrito, y después abre la respuesta razonada: lo importante es el porqué, no la palabra exacta.

Nivel 1 (Básico) ¿Por qué Spring Boot 3 no permite arrancar aplicaciones con Java 8 o Java 11? Ver respuesta

Respuesta razonada

Porque las clases de Spring Framework 6 y Spring Boot 3 están compiladas para Java 17 (bytecode versión 61). Una JVM 8 (versión 52) o 11 (versión 55) se niega a cargarlas y la aplicación falla nada más arrancar con UnsupportedClassVersionError. No es una comprobación artificial: el framework usa internamente APIs y características que no existen en esas versiones.

Subir la versión mínima permitió además simplificar el código del framework, adoptar Jakarta EE 9+ y habilitar AOT y GraalVM. Si un sistema está atado a Java 11, debe quedarse en Spring Boot 2.7, que ya no tiene soporte gratuito.

Qué está evaluando la pregunta

Porque Spring Framework 6 fue compilado con target de Java 17 y migró la especificación corporativa a Jakarta EE 10, requiriendo un JDK 17 o superior como baseline.

Nivel 2 (Intermedio) ¿Qué diferencia práctica hay entre @Component, @Service y @Repository en Spring? Ver respuesta

Respuesta razonada

Las cuatro son estereotipos: anotaciones meta-anotadas con @Component, así que el escaneo las detecta igual y todas crean un bean singleton. La diferencia está en la intención y en algún comportamiento extra.

@Service es puramente semántica: marca lógica de negocio y no añade comportamiento. @Repository sí añade algo: el PersistenceExceptionTranslationPostProcessor envuelve el bean para traducir excepciones nativas de JPA, Hibernate o JDBC a la jerarquía DataAccessException de Spring. @Controller y @RestController hacen que Spring MVC busque en ellos métodos @GetMapping, @PostMapping, etc. Usar el estereotipo correcto documenta la arquitectura y permite aplicar aspectos por capa.

Qué está evaluando la pregunta

En tiempo de ejecución son prácticamente iguales (todas son especializaciones de @Component), pero @Repository añade traducción automática de excepciones de base de datos a DataAccessException, y @Service comunica semántica de capa de negocio.

Nivel 3 (Entrevista Senior) ¿Cómo activas Virtual Threads de Java 21 en una aplicación Spring Boot 3.2+ y qué cambia internamente en Tomcat? Ver respuesta

Respuesta razonada

Con Java 21 y Spring Boot 3.2 o superior basta con spring.threads.virtual.enabled=true en la configuración. Internamente, Tomcat deja de usar su pool de hilos de plataforma (200 por defecto) y pasa a usar un ejecutor que crea un hilo virtual por petición. También se configuran con hilos virtuales el TaskExecutor de @Async, el planificador de @Scheduled y los listeners de Kafka y RabbitMQ.

El efecto es que las peticiones que esperan a E/S (base de datos, llamadas HTTP) ya no bloquean un hilo real, así que la aplicación aguanta muchas más peticiones concurrentes sin aumentar memoria. Hay que vigilar tres cosas: el pinning por bloques synchronized que hacen E/S (mejorado en Java 24), el abuso de ThreadLocal (cada hilo virtual tiene el suyo) y que el pool de conexiones a la base de datos pasa a ser el verdadero límite.

Qué está evaluando la pregunta

Con spring.threads.virtual.enabled=true. Internamente, el TomcatProtocolHandler sustituye su pool de hilos de plataforma por un Executors.newVirtualThreadPerTaskExecutor(), atendiendo cada petición HTTP en un Virtual Thread efímero.

Reto del tutor

Un desarrollador júnior dice: "Tengo un bean con @Scope("prototype") y otro con @Scope("singleton"). Si inyecto el Prototype dentro del Singleton, cada petición web obtendrá una instancia nueva del Prototype". ¿Es correcto?

Tu respuesta (se guarda en este navegador)

Lo que una respuesta suele tener bien

Reconoce que Prototype genera instancias nuevas al solicitarse al contenedor.

Lo que suele quedarse en la superficie

Decir que "sí, porque es prototype".

El concepto de fondo que suele faltar

No entender que el Singleton solo se instancia UNA vez al arrancar la app; en ese momento se le inyecta el Prototype y ese mismo Prototype quedará fijado para siempre dentro del Singleton.

Cómo lo respondería alguien senior en una entrevista

Es completamente FALSO (el clásico "problema del bean scoping"). El Singleton se inicializa una sola vez; por tanto, la inyección del Prototype ocurre una sola vez. Cada petición web usará la misma instancia inyectada al inicio. Para resolverlo se debe usar un ObjectProvider<MiPrototype>, @Lookup o rediseñar la arquitectura evitando beans con estado mutable.

Proyecto «Pedidos» · paso 12 de 30

Pasar a Spring Boot 3

Dejar que Spring cree y conecte los componentes que hasta ahora ensamblabas a mano.

De qué va el proyecto

El backend de una tienda online: clientes, catálogo de productos y pedidos con sus líneas, pagos y envíos. Empieza como un proyecto Maven con records y termina como un sistema con API REST, seguridad, mensajería, contenedores y observabilidad. Cada paso construye sobre el anterior, así que trabaja siempre en el mismo repositorio.

Qué hacer

Convierte el proyecto en una aplicación Spring Boot 3 y elimina el ensamblado manual del main.
Mueve las comisiones de cada medio de pago a application.yml y léelas con @ConfigurationProperties sobre un record.
Crea los perfiles dev (H2) y prod (PostgreSQL).

Está listo cuando

La aplicación arranca con ./mvnw spring-boot:run y el perfil dev sin configuración extra.
Ningún componente usa @Autowired sobre campos.

He terminado este paso Llevas 0 de 30 pasos del proyecto.

Katas: ejercicios cortos

Kata 12.1: Inyección limpia en Spring Boot 3 Crea una aplicación Spring Boot 3 con un @RestController y un @Service. Inyecta el servicio en el controlador sin usar @Autowired, usando únicamente constructor y variables final.

Reglas de oro

Usa siempre inyección por constructor sobre campos private final; evita @Autowired en atributos.
Importa siempre jakarta.*, jamás el obsoleto javax.*.
En Java 21 activa Virtual Threads para maximizar el throughput HTTP de Tomcat.

Java 17 frente a Java 21

Característica	Java 17 LTS	Java 21 LTS
Versión mínima requerida	Obligatoria en Spring Boot 3	Completamente soportada
Virtual Threads integrados	No disponible	Disponible con `spring.threads.virtual.enabled=true`

Notas del día 12 Se guarda automáticamente

Fuentes oficiales

Revisado el 29 de octubre de 2026. Este día en Markdown

Bloque 1: Arquitectura Spring Boot 3 (0 - 25 min)

Bloque 2: Inyección por Constructor Idiomática (25 - 50 min)

Bloque 3: Configuración con Records (50 - 80 min)

Cierre y Consolidación (80 - 90 min)

Explícalo desde cero

Cómo encuentra Spring tus Beans (@ComponentScan)

Lo que debes entender

Analogía para contarlo

Lo que suele explicarse mal

Señal de que aún no lo dominas

Preguntas trampa

Respuesta razonada

Qué está evaluando la pregunta

Respuesta razonada

Qué está evaluando la pregunta

Respuesta razonada

Qué está evaluando la pregunta

Reto del tutor

Lo que una respuesta suele tener bien

Lo que suele quedarse en la superficie

El concepto de fondo que suele faltar

Cómo lo respondería alguien senior en una entrevista

Pasar a Spring Boot 3

Qué hacer

Está listo cuando

Katas: ejercicios cortos

Reglas de oro

Java 17 frente a Java 21

Fuentes oficiales