liksi logo

.blog

java spring springboot ai back

Spring Framework 7 et Spring Boot 4 - les évolutions majeures de 2025

Mathieu Durand - Publié le 25 août 2025
Spring Framework 7 et Spring Boot 4 - les évolutions majeures de 2025

Spring Boot + Kotlin : le socle technique de Liksi

Chez Liksi, nous avons fait le choix de Spring Boot et Kotlin comme stack de référence pour nos développements backend. Cette combinaison nous offre :

  • Productivité - syntaxe concise de Kotlin et conventions Spring Boot
  • Fiabilité - null-safety native et écosystème mature Spring
  • Performance - optimisations JVM et intégration parfaite des deux technologies
  • Maintenabilité - code expressif et architecture robuste

Cette approche nous permet de livrer rapidement des applications robustes et évolutives, parfaitement adaptées aux enjeux business de nos clients.

L’évolution perpétuelle ou “l’art de ne jamais s’arrêter”

L’écosystème Spring n’a jamais été aussi dynamique qu’en 2025. Avec l’arrivée de Spring Framework 7.0 (novembre 2025) et Spring Boot 4.0 (milestone M2 disponible), nous assistons à des évolutions significatives dans l’univers du développement Java enterprise.

Mais pourquoi tant d’agitation autour de ces nouvelles versions ? Parce qu’elles marquent une rupture technologique majeure : abandon définitif de javax, adoption massive de Jakarta EE 11, et intégration native des dernières innovations Java.

Cette évolution nous amène à nous poser une question essentielle : comment ces changements vont-ils transformer notre façon de concevoir et déployer nos applications Java ?

Spring Framework 7.0 - la maturité technique au service de l’innovation

Jakarta EE 11 - enfin la transition complète

Fini les javax.* ! Spring Framework 7 adopte Jakarta EE 11 comme baseline, avec Jakarta Servlet 6.1 et WebSocket 2.2. Cette transition, amorcée depuis plusieurs années, trouve enfin son aboutissement. Pour en savoir plus sur cette évolution majeure, consultez l’article From Spring Framework 6.2 to 7.0 sur le blog officiel Spring.

Concrètement, cela signifie :

  • déploiement obligatoire sur Tomcat 11+ ou Jetty 12.1+
  • migration complète des imports javax vers jakarta
  • compatibilité native avec les derniers standards enterprise

De nouvelles APIs pour simplifier le quotidien

Spring 7 introduit plusieurs nouvelles APIs :

  • JmsClient - alternative moderne à JmsMessagingTemplate
  • JdbcClient enrichi - avec fetch size, max rows, et query timeout au niveau statement
  • Support natif du versioning d’API - pour Spring MVC et WebFlux

Versioning d’API natif - enfin intégré au framework !

Jusqu’à présent, les développeur·se·s Spring devaient recourir à des bricolages avec des paths, des query parameters ou des filtres personnalisés pour versionner leurs APIs. Avec Spring Framework 7.0, le versioning d’API est enfin natif !

Comment ça marche ?

Spring Framework 7.0 introduit un attribut version sur @RequestMapping permettant de maintenir plusieurs versions d’un endpoint dans un même contrôleur :

@RequestMapping(value = "/octopus", version = "1")

Quand votre client demande la version 1, Spring route automatiquement la requête vers le bon handler. Il suffit d’indiquer à Spring où trouver l’information de version.

Exemple concret : API de gestion d’octopus

Voici un exemple réel avec un endpoint /octopus :

  • Version 1 : retourne les informations basiques de l’octopus
  • Version 2 : retourne des détails enrichis avec habitat et comportement
@RestController
@RequestMapping("/api")
public class OctopusController {

    @Autowired
    private OctopusService octopusService;
    
    @RequestMapping(value = "/octopus", version = "1")
    public ResponseEntity<OctopusBasicDto> getOctopusV1() {
        return ResponseEntity.ok(octopusService.getBasicInfo());
    }
    
    @RequestMapping(value = "/octopus", version = "2")
    public ResponseEntity<OctopusEnhancedDto> getOctopusV2() {
        return ResponseEntity.ok(octopusService.getEnhancedInfo());
    }
}

Même URL, version différente → handler différent. Simple et élégant !

Configuration du versioning

Par défaut, Spring a besoin de savoir où trouver l’information de version. Vous configurez cela avec ApiVersionConfigurer :

@Configuration
public class WebConfiguration implements WebMvcConfigurer {

    @Override
    public void configureApiVersioning(ApiVersionConfigurer configurer) {
        configurer.useRequestHeader("X-API-VERSION");
    }
}

💡 Astuce : Vous pouvez aussi utiliser configurer.useRequestParam("version") si vous préférez les query parameters.

