TL;DR

• Spring Boot 4 + Spring Framework 7 sortent en novembre 2025. C'est la plus grosse mise a jour depuis Spring Boot 3 et la migration vers Jakarta EE.
• Nouvelle baseline : JDK 25, Jakarta EE 11, Hibernate 7. Si tu es sur JDK 17, il faut sauter deux versions majeures de Java.
• Les features marquantes : API versioning natif, declarative HTTP interface clients, Jackson 3, Spring Security 7, BeanRegistrar.
• La migration depuis Boot 3 est plus douce que la migration Boot 2 vers 3 (pas de changement de namespace javax vers jakarta cette fois).
• Les virtual threads sont desormais le defaut pour Tomcat. Le modele thread-per-request revit.
• Mon avis : si tu es encore sur Boot 2, c'est maintenant ou jamais. La fenetre de migration se referme.

Le contexte : pourquoi maintenant

Spring Boot 3 est sorti fin 2022. Trois ans plus tard, Spring Boot 4 arrive avec Spring Boot 4 et Spring Framework 7. C'est un cycle de release plus long que d'habitude, et ca se sent : la quantite de changements est massive.

La raison principale de ce timing, c'est Java. JDK 25 est la LTS de septembre 2025, et elle apporte des fonctionnalites que Spring attendait pour justifier un bump de baseline : les virtual threads stabilises, les pattern matching complets, les records avances, et les scoped values.

Spring a toujours ete conservative sur les baselines JDK. Passer de JDK 17 (Boot 3) a JDK 25 (Boot 4) directement, c'est un saut de 8 versions. Mais les gains sont reels.

Ce qui change : les features majeures

API Versioning natif

C'est probablement la feature la plus demandee depuis 10 ans. Spring Boot 4 integre un support natif du versioning d'API. Plus besoin de bricolage avec des headers custom ou des prefixes d'URL.

@RestController
@RequestMapping("/api/users")
public class UserController {

    @GetMapping
    @ApiVersion("1")
    public List<UserV1> getUsersV1() {
        return userService.getAllV1();
    }

    @GetMapping
    @ApiVersion("2")
    public List<UserV2> getUsersV2() {
        return userService.getAllV2();
    }
}

// Le client specifie la version via header, query param, ou URL
// Accept: application/vnd.api+json; version=2
// GET /api/users?version=2
// GET /api/v2/users

La strategie de versioning (header, URL, query param) est configurable dans application.properties. Spring genere automatiquement la documentation OpenAPI avec les versions.

Declarative HTTP Interface Clients

Spring Boot 3.2 avait introduit les HTTP interface clients en preview. Boot 4 les stabilise et les rend premiere classe. C'est le remplacement de Feign et RestTemplate pour la communication inter-services.

@HttpExchange("/api")
public interface UserClient {

    @GetExchange("/users/{id}")
    User getUser(@PathVariable Long id);

    @PostExchange("/users")
    User createUser(@RequestBody CreateUserRequest request);

    @DeleteExchange("/users/{id}")
    void deleteUser(@PathVariable Long id);
}

// Spring genere l'implementation au runtime
// Plus besoin de Feign, plus besoin de WebClient mannuel

L'avantage par rapport a Feign : c'est natif Spring, ca supporte WebClient et RestClient, et ca s'integre avec le circuit breaker et le retry de Spring sans configuration supplementaire.

Jackson 3

Spring Boot 4 passe a Jackson 3. C'est un changement de version majeure du serialiseur JSON, et ca implique quelques breaking changes.

Les principaux changements :

• Le package passe de com.fasterxml.jackson a tools.jackson (oui, encore un changement de package)
• Les annotations restent largement compatibles, mais certaines sont renommees
• Les performances sont ameliorees de 15-20% sur la serialisation
• Le support natif des records Java est ameliore
• Les modules (JavaTime, Kotlin, etc.) sont reorganises

