Spring Boot 4 - What's new in this release?

La sortie de Spring Boot 4 marque une rupture attendue et assumee dans l'ecosysteme Java. Dans la transcription originale, le presentateur parle parfois de "Springwood", mais le contexte est clair: il s'agit bien de Spring Boot 4 et de ses evolutions majeures. Cette version s'appuie sur Spring Framework 7, revoit sa structure interne et propose un socle moderne pour construire des applications et des microservices. L'ambition est d'alleger les dependances, d'apporter de la clarte dans la modularisation, et d'imposer une trajectoire d'upgrade plus saine.

Le ton du contenu source est celui d'une revue guidee: on passe des release notes a la migration guide, puis aux changements pratiques autour des dependances, des starters et des clients HTTP. L'article qui suit ne resserre pas le contenu mais le developpe et l'explique, avec des exemples concrets, des cas d'usage et un focus sur le pourquoi et le comment. L'objectif est de vous donner une vue operationnelle pour planifier une migration, comprendre les impacts et agir sans surprises.

Contexte et vision de la release

Spring Boot 4 est presente comme l'une des plus grosses mises a jour de ces dernieres annees. Pourquoi une telle ampleur? Parce qu'elle repositionne le projet autour d'une modularisation stricte et d'un socle moderne (Spring Framework 7), ce qui implique des changements de dependencies, de starters et de pratiques. Ce n'est pas une simple version mineure: c'est un cap qui vise a eviter l'accumulation de dettes techniques et a mieux separer production et tests.

La transcription insiste sur un point pratique: la version est deja disponible dans Spring Initializr. Cela signifie que les nouveaux projets peuvent demarrer directement avec Spring Boot 4, sans bricolage. Pour un cas d'usage concret, imaginez un nouveau projet microservices: partir d'une base Boot 4 permet de profiter des dernieres conventions, de dependencies rationalisees et d'un pipeline build/test plus clair.

Ce type de release suppose un changement de mentalite. Pourquoi? Parce qu'on ne peut plus s'appuyer sur des APIs deprecies en attendant. La version retire de nombreuses APIs deprecies en 3.x, ce qui force la migration des applications existantes. C'est un effort, mais c'est aussi un nettoyage salutaire qui evite des comportements ambigus et des bibliotheques d'anciennes generations qui trainent.

Socle technique: Spring Framework 7 et Java 17/25

L'un des axes centraux est l'alignement sur Spring Framework 7. Pourquoi est-ce important? Parce que Spring Boot n'est pas qu'un ensemble de starters: il depend du coeur Spring pour la gestion des beans, le web, la securite et l'observabilite. En montant au Framework 7, Boot 4 adopte un socle qui vise la modernite et des chemins d'upgrade plus nets.

Sur la JVM, la version minimale est Java 17, avec un support de Java 25. Cela cree un cadre clair: plus besoin de supporter des versions legacy qui complexifient les builds. Le comment est simple: vos pipelines doivent compiler et tester en Java 17 au minimum. Un cas d'usage typique est une organisation qui veut standardiser son parc d'applications: imposer Java 17 permet de simplifier l'outillage et d'activer les outils modernes de performance et d'observabilite.

Le choix d'un minimum de Java 17 a aussi un impact positif sur les equipes. On peut utiliser des features de langage plus recentes, standardiser des libs compatibles et reduire les incompatibilites. Pour les architectures microservices, cela signifie que tous les services peuvent partager un ensemble coherent d'outils, ce qui simplifie la maintenance et les audits de securite.

// Exemple de configuration Gradle pour Java 17
plugins {
    id "java"
    id "org.springframework.boot" version "4.0.0"
}

java {
    toolchain {
        languageVersion = JavaLanguageVersion.of(17)
    }
}

Modularisation et nouvelles dependances

La modularisation est presentee comme l'un des changements majeurs. Jusqu'ici, certains starters incorporaient a la fois des dependances d'execution et des dependances de test dans un meme bloc. Boot 4 separe davantage ces couches, avec des modules distincts pour le runtime et pour les tests. Pourquoi? Pour alleger le classpath de production, accelerer le demarrage, et limiter les conflits de versions.

Concretement, cela se traduit par de nouveaux artifacts ou des artifacts scindes. Le cas de l'AOP est mentionne: la dependance est separee en un module principal et un module de test. Le comment? Dans le `pom.xml` ou le `build.gradle`, on declare explicitement les modules dont on a besoin. Cela permet aux equipes d'eviter d'embarquer des outils de test en production par accident.