Appel de l’API

Pour appeler la version 1 :

curl -H "X-API-VERSION: 1" http://localhost:8080/api/octopus

Pour appeler la version 2 :

curl -H "X-API-VERSION: 2" http://localhost:8080/api/octopus

JSpecify - la null-safety enfin standardisée

L’une des évolutions les plus significatives de Spring Framework 7 concerne l’adoption de JSpecify pour remplacer les annotations de nullité JSR 305. Cette migration apporte des bénéfices considérables :

Pourquoi JSpecify ?

Spring Framework 7 abandonne ses propres annotations @Nullable, @NonNull au profit de JSpecify, un standard collaboratif développé par Google, JetBrains, Oracle, Uber et VMware :

  • Spécifications claires - définitions précises vs l’approche JSR 305
  • Meilleur support tooling - intégration native dans les IDEs
  • Types génériques - nullité spécifiée pour les génériques, arrays et varargs
  • Interopérabilité Kotlin - APIs null-safe natives pour Kotlin

Avantages techniques concrets

// Avant (JSR 305) - annotation sur le paramètre
public List<String> process(@Nullable String input) { ... }

// Avec JSpecify - annotation sur le type
public List<@Nullable String> process(@Nullable String input) { ... }

Cette différence permet de distinguer la nullité des éléments de celle des conteneurs, apportant une précision inédite.

Impact pour les développeur·se·s

  • Java - meilleure vérification compile-time avec NullAway
  • Kotlin - interopérabilité native, APIs idiomatiques
  • Consistance - vérifications build-time pour l’ensemble du portfolio Spring

La migration vers JSpecify représente un pas majeur vers la null-safety standardisée dans l’écosystème JVM, bénéficiant autant aux développeur·se·s Java qu’à celles et ceux utilisant Kotlin.

Spring Boot 4.0 - la modularisation comme nouveau paradigme

Java 17 minimum, Java 25 recommandé

Breaking change majeur : Spring Boot 4 abandonne définitivement Java 11. La baseline passe à Java 17, avec JDK 25 comme version recommandée.

Cette décision permet d’exploiter pleinement :

  • les pattern matching
  • les sealed classes et interfaces
  • les records
  • les virtual threads

Partenariat stratégique avec Kotlin

Spring Framework 7 et Spring Boot 4 marquent également le renforcement du partenariat stratégique avec JetBrains annoncé en mai 2025. Cette collaboration, menée notamment par Sébastien Deleuze côté Spring, apporte des améliorations significatives :

Support Kotlin 2.2 natif

  • Baseline Kotlin 2.2 - support des dernières fonctionnalités du langage
  • Null-safety renforcée - intégration parfaite avec JSpecify
  • Performance améliorée - nouvelle librairie kotlinx.reflect pour l’injection de dépendances

Nouveautés pour les développeur·se·s Kotlin

// Nouveau Bean Registration DSL
class MyBeanRegistrar : BeanRegistrarDsl({
    registerBean<Foo>()
    registerBean(
        name = "bar",
        prototype = true,
        lazyInit = true,
        description = "Custom description") {
            Bar(bean<Foo>())
    }
    profile("baz") {
        registerBean { Baz("Hello World!") }
    }
})

Bean Registration DSL - simplifier l’injection de dépendances

Cette nouvelle syntaxe Bean Registration DSL transforme radicalement l’expérience développeur·se Kotlin dans Spring. Fini les annotations @Component ou @Service dispersées : vous centralisez maintenant la configuration des beans dans un DSL idiomatique Kotlin.

Cette approche apporte une type-safety compile-time qui détecte les erreurs avant l’exécution, une configuration centralisée qui rassemble tous vos beans dans un seul endroit, des performances optimisées grâce à l’enregistrement direct sans scanning d’annotations, et une syntaxe kotlin idiomatique utilisant ref<>() pour les dépendances et des lambdas pour l’instanciation.

Adoption croissante

Avec 27% des développeur·se·s Spring utilisant Kotlin et des entreprises comme Expedia, Atlassian, et Mercedes-Benz.io qui l’adoptent, ce partenariat vise à faire de Kotlin un choix de plus en plus attractif pour le développement backend.

Merci à Sébastien Deleuze pour son travail sur cette intégration !

Architecture modulaire - l’avenir du framework

Le point fort de Spring Boot 4 ? Sa nouvelle architecture modulaire. Les premières milestones (M1 en juillet et M2 en août 2025) mettent l’accent sur cette refonte structurelle qui promet :

  • réduction significative de la taille des applications
  • chargement sélectif des modules selon les besoins
  • amélioration des performances de démarrage

