En 2025, j’ai eu l’opportunité de mettre en place Spring Modulith sur une nouvelle application web. Pour partager cette expérience avec mes collègues, j’ai préparé une démonstration live montrant comment intégrer Spring Modulith dans une application Spring Boot.

J’avais besoin pour cela d’une application simple et universelle. Vous commencez à me connaitre : mon choix s’est naturellement porté sur la version canonique de Spring Petclinic.

Pris au jeu, j’ai progressivement enrichi l’application afin d’illustrer plusieurs fonctionnalités clés de Spring Modulith. J’ai ensuite mis ce fork à disposition de la communauté Spring Petclinic dont le code source complet est disponible sur GitHub : spring-petclinic-modulith.

Dans ce billet, je vous propose de découvrir Spring Modulith, puis de suivre pas à pas comment l’application démo Spring Petclinic a été enrichie pour tirer parti de ses fonctionnalités.

Lors de la conférence Devoxx France 2025, j’ai participé à un hands-on lab de 2h intitulé Sortir des ORMs avec jOOQ. Acronyme de « Java Object Oriented Querying », jOOQ se présente comme une alternative à JPA permettant d’ écrire des requêtes SQL en Java via une fluent API. Animé par Sylvain Decout et Samuel Lefebvre, cet atelier visait à migrer une application Spring Boot / JPA vers jOOQ à l’aide du starter Spring Boot pour jOOQ. Pour les curieux, le repo de l’atelier est disponible sur Github : jooq-handson.

Fort de cette découverte, je me suis à mon tour prêté à l’exercice de migrer vers jOOQ la couche de persistance Spring Data JPA de l’application démo Spring Petclinic. Un nouveau fork est né : spring-petclinic-jooq. Bienvenue à ce dernier dans la communauté Spring Petclinic.

L’usage de jOOQ se rapproche de l’utilisation de JdbcTemplate. Le développeur maitrise le nombre de requêtes envoyées à la base de données relationnelle. Ce qui les différencie, c’est la syntaxe : pas de SQL, mais une API Java fluide et type-safe spécifique à jOOQ qu’il va falloir appréhender. Rassurez-vous, cette API se rapproche du SQL : on y retrouve les mots clés select, update, insertInto, where, from, join, on, as… A ceux-ci, on ajoute des mots clés spécifiques à jOOQ : paginate, fetch, convertFrom … La documentation de jOOQ est très complète. On y apprend comment écrire des requêtes complexes à base de window function ou de Common Table Expressions (CTE) et comment utiliser des fonctionnalités avancées de SQL que peu de frameworks ORM supportent nativement : JSON functions, PIVOT, MERGE, UNION …

Cet article a pour objectif d’expliquer les étapes adoptées pour migrer l’implémentation Spring Data JPA des repository vers jOOQ. Des exemples de code avant / après y sont proposés.

Conférence : Devoxx France 2025
Date : 17 avril 2025
Speaker : Sébastien Deleuze (Broadcom)
Format : Conférence (45 mn) / Replay Youtube

Sébastien est Core Commiter sur Spring Framework. Il intervient également sur des sujets transverses au portfolio Spring : support de Kotlin, null-safety (avec JSpecify) et les sujets d’optimisation. Dans ce talk, il a pour ambition de nous montrer comment améliorer l’efficacité de 80% des applications Spring, que ce soit de nouvelles applications ou des applications Legacy.

Les raisons d’améliorer l’efficacité de nos applications sont multiples :

• Baisser le cout de run des applications
• Développement durable pour diminuer la consommation d’énergie, de mémoire et de CPU
• Optimiser les applications pour les containers (sur le Cloud ou OnPremise)

Pour arriver à nos fins, Sébastien nous propose 3 technologies :

1. CDS : techno relativement vieille mais qui s’est améliorée au fil des versions de Java
2. AOT cache : Java 24 permet d’utiliser l’AOT cache qui est une version améliorée CDS. Sébastien prédit l’exploision de AOT Cache avec la LTS Java 25
3. AOT cache with profiling : technologie expérimentale et prometeuse

Spring et Quarkus dans le même repository Git, ou presque. Cela vous intrigue ?
Figurez-vous qu’il y’a quelques mois, la lecture du très bon livre Understanding Quarkus 2.x d’Antonio Gongalves m’a donné envie de pratiquer ce framework alternatif à Spring Boot. Et pour apprendre une nouvelle technologie, quoi de plus stimulant que de se fixer un objectif. Je me suis donc donné comme challenge de migrer vers Quarkus l’application démo Spring Boot que je connais bien. Une fois migrée, l’application devait rester iso-fonctionnelle.
A travers leur repo quarkus-petclinic, RedHat avait fait l’exercice avant moi. Malheureusement, l’historique Git a été écrasé, ne laissant aucune trace du chemin de migration parcouru. Pendant 3 mois, j’ai donc travaillé sur un nouveau fork que je suis fier de vous présenter : quarkus-spring-petclinic. Ajouté à la communauté Spring Petclinic, ce fork a un double objectif :