Ce changement favorise aussi une meilleure lisibilite des dependances. Pour les equipes qui appliquent une gouvernance stricte des libs, la separation des scopes devient un levier: on peut verifier que seules les dependances requises sont en production. Pour un environnement reglemente, c'est un gain concret: moins de CVE possibles et des audits plus simples.

// Exemple Maven: separation runtime / test pour l'AOP (illustration)
<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-aop</artifactId>
</dependency>

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-aop-test</artifactId>
    <scope>test</scope>
</dependency>

Migration de Spring Boot 3.5 a 4

Le guide de migration insiste sur une etape cle: passer d'abord a Spring Boot 3.5, puis migrer vers la 4. Pourquoi cette recommandation? Parce que 3.5 est le point de transition ou les deprecations sont signalees clairement. Si vous sautez cette etape, vous risquez d'ignorer des warnings et de vous heurter directement a des erreurs bloquantes.

Le comment est tres pragmatique: d'abord, monter l'application en 3.5, corriger les warnings deprecies, adapter le code, puis seulement passer en 4. Cela suppose un cycle de build et de test complet. Un cas d'usage concret est un monolithe e-commerce qui utilise des starters anciens: le fait de nettoyer les APIs deprecies en 3.5 permet de prevoir les impacts et d'isoler les modifications avant le saut final.

La suppression de classes et de methodes deprecies en 3.x est volontaire. Cela pousse a adopter des patterns plus actuels et a eviter que des pratiques obsolete persistent. C'est un investissement initial, mais qui rationalise la base de code. Pour les equipes, la migration peut etre l'occasion d'ajouter des tests d'integration manquants, afin de valider chaque changement.

// Exemple: configurer un profil de migration via properties
spring.profiles.active=migration
spring.main.banner-mode=off
logging.level.org.springframework=INFO

Nouvelles fonctionnalites et ecosysteme

Parmi les nouveautes citees, on trouve le support de Gradle 9, tout en conservant la compatibilite avec Gradle 8.x. Le pourquoi est clair: permettre aux equipes de migrer progressivement leurs pipelines de build. Le comment? En ajustant le wrapper Gradle, puis en verifiant les compatibilites des plugins Spring Boot et des plugins internes.

Un autre point important est l'ajout d'auto-configuration et de configuration properties pour les clients de services HTTP. Cela facilite la creation de clients declaratifs et coherents. Dans une architecture microservices, cela permet de centraliser des parametres comme les timeouts, les retries, ou les headers de tracing, au lieu de les dupliquer dans chaque client.

La version aborde aussi le versioning d'API via properties. Pourquoi? Pour permettre une gouvernance claire des endpoints, en separant les versions tout en gardant un code maintenable. Le comment? En configurant des prefixes ou des conventions de routing dans la configuration de l'application, puis en organisant les controllers de maniere explicite. Ce pattern facilite l'evolution des contrats d'API sans casser les clients existants.

// Exemple d'API versioning via configuration
api.versioning.enabled=true
api.versioning.prefix=/api
api.versioning.default-version=v1

Starters, remplacements et cas concrets

Le guide mentionne des starters deprecies et leurs remplacements. Le pourquoi est double: clarifier les responsabilites des starters et aligner leur nommage avec les nouveaux modules. Pour les equipes, cela signifie qu'une migration peut impliquer des modifications dans les dependances build, mais aussi dans les imports de code.

La transcription signale notamment le changement autour du starter AOP et la separation des modules de test. On peut generaliser cela a d'autres librairies: la logique est de rendre explicite ce qui est runtime et ce qui est test. Cela rebat les cartes de certains `pom.xml` historiques, mais offre un meilleur controle.

Un cas concret cite par l'auteur est la creation d'un nouveau projet microservices qui s'appuie sur Spring Boot 4. Dans ce scenario, on beneficie immediatement de la modularisation et des configurations recentes. Par exemple, un service de commande peut adopter un client HTTP auto-configure, des timeouts normalises et un versioning d'API coherent avec les autres services du domaine.

// Exemple de client HTTP auto-configure (pseudo-illustration)
http.clients.orders.base-url=https://orders.internal
http.clients.orders.connect-timeout=2000
http.clients.orders.read-timeout=5000

// Exemple d'organisation des routes versionnees (illustration)
GET /api/v1/customers
GET /api/v2/customers
POST /api/v1/orders
POST /api/v2/orders

Enfin, la transcription mentionne un detail interessant: un petit probleme dans la documentation (une classe Spring Session mal referencee). Cela rappelle que Spring Boot est open source et que l'on peut contribuer en ouvrant des issues. Ce point est pratique: si vous trouvez une incoherence dans le guide, remontez-la, ce qui ameliorera la qualite globale pour toute la communaute.