Après plusieurs mois de négociations, la fondation Eclipse et Oracle n'ont pas été capables de s’entendre sur les termes d’un accord pour que la communauté Eclipse puisse modifier l’espace de noms des packages javax ou utiliser les marques Java actuellement utilisées dans les spécifications Java EE. En conséquence, toutes les mises à jour et les améliorations futures apportées à la structure sous les auspices de Jakarta EE devront utiliser un nom de package différent et nécessiteront une migration du code dans les applications et les bibliothèques.
Mike Milinkovich, directeur exécutif de la fondation Eclipse, a expliqué la fin des négociations sur l'utilisation du package javax.* dans un article de blog de la fondation Eclipse intitulé " Mise à jour des droits de Jakarta EE sur les marques Java ". Cet article indique les droits de licence convenus pour le package historique et représente une ligne claire pour les futures implémentations de Jakarta EE à mesure que ses spécifications et son kit de test de compatibilité (TCK) évoluent. "Les implications de ceci sont les suivantes", écrit Milinkovich:
L'espace de noms du package javax peut être utilisé dans les spécifications de Jakarta EE, mais uniquement "tel quel". Aucune modification de l'espace de nom du package javax n'est autorisée dans les spécifications de composants Jakarta EE. Les spécifications Jakarta EE qui continuent à utiliser l'espace de noms du package javax doivent rester compatibles avec le TCK et les spécifications Java EE correspondantes.
Les spécifications des composants Jakarta EE utilisant l'espace de noms du paquet javax peuvent être entièrement omises des futures spécifications de la plate-forme Jakarta EE.
Les noms de spécifications doivent être changés d'une convention de dénomination "Java EE" à une convention de dénomination "Jakarta EE". Cela inclut des acronymes tels que EJB, JPA ou JAX-RS.
Le changement de nom de package élimine toute ambiguïté de propriété puisque Java EE 8 et ses versions antérieures ont été développées sous la supervision de Sun et Oracle, et que Jakarta EE 8 et versions ultérieures sont supervisées par la fondation Eclipse. Cette modification aura un impact sur toutes les API EE, car elles commencent toutes par javax. Ce changement aura probablement des répercussions sur de nombreuses applications Web non liées à EE, y compris les applications Web de Spring, comme EE contient l'API Java Servlet , API Java Mail, et d'autres composants critiques.
Mark Little, responsable technique JBoss pour Red Hat, a fourni une analyse personnelle et technique des efforts importants nécessaires pour cette refactorisation.
Dans un fil Twitter, Milinkovich souligne que ces négociations étaient extrêmement complexes et note qu'Oracle a effectué de nombreux dons substantiels:
Oracle a fourni des millions de lignes de code dans les implémentations de référence pour Java EE, notamment GlassFish, Jersey, Grizzly, etc. Oracle a fourni le TCK Java EE. Ce fut un grand pas en avant pour eux, car il était jusque-là hautement confidentiel et exclusif. Il s’agissait d’un actif très important, qui rapportait des millions de dollars en revenus de licences issus de Java EE. Oracle concède sous licence leurs droits d'auteur sur toutes les spécifications Java EE. Cela inclut tout le travail passé qui a eu lieu chez Sun et BEA, il s’agit donc d’un pourcentage très élevé du contenu global des spécifications.
Le changement de nom du package obligera les développeurs à modifier leurs applications et leurs bibliothèques pour utiliser le nouvel espace de noms. Cela introduit un problème de compatibilité dans lequel les applications existantes doivent être activement migrées sinon elles pourront présenter un risque de compatibilité avec le prochain Jakarta EE. Les environnements de développement intégrés, tels qu'IntelliJ IDEA, Apache NetBeans et Eclipse, peuvent aider à automatiser ce refactoring. L'auteur de ByteBuddy, Rafael Winterhalter, a également expliqué sur Twitter à quel point de puissants agents d'instrumentation peuvent modifier de manière dynamique les informations sur les packages. Mark Struberg, responsable technique de la JSR-382, a décrit certaines des autres options disponible plus en détail, tout en notant "Toutes ces options ont un inconvénient et je ne sais toujours pas moi-même quelle serait la meilleure solution".
Cette migration est un changement par rapport à la longue histoire de compatibilité de Java SE et de Java EE. "Près de deux décennies de logiciels cassés sans raison valable. Absolument stupéfiant", se lamente Josh Long , Spring Devloper Advocate pour Pivotal. Josh Long poursuit: "Misez sur les normes du Java Community Process (JCP), ont-ils dit. Faites confiance au JCP, ont-ils déclaré."
Le JCP est une représentation des membres de la communauté élus et d'experts qui font évoluer Java SE (JSR-386.) et Java EE (JSR-000366) mais ne détient aucun droit sur la marque déposée de Java dans la mesure où elle se rapporte à des programmes d'ordinateur . La marque déposée s’applique au JCP lui-même, qui est autorisé à utiliser le mot en son nom.
L'applicabilité du JCP pour Java EE a été évaluée par l'industrie depuis plusieurs années avant cet événement. En 2016, les dirigeants d'Oracle Anil Gaur et Thomas Kurian ont partagé une stratégie pour Java EE avec le JCP. Oracle a ensuite fait don de Java EE à la fondation Eclipse en 2017. Un an après, Oracle a déclaré qu'" il ne recommande ni ne prend en charge l'utilisation du processus JCP pour aucune amélioration fonctionnelle future de Java EE 8. ". Ce processus est toujours utilisé pour Java SE, guidé par Heather Vancura .
David Blevins, PDG de Tomitribe, a expliqué comment les développeurs et les architectes peuvent participer à la discussion de la transition de Jakarta EE vers l'espace de noms jakarta qui s'achèvera le dimanche 9 juin 2019. Les personnes intéressées à participer peuvent également consulter le processus de spécification de Jakarta EE pour leur successeur du JCP, ou rejoindre une nouvelle liste de diffusion, Jakarta EE Platform Dev.