Java EE vs Jakarta EE : quand et pourquoi passer à l’action ?

TL;DR : les principaux enseignements

• Java EE (Enterprise Edition) est depuis longtemps la plateforme de référence pour la création d'applications Java d'entreprise.

• Son successeur, Jakarta EE, poursuit cet héritage sous l'égide de la fondation Eclipse, avec une gouvernance moderne, un soutien actif de la communauté et un changement essentiel : toutes les API utilisent désormais l'espace de noms jakarta.* au lieu de javax.*.

• Java EE arrivant en fin de vie, la migration vers Jakarta EE est essentielle pour assurer la compatibilité, la sécurité et l'innovation à long terme.

• Cet article présente les principales différences, l'importance du changement et la manière de planifier une migration réussie.

À l'heure actuelle, la communauté Java peaufine la troisième et dernière étape : la mise à jour et le transfert des documents de spécification, afin de définir l’objectif de l’API et ses modalités d’utilisation. Et lorsque tout sera terminé, toutes les API Java EE changeront fondamentalement de nom de paquet pour devenir Jakarta EE.

Quelle est la différence entre Java EE et Jakarta EE ?

Pour comprendre l'impact de ce changement, il est impératif de comprendre la différence entre Java EE et Jakarta EE. 

Java EE

Java EE, aujourd'hui Jakarta EE, a été initialement développé par Sun Microsystems avant qu'Oracle rachète la société mère en 2009. Pendant longtemps, Java EE a été la norme pour la création d'applications d'entreprise en Java. Le framework fournit notamment des spécifications pour la messagerie, les Enterprise JavaBeans, la persistance et les services Web. Depuis près de vingt ans, les développeurs s'appuient sur ces composants pour créer des applications d'entreprise robustes, évolutives et faciles à maintenir.

L'architecture bien définie de Java EE a été le choix privilégié des développeurs pendant près d'une décennie. En 2017, la communauté Java a décidé à l'unanimité d'apporter des changements fondamentaux à la norme de développement autrefois vénérée. Pourquoi ? La gestion de Java EE par Oracle n'a pas vraiment été basée sur l'innovation, ce qui a provoqué une frustration généralisée au sein de la communauté.

Jakarta EE

Ce que vous avez toujours connu sous le nom de Java EE sera bientôt entièrement rebaptisé Jakarta EE. Placé sous la gouvernance de la fondation Eclipse, Jakarta EE est le successeur de Java EE et représente, dans une certaine mesure, la tentative d'Oracle d'apaiser la frustration au sein de la communauté. Il s'agit fondamentalement d'une initiative communautaire dont le cœur est l'innovation en matière de logiciels libres.

La différence la plus importante entre les deux frameworks est le changement d'espace de noms. L'espace de noms javax.*, très utilisé dans Java EE, a été remplacé par jakarta.*. Cette mise à jour concerne toutes les API Java d'entreprise et nécessite des modifications des applications existantes qui utilisent Java EE. Il ne s'agit pas seulement d'un changement de marque, c'est la base du développement et de l'innovation future dans le domaine de l'entreprise Java.

En résumé :

• Jakarta EE est le successeur de Java EE.

• Ils définissent tous deux des normes pour le développement de Java dans le cadre des entreprises.

• La principale différence réside dans le nom et l'espace de noms des API.

Quand et pourquoi un développeur doit-il choisir entre Java EE et Jakarta EE ?

Alors que le développement de logiciels d'entreprise continue d'évoluer à un rythme sans précédent, il est vital pour les développeurs de déterminer le meilleur moment pour migrer vers Jakarta EE. Voici quelques facteurs à prendre en compte avant de faire le grand saut :

Exigences du projet

Avant tout, les développeurs doivent tenir compte des exigences spécifiques et nuancées de leur projet. Si l'application dépend fortement de fonctionnalités Java EE héritées qui seront bientôt supprimées ou qui sont encore reproduites à Jakarta, il est judicieux d'attendre pour l'instant. En revanche, si le projet est tout nouveau et tourné vers l'avenir, Jakarta EE est le choix le plus logique car, il est plus moderne, en cours de développement actif et bénéficie du soutien total de la communauté Java.

Prise en charge des serveurs d'applications

Un autre facteur de décision devrait être la prise en charge des serveurs d'application tels que Payara, WildFly et Open Liberty. Les principaux serveurs d'applications ont déjà effectué la transition et prennent désormais en charge Jakarta EE dans son intégralité. Par conséquent, nombre d'entre eux ne prennent plus en charge Java EE. Si votre application d'entreprise repose sur une version obsolète de Java EE (p. ex., J2EE) et que vous souhaitez tirer le meilleur parti des outils de développement modernes et des optimisations de performances, le passage à Jakarta EE s'impose d'emblée.

Communauté et innovation

La communauté qui soutient, contribue et peaufine Jakarta EE se développe assez rapidement. La fondation Eclipse encourage une communauté dynamique de développeurs en herbe et expérimentés, qui contribuent tous activement à l'avenir de Jakarta EE. La situation n'est plus aussi sombre et peu prometteuse qu'elle l'était auparavant.

