Jakarta EE 9, la seconde version officielle depuis ses débuts en 2018, est prévue pour une sortie GA le 20 novembre 2020. Initialement prévue pour le 16 septembre 2020 en conjonction avec la seconde conférence JakartaOne Livestream 2020, des retards ont rendu nécessaire le report de la date de sortie de la release GA.
Comme spécifié dans le plan de release de Jakarta EE 9, les développeurs peuvent s'attendre à une version stable des outils à partir de laquelle : les fournisseurs d'outils peuvent prendre en charge le nouvel espace de noms du package jakarta; les équipes de développement peuvent tester la migration de leurs applications vers le nouvel espace de noms; et les fournisseurs de runtime peuvent tester et proposer des options et des capacités qui prennent en charge la migration et la rétrocompatibilité avec Jakarta EE 8. Jakarta EE 9 peut également être considérée comme une base pour l'innovation pour générer de nouvelles fonctionnalités dans Jakarta EE 10 et au-delà.
David Blevins, CEO de Tomitribe et membre du comité directeur de Jakarta EE, a informé InfoQ des contributions de Kevin Sutter, responsable de la version Jakarta EE 9 chez IBM, concernant le plan de version Jakarta EE 9 :
Kevin Sutter mérite un peu d'être mis en avant pour son travail sur le plan final qui a été approuvé. C'est lui qui a gardé tous les chats au dernier kilomètre. Il a bouclé tous les fils de discussion, organisé les votes ouverts de la communauté, organisé les appels de la communauté tout au long de novembre et décembre et a rédigé le plan final selon le calendrier demandé par le comité directeur.
La première milestone release de Jakarta EE 9, célébrée le 23 juin 2020, comprenait des mises à jour sur le projet Jakarta EE Platform (Platform and Web Profile 9.0.0-RC2 APIs), Jakarta EE TCK (Platform TCK 9.0.0-M1), Eclipse GlassFish 6.0-M1 et le projet Eclipse Transformer. L'événement a réuni 155 développeurs représentant environ 20 pays.
Les spécifications de Jakarta EE mises à jour incluses dans cette nouvelle version ont été progressivement transmises au TCK et au vote. Par exemple, la spécification Bean Validation 3.0 était la première à être prête pour Jakarta EE 9.
Kevin Sutter a parlé à InfoQ de la sortie prochaine de Jakarta EE 9.
InfoQ : Peux-tu décrire à nos lecteurs le processus de certification et de vote pour chaque spécification Jakarta EE.
Kevin Sutter : Le processus de certification et de vote des spécifications garantit que nos parties prenantes (membres du comité de spécification) ont suffisamment examiné et approuvé les artefacts associés à une version des spécifications - le document de spécification lui-même, l'API associée, le TCK (Test Compatibility Kit) et une CI (Compatible Implementation) - qui implémente et teste correctement la spécification. Sans cet ensemble «béni» de produits livrables, les utilisateurs n'aurait pas la confiance nécessaire pour mettre cette technologie en développement ou en utilisation en production. Ce processus de certification et de vote est probablement la tâche la plus importante du comité de spécification EE de Jakarta.
En un mot, chaque projet de spécification (exemple Persistence, Concurrency, Bean Validation, etc.) doit préparer ses artefacts pour ce processus de certification et de vote. Cela se fait via PR (Pull Requests) par rapport au référentiel de spécifications. Tout le matériel nécessaire est fourni soit via certains fichiers markdown définis (par exemple,
_index.md) ou via les listes de contrôle, qui sont ajoutées à chacune des PR.Le comité de spécification désigne un mentor du comité pour s'assurer que toutes les barres sont mises sur les t et que les points sont sur les i pour le scrutin final. Une fois que le mentor a approuvé la PR (en fonction des commentaires de toutes les sources), le mentor peut alors lancer un vote formel sur la version de la spécification. Ce scrutin est effectué sur notre liste de diffusion publique du Comité des spécifications. Outre les membres du comité de spécification, nous encourageons également l'examen et l'approbation du matériel par la communauté au sens large. Le scrutin réussit si nous obtenons une super majorité des membres indiquant un vote +1.
Presque tout le temps, en raison de la diligence raisonnable du mentor et des autres évaluateurs, les bulletins de vote se terminent par un vote qui passe. Cependant, il existe des exceptions documentées où un vote peut devoir être annulé et redémarré une fois les problèmes résolus.
InfoQ : Quel est l'avenir pour Jakarta EE ?
Kevin Sutter : La première à l'horizon est une version Jakarta EE 9.1. À l'origine, Jakarta EE 9 allait prendre en charge la compatibilité avec Java SE 8 et Java SE 11. En raison de certains problèmes découverts lors du test du Platform TCK et CI plus tôt cet été, le support de Java SE 11 a dû être abandonné. Cela a été fait pour nous assurer que nous avons toujours livré Jakarta EE 9 cet automne. Ainsi, Jakarta EE 9 ne supportera que Java SE 8. Dès que Jakarta EE 9 sera sorti, Jakarta EE 9.1 sera en cours afin de supporter Java SE 11. Cela devrait être une version relativement rapide. Les éléments à traiter sont assez bien compris. Il s'agit de codifier ces hypothèses et de terminer la mise en œuvre et les tests. Ensuite, nous pouvons commencer à penser à Jakarta EE 10.
Tout d'abord, nous recherchons activement quelqu'un pour piloter la version Jakarta EE 10. Diriger la version Jakarta EE 9 a été une expérience très enrichissante. J'ai beaucoup appris sur Jakarta EE en tant que plate-forme, ainsi que sur certains des défis auxquels les différentes technologies ont été confrontées. Mais il est temps d'apporter du sang neuf avec de nouvelles idées pour conduire cette prochaine version majeure de Jakarta EE.
En ce qui concerne les éléments spécifiques à Jakarta EE 10, j'ai été tellement attentif à Jakarta EE 9 que je n'ai vraiment pas beaucoup regardé l'avenir. J'aimerais que de nouvelles spécifications soient introduites dans la famille Jakarta EE - peut-être dans le cadre de la plate-forme, mais peut-être simplement en tant que spécifications autonomes.
Nous avons deux nouveaux projets de spécifications qui démarrent tout juste : Jakarta MVC et Jakarta NoSQL. Le projet MVC a commencé avec le JCP et a récemment migré vers Jakarta EE. Ils ont une petite longueur d'avance puisqu'ils créaient activement une spécification sous la direction du JCP. Il sera intéressant de voir s'ils sont suffisamment avancés pour s'intégrer à la plate-forme.
Le projet NoSQL a une expérience de mise en œuvre assez précoce, qui prend en charge notre mantra «code first». L'aspect intéressant de ce projet est de savoir si nous pouvons obtenir une participation communautaire suffisante pour démontrer l'intérêt d'un éventail d'utilisateurs. Et nous pouvons définir comment NoSQL interagit ou non avec les technologies Persistence (JPA) et JDBC existantes.
L'autre gros morceau est MicroProfile (un autre de mes projets favoris). Maintenant que le groupe de travail MicroProfile a été créé, ils créeront des spécifications suivant le Eclipse Foundation Specification Process (EFSP) tout comme Jakarta EE. Cela ouvre la porte à une collaboration accrue entre ces projets. Dans le passé, Jakarta EE avait un problème avec la spécification d'une dépendance à une technologie MicroProfile en raison du manque d'utilisation du FESP. Tout cela devrait maintenant être résolu et j'attends plus de synergie entre ces deux efforts de développement.
InfoQ : Comment la communauté Java peut-elle s'impliquer dans la contribution à Jakarta EE ?
Kevin Sutter : C'est un domaine dans lequel nous pouvons continuer à nous développer. Lors de Jakarta EE 8, les principaux contributeurs étaient des membres du Comité de spécification. Avec Jakarta EE 9, nous avons vu cette sphère s'enrichir et de plus en plus de personnes contribuaient aux projets de spécification et aidaient à préparer les PR pour le vote.
Maintenant que nous avons cette base Jakarta EE 9, nous avons besoin d'encore plus d'implication communautaire. Ma suggestion est de commencer petit. Trouvez un projet qui vous intéresse et demandez comment vous pouvez aider. Ou, surveillez leur liste de diffusion et/ou leurs problèmes et suggérez des changements et des améliorations. Si vous possédez des compétences susceptibles d'aider à résoudre un problème, proposez une PR pour le résoudre.
Presque tous les projets recherchent de l'aide pour définir la prochaine version (de service ou majeure). Alors, franchissez le pas et essayez d'aider. Vous trouverez qu'il est beaucoup plus facile de contribuer au début d'une nouvelle version lorsqu'un plan spécifique n'est pas encore figé.
Il existe également d'autres moyens de contribuer. Il existe plusieurs référentiels liés à la démonstration des capacités de Jakarta EE. Ou peut-être aimez-vous écrire sur la technologie. Les articles de blog sur Jakarta EE sont toujours les bienvenus. Nous avons également le programme "Adopt a Spec" où les JUG peuvent jouer un rôle plus actif avec les spécifications.
InfoQ : Que devraient savoir de plus nos lecteurs sur Jakarta EE 9 ?
Kevin Sutter : Jakarta EE 9 a vraiment été un succès open-source. Cette année a apporté tant de défis. Lorsque nous avons proposé pour la première fois un plan de sortie pour Jakarta EE 9 au cours des premiers mois de 2020, nous pensions vraiment que juin 2020 serait une date de sortie réalisable. Mais, ensuite, la pandémie a frappé et toutes nos vies ont été bouleversées. Même si vous n'étiez pas directement affecté par le virus, vous connaissiez quelqu'un qui l'avait. Ou peut-être que vos enfants sont maintenant scolarisés à domicile pour la première fois. Ou peut-être que votre entreprise a été touchée par le ralentissement économique. Quelles que soient les conditions, vous avez probablement été affecté par le virus. Et cela a eu un effet mondial.
En plus de cela, le travail pour Jakarta EE 9 était un peu plus complexe que prévu à l'origine. L'effet d'entraînement du changement de
javaxenjakartaa été plus complexe que prévu. Le recul est de 20/20, mais certains éléments ont fait surface après que nous ayons commencé à éplucher cet oignon d'espace de nomsjakarta. Et la question de la prise en charge de Java SE 11 a légèrement compliqué le calendrier.Mais nous avons continué à travailler avec la communauté pour déterminer ce qui était faisable. Finalement, nous avons défini à la date du 20 novembre et, jusqu'à présent, cela semble bon!
JakartaOne Livestream 2020, désormais prévu pour le 8 décembre 2020, aura un programme similaire à celui de la conférence inaugurale JakartaOne Livestream 2019 qui a eu lieu parallèlement à la sortie officielle de Jakarta EE 8 en septembre 2019.
A propos l'éditeur
Michael Redlich siège au conseil de direction des ambassadeurs de Jakarta EE et siégera au comité de programme de la conférence JakartaOne Livestream 2020.