TL;DR
- Spring Boot 4 est prevu pour novembre 2025. C'est la plus grosse release Spring en 5 ans.
- Les nouveautes majeures : API versioning natif, clients HTTP declaratifs, Jackson 3, Spring Security 7.
- Le baseline change : Jakarta EE 11, Hibernate 7, JDK 25. Ca casse la compatibilite avec Boot 3.x.
- La migration depuis Boot 3 sera non triviale mais bien documentee. Spring fournit un guide detaille et un outil de migration.
- Si tu es encore sur Boot 2.x, c'est le moment de planifier serieusement -- le support etendu Boot 2 s'arrete.
Le contexte : pourquoi c'est un evenement
Spring Boot 3.0 est sorti en novembre 2022. Trois ans plus tard, Boot 4 arrive. Entre les deux, on a eu des releases mineures (3.1, 3.2, 3.3, 3.4) qui apportaient des ameliorations incrementales. Boot 4, c'est autre chose. C'est un changement de baseline complet qui embarque trois ans d'evolution de l'ecosysteme Java.
J'ai suivi la serie d'articles "Road to GA" du blog Spring depuis les premieres milestones. Voici un resume de ce qui arrive, ce qui casse, et comment s'y preparer.
Les nouveautes qui comptent
API Versioning natif
C'etait la fonctionnalite la plus demandee depuis des annees. Jusqu'ici, gerer le versioning d'API REST avec Spring, c'etait du bricolage : annotations custom, intercepteurs maison, ou des librairies tierces plus ou moins maintenues.
Boot 4 integre un support natif :
@RestController
@RequestMapping("/api/users")
public class UserController {
@GetMapping
@ApiVersion("1")
public List<UserV1> getUsersV1() {
// Version 1 : champs basiques
}
@GetMapping
@ApiVersion("2")
public List<UserV2> getUsersV2() {
// Version 2 : champs enrichis
}
}
Le routage par version se configure au niveau global -- header, path, query param, ou media type. Plus besoin de reinventer la roue a chaque projet.
Interface HTTP Clients
Les @HttpExchange interfaces, introduites en Boot 3.2, deviennent l'approche recommandee pour les clients HTTP. C'est le remplacement officiel de Feign (et de RestTemplate pour ceux qui n'ont pas encore migre).
@HttpExchange("/api/users")
public interface UserClient {
@GetExchange
List<User> getAll();
@GetExchange("/{id}")
User getById(@PathVariable Long id);
@PostExchange
User create(@RequestBody CreateUserRequest request);
}
L'implementation est generee automatiquement. Tu declares l'interface, Spring genere le client. Ca marche avec RestClient, WebClient, ou meme RestTemplate comme transport.
Jackson 3
Jackson 2 date de 2012. Treize ans plus tard, Jackson 3 arrive avec Boot 4. Les changements majeurs :
- Nouveau package (
tools.jacksonau lieu decom.fasterxml.jackson) - Meilleur support des records Java
- Performance amelioree sur la serialisation de gros objets
- Suppression du code legacy accumule sur 13 ans
Le probleme : c'est un changement de package. Toutes tes annotations @JsonProperty, @JsonIgnore, tes ObjectMapper custom -- tout doit etre mis a jour. Spring Boot 4 fournit un module de compatibilite pour la transition, mais a terme, il faudra migrer.
Spring Security 7
Security 7 est une refonte significative. Les points importants :
- Nouveau modele d'autorisation base sur des policies (plus flexible que les roles)
- Support natif de la MFA (Multi-Factor Authentication)
- Configuration simplifiee -- moins de
SecurityFilterChainverbose - Meilleure integration avec OAuth 2.1 et OIDC
@Bean
public SecurityFilterChain filterChain(HttpSecurity http) throws Exception {
return http
.authorizeHttpRequests(auth -> auth
.requestMatchers("/api/public/**").permitAll()
.requestMatchers("/api/admin/**").hasPolicy("admin-access")
.anyRequest().authenticated()
)
.mfa(mfa -> mfa
.defaultMethod(MfaMethod.TOTP)
.rememberDevice(Duration.ofDays(30))
)
.build();
}
La MFA integree, c'est un vrai gain. Jusqu'ici, implementer la MFA avec Spring Security demandait du code custom non trivial.
BeanRegistrar
Nouveau mecanisme pour enregistrer des beans programmatiquement, sans passer par @Configuration classes. C'est utile pour les frameworks et les librairies qui generent des beans dynamiquement.
public class MyBeanRegistrar implements BeanRegistrar {
@Override
public void register(BeanRegistry registry) {
registry.registerBean("myService", MyService.class,
spec -> spec.supplier(MyService::new));
}
}
Ca remplace les patterns de BeanDefinitionRegistryPostProcessor qui etaient verboses et fragiles. Pour la plupart des projets applicatifs, ca ne change rien. Pour les developpeurs de librairies, c'est une simplification bienvenue.
Ce qui casse
Jakarta EE 11 baseline
Boot 3 utilisait Jakarta EE 9/10. Boot 4 passe a Jakarta EE 11. Concretement :
- Servlet 6.1 (au lieu de 6.0)
- JPA 3.2 (au lieu de 3.1)
- Bean Validation 3.1
- CDI 4.1
Si tu as des dependances qui ciblent Jakarta EE 9 ou 10, elles ne seront pas compatibles directement.
Hibernate 7
Boot 4 embarque Hibernate 7 (au lieu de Hibernate 6.x dans Boot 3). Les changements importants :
- Nouveau moteur de metamodel
- API de criteria revue
- Certaines annotations deprecees supprimees (
@Tablegenerator strategies, certains@Typeusages) - Meilleur support des types Java modernes (records, sealed classes)
Si ton projet utilise des features avancees d'Hibernate (custom types, interceptors, listeners), prevois du temps de migration.
JDK 25 minimum
C'est le changement le plus impactant pour les equipes. Boot 4 requiert JDK 25 minimum. Si tu es encore sur JDK 17 ou 21, il faut d'abord migrer la JVM avant de passer a Boot 4.
La bonne nouvelle : JDK 25 est le nouveau LTS, donc c'est un investissement durable. La mauvaise : si ton entreprise met 6 mois a valider un changement de JDK, il faut commencer maintenant.
La strategie de migration
Depuis Boot 3.x
Spring fournit un guide de migration detaille et un outil d'analyse (spring-boot-migrator) qui scanne ton projet et liste les changements necessaires.
Le plan en grandes lignes :
- Migrer vers Boot 3.4 (derniere version 3.x) -- corriger les deprecations
- Passer a JDK 25 -- tester la compatibilite de toutes les dependances
- Migrer Jackson 2 vers 3 -- utiliser le module de compatibilite pendant la transition
- Appliquer la migration Boot 4 -- suivre le guide officiel
- Adapter Spring Security -- revoir la configuration d'autorisation
Depuis Boot 2.x
Si tu es encore sur Boot 2, la situation est plus urgente. Le support etendu de Boot 2 arrive a son terme. La migration directe Boot 2 vers Boot 4 n'est pas recommandee -- il vaut mieux passer par Boot 3 d'abord (javax vers jakarta) puis Boot 4.
C'est un investissement, mais Boot 4 est prevu pour etre supporte jusqu'en 2028 minimum. Ca vaut le coup de planifier proprement.
Mon avis
Spring Boot 4, c'est la plus grosse release Spring en 5 ans. L'API versioning natif et les interface clients comblent des lacunes reelles. Jackson 3 et Security 7 modernisent des couches qui en avaient besoin.
Le cout de migration est reel mais gerable. La plupart des projets Boot 3 standard (REST APIs, Spring Data JPA, Security basic) migreront en quelques jours. Les projets complexes avec du Hibernate custom et du Security avance auront plus de travail.
Le nouveau stack ideal pour fin 2025 : JDK 25 + Spring Boot 4 + Jakarta EE 11 + Hibernate 7. C'est le baseline qui va tenir pour les 3-4 prochaines annees.
Si tu demarres un nouveau projet maintenant, attends Boot 4 GA (novembre 2025) ou commence sur Boot 3.4 avec un plan de migration. Ne demarre pas un nouveau projet sur Boot 2 -- c'est une dette technique immediate.