Résumé de l'actualité Java : présentation de Spring AI, Spring Modulith 1.0 et Testcontainers Desktop

Accueil InfoQ Actualités Tour d'horizon de l'actualité Java : Présentation de Spring AI, Spring Modulith 1.0, Testcontainers Desktop

28 août 2023 12 min de lecture

par

Michael Redlich

Le résumé Java de cette semaine du 21 août 2023 présente des actualités d'OpenJDK, JDK 22, JDK 21, Jakarta EE, BellSoft, Spring Modulith 1.0, Spring Boot, Spring Authorization Server, Spring Batch, Spring AI, Testcontainers, Open Liberty, Quarkus, MicroProfile. Métriques et télémétrie, Micronaut, Groovy, Tomcat, Grails, JHipster Lite, Vert.x Pinot Client, Yupiik Fusion et conférence SpringOne.

Ron Pressler, architecte et responsable technique du projet Loom chez Oracle, a présenté le projet JEP 8307341, Préparez-vous à restreindre l'utilisation de JNI, qui propose de restreindre l'utilisation de l'interface native Java (JNI) intrinsèquement dangereuse en conjonction avec l'utilisation de méthodes restreintes. dans l'API Foreign Function & Memory (FFM) qui devrait devenir une fonctionnalité finale du JDK 22. La stratégie d'alignement, à partir du JDK 22, fera en sorte que le runtime Java affiche des avertissements concernant l'utilisation de JNI, à moins qu'un utilisateur FFM n'active des fonctionnalités natives non sécurisées. accès en ligne de commande. Il est prévu que dans les versions postérieures au JDK 22, l'utilisation de JNI génère des exceptions au lieu d'avertissements.

Version 7.3.1 du harnais de tests de régression pour le JDK,jtreg, a été publié et prêt à être intégré dans le JDK qui corrige une régression introduite dansjtreg 7.3 qui empêchait de configurer correctement les variables d'environnement par défaut sous Windows. Plus de détails sur cette version peuvent être trouvés dans les notes de version.

La build 35 reste la build actuelle dans les builds à accès anticipé du JDK 21. De plus amples détails sur cette version peuvent être trouvés dans les notes de version.

La version 12 des versions à accès anticipé du JDK 22 a également été mise à disposition la semaine dernière, avec des mises à jour de la version 11 qui incluent des correctifs à divers problèmes. De plus amples détails sur cette version peuvent être trouvés dans les notes de version.

Pour JDK 22 et JDK 21, les développeurs sont encouragés à signaler les bogues via la base de données de bogues Java.

Dans son blog hebdomadaire Hashtag Jakarta EE, Ivar Grimstad, défenseur des développeurs de Jakarta EE auprès de la Fondation Eclipse, a fourni les résultats du vote sur les motions visant à ajouter les spécifications Jakarta Data, Jakarta MVC et Jakarta NoSQL à la plateforme Jakarta EE 11. Une seule de ces spécifications,Données de Jakarta, a passé.

Quelques commentaires de ceux qui ont voté contre ou se sont abstenus d’inclure Jakarta MVC :

Il s'agit d'une spécification mature avec une certaine adoption pour le moment, mais avant de rendre cela obligatoire, il devrait y avoir davantage d'adoption de la part du fournisseur. Comme mentionné précédemment par d'autres, il pourrait être ajouté à chaque profil en tant que spécification autonome, de sorte que personne ne soit empêché de l'utiliser pour le moment et créer davantage de demande pour l'ajouter dans une version future (ou donner une raison pour une mise à jour sur les prochaines versions). Plan).

J’encourage ce travail et j’espère qu’il se poursuivra. J’attends avec impatience l’adoption éventuelle par la plateforme.

Je pense que c'est un ajout intéressant à la plateforme, et nous l'avons déjà ajouté à GlassFish où il peut être utilisé immédiatement. Nous avons cependant plusieurs préoccupations. Parmi eux, le fait que Jakarta MVC est basé sur Jakarta REST, tandis que le cadre MVC existant dans Jakarta EE est basé sur Jakarta Servlet. Baser de nouvelles API sur REST rend encore plus confus la question de savoir quelle « API de gestion HTTP » à Jakarta EE est la principale. Nous aimerions voir une base commune être établie entre Jakarta Servlet et Jakarta REST, avant d'accepter quoi que ce soit dans la plate-forme qui s'appuie sur Jakarta REST.

Quelques commentaires de ceux qui ont voté contre ou se sont abstenus d'inclure Jakarta NoSQL :

La conception architecturale actuelle semble nécessiter des mises à jour plus fréquentes que prévu pour les versions de la plate-forme de Jakarta - cela donne un argument solide pour la maintenir en dehors de la plate-forme maintenant. Une autre exigence pourrait être d’ajouter en premier Jakarta Data et Jakarta Config. En général, prendre en charge NoSQL est une bonne idée – cela pourrait donc changer à l'avenir.