1. Montrer comment migrer une application Spring Boot 3.4 vers Quarkus 3.21, avec le minium d’effort et en modifiant le moins de code possible
2. Utiliser les extensions Spring proposées par Quarkus pour garder un lien avec le monde Spring tout en soulignant l’effort de l’équipe Quarkus pour supporter Spring, un framework incontournable de l’écosystème Java

Les extensions Spring pour Quarkus utilisées sont au nombre de quatre : Spring DI, Spring Web, Spring Data JPA et Spring Cache.
Le changement majeur aura été de porter le templating des pages HTML de Thymeleaf vers Qute.

Débutant en Quarkus, le code proposé ne respecte peut-être pas toutes les règles de l’art prônées par l’équipe de dév Quarkus. Je m’en excuse par avance. Si vous voulez contribuer et corriger le tir : issue et Pull Request sont les bienvenues.

Le différenciel complet entre la version Spring Boot et la version Quarkus de Petclinic peut-être visualisé sur Github.

Cet article explique comment intégrer un chatbot utilisant l’ IA générative dans une application de gestion codée en Java.

Nous nous appuierons sur le framework Open Source LangChain4j, une adaptation Java de la célèbre librairie python LangChain, visant à simplifier l’intégration de grands modèles de langage ( LLM). LangChain4j permet de créer des agents conversationnels, des assistants virtuels (comme notre chatbot), ou des applications capables d’effectuer des analyses de texte et de répondre en fonction de données contextuelles, le tout sans devoir écrire de code complexe et avec un haut niveau d’abstraction. Elle facilite notamment l’utilisation des API des Large Langage Model comme OpenAI et Hugging Face, et propose différents connecteurs pour des bases de données vectorielles, incluant Elasticsearch et Qdrant. Pour accélérer son intégration, LangChain4j propose des extensions pour Quarkus et des starters pour Spring Boot.

Pour illustrer cet article, nous utiliserons l’illustre application démo Spring Petclinic et son récent fork dédié à LangChain4j : spring-petclinic-langchain4j
Propulsé par Spring Boot, Spring Petclinic s’appuie sur Spring Data JPA pour l’accès aux données et Thymeleaf pour la couche présentation HTML / CSS / JavaScript.
En septembre 2024, Oded Shopen, contributeur en 2020 du fork Spring Petclinic Cloud, a proposé une intégration de Spring AI dans Spring Petclinic. De son travail, est né le projet spring-petclinic-ai. Le repository spring-petclinic-langchain4j est un portage du framework Spring AI vers LangChain4j. Y a été ajouté notamment une fonctionnalité de streaming.
Extraits du sample, les exemples de code s’appuient sur les versions 3.3 de Spring Boot et 0.35.0 de LangChaing4j.

Le live coding qui rendra vos applications plus pérennes

Conférence : Devoxx France 2024
Date : 19 avril 2024
Speakers : Julien Topçu ( Shodo)
Format : Conférence (45mn)
Repo GitLab : https://gitlab.com/beyondxscratch/hexagonal-architecture-java-springboot
Vidéo Youtube : https://www.youtube.com/watch?v=-dXN8wkN0yk

Cette session de live coding se déroule dans l’univers de Starwars et commence par une citation de Maitre Yoda.

En 45mn, Julien doit développer le système Rebels Rescue visant à reconstituer des flottes de sauvetage. N’en déplaise à l’Empire, les technos seront Spring Boot et Java 21.

A cet effet, il s’appuiera sur l’API publique SWAPI permettant d’accéder à un référentiel de vaisseaux à disposition. L’application sélectionne les vaisseaux qui permettent d’effectuer la mission de sauvetage. Le code source est disponible dans le repo GitLab de Julien : hexagonal-architecture-java-springboot

Julien commence par rappeler les inconvénients d’une architecture 3-tiers basée sur le triptyque Contrôleur -> Service -> Persistance

Dans une grande entreprise, le développement d’applications métiers doit respecter les règles en vigueur : normes de développement, normes de sécurité, barrière qualité, socle technique borné, intégration à l’usine de dév …
Le démarrage d’une nouvelle application Java peut être accélérée de bien des manières : usage d’outils Low Code comme Palmyra, générateur de squelettes d’application comme JHipster, utilisation d’applications blanches déclinées par catégorie d’appli (ex : batch, web), copier/coller/élagage d’une application de référence, guide de démarrage sous forme wiki … Chaque technique présente ses avantages et ses inconvénients. Mais certaines ne couvrent pas toutes les règles évoquées précédemment.
Afin d’ accélérer le développement d’une nouvelle application, mon objectif était de générer un squelette d’application minimaliste dont le code généré est parfaitement maitrisé et avec des dépendances choisies à la carte par le tech lead. Libre à lui ensuite de retravailler le code généré pour mettre en place l’architecture cible de l’application, en choisissant par exemple de partir sur une architecture hexagonale.

