L’API Java EE, un standard de référence pour l’écosystème Java depuis près de 20 ans, a été rebaptisée Jakarta EE 9 début décembre dans le cadre de sa première version complète sous la responsabilité de son mainteneur actuel.
Java EE a été conçu à l’origine par Sun Microsystems, puis développé par Oracle. Oracle a fait don du code source en 2017 à la Fondation Eclipse, une organisation qui gère des centaines de projets open source. Au-delà du changement de marque, les ingénieurs logiciel n’auront pas à se débattre avec des modifications monumentales du code lui-même. En fait, le passage de Java EE à Jakarta EE incite pour l’instant à prendre de nouvelles habitudes.
Quoi de neuf avec Jakarta EE 9 ?
Mike Milinkovich, directeur général de la Fondation Eclipse qualifie Jakarta EE 9 de « version forcée » (constrained release, en VO). Le responsable explique que l’objectif d’Eclipse était de simplement remplacer les dénominations des paquets javax.* en jakarta.*.
« Le fait que nous ayons publié cette version d’une manière vraiment contraignante… découle d’une grande décision de la communauté. »
Mike MilinkovichDG, Fondation Eclipse
« Le fait que nous ayons publié cette version d’une manière vraiment contraignante… découle d’une grande décision de la communauté », déclare-t-il. Mike Milinkovich et les membres de la Fondation Eclipse qualifient ce renommage de « big bang ».
Avec Jakarta EE 9, la classe java. servlet. GenericServlet est maintenant désignée par jakarta. servlet. GenericServlet. La nouvelle version n’ajoute aucune propriété, ne supprime aucune méthode obsolète et ne corrige aucun bogue. Cependant, ce changement de nom s’étend à toutes les classes, interfaces et énumérations de la spécification.
Il s’agit avant tout de répondre à des obligations légales. Bien qu’Oracle ait fait don de la spécification à Eclipse, il possède toujours la marque déposée Java. Cette étape qui peut paraître anecdotique représente également une séparation nette entre l’ancien et le nouveau mainteneur du projet.
Les éditeurs qui distribuent des serveurs d’application utilisant des API Java EE devront renouveler leur logiciel pour prendre en charge les appellations de Jakarta EE. Mike Milinkovich se dit toutefois convaincu que les fournisseurs vont rattraper leur retard.
« L’écosystème va progresser au fur et à mesure que la plateforme évolue », assure-t-il. « Et nous sommes très optimistes quant au fait que tous les éditeurs de serveurs d’applications s’engagent à faire avancer les choses ».
Cependant, les ingénieurs devront réécrire les programmes qui contiennent des références aux composants Java EE lorsqu’ils les migreront vers un serveur basé uniquement sur Jakarta EE. De plus, les outils de développement et de déploiement d’applications doivent rattraper leur retard.
Par exemple, si l’on appelle un servlet Java dans l’IDE Eclipse, il utilise par défaut les classes javax estampillées Java EE, même si vous avez configuré Tomcat 10, normalement compatible avec Jakarta EE, en tant que runtime Java. Il signale les erreurs qui n’existent pas et des builds cassées qui ne le sont pas non plus.
Un changement de nom non sans conséquence
« En tant que développeur, la principale raison de passer à Jakarta EE 9 est de migrer votre application et d’être prêt pour les nouvelles choses qui arrivent avec Jakarta EE 10. »
Bert Jan SchrijverCTO, OpenValue
Pour Bert Jan Schrijver, CTO d’OpenValue, un concepteur de logiciels néerlandais, Jakarta EE 9 n’apporte pas de fonctionnalités supplémentaires et ne représente qu’une étape sur la feuille de route de la fondation open source.
« En tant que développeur, la principale raison de passer à Jakarta EE 9 est de migrer votre application et d’être prêt pour les nouvelles choses qui arrivent avec Jakarta EE 10 », considère-t-il. « Mais vous êtes également libre d’attendre et d’adopter Jakarta EE 10 [directement], en évitant la version 9 ».
Bert Schrijver estime que même s’il est préférable de faire de petits pas, donc d’installer la release 9 puis la 10, la décision des ingénieurs dépendra de la situation. « Si vous employez un serveur d’application qui ne supporte pas encore Jakarta EE 9, alors, en tant que développeur, il est inutile de migrer », tranche-t-il.
Selon Bert Schrijver, la démarche de limiter la version initiale de Jakarta EE 9 à un changement de nom a simplifié les choses pour la communauté des développeurs. Si Eclipse avait ajouté de nouvelles fonctions en plus de la modification de name space, cela aurait amené son lot de problèmes plus complexes à résoudre.
