Jakarta EE 9.1
Cinq mois après la sortie de Jakarta EE 9, le Groupe de travail Jakarta EE a annoncé la sortie des spécifications Plateform et Web Profile de Jakarta EE 9.1 et les TCK associés. Depuis ses débuts en 2018, deux versions majeures - Jakarta EE 8 en 2019 et Jakarta EE 9 en 2020 - ont été publiés. Il s'agit de la première version intermédiaire avec laquelle les développeurs peuvent désormais : développer et déployer des applications Jakarta EE 9.1 sur JDK 11 et JDK 8 ; profiter des nouvelles fonctionnalités Java SE 11 et des nouvelles technologies ajoutées depuis Java SE 8 ; migrer les applications Jakarta EE 9 existantes vers Java SE 11 sans modifications ; et migrer les applications Java EE et Jakarta EE 8 existantes vers Jakarta EE 9.1 en utilisant le même processus simple disponible pour la migration vers Jakarta EE 9.
À l'heure actuelle, il existe cinq implémentations compatibles de Jakarta EE 9.1, dont IBM et Tomitribe ayant récemment annoncé que Open Liberty et TomEE, respectivement, ont passé le TCK. Tous sont certifiés Plateform et WebProfile sauf indication contraire :
- IBM Open Liberty 21.0.0.3-beta: Java 8 (TCK) and Java 11 (TCK)
- Eclipse Glassfish 6.0 (TCK) and 6.1-RC1 (TCK)
- Apache TomEE 9.0.0.M7 Web Profile (TCK)
- Red Hat Wildfly 23.0.2.Final: Java 8 (TCK) and Java 11 (TCK)
- ManageCat ManageFish Platform (TCK)
Le chemin a été long pour Tomitribe et la Foundation Apache Software pour certifier TomEE en tant qu'implémentation Jakarta compatible EE 9.1. David Blevins, PDG de Tomitribe, se souvenant de ce travail et la voie à suivre vers Jakarta EE 10, a déclaré à InfoQ :
La version Jakarta EE 9.1 est tout simplement historique pour Apache TomEE et la communauté Apache. Tous les projets Apache, y compris TomEE, Tomcat, CXF, ActiveMQ, MyFaces et bien d'autres, ont perdu l'accès au Java EE TCK en 2013 lorsque la licence Java EE de 10 ans d'Apache a expirée. Cet accès a été restauré via la première version de Jakarta EE en septembre 2019 et au cours des 20 derniers mois, nous, dans la communauté TomEE, avons été en mesure de combler l'écart sur trois versions majeures d'EE (7, 8 et 9) et d'atteindre la certification pour le Web Profile de Jakarta EE 9.1 le jour de la sortie.
Après avoir quitté le JCP en 2010, Apache a rejoint le groupe de travail Jakarta EE en tant que membre invité. L'importance de ces deux événements ne peut pas être surestimée. Nous attendons avec impatience le profil de base de Jakarta EE 10 et l'élimination de près de 10 ans d'idées refoulées dans les prochaines versions de Jakarta EE. C'est un grand moment.
La route vers Jakarta EE 10
Prévu pour une version GA au premier trimestre 2022, le développement de Jakarta EE 10 est déjà en cours avec de nombreuses spécifications actuellement mises à jour. L'accent sera également mis sur l'amélioration de l'alignement avec Jakarta Contexts and Dependency Injection (CDI) pour compléter ce que cette spécification prend déjà en charge dans la plateforme Jakarta EE telle que l'annotation @Transactional
dans Jakarta Transactions, la dépréciation du managed bean dans Jakarta Server Faces et utilisation de CDI dans Jakarta Security.
Les spécifications Jakarta EE qui bénéficieraient de CDI incluent : les artefacts injectables dans Jakarta Batch; la dépréciation de l'annotation @Context
en faveur de l'injection de CDI dans les Jakarta RESTful Web Services ; et l'amélioration de la propagation du contexte CDI dans Jakarta Concurrency.
Malgré une spécification Jakarta Enterprise Beans établie avec des versions prenant en charge Jakarta EE 8 et Jakarta EE 9, le développement de cette spécification est peu probable en ce moment. Cependant, Arjan Tijms, consultant Java indépendant, a discuté de l'importance de la prise en charge continue de cette spécification, en écrivant :
Le plan pour Jakarta EE 10 est d'introduire des versions basées sur CDI de presque toutes les fonctionnalités d'Enterprise Bean. Ces fonctionnalités, ainsi que les fonctionnalités d'Enterprise Beans telles que
@Transactional
, qui ont déjà des alternatives, signifient que le nouveau code n'aura pas besoin d'utiliser beaucoup, le cas échéant, de technologie Jakarta Enterprise Beans.Cependant, il reste un cas d'utilisation majeur à considérer : le code existant qui utilise encore beaucoup d'Enterprise Beans, comme l'annotation
@Stateless
. Les technologies plus anciennes, telles que Eclipse GlassFish, conserveront probablement leurs vénérables implémentations Enterprise Beans pendant longtemps, et il n'est pas prévu de déprécier ou d'élaguer la spécification de sitôt.
Le groupe de travail Jakarta EE a également défini un objectif pour prédire comment les spécifications de Jakarta EE s'aligneront sur une version spécifique de Java SE. Des discussions sur les appels hebdomadaires de la plate-forme pour déterminer quelle version de Java SE devrait être requise par Jakarta EE 10 ont donné un certain nombre d'options qui étaient réduit à trois. La communauté Java a eu l'opportunité de voter pour son option préférée :
- Option 1 : source=Java SE 11, bin=Java SE 11, TCK=Java SE 11+
- Java SE 11 en tant que niveau source/langue et niveau binaire pour tous les fichiers JAR d'API. Les implémentations compatibles sont libres de passer les TCK en utilisant n'importe quelle version de Java SE à 11 ou plus.
- Option 2 : source=Java SE 11, bin=Java SE 17, TCK=Java SE 17+
- Java SE 11 comme niveau source/langage et Java SE 17 comme niveau binaire pour tous les JAR d'API. Les implémentations compatibles sont libres de passer les TCK en utilisant n'importe quelle version de Java SE à 17 ou plus.
- Option 3 : source=Java SE 17, bin=Java SE 17, TCK=Java SE 17+
- Java SE 17 en tant que niveau source/langue et niveau binaire pour tous les fichiers JAR d'API. Les implémentations compatibles sont libres de passer les TCK en utilisant n'importe quelle version de Java SE à 17 ou plus.
Le vote final a révélé que l'option 1 était l'option préférée pour Jakarta EE 10.
Vous trouverez plus de détails sur ce à quoi les développeurs peuvent s'attendre dans Jakarta EE 10 dans cet article de blog.
Les Jakarta EE Ambassadors, un groupe indépendant de développeurs Java déterminés à faire avancer Jakarta EE grâce à la participation active de la communauté et au plaidoyer, ont créé ce guide de contribution disponible pour les développeurs souhaitant contribuer à Jakarta EE 10.