Le codemod Spring fournit gere 90% de la migration automatiquement. Les 10% restants sont des cas edge ou tu utilisais des API internes de Jackson.

Spring Security 7

Security 7 simplifie la configuration et durcit les defauts. Le changement le plus visible : la configuration par SecurityFilterChain est desormais la seule option. La vieille approche WebSecurityConfigurerAdapter (deprecated depuis Security 5.7) est supprimee.

@Configuration
@EnableWebSecurity
public class SecurityConfig {

    @Bean
    public SecurityFilterChain filterChain(HttpSecurity http) throws Exception {
        return http
            .authorizeHttpRequests(auth -> auth
                .requestMatchers("/api/public/**").permitAll()
                .requestMatchers("/api/admin/**").hasRole("ADMIN")
                .anyRequest().authenticated()
            )
            .oauth2ResourceServer(oauth2 -> oauth2
                .jwt(jwt -> jwt.decoder(jwtDecoder()))
            )
            .build();
    }
}

Les autres changements notables : CSRF est desactive par defaut sur les API stateless (enfin), le support PASETO est ajoute en alternative a JWT, et la gestion des permissions est simplifiee avec un nouveau DSL.

BeanRegistrar : l'alternative a @Bean

BeanRegistrar est une nouvelle facon de declarer des beans, orientee performance. Au lieu d'annotations scannees au runtime, tu declares les beans programmatiquement.

public class AppBeanRegistrar implements BeanRegistrar {

    @Override
    public void register(BeanRegistry registry) {
        registry.registerBean(UserService.class, spec -> {
            spec.setScope(BeanScope.SINGLETON);
            spec.setLazy(false);
        });
    }
}

L'interet : le startup est plus rapide (pas de classpath scanning), et c'est plus previsible. Pour une application qui demarre en container (Docker, Kubernetes), chaque milliseconde de startup compte. Spring Boot 4 avec BeanRegistrar et les AOT optimisations peut demarrer en moins de 500ms pour une application moyenne.

Modularized Autoconfigure JARs

Les JARs d'autoconfiguration Spring Boot sont desormais modulaires. Au lieu d'un gros spring-boot-autoconfigure qui contient TOUT, chaque module (web, data, security, actuator) a son propre JAR.

Le resultat : un classpath plus propre, des builds plus rapides, et une application qui ne charge que ce dont elle a besoin. C'est particulierement impactant pour GraalVM native image, ou chaque classe chargee augmente le temps de compilation et la taille du binaire.

Virtual Threads : le defaut qui change tout

C'est peut-etre le changement le plus impactant de Spring Boot 4. Les virtual threads (Project Loom) sont desormais le defaut pour Tomcat et Undertow.

Ca signifie que chaque requete HTTP est traitee dans un virtual thread. Tu peux faire du blocking IO (appels base de donnees, HTTP clients, file IO) sans bloquer un thread OS. Le modele thread-per-request, qui etait considere comme obsolete face a l'async/reactive, revient en force.

// Avant (reactive, complexe)
@GetMapping("/users/{id}")
public Mono<User> getUser(@PathVariable Long id) {
    return userRepository.findById(id)
        .flatMap(user -> enrichService.enrich(user));
}

// Maintenant (imperatif, simple, tout aussi performant)
@GetMapping("/users/{id}")
public User getUser(@PathVariable Long id) {
    User user = userRepository.findById(id);
    return enrichService.enrich(user);
}
// Chaque requete tourne dans un virtual thread
// Le blocking IO ne bloque pas le thread OS

Le code imperatif est plus simple a lire, a debugger, et a maintenir. Les virtual threads eliminent le besoin de passer au reactive pour la performance. WebFlux reste disponible pour les cas d'usage avances (backpressure, streaming), mais pour 90% des applications CRUD, le modele classique avec virtual threads suffit.

Spring AI 2.0

