Java EE contre J2EE contre Jakarta EE

1. Introduction

Avez-vous déjà entendu parler de Java EE? Qu'en est-il de Java 2EE, J2EE ou maintenant Jakarta EE? En fait, ce sont tous des noms différents pour la même chose: un ensemble de spécifications d'entreprise qui étendent Java SE.

Dans ce court article, nous décrirons l'évolution de Java EE.

2. Histoire

Dans la première version de Java, les extensions d'entreprise Java faisaient simplement partie du noyau JDK.

Puis, dans le cadre de Java 2 en 1999, ces extensions ont été séparées des binaires standard, et J2EE , ou Java 2 Platform Enterprise Edition, est né. Il conservera ce nom jusqu'en 2006.

Pour Java 5 en 2006, J2EE a été renommé Java EE ou Java Platform Enterprise Edition. Ce nom resterait jusqu'en septembre 2017, lorsque quelque chose d'important s'est produit .

Voir, en septembre 2017, Oracle a décidé de céder les droits de Java EE à la Fondation Eclipse (le langage appartient toujours à Oracle) .

3. En transition

En fait, la Fondation Eclipse devait légalement renommer Java EE. C'est parce qu'Oracle a les droits sur la marque «Java».

Alors pour choisir le nouveau nom, la communauté a voté et choisi: Jakarta EE. D'une certaine manière, c'est toujours J EE.

* Nouveau nom annoncé

C'est encore une histoire en évolution, cependant, et la poussière n'est pas complètement retombée.

Par exemple, alors qu'Oracle a ouvert le code source, ils n'ont pas ouvert toute la documentation. Il y a encore beaucoup de discussions sur cette question en raison de problèmes juridiques qui rendent difficile la documentation open-source liée, par exemple, à JMS et EJB.

On ne sait pas encore si la nouvelle documentation Eclipse Foundation pourra faire référence aux originaux.

Aussi, curieusement, la Fondation Eclipse ne peut pas créer de nouveaux packages Java en utilisant l' espace de noms javax , mais elle peut créer de nouvelles classes et sous-classes sous celles existantes.

La transition signifie également un nouveau processus pour ajouter des spécifications à Jakarta EE. Pour mieux le comprendre, voyons à quoi ressemblait ce processus sous Oracle et comment il évolue sous la Fondation Eclipse.

4. L'avenir

Historiquement, pour qu'une fonctionnalité soit transformée en «EE», nous avions besoin de trois choses: une spécification, une implémentation de référence et des tests. Ces trois choses pourraient être fournies par n'importe qui dans la communauté, et un comité exécutif déciderait quand elles seraient prêtes à être ajoutées à la langue.

Pour mieux comprendre le processus passé, examinons de plus près ce que sont les JSR, Glassfish et le TCK et comment ils incarnaient de nouvelles fonctionnalités EE .

Nous aurons également un aperçu de ce à quoi nous attendre à l'avenir.

4.1. Le JCP et maintenant, l'EFSP

Dans le passé, le processus par lequel une nouvelle fonctionnalité EE était née s'appelait le Java Community Process (JCP).

Java SE utilise toujours le JCP aujourd'hui. Mais, depuis qu'EE a changé de propriétaire, d'Oracle à Eclipse Foundation, nous avons un nouveau processus distinct pour cela. C'est le processus de spécification Eclipse Foundation (EFSP) et c'est une extension du processus de développement Eclipse.

Il existe cependant des différences importantes, principalement en ce qui concerne «la transparence, l'ouverture, la charge partagée et la neutralité des fournisseurs». Les organisateurs de l'EFSP, par exemple, envisagent des groupes de travail collaboratifs indépendants des fournisseurs, un processus de certification en libre-service et une organisation qui fonctionne et gouverne comme une méritocratie.

4.2. JSR

Dans le JCP, la première étape pour ajouter une fonctionnalité à EE était de créer une demande de spécification JSR ou Java. Le JSR était un peu comme l' interface d'une fonction EE. Le comité exécutif du JCP a examiné et approuvé un JSR terminé, puis les contributeurs de JSR l'ont codé et mis à la disposition de la communauté.

Le JSR-339 - ou JAX-RS - qui a été proposé à l'origine en 2011, approuvé par JCP en 2012 et finalement publié en 2013 en est un bon exemple.

Et tandis que la communauté pouvait toujours peser pendant qu'une spécification était en discussion, le temps a montré qu'une approche axée sur la mise en œuvre - comme dans le cas de JSR 310, java.time et Joda Time - avait tendance à créer des fonctionnalités et des API plus largement acceptées. .

Ainsi, l'EFSP reflète cette vision du code d'abord dans son objectif déclaré: «L'EFSP sera d'abord basé sur l'expérimentation pratique et le codage, afin de prouver que quelque chose mérite d'être documenté dans une spécification.

4.3. Glassfish

Ensuite, dans le cadre du JCP, un JSR avait besoin d'une implémentation de référence. C'est un peu comme la classe qui implémente l' interface . Une implémentation de référence aide les développeurs de bibliothèques compatibles ou d'autres organisations qui souhaitent créer leur propre implémentation de la spécification.

Pour les fonctionnalités Java EE, le JCP a utilisé Glassfish pour ses implémentations de référence.

Et si cette centralisation sur Glassfish simplifiait le processus de découverte pour les implémenteurs, cette centralisation exigeait également plus de gouvernance et avait tendance à favoriser un fournisseur par rapport à un autre.

Par conséquent, l'EFSP ne nécessite pas d'implémentation de référence, mais uniquement une implémentation compatible . En termes simples, ce changement subtil fait que les implémentations à l'intérieur d'une architecture centrale, comme Glassfish, ne seront pas préférées par inadvertance par la fondation.

4.4. TCK

Enfin, le JCP exigeait que les fonctionnalités EE soient testées via le kit de compatibilité technologique, ou TCK.

Le TCK était une suite de tests pour valider un EE JSR spécifique. En termes simples, pour se conformer à Java EE, un serveur d'applications doit implémenter tous ses JSR et réussir tous les tests sur le TCK désigné.

Pas beaucoup de changements ici. Oracle a ouvert le TCK ainsi que les EE JSR. Bien entendu, tous les futurs documents et le TCK seront open-source.

5. Conclusion

Java EE a certainement beaucoup évolué au cours de ces années. C'est agréable de le voir continuer à changer et à s'améliorer.

De nombreux défis nous attendent, alors espérons une transition en douceur.