BT

Diffuser les Connaissances et l'Innovation dans le Développement Logiciel d'Entreprise

Contribuez

Sujets

Sélectionner votre région

Accueil InfoQ Actualités VMware Révise Spring 6 Et Spring Boot 3 Pour Une Autre Décennie

VMware Révise Spring 6 Et Spring Boot 3 Pour Une Autre Décennie

À Spring One 2021, VMware a révélé comment Spring 6, prévu pour une version d'octobre 2022, prépare le framework pour une autre décennie : il nécessitera Java 17 et Jakarta EE 9, fournit une prise en charge des modules Java et de la compilation native, intègre l'observabilité dans Spring et supprime les fonctionnalités obsolètes et les intégrations tierces. Spring Boot 3 utilisera Spring 6 mais n'a pas encore de date de sortie.

Démontrant l'ampleur de cette refonte, Spring Framework n'aura pas de nouvelle version majeure cette année - pour la première fois depuis 2010. Cependant, une prochaine version mineure prendra en charge Java 17, tandis que le train de versions Spring Boot 2.xy bénéficiera toujours de versions majeures en novembre 2021 et mai 2022.

Des enquêtes récentes auprès des développeurs ont montré l'adoption précoce de nouveaux frameworks Java natifs pour le cloud, tels que Quarkus et Micronaute. Ces frameworks produisent des applications natives avec une faible utilisation de la mémoire et des temps de démarrage rapides. Spring 6 peut être considéré comme la réponse de VMware à ces frameworks concurrents.

Spring 6 aura les branches habituelles de la version de maintenance qui se chevauchent. Mais « les utilisateurs de Spring Framework 6 sont fortement encouragés à rejoindre notre flux de versions de fonctionnalités, ne s'attendant pas à rester longtemps sur 6.0.x, mais plutôt à intégrer les mises à niveau 6.1, 6.2, etc. dans leur modèle d'utilisation habituel. »

La cadence de publication peut également passer d'un cycle annuel à un cycle semestriel, comme le fait déjà Spring Boot.

Exiger Java 17 est moins agressif qu'il n'y paraît aujourd'hui : au moment où Spring 6 sera disponible, Java 19 sera disponible. Jakarta EE 9 en tant que baseline brise la rétrocompatibilité avec le nouvel espace de nommage jakarta, mais permet à Spring de suivre : certaines dépendances : Spring prent déjà en charge Jakarta EE 9 (comme Tomcat 10 ou Jetty 11), tandis que d'autres ne le feront pas avant l'année prochaine (comme Hibernate ORM 6).

Spring 6 devrait utiliser le système de module de plate-forme Java (JPMS : Java Platform Module System) et permettre aux développeurs d'écrire des applications Spring avec JPMS.

Spring Native fournit aujourd'hui une compilation native des applications Spring avec GraalVM. Il va encore s'améliorer avec la sortie de la version 0.11, prévue pour le 19 novembre 2021, qui s'appuiera sur GraalVM 21.3 et Spring Boot 2.6. Mais Spring Boot 3 intégrera de manière transparente la compilation native avec une configuration de démarrage et des packs de construction, remplaçant Spring Native dans Spring 6.

Spring Boot 3 n'offrira probablement pas de compilation native de toutes les bibliothèques de Spring Initializr dès le départ. Et comme c'est le cas avec d'autres frameworks, il n'existe actuellement aucun moyen simple de savoir si une bibliothèque Java donnée fonctionne en mode natif.

Spring Observability est un nouveau projet de Spring 6 et s'appuie sur les enseignements tirés de Spring Cloud Sleuth. Il enregistre les métriques avec Micrometer et propose un traçage via des fournisseurs tels que OpenZipkin ou OpenTelemetry. Contrairement à l'observabilité basée sur des agents, Spring Observability fonctionnera dans les applications Spring compilées en natif. Et dans le cadre du framework Spring de base, il fournira également plus efficacement de meilleures informations.

VMware a fourni quelques exemples de fonctionnalités obsolètes qu'il envisage de supprimer, à savoir l'autowiring sur les setters par nom/type, certaines fonctionnalités de FactoryBean et "certaines options liées au Web". EJB et JAX-WS sont des intégrations tierces qui pourrait être supprimées de Spring 6.

Le premier jalon Spring 6 est prévu pour la fin de 2021 avec une release candidate prévue pour juillet 2022. VMware invite la communauté à commenter ses plans pour Spring et Spring Boot.

InfoQ a rencontré Kristen Strem, responsable principale des communications chez VMware, qui a assuré la liaison avec l'équipe Spring pour des questions sur Spring Framework 6 et Spring Boot 3.

La version 6 prépare Spring Framework pour une nouvelle décennie. Pourquoi était-ce nécessaire et pourquoi maintenant ?

Nous assistons à un tournant majeur pour l'écosystème Java, l'industrie adoptant enfin la nouvelle génération de Java et faisant passer JDK 8 au statut legacy pour les systèmes legacy. Nous nous attendons à ce que JDK 17 joue un rôle clé dans ce changement, offrant une nouvelle génération de support à long terme attrayante avec de nombreuses améliorations accumulées du langage Java, des API et des machines virtuelles - plus que JDK 11 LTS qui vient pour la plupart d'être adopté comme un simple remplacement de JDK 8 pour des raisons de politique de support. De plus, il n'y a pas seulement que le JDK 17 en tant que nouvelle génération LTS, nous attendons également d'autres avantages clés de fonctionnalités du JDK dans les prochaines versions - par exemple, le project Loom - que nous avons l'intention de prendre en charge facultativement tout en conservant une ligne de base sur le JDK 17. Finalement, nous continuerons à prendre en charge les versions du JDK jusqu'au JDK 29 LTS dans notre version 6.x.