Native Images et AOT - performance au rendez-vous

Spring Boot 4 perfectionne l’intégration GraalVM avec :

  • compilation Ahead-of-Time (AOT) optimisée
  • support natif des virtual threads
  • deux options d’efficacité : Project Leyden’s AOT cache et native images

Spring AI 1.0 - l’IA native dans l’écosystème Spring

Une évolution parallèle : l’IA pour tou·te·s les développeur·se·s Java

Parallèlement aux évolutions de Spring Framework et Spring Boot, Spring AI 1.0 GA (mai 2025) et sa mise à jour 1.0.1 (août 2025) marquent l’entrée officielle de l’intelligence artificielle dans l’écosystème Spring. Ces releases démocratisent le développement d’applications IA pour les développeur·se·s Java avec plus de 150 améliorations de stabilité.

ChatClient API - l’interface universelle

Le cœur de Spring AI réside dans son ChatClient API, une interface unifiée et agnostique qui permet d’interagir avec les principaux modèles IA :

  • OpenAI GPT, Anthropic Claude, Azure OpenAI
  • API fluide pour construire des prompts complexes
  • Support synchrone et streaming
  • Gestion native de la mémoire conversationnelle
@Autowired
private ChatClient chatClient;

public String generateResponse(String userMessage) {
    return chatClient.prompt()
        .user(userMessage)
        .call()
        .content();
}

Model Context Protocol (MCP) - l’interopérabilité standardisée

Spring AI 1.0 introduit le support du Model Context Protocol, standard ouvert pour l’interaction entre modèles IA et outils externes :

  • protocole client-serveur language-agnostique
  • intégration native avec Spring Security
  • support OAuth2 pour les environnements enterprise (Spring AI 1.1)
  • starter spring-ai-starter-mcp-client avec auto-configuration
  • négociation multi-protocole (versions 2024-11-05 et 2025-03-26)

Tool Calling - quand l’IA rencontre votre métier

La fonctionnalité Tool Calling permet aux modèles d’invoquer dynamiquement des méthodes Java, transformant votre logique métier en outils IA :

@Component
public class BusinessTools {
    
    @Tool("Get customer information")
    public Customer getCustomer(String customerId) {
        return customerService.findById(customerId);
    }
}

Prêt pour la production

Spring AI 1.0 ne se contente pas d’être un framework expérimental. Il apporte :

  • Patterns enterprise : RAG (Retrieval-Augmented Generation), gestion des contextes
  • Sécurité intégrée : contrôle des données exposées aux LLM
  • Observabilité : métriques et monitoring natifs
  • Scalabilité : compatible avec l’architecture microservices Spring

Préparer la migration - guide pratique

Chez Liksi, ces évolutions majeures soulèvent plusieurs questions pratiques :

Quand migrer ?

  • Spring Framework 7 - milestone M2 & RC2 disponible, GA prévue novembre 2025
  • Spring Boot 4 - milestone M2 disponible (août 2025), M3 attendue prochainement
  • Spring AI - version 1.0.1 stable pour la production

Quels sont les impacts ?

  • Migration Jakarta EE - refactoring massif des imports
  • Java 17+ - mise à jour obligatoire des environnements
  • Architecture modulaire - repenser la structure des applications
  • Intégration IA - nouvelles opportunités avec Spring AI 1.0

Comment s’y préparer ?

  1. Audit des dépendances - vérifier la compatibilité Jakarta EE 11
  2. Montée de version Java - planifier la migration vers JDK 17/25
  3. Formation des équipes - accompagner les développeur·se·s sur les nouveautés
  4. Exploration Spring AI - identifier les cas d’usage IA dans vos projets

L’écosystème Spring en 2025 - vers une nouvelle ère

Ces évolutions marquent un tournant dans l’écosystème Java enterprise. Spring Framework 7, Spring Boot 4 et Spring AI ne sont pas de simples mises à jour : elles redéfinissent les standards de développement pour les années à venir.

Les enjeux sont multiples :

  • performance native avec GraalVM et les virtual threads
  • modularité pour des applications plus légères
  • standards modernes avec Jakarta EE 11
  • intelligence artificielle native avec Spring AI

Et chez Liksi ?

Ces nouveautés s’inscrivent parfaitement dans notre approche Software Craftsmanship : adopter les meilleures pratiques et technologies pour créer des applications performantes et maintenables.

La question n’est plus “faut-il migrer ?” mais “comment bien préparer cette transition ?”

2025 s’annonce comme une année charnière pour l’écosystème Spring !

Ressources utiles

Pour suivre les développements de ces nouvelles versions :

Vidéos recommandées

Pour approfondir vos connaissances sur ces évolutions :

Derniers articles