Anticipant une release GA à la mi-2020, l'équipe de projet de la plate-forme Jakarta EE a présenté le plan de livraison de Jakarta EE 9 au comité directeur de Jakarta EE. Il est prévu que Jakarta EE 9 soit une version d'outils stable à partir de laquelle : les fournisseurs d'outils puissent prendre en charge le nouvel espace de noms de packages jakarta ; les équipes de développement puissent tester la migration de leurs applications vers le nouvel espace de noms; et les fournisseurs d'exécution puissent tester et fournir des options et des fonctionnalités qui prennent en charge la migration et la compatibilité descendante avec Jakarta EE 8. Jakarta EE 9 peut également être considéré comme une base pour l'innovation afin de piloter de nouvelles fonctionnalités dans Jakarta EE 10 et au-delà.
Lorsque Oracle a choisi la fondation Eclipse comme le nouveau foyer pour Java EE, Reza Rahman, responsable principal de programme, Java sur Azure chez Microsoft, a invité la communauté Java à participer à deux enquêtes. La première enquête, menée en août 2017, a demandé si Java EE devait être renommé. Les deux tiers des répondants étaient en faveur du maintien du nom Java EE. La deuxième enquête, menée en novembre 2017, a demandé si Oracle devait autoriser la Fondation Eclipse à maintenir la marque Java et javax comme espace de noms de packages. Les trois quarts des répondants ont soutenu cette initiative. Dans une lettre ouverte commune de la communauté pour Oracle, Reza Rahman a résumé ces résultats et énuméré plusieurs raisons de maintenir le statu quo, notamment : Java EE maintient une marque forte; renommer Java EE pourrait entraîner une confusion marketing; et Java EE devrait être valorisée comme une plate-forme open source.
Les négociations entre la Fondation Eclipse et Oracle, réglées en mai 2019, sur les droits de Jakarta EE sur les marques Java ont déterminé que les marques Java sont la propriété exclusive d'Oracle et la Fondation Eclipse n'a pas le droit de les utiliser. Par conséquent :
- L'espace de noms de packages
javaxpeut être utilisé dans les spécifications de Jakarta EE mais peut être utilisé "tel quel" uniquement. Aucune modification de l'espace de noms de packagesjavaxn'est autorisée dans les spécifications de composants Jakarta EE. Les spécifications Jakarta EE qui continuent à utiliser l'espace de noms de packagesjavaxdoivent rester compatibles avec les spécifications Java EE et le TCK correspondants.- Les spécifications des composants Jakarta EE utilisant l'espace de noms de packages
javaxpeuvent être entièrement omises des futures spécifications de la plate-forme Jakarta EE.- Les noms de spécifications doivent être passés d'une convention de dénomination "Java EE" à une convention de dénomination "Jakarta EE". Cela comprend des acronymes tels que EJB, JPA ou JAX-RS.
David Blevins, PDG de Tomitribe, a proposé deux propositions, avec des avantages et des inconvénients pour chacune, comme solution au passage de javax vers jakarta concernant la migration de l'espace de noms des packages : le "big bang", migrez d'un seul coup; et "incrémental", migrez si nécessaire au fil du temps. Les réponses aux propositions semblaient favoriser l'approche du "big bang", mais David Blevins ne s'est pas arrêté là. Une nouvelle section d'espace de noms au sein du repository GitHub de la plate-forme Jakarta EE a été créé comme un "lieu informel de type wiki où les données peuvent être collectées sur les différents impacts du changement d'espace de noms de javax vers jakarta." en expliquant sa justification de cet effort :
Un mois de discussion ne portera aucun fruit si nous ne conservons pas les informations au fur et à mesure. Les gens cesseront de contribuer très rapidement en raison de leur incapacité à digérer deux semaines de discussions libres.
L'analyse de bytecode de David Blevins a produit plusieurs documents qui comprenaient l'API Jakarta EE dépendances, un mapping de javax à jakarta et des modifications transitives sur les API Jakarta EE.
Mike Milinkovich, directeur exécutif de la Fondation Eclipse, a récemment diffusé moving forward with Jakarta EE9 et a reconnu l'effort de la communauté Java dans le développement de ce plan de livraison, en écrivant :
Beaucoup de temps et d'énergie ont été consacrés à son développement. Il a été passionnant de voir les ... euhm passionnantes ... discussions évoluer vers un consensus assez large sur cette approche. Je voudrais particulièrement souligner les contributions de Steve Millidge, Kevin Sutter, Bill Shannon, David Blevins, et Scott Stark pour leur travail inlassable et parfois ingrat pour guider ce processus.
En réfléchissant à 2019, Mike Milinkovich a également noté les points importants qui comprenaient : le succès de la conférence virtuelle inaugurale JakartaOne; Jakarta EE ayant été l'un des récipiendaires du Duke's Choice Award; et la publication du second Jakarta EE developers survey.
Conformément aux responsabilités de tous les comités de Jakarta EE, l'équipe de la plateforme de projets de Jakarta EE est responsable de : produire la feuille de route et le plan de livraison; suivre les délais de publication; s'assurer qu'au moins une implémentation compatible est disponible; et fournir des mises à jour périodiques au comité directeur et au comité de spécifications. Ceci est requis pour chaque version de Jakarta EE et suit le Jakarta EE Specification Process (JESP). L'élaboration du plan de llivraison était ouverte aux contributions de la communauté Java via des listes de diffusion et les téléconférences hebdomadaires de la plate-forme Jakarta EE.
Steve Millidge, fondateur et PDG de Payara, a discuté de la justification derrière les décisions du plan de livraison, en écrivant :
Avec le changement d'espace de noms requis de javax vers jakarta, cela a créé une rupture avec la compatibilité descendante. Le projet a profité de l'occasion pour supprimer un certain nombre d'anciennes API, en rendre certaines plus facultatives (et donc pas nécessaires pour un nouveau serveur d'applications) et pour ne pas exiger de compatibilité descendante avec les applications écrites dans l'ancien espace de noms. Cela signifie qu'il est possible de fournir un nouveau serveur d'applications entièrement compatible avec Jakarta EE 9 qui ne prend en charge que les API Jakarta EE 9 dans le nouvel espace de noms sur JDK 11. Pour moi, c'est une énorme victoire et nous donne l'occasion d'innover avec les nouveaux runtimes Jakarta EE 9, tout en offrant la possibilité de prendre en charge les anciennes applications sur les produits Jakarta EE 9.
Will Lyons, directeur principal, gestion de projets chez Oracle, a résumé ses réflexions sur la version Jakarta EE 8 en mettant l'accent sur les domaines à améliorer, en écrivant :
Le but de la rétrospective était de recueillir des commentaires sur le processus de livraison de Jakarta EE 8 qui peuvent être transformés en actions pour améliorer notre livraison des versions ultérieures et permettre à la plus grande partie de la communauté de participer.
Les domaines à améliorer comprenaient la gestion des spécifications et des versions, les communications et l'organisation. En réponse, le comité directeur de Jakarta EE se concentrera sur les améliorations dans tous ces domaines.
Jakarta EE 8, officiellement publié en septembre 2019, a été livré en tant que Java EE 8 en utilisant l'espace de noms de packages javax . Le principal objectif de Jakarta EE 9 est de fournir des spécifications similaires à Jakarta EE 8 avec l'espace de noms de packages jakarta implémenté dans la spécification.
Ressources
- Update on Jakarta EE Rights to Java Trademarks par Mike Milinkovich (3 mai2019)
- Jakarta EE 9 Release Plan par Jakarta EE
- Summary of Community Retrospective on Jakarta EE 8 Release par Will Lyons (13 janvier 2020)
- Moving Forward with Jakarta EE 9 par Mike Milinkovich (16 janvier 2020)
- Jakarta EE 9 Release Plan Approved par Steve Millidge (27 janvier 2020)