En revanche, Java EE est dans une impasse en termes de développement actif. Oracle a pratiquement cessé d'y injecter des ressources, ce qui signifie qu'il manque désormais d'innovation. L'attention se porte désormais entièrement sur Jakarta EE, avec pour objectif d'en faire une plateforme de développement Java open source révolutionnaire. Grâce au soutien solide et constant de la communauté, Jakarta EE va continuer à bénéficier de nouvelles capacités et d'améliorations. 

Bien qu'il existe encore un certain soutien communautaire pour et autour de Java EE, il est au mieux très limité. Les développeurs qui pensent à long terme trouveront que ce n'est pas viable et que le passage à Jakarta EE est une bien meilleure solution.

Prise en charge à long terme

Une assistance intermittente à court terme peut suffire pour les applications de base, mais certainement pas pour les applications d'entreprise critiques. Sans un soutien actif et régulier, ces éléments finiront par seffondrer et laisseront l'organisation fortement exposée.

Jakarta EE étant l'avenir de Java EE, on s'attend à ce qu'il bénéficie d'un soutien actif de la communauté à long terme. Java EE étant sur le point de disparaître, la migration vers Jakarta EE est le seul moyen de garantir l'accès à des mises à jour régulières, à des correctifs de sécurité et à de nouvelles fonctionnalités. 

En résumé :

• Jakarta EE est le successeur de Java EE.

• Ils définissent tous deux des normes pour le développement de Java dans le cadre des entreprises.

• La principale différence réside dans le nom et l'espace de noms des API

Comment un développeur passe-t-il de Java EE à Jakarta EE ?

C'est la grande question. Comme l'ont constaté les chefs de projet eux-mêmes, le passage de Java EE à Jakarta EE est aussi complexe que gratifiant.

Voici comment procéder :

1. Évaluer et planifier

Prenez du recul et évaluez soigneusement votre candidature actuelle. Il y a de fortes chances que certains (ou la plupart) des composants et des bibliothèques Java EE qu'il utilise soient compatibles avec Jakarta EE. Pour les grandes applications, il est tout aussi important de déterminer si la migration doit se faire en une seule fois ou par petites étapes contrôlées.

2. Mettre à jour les bibliothèques

La raison est simple : Jakarta EE introduit un tout nouvel espace de noms (jakarta.*). Les développeurs doivent donc mettre à jour toutes les dépendances qui reposent sur les bibliothèques Java EE.

Les deux principaux points d'attention sont les suivants :

• Mise à jour des fichiers pom.xml ou build.gradle (pour les projets basés sur Maven ou Gradle) pour référencer les bibliothèques Jakarta EE.

• Remplacement des importations javax par les importations jakarta correspondantes

3. Refonte du code

Cette étape est tout simplement incontournable. Le remaniement garantit que le code s'aligne parfaitement sur les changements les plus récents et les plus importants apportés aux API de Jakarta EE.

Les pistes de réflexion sont les suivantes : 

• Changement d'espace de noms : jakarta doit remplacer javax dans toutes les bases de code.

• Mise à jour des API : certaines API Java EE ont été dépréciées dans Jakarta EE ou, dans certains cas, entièrement modifiées. Les développeurs devront donc améliorer leur code pour tenir compte de ces changements.

4. Choisir un serveur compatible avec Jakarta EE

Seuls quelques serveurs d'applications Java EE sont entièrement compatibles avec Jakarta EE. Pour le déploiement, les développeurs devront choisir un serveur compatible avec Jakarta EE. Les options les plus courantes sont les suivantes :

• WildFly (anciennement JBoss EAP)

• Payara (le successeur de GlassFish)

• Open Liberty (d'IBM)

• TomEE (variante Java EE d'Apache Tomcat)

5. Tester en détail

Comme pour toute migration d'une ampleur considérable, le fait de ne pas tester le nouveau code conforme à Jakarta pourrait introduire des bugs ou des problèmes récurrents dans votre environnement d'application. Les tests fonctionnels, les tests de performance et les tests d'intégration sont tous essentiels pour vérifier le comportement et les performances de l'application.

Considérations importantes

Si nous devions choisir trois considérations évidentes pour une migration transparente entre Java EE et Jakarta EE, ce serait celles-ci :

• La complexité : la complexité de la migration dépend de la taille et de la complexité de votre application, ainsi que des dépendances.

• Les tests : des tests approfondis font souvent la différence entre une migration réussie et une migration qui tombe à l'eau. 

• Une approche progressive : pour les grandes applications, une approche progressive est le choix le plus judicieux. Cela permet non seulement de réduire considérablement les risques, mais aussi de rendre le processus beaucoup plus facile à gérer.

Prochaine version de Jaspersoft

Chez Jaspersoft, nous nous tenons constamment au courant de toutes les évolutions de l'écosystème Jakarta EE. Avec la version 10.0 qui sortira à l'automne 2025, nous fournissons une prise en charge complète pour Jakarta EE. Nous voulons que les développeurs soient compatibles avec les applications et les cadres Java modernes tout en restant au fait des dernières tendances et technologies.