Vous avez comparé les versions de fonctionnalités Spring Framework 6.x au modèle de version OpenJDK. Cela signifie-t-il qu'une fois la nouvelle version 6.x publiée, vous arrêterez de produire des versions pour la branche de version précédente ?

En termes de versions de maintenance open source, nous conserverons le même modèle que ces dernières années, avec des branches de maintenance qui se chevauchent comme d'habitude. Le modèle de version OpenJDK fournit une inspiration sur la façon dont les fonctionnalités majeures telles que la prise en charge du project Loom peuvent être intégrées dans les versions de fonctionnalités 6.x plutôt que dans une nouvelle génération majeure du framework. En outre, nous pourrions fournir des versions de fonctionnalités 6.x plus fréquentes au niveau du framework de base, en rejoignant non seulement OpenJDK, mais également Spring Boot pour publier des itérations de fonctionnalités deux fois par an. Enfin et surtout, les utilisateurs de Spring Framework 6 sont fortement encouragés à rejoindre notre flux de versions de fonctionnalités, ne s'attendant pas à rester longtemps sur 6.0.x, mais plutôt à intégrer les mises à niveau 6.1, 6.2, etc. dans leur modèle d'utilisation habituel.

Vous avez montré comment les développeurs Spring 6 pouvaient recharger et déboguer rapidement leur application en cours d'exécution dans Kubernetes. Cela nécessite-t-il la plate-forme d'application Tanzu ? Si tel est le cas, prévoyez-vous de le rendre disponible pour chaque installation Kubernetes ?

Vous n'avez besoin d'aucune technologie spécifique à Tanzu pour prendre en charge le rechargement et le débogage des applications dans Kubernetes. Spring Boot est livré avec un module devtools depuis la v1.3 qui fonctionne très bien avec Kubernetes. Il y a souvent quelques décisions que vous devrez prendre concernant les outils à utiliser et comment les configurer. Il y a un bon aperçu de cela dans la session "Inner Loop Development with Spring Boot on Kubernetes" présentée par Dave Syer à Spring One de cette année.

Bien sûr, une partie de la valeur de la plate-forme d'application Tanzu réside dans le fait que nous pouvons fournir des intégrations avec les outils qui fonctionnent bien avec Spring, et nous pouvons automatiser beaucoup de choses afin que les développeurs n'aient pas à s'inquiéter à propos d'eux. C'est quelque chose que beaucoup de nos clients souhaitent et vous pouvez voir cette automatisation en action lors de la keynote à SpringOne de cette année.

De nombreux frameworks, y compris Spring, utilisent GraalVM pour la compilation native. Comment voyez-vous Spring coopérer avec ces frameworks pour améliorer la compilation native pour l'ensemble de la communauté Java ? Par exemple, vous avez mentionné un repository de compatibilité GraalVM pour les bibliothèques Java et des benchmarks de l'équipe GraalVM à Spring One.

Dès le premier jour, l'équipe Spring s'est concentrée sur l'aide à la maturation de l'écosystème Java natif via une collaboration étroite avec l'équipe GraalVM. Les outils de construction natifs, qui permettent de construire et de tester des exécutables natifs via les plugins Gradle et Maven, en sont une excellente incarnation. Il a été initié par les équipes Spring et GraalVM, avec une contribution au projet JUnit. Récemment, l'équipe Micronaut a uni ses forces, et des collaborations similaires seraient très précieuses pour l'écosystème Java.

Avoir une vision partagée entre les équipes Spring et GraalVM sur la façon de rendre l'écosystème Java natif plus durable et maintenable permet également une collaboration approfondie sur le projet de configuration native, qui devrait fournir des directives et des outils pour partager la configuration native entre différents frameworks. Notez que ce type d'effort est rendu possible en tirant parti des améliorations récentes de la prise en charge native de GraalVM : tests natifs, améliorations de la configuration native, intégration au moment de la construction, etc.

Au final, il est parfaitement bien et attendu que chaque framework fournisse sa propre "sauce secrète". Mais l'écosystème Java natif ne peut pas être durable sans un support plus partagé dans les outils et les bibliothèques Java, et nous continuerons à consacrer beaucoup d'efforts à ce type de collaboration avec l'écosystème au sens large dans le cadre de notre travail sur le support natif de Spring Boot 3.x.

En avril, Juergen Hoeller a écrit qu'ils envisagent "l'introduction de définitions de module-info dans la base de code" pour Spring Framework 6. Cela signifie-t-il que Spring Framework 6 apportera une prise en charge prête à l'emploi pour l'écriture d'applications Java avec le système de module de la plate-forme Java ?

Spring Framework 6 devrait en effet introduire des descripteurs de module pour tous les modules du framework de base, avec des dépendances minimales requises sur les modules Java de base, permettant à l'outil jlink du JDK de créer des images d'exécution personnalisées pour les configurations Spring. Il peut y avoir des contraintes avec les bibliothèques tierces facultatives et certaines stratégies de configuration, on ne sait donc toujours pas à quel point une telle utilisation explicite de modules deviendra populaire parmi les utilisateurs de Spring. Jusqu'à présent, nous n'avons pas reçu beaucoup de demandes, malgré un grand intérêt général pour les versions récentes de Java.

Les vidéos et les slides des sessions Spring One associées sont disponibles : Spring 6, Spring Native et Spring Observability.

 

Evaluer cet article

Pertinence
Style

Contenu Éducatif

BT