Spring AI atteint sa version 2.0 en meme temps que Boot 4. C'est un milestone important : le support des LLM est desormais premiere classe dans l'ecosysteme Spring.

Les points marquants :

• API unifiee pour OpenAI, Anthropic, Ollama, et d'autres providers
• Support natif du RAG (Retrieval Augmented Generation) avec Spring Data
• Function calling integre avec les beans Spring
• Embedding et vector store support (pgvector, Pinecone, Milvus)

Pour les devs Java qui veulent integrer de l'IA dans leurs applications, c'est la voie royale. L'API est idiomatique Spring, la configuration est par properties, et l'injection de dependances fonctionne comme attendu.

La migration depuis Boot 3

La bonne nouvelle : la migration Boot 3 vers Boot 4 est plus douce que la migration Boot 2 vers Boot 3. Pas de changement de namespace javax/jakarta cette fois. Les principaux points de friction :

1. JDK 25 minimum. C'est le plus gros bloqueur. Si ton CI est sur JDK 17, il faut upgrader toute la chaine.

2. Jackson 3. Le changement de package necessite de toucher aux imports. Le codemod gere ca.

3. Hibernate 7. Si tu utilises des API Hibernate specifiques (pas juste JPA), il y a des breaking changes. Les HQL queries avec des syntaxes deprecated sont supprimees.

4. Spring Security 7. Si tu as encore du WebSecurityConfigurerAdapter, c'est le moment de migrer vers SecurityFilterChain.

5. Dependencies tierces. Certaines librairies ne supportent pas encore JDK 25 ou Jakarta EE 11. Verifie tes deps avant de commencer.

# Etape 1 : upgrade le JDK
sdk install java 25-open

# Etape 2 : lance le codemod Spring
npx @openrewrite/cli run org.openrewrite.java.spring.boot4.UpgradeSpringBoot_4_0

# Etape 3 : fix les erreurs de compilation manuellement

# Etape 4 : lance les tests
./gradlew test

# Etape 5 : verifie le startup
./gradlew bootRun

Si tu es sur Boot 2 : c'est maintenant ou jamais

Spring Boot 2 est en fin de support etendu. Plus de patches de securite. Plus de corrections de bugs. Si tu es encore dessus, tu as deux options :

1. Migrer vers Boot 3 puis Boot 4. C'est la voie sure. Boot 2 vers 3 (javax vers jakarta), puis Boot 3 vers 4 (JDK 25, Jackson 3).

2. Migrer directement vers Boot 4. C'est plus risque mais plus rapide. OpenRewrite a des recettes qui font le saut complet.

Mon conseil : si ton application est critique, fais le saut en deux temps. Si c'est un microservice isole avec une bonne couverture de tests, tente le saut direct. Dans les deux cas, ne reste pas sur Boot 2. C'est une dette technique qui s'accumule chaque mois.

Le verdict

Spring Boot 4 est une release qui consolide plutot qu'elle ne revolutionne. Les virtual threads par defaut simplifient le modele de programmation. L'API versioning et les HTTP interface clients comblent des lacunes historiques. La baseline JDK 25 permet d'exploiter les fonctionnalites modernes de Java.

C'est une bonne release. Pas spectaculaire, mais solide. Et c'est exactement ce qu'on attend de Spring : de la stabilite, de la retrocompatibilite quand c'est possible, et des breaking changes justifies quand c'est necessaire.

Si tu fais du Java en entreprise, Spring Boot 4 est la release qui te permet de dire a ton management : "notre stack est moderne." Et parfois, c'est ca le plus important.

Ressources

• Spring Boot 4 Release Notes -- les notes de version officielles
• Spring Framework 7 What's New -- les nouveautes du framework
• Migration Guide Boot 3 to 4 -- le guide officiel
• OpenRewrite Spring Boot 4 Recipes -- migration automatisee
• Virtual Threads in Spring -- le guide complet sur les virtual threads
• Spring AI -- la doc Spring AI