maciek905 - Fotolia
Spring aligne sa feuille de route sur celle de l’OpenJDK
Au début du mois de février, VMware et la communauté ont animé l’événement Spring One. L’occasion de faire le point sur l’évolution des technologies et des offres qui entourent l’écosystème Spring. Force est de constater que l’avenir de Spring est fortement lié à celui de l’OpenJDK.
Écosystème particulièrement populaire auprès des développeurs Java Web, Spring s’adapte aux nouvelles architectures multicloud, hybrides et conteneurisées, mais surtout aux évolutions de l’OpenJDK.
D’abord, Spring Framework est passé en version 6.0 au mois de novembre 2022. Le framework pensé pour simplifier le développement d’applications Web et la manipulation des dépendances JEE, prend désormais en charge les spécifications de Jakarta EE 9 (Servlet 5.0 et plus, JPA 3.0 et plus) en sus de celles spécifiques à Jakarta EE 10. Pour cela, il a fallu changer l’ensemble des namepaces Javax vers Jakarta, une condition imposée par Oracle à la fondation Eclipse.
Aussi, Spring Framework 6 est « totalement compatible » avec les API Tomcat 10.1, Jetty 11, Undertow 2.3 et Hibernate ORM 6.2.
Surtout, l’entièreté de la base de code repose dorénavant sur JDK 17, la version LTS actuelle de Java.
La communauté Spring souhaitait profiter des améliorations du langage (les expressions switch, l’opérateur instanceof), des librairies, des classes scellées, ou de la gestion des modules. De manière plus générale, les évolutions de Java servent de base de travail pour améliorer l’ensemble des outils-modules Spring.
Ainsi, VMware, principal contributeur au projet, et la communauté sont en train de renforcer la compatibilité avec JDK 19 et 21.
En septembre 2022, JDK 19 a introduit deux fonctionnalités en préversion : Record Patterns et Virtual Threads.
Les Record Patterns doivent permettre d’exprimer des requêtes de données « plus sophistiquées et plus composables ». Cette fonctionnalité émane du projet Amber qui incube une collection de petites améliorations de productivité en direction des développeurs Java.
La fonctionnalité Virtual Threads, comme son nom l’indique, introduit des threads légers qui doivent « réduire considérablement les efforts d’écriture, de maintenance et d’observation des applications concurrentes à haut débit ». C’est l’un des pendants du projet Loom, dont l’objectif est de moderniser et d’améliorer les performances de la JVM.
En clair, les contributeurs à l’écosystème Spring doivent s’adapter au nouveau cycle de mise à jour de Java. La prochaine version supportée à long terme de Java, à travers JDK 21, sera disponible en septembre 2023. Spring Framework 6.1 sera introduit en novembre 2023. Entre-temps, une version intermédiaire du JDK sera lancée en mars.
Lord d’une session de Spring One, la conférence consacrée à l’écosystème Spring, Juergen Hoeller, responsable du projet Spring Framework chez VMware, recommande de mettre à jour son JDK vers la version 17 au moment d’adopter Spring Framework 6.
Spring Native (GraalVM) gagne en traction
Spring Framework n’est pas le seul à être concerné par les évolutions de Java. Pour rappel, les contributeurs au projet Spring Boot, le framework de développement de microservices servant à propulser (majoritairement) des API Web, planchaient sur le projet Spring Native, une intégration de GraalVM Native Image, la fonction de compilation Ahead of Time de la machine virtuelle polyglotte.
Spring Native est désormais intégré à Spring Boot 3. L’outil supporte le standard GraalVM porté par Oracle Labs.
« Il y a trois – quatre ans, quand les équipes de Spring ont commencé à travailler sur Native, son implémentation était relativement intrusive », affirme Erwan Bornier, SEMEA Tanzu Solution Engineering Lead, chez VMware. « La communauté Spring a simplifié l’usage de cette fonction pour que les développeurs n’aient pas forcément besoin de réécrire leur code afin de l’utiliser ».
Pour rappel, tout l’intérêt de GraalVM et de ses déclinaisons est de réduire le temps de démarrage des applications et leur consommation en mémoire vive, moyennant l’ajout de quelques dépendances et la désactivation de certaines fonctions.
« Selon les retours des développeurs, Spring Native permet de diviser l’enveloppe mémoire des microservices par deux et le temps de démarrage par dix », indique Erwan Bornier. « Au-delà des questions de performance, de réduction de coût et de move-to-cloud, certains de nos clients souhaiteraient utiliser Spring Native pour tenter de réduire la consommation d’énergie de leur pile applicative ».
La prochaine échéance pour la communauté Spring n’est autre que le projet Galahad. Celui-ci prévoit l’infusion de GraalVM dans l’OpenJDK.
Pour les développeurs, cette meilleure prise en charge de cette technologie dans l’écosystème Spring va permettre d’exécuter des charges de travail serverless dans le cloud public, selon Erwan Bornier.
Simplifier la supervision des JVM (et de leurs contenus)
L’autre enjeu pour la communauté Spring est de simplifier la collecte des traces des applications s’exécutant depuis des JVM. Spring Framework et plusieurs modules de l’écosystème « profitent » d’une instrumentation intégrée via l’API du projet Micrometer. Micrometer est présenté comme « une interface simple » et open source pour les clients d’instrumentation des systèmes d’observabilité les plus populaires (New Relic, Datadog, Prometheus, Elastic, etc.). Il existe également des collecteurs pour exploiter les logs, les traces et les métriques des applications Spring Boot à l’aide de la collection d’outils OpenTelemetry.
« Il s’agit de faire en sorte que tout développeur soit capable, en local sur sa machine, ou depuis des solutions SaaS de comprendre l’exécution de ses composants », remarque Erwan Bornier.
Spring Cloud, une suite d’outils et de patterns pour concevoir des systèmes distribués (routage, load balancing, circuit breakers, découverte de services) dans différents contextes cloud a été adaptée en conséquence des évolutions de Spring Boot et du support de Micrometer.
VMware veut favoriser la migration des workloads Spring vers le cloud
En revanche, Azure Spring Cloud a été renommé Azure Spring Apps au cours de l’été 2022. Le service managé, lancé en partenariat entre VMware et Microsoft, a évolué dans le but de séduire les clients qui voudraient migrer leurs applications Spring vers Azure.
« Il s’agit de réduire au maximum l’effort de migration des workloads Spring vers le cloud pour les entreprises », vante Erwan Bornier.
Les prémisses Azure Spring Cloud ne disparaissent pas : Spring Cloud Azure est un projet open source qui reprend les fonctionnalités de base d’Azure Spring Cloud. Des modèles ouverts ont été adaptés pour GCP et AWS par la communauté.
Le responsable chez VMware Tanzu remarque que peu d’entreprises choisissent un seul cloud. « Les entreprises ont compris qu’elles ne pouvaient pas tout faire avec les services d’un seul fournisseur pour diverses raisons : la performance des services, le coût, la préférence des équipes, etc. », avance Erwan Bornier. « Notre ambition est de fournir un modèle opérationnel multicloud, des technologies qui sont aussi efficaces dans un cloud que dans un autre ».
Pour autant, il est bon de rappeler qu’il n’existe pas de services managés équivalents à Azure Spring Apps sur Google Cloud ou AWS.
Enfin, un autre projet devrait favoriser la migration des applications Spring vers le cloud. Si le rapport State of Spring 2022, une étude commandée par VMware, tend à démontrer que 93 % des 1421 développeurs interrogés ont adopté une architecture de microservices couplée à Docker et Kubernetes, l’approche consistant à rendre un monolithe modulaire gagne aussi en popularité.
En tout cas, VMware et la communauté Spring veulent mettre en avant le projet expérimental Spring Modulith. Modulith doit permettre de guider les développeurs pour exprimer des modules logiques dans des applications Spring Boot « très structurées ». Il reprend les grandes lignes du projet Moduliths et s’appuie sur les fonctionnalités clés de Spring, dont l’injection de dépendances. Modulith doit permettre de gérer des fonctions spécifiques liées aux domaines contenus dans des paquets isolés, accessibles par API. Ces modules sont rattachés à un paquet jouant le rôle d’un squelette applicatif et peuvent être enclenchés de manière évènementielle.