Bien connu des développeurs Spring Boot, je me suis appuyé sur le code backend faisant tourner le site https://start.spring.io/, à savoir le projet Spring Initializr conçu et maintenu majoritairement par Stéphane Nicoll. Léger, codé en Java, reposant sur Spring Boot et documenté, ce projet a été conçu pour être personnalisé et extensible. Cela en a fait un excellent candidat.
La première mouture de ce générateur développé en quelques jours m’aura permis de générer :

• la configuration du socle Spring Boot d’entreprise
• la configuration du logger permettant de standardiser les logs au format JSON
• la sécurisation des API REST avec Spring Security, OpenID Connect et le SSO d’entreprise
• les contrôleurs et DTO d’une API REST à partir d’une spécification OpenAPI 3
• le Dockerfile et la configuration du pipeline CI/CD

Contexte

De nos jours, il est courant de devoir consommer une API REST sécurisée à l’aide du standard OAuth 2.0 ou de sa surcouche OpenID Connect (OIDC).
Schématiquement, le consommateur génère un jeton (token) opaque ou JWT en appelant un serveur d’autorisation (Authorization server) puis, à chaque appel d’API REST, le transmet en tant que bearer via l’ en-tête HTTP Authorization. Ce token a souvent une durée de vie transmise par le serveur d’autorisation via la propriété expires_in.

OAuth 2.0 propose quatre cinématiques (flows), la plus commune étant l’Authorization Code Flow. Lorsque l’API REST est appelée depuis une application web, il est courant de voir utiliser le Client Credentials Flow ou le Resource Owner Password Credentials Flow.

Récemment, j’ai été amené à consommer l’API REST du CRM Salesforce depuis une application Spring Boot. Cette API était sécurisée avec le Resource Owner password Credentials Flow. Salesforce joue à la fois le rôle de l’Authorization Server et du Resource Owner. Le client (l’application Spring Boot) transmet ses credentials (login et mot de passe) à l’Authorization Server pour obtenir un Access Token.
Cet article a pour objectif de vous présenter la configuration Spring Security mise en œuvre pour appeler cette API. Les extraits de code proviennent du repository GitHub arey/spring-security-oauth2-salesforce-sample.

Or, certains des projets historiques de Netflix OSS ne sont plus activement développés. Ils sont rentrés en mode maintenance. C’est notamment le cas d’ Hystrix, de Zuul 1 et de Ribbon. En décembre 2018, lors de l’annonce de la sortie de Spring Cloud Greenwich RC1, Pivotal recommande de migrer vers des projets tiers et de nouveaux modules Spring Cloud :

Anciennement****Solutions cibles Hystrix Resilience4jHystrix Dashboard / Turbine Micrometer + Monitoring System Ribbon Spring Cloud Loadbalancer Zuul 1 Spring Cloud Gateway Archaius 1 Spring Boot external config + Spring Cloud Config

Dans le cadre de Spring Petclinic Microservices, seul Eureka est épargné et continue de jouer son rôle d’annuaire de service. Un désendettement vers Resilience4j, Micrometer, Spring Cloud Loadbalancer et Spring Cloud Gateway s’est naturellement imposé (issue #117).

Cet article retrace les différentes étapes de migration. J’espère qu’il vous sera utile si vous avez le même chemin à parcourir.

Dans ce billet, j’aimerais vous présenter les différentes briques techniques permettant de mettre en œuvre une architecture microservices reposant sur Spring Boot, Spring Cloud, Netflix OSS et Docker. Pour m’y aider, je m’appuierai sur l’application démo Spring Petclinic Microservices que je vous avais déjà brièvement présenté en 2016 et que j’ai récemment migrée vers Spring Cloud Finchley et Spring Boot 2.

Ce fork a été construit à partir de l’application monolithique spring-petclinic-angularjs. Cette dernière a été découpée en plusieurs services, chacun responsable d’un domaine métier de la clinique vétérinaire : les animaux et leurs propriétaires, leurs visites à la clinique et les vétérinaires.

Au final, Spring Petclinic Microservices est construit autour de petits services indépendants (quelques centaines de ligne de code), s’exécutant dans leur propre JVM et communiquant sur HTTP via une API REST. Ces microservices sont tous écrits en Java. Mais on aurait pu utiliser Kotlin pour développer certains d’entre eux. Le front est quant à lui codé en JavaScript.

Architecture technique

Pour fonctionner, les différents microservices composant l’application Petclinic reposent sur différentes briques techniques matérialisées sur le diagramme d’architecture ci-dessous :