L'équipe Spring Boot a récemment publié sa version 2.2.0 M1, le premier jalon vers la publication finale de Spring Boot 2.2. Ce jalon comprend des améliorations de consommation mémoire et de performances. Il inclut la détection de Kubernetes et des mises à jour de ses dépendances. Plus de 140 problèmes ont été résolu dans cette publication.
JMX est désactivé par défaut à partir de cette version. Brian Clozel, de l’équipe Spring remarque :
"Cette fonctionnalité ne semble pas être très utilisée et utilise une quantité significative de ressources. Nous envisageons sa désactivation par défaut pour la version 2.2."
Les améliorations de performance lors du démarrage comprennent un nouvelle fonctionnalité pour apporter la possibilité d’une initialisation globale en mode lazy, la suppression de certaines analyses JPA qui étaient redondantes, une analyse des grands fichiers de configuration plus rapide ainsi que qu’une amélioration de la rapidité de création et d’injection des beans.
L’initialisation globale en mode lazy (que l'on active avec spring.main.lazy.initialization) est une nouvelle fonctionnalité de la version 2.2 qui mérite d'être mentionnée. Elle réduit le temps de démarrage de façon significative en reportant la création des beans jusqu'au moment de leur utilisation. Cela vient cepandant avec des inconvénients. Les premières requêtes HTTP servies peuvent voir un temps de réponse augmenté, du fait que les beans qui leur sont nécessaires doivent être créés. Les requêtes suivantes ne seront toutefois plus affectées. Un autre inconvénient, plus risqué, est que les éventuelles erreurs dans l'assemblage des beans, qui étaient détectées dès le démarrage, ne seront plus vues que bien plus tard.
Le temps de démarrage a aussi été amélioré en désactivant les scanners JPA (par exemple celui d'Hibernate). Spring Boot fournit déjà sont propre scanner JPA. Tous les autres scanner étaient donc redondants et ne faisaient que ralentir inutilement ce démarrage.
L’analyse des fichiers de configuration de grande taille, un processus qui doit intervenir lors du démarrage d’une application, est maintenant plus rapide. C’est une excellente chose pour les utilisateurs, comme le mentionnait une personne sur Reddit : "… le temps de chargement d’un fichier YAML (environ 5000 propriétés) prenait 10 secondes sur mon Core i7".
La création et l'injection de beans ont un impact direct sur le temps de démarrage des applications et l’utilisation mémoire. Spring Boot fait une sélection plus intelligente des beans qu’il a besoin de créer et d’injecter. En particulier, les beans utlisés par les actionneurs Spring Boot ne sont maintenant créés que si ces actionneurs sont effectivement utilisés et exposés (par exemple via HTTP). Spring Boot est aussi plus intelligent dans ses auto-configurations. Si une auto-configuration utilise un bean qui n’est injecté que par le constructeur, alors il n’est pas nécessaire de le créer et de l’injecter dans d’autres endroits où il se sera même pas utilisé. Les auto-configurations sont maintenant plus sélectives quant à l’utilisation des beans dont elles ont besoin.
L’annotation @ConditionalOnCloudPlatform a reçu une mise à jour avec la possibilité de détecter quand l’application est exécutée dans un environnement Kubernetes. Cela permet aux utilisateurs ou aux frameworks externes de configurer des fonctionnalités ou des implémentations particulières qui ne s’appliquent qu’à Kubernetes.
Sur le plan de dépendances, AssertJ, Mockito, Kafka, Spring HATEOAS, et Spring Data sont les principales dépendances externes qui ont été mises à jour, parmi d’autres.
Il y a également eu des changements dans les dépendances Java EE. Toutes les dépendances Java EE ont été remplacées par leurs dépendances équivalentes Jakarata EE. Cela fait partie d’un plan de migration plus large, de Java EE à Jakarta EE, le nouveau nom de Java EE géré désormais par la fondation Eclipse.
Les publications intermédiaires sont des points importants dans le cycle de développement de Spring Boot. Cela indique que le produit devient plus solide et que la majorité des bugs et problèmes ont été résolus. Cela indique aussi qu’une publication en version finale est imminente et que les équipes en sont aux réglages fins et au polissage des problèmes restants. Les versions majeures précédentes ont vu entre 4 et 7 pré-publications telles que celle-ci.