Je ne vais pas revenir sur l’historique de Java EE, si vous avez besoin d’une mise à jour sur le sujet, je vous recommande la lecture de mon article : “Les rendez-vous manqués de Spring” qui l’évoque longuement.
Pour résumer, un certain nombre de mauvais choix de conception (principalement les versions 1.X et 2.X des EJB) ont grandement nuit à l’image de Java EE (J2EE à l’époque) et ont conduit à l’établissement d’un standard alternatif : le framework Spring. Là où J2EE était lourd à mettre en oeuvre, conduisait à du code très dépendant de la technologie et compliqué à maintenir, Spring amenait une couverture fonctionnelle quasi identique, avec une approche élégante et un code ne comportant (presque) aucune dépendance au framework.
Java EE 5 : une copie largement révisée
Les critiques et le manque d’enthousiasme autour de J2EE ne laissèrent pas de marbre Sun et son entité de spécification le JCP. En 2006, après 3 ans de travail, une nouvelle version de J2EE renommé Java EE, voit le jour. Java EE 5 est une simplification majeure de la plate-forme et comporte une refonte en profondeur des EJB. Les EJB 3 empruntent la légèreté et la facilité de mise en oeuvre à Spring et dépassent même le fameux framework sur certains points (les composants sont transactionnels et distribués par défaut). Malgré tout, la nouvelle mouture manque d’une réelle colonne vertébrale pour faire interagir les différentes technologies entre elles. Depuis l’arrivée de Spring, une grande majorité des développeur est devenue accro au pattern ioc et Java EE 5 ne propose qu’une solution partielle sur le sujet avec les EJB.
C’est pour palier à ce manque que JBoss sort le framework Seam qui propose une solution d’intégration très puissante pour Java EE 5. Une communauté significative né autour de cet outil et devient utilisatrice de Java EE 5 et des EJB 3, à travers un framework propriétaire certes, mais c’est un premier pas vers l’émergence d’un standard.
Java EE 6, une plateforme enfin autonome
En décembre 2009, la sortie de Java EE 6 marque un tournant important. La simplification intervenue autour des EJB dans la version 5 est confirmée et surtout l’arrivée de CDI complète enfin la stack et créé enfin un standard concurrent à Spring.
Le cocktail Java EE 6
Les articles suivant détailleront les principales innovations de Java EE 6 mais il est toujours bon de faire un petit rappel sur les spécifications contenues dans la bebête
| Technologies | JSR | Notes |
|---|---|---|
| **[Java Platform, Enterprise Edition 6 ](http://jcp.org/en/jsr/detail?id=316)**(inclus Managed Beans 1.0) | [JSR 316](http://jcp.org/en/jsr/detail?id=316) | Spécification “Parapluie”. La notion de Managed Beans est mise en oeuvre via CDI (JSR 299) |
| **Web Services Technologies** | ||
| [**Java API for RESTful Web Services (JAX-RS) 1.1**](http://jcp.org/en/jsr/detail?id=311) | [JSR 311](http://jcp.org/en/jsr/detail?id=311) | [](http://jcp.org/en/jsr/detail?id=311) |
| [**Implementing Enterprise Web Services 1.3**](http://jcp.org/en/jsr/detail?id=109) | [JSR 109](http://jcp.org/en/jsr/detail?id=109) | |
| [**Java API for XML-Based Web Services (JAX-WS) 2.2**](https://jax-ws.dev.java.net/) | [JSR 224](http://jcp.org/en/jsr/detail?id=224) | [](http://jcp.org/en/jsr/detail?id=224) |
| [**Java Architecture for XML Binding (JAXB) 2.2**](https://jaxb.dev.java.net/) | [JSR 222](http://jcp.org/en/jsr/detail?id=222) | [](http://jcp.org/en/jsr/detail?id=222) |
| [**Web Services Metadata for the Java Platform**](http://jcp.org/en/jsr/detail?id=181) | [JSR 181](http://jcp.org/en/jsr/detail?id=181) | [](http://jcp.org/en/jsr/detail?id=181) |
| [**Java API for XML-Based RPC (JAX-RPC) 1.1**](https://jax-rpc.dev.java.net/) | [JSR 101](http://jcp.org/en/jsr/detail?id=101) | deprecated |
| [**Java APIs for XML Messaging 1.3**](http://jcp.org/en/jsr/detail?id=67) | [JSR 67](http://jcp.org/en/jsr/detail?id=67) | [](http://jcp.org/en/jsr/detail?id=67) |
| [**Java API for XML Registries (JAXR) 1.0**](http://jcp.org/en/jsr/detail?id=93) | [JSR 93](http://jcp.org/en/jsr/detail?id=93) | deprecated |
| **Web Application Technologies** | ||
| [**Java Servlet 3.0**](http://www.oracle.com/technetwork/java/index-jsp-135475.html) | [JSR 315](http://jcp.org/en/jsr/detail?id=315) | [](http://jcp.org/en/jsr/detail?id=315) |
| [**JavaServer Faces 2.0**](http://www.oracle.com/technetwork/java/javaee/javaserverfaces-139869.html) | [JSR 314](http://jcp.org/en/jsr/detail?id=314) | [](http://jcp.org/en/jsr/detail?id=314) |
| [**JavaServer Pages 2.2/Expression Language 2.2**](http://www.oracle.com/technetwork/java/jsp-138432.html) | [JSR 245](http://jcp.org/en/jsr/detail?id=245) | [](http://jcp.org/en/jsr/detail?id=245) |
| [**Standard Tag Library for JavaServer Pages (JSTL) 1.2**](http://www.oracle.com/technetwork/java/jstl-137486.html) | [JSR 52](http://jcp.org/en/jsr/detail?id=52) | [](http://jcp.org/en/jsr/detail?id=52) |
| [**Debugging Support for Other Languages 1.0**](http://jcp.org/en/jsr/detail?id=45) | [JSR 45](http://jcp.org/en/jsr/detail?id=45) | [](http://jcp.org/en/jsr/detail?id=45) |
| **Enterprise Application Technologies** | ||
| [**Contexts and Dependency Injection for Java (Web Beans 1.0)**](http://jcp.org/en/jsr/detail?id=299) | [JSR 299](http://jcp.org/en/jsr/detail?id=299) | utilise la JSR 330 pour l’injection |
| [**Dependency Injection for Java 1.0**](http://jcp.org/en/jsr/summary?id=330) | [JSR 330](http://jcp.org/en/jsr/summary?id=330) | [](http://jcp.org/en/jsr/summary?id=330) |
| [**Bean Validation 1.0**](http://jcp.org/en/jsr/detail?id=303) | [JSR 303](http://jcp.org/en/jsr/detail?id=303) | [](http://jcp.org/en/jsr/detail?id=303) |
| [**Enterprise JavaBeans 3.1**](http://www.oracle.com/technetwork/java/ejb-141389.html)(includes Interceptors 1.1) | [JSR 318](http://jcp.org/en/jsr/detail?id=318) | Les Entity Bean (Context Manged Persistence) sont deprecated |
| [**Java EE Connector Architecture 1.6**](http://jcp.org/en/jsr/detail?id=322) | [JSR 322](http://jcp.org/en/jsr/detail?id=322) | [](http://jcp.org/en/jsr/detail?id=322) |
| [**Java Persistence 2.0**](http://www.jcp.org/en/jsr/detail?id=317) | [JSR 317](http://www.jcp.org/en/jsr/detail?id=317) | [](http://www.jcp.org/en/jsr/detail?id=317) |
| [**Common Annotations for the Java Platform 1.1**](http://jcp.org/en/jsr/detail?id=250) | [JSR 250](http://jcp.org/en/jsr/detail?id=250) | [](http://jcp.org/en/jsr/detail?id=250) |
| [**Java Message Service API 1.1**](http://www.oracle.com/technetwork/java/jms-136181.html) | [JSR 914](http://www.jcp.org/en/jsr/detail?id=914) | [](http://www.jcp.org/en/jsr/detail?id=914) |
| [**Java Transaction API (JTA) 1.1**](http://www.oracle.com/technetwork/java/javaee/tech/jta-138684.html) | [JSR 907](http://jcp.org/en/jsr/detail?id=907) | [](http://jcp.org/en/jsr/detail?id=907) |
| [**JavaMail 1.4**](http://www.oracle.com/technetwork/java/javamail-138606.html) | [JSR 919](http://jcp.org/en/jsr/detail?id=919) | [](http://jcp.org/en/jsr/detail?id=919) |
| **Management and Security Technologies** | ||
| [**Java Authentication Service Provider Interface for Containers**](http://jcp.org/en/jsr/detail?id=196) | [JSR 196](http://jcp.org/en/jsr/detail?id=196) | [](http://jcp.org/en/jsr/detail?id=196) |
| [**Java Authorization Contract for Containers 1.3**](http://jcp.org/en/jsr/detail?id=115) | [JSR 115](http://jcp.org/en/jsr/detail?id=115) | [](http://jcp.org/en/jsr/detail?id=115) |
| [**Java EE Application Deployment 1.2**](http://jcp.org/en/jsr/detail?id=88) | [JSR 88](http://jcp.org/en/jsr/detail?id=88) | deprecated |
| [**J2EE Management 1.1**](http://jcp.org/en/jsr/detail?id=77) | [JSR 77](http://jcp.org/en/jsr/detail?id=77) | [](http://jcp.org/en/jsr/detail?id=77) |
| [**Java API for XML Processing (JAXP) 1.3**](https://jaxp.dev.java.net/) | [JSR 206](http://jcp.org/en/jsr/detail?id=206) | [](http://jcp.org/en/jsr/detail?id=206) |
| [**Java Database Connectivity 4.0**](http://jcp.org/en/jsr/detail?id=221) | [JSR 221](http://jcp.org/en/jsr/detail?id=221) | [](http://jcp.org/en/jsr/detail?id=221) |
| [**Java Management Extensions (JMX) 2.0**](http://www.oracle.com/technetwork/java/javase/tech/javamanagement-140525.html) | [JSR 255](http://jcp.org/en/jsr/detail?id=255) | [](http://jcp.org/en/jsr/detail?id=255) |
| [**JavaBeans Activation Framework (JAF) 1.1**](http://www.oracle.com/technetwork/java/javase/jaf-135115.html) | [JSR 925](http://jcp.org/en/jsr/detail?id=925) | [](http://jcp.org/en/jsr/detail?id=925) |
| [**Streaming API for XML (StAX) 1.0**](http://jcp.org/en/jsr/detail?id=173) | [JSR 173](http://jcp.org/en/jsr/detail?id=173) | ** **[](http://jcp.org/en/jsr/detail?id=173) |
Java EE 6 introduit la notion de “profile” pour permettre à des éditeurs de supporter un sous ensemble de spécification de Java EE. Actuellement, il existe un seul de ces profile : le “profile Web” qui, comme son nom l’indique ne garde que les technologies pour faire du web en excluant les briques lourdes de Java EE 6. Cette approche permet à certains éditeurs de sortir rapidement un serveur d’application compatible avec un sous ensemble de technologies Java EE. Pour information le web profile ne comprend que les technologies suivantes :
| Technologies | JSR | Notes |
|---|---|---|
| **Web Profile** | ||
| **Java Servlet 3.0** | [JSR 315](http://jcp.org/en/jsr/detail?id=315) | [](http://jcp.org/en/jsr/detail?id=315) |
| **JavaServer Faces 2.0** | [JSR 314](http://jcp.org/en/jsr/detail?id=314) | [](http://jcp.org/en/jsr/detail?id=314) |
| **JavaServer Pages 2.2/Expression Language 2.2** | [JSR 245](http://jcp.org/en/jsr/detail?id=245) | [](http://jcp.org/en/jsr/detail?id=245) |
| **Standard Tag Library for JavaServer Pages (JSTL) 1.2** | [JSR 52](http://jcp.org/en/jsr/detail?id=52) | [](http://jcp.org/en/jsr/detail?id=52) |
| **Debugging Support for Other Languages 1.0** | [JSR 45](http://jcp.org/en/jsr/detail?id=45) | [](http://jcp.org/en/jsr/detail?id=45) |
| **Contexts and Dependency Injection for Java (Web Beans 1.0)** | [JSR 299](http://jcp.org/en/jsr/detail?id=299) | utilise la JSR 330 pour l’injection |
| **Dependency Injection for Java 1.0** | [JSR 330](http://jcp.org/en/jsr/summary?id=330) | [](http://jcp.org/en/jsr/summary?id=330) |
| **Bean Validation 1.0** | [JSR 303](http://jcp.org/en/jsr/detail?id=303) | [](http://jcp.org/en/jsr/detail?id=303) |
| **Enterprise JavaBeans 3.1 lite** | [JSR 318](http://jcp.org/en/jsr/detail?id=318) | sans backward compatibility, sans remote EJB ou MDB |
| **Managed Beans** | [JSR 316](http://jcp.org/en/jsr/detail?id=316) | |
| **Interceptors** | [JSR 318](http://jcp.org/en/jsr/detail?id=318) | |
| **Java Persistence 2.0** | [JSR 317](http://www.jcp.org/en/jsr/detail?id=317) | [](http://www.jcp.org/en/jsr/detail?id=317) |
| **Common Annotations for the Java Platform 1.1** | [JSR 250](http://jcp.org/en/jsr/detail?id=250) | [](http://jcp.org/en/jsr/detail?id=250) |
| **Java Transaction API (JTA) 1.1** | [JSR 907](http://jcp.org/en/jsr/detail?id=907) | [](http://jcp.org/en/jsr/detail?id=907) |
CDI : une brique qui change tout
CDI est la standardisation de la majorité des principes introduits dans Seam et donne à Java EE la colonne vertébrale qui lui manquait jusqu’ici. L’injection de dépendance supportée par CDI et disséminée dans toutes les autres technologies de Java EE est la standardisation de Seam. Mais la cerise sur le gâteau, c’est probablement les capacité d’évolution de CDI qui constitue l’une des première spécifications du JCP intégrant dans son code génétique de quoi la faire évoluer. Si on ajoute à ça la constitution des profils dans Java EE 6 et la dépréciation d’un certain nombre de technologies obsolètes (compatibilité avec les EJB 1.X et 2.X), on obtient une plate-forme vraiment innovante et que tout développeur Java dôté d’un minimum de curiosité voudrait essayer.
Malgré toutes ces nouveautés, le succès reste mitigé et ce qui devrait constituer un renouveau de la plateforme Java passe un peu à la trappe. Essayons de comprendre pourquoi.
Les raisons d’un accueil en demi-teinte.
Sans trop s’appesantir dessus, on peut analyser les raisons (bonnes et mauvaises) du manque d’enthousiasme de la communauté face à l’arrivée d’une spécification Java EE enfin pleinement exploitable
Arrivée tardive des Implémentations
A la sortie de Java EE 6 en décembre 2009, le seul serveur à suporter totalement la spécification est Glassfish 3, l’implémentation de référence. Le premier éditeur à proposer Java EE6 est Caucho qui livre une version de Resin intégrant le Web Profile Java EE 6 début 2010. Il faudra attendre fin 2010 pour que le poids lourd de l’Open source java : JBoss livre JBoss 6.
Actuellement IBM Websphere 8 est en beta et on peut espérer avoir une release avant la fin de l’année. Concernant WebLogic, la verion 11g R2 supportant EE 6 devrait sortir pour Oracle Open World en octobre.
Il est clair que cette lenteur ne joue pas en faveur de Java EE, néanmoins la notion de “Profile” a permis à des acteurs comme Caucho ou SIwpas de sortir des serveurs assez rapidement en n’implementant que le Web Profile. Espérons que JBoss avec la sortie de la version 7 de son serveur disposera d’une solution plus réactive et qui permettra à l’éditeur de livrer une implémentation de Java EE 7 peu de temps après sa sortie officielle.
Rod Johnson l’a déjà fait !
C’est clairement l’objection la plus commune entendue à propos Java EE et les spécifications qui entrent en concurrence avec Spring Framework à savoir EBJ et CDI : “qu’est-ce que j’ai besoin d’apprendre un nouveau truc alors que Spring fait déjà le job”. Et c’est en partie vrai, même si CDI et EJB apportent une approche différente et par certains aspects plus moderne.
Cependant, le core framework de Spring n’a pas beaucoup bougé depuis sa version 2. On a assisté à l’introduction d’annotations (à reculons), la simplification de l’utilisation de l’AOP et l’adoption de certaines technologies Java EE 6 (bean validation, @Inject) mais pas de grosses nouveautés. De son côté CDI apporte du neuf dans le paysage en incluant par exemple un bus d’événement au framework iOC ou un mode d’extension assez ingénieux.
L’absence de documentation unique
La rien à dire, ça pêche pas mal. La plupart des documents de spécification sont inexploitables et incompréhensibles par le commun des mortels. Certaines implémentations de référence sont bien documentées : c’est le cas de CDI (avec la doc sur Weld) ou JAX-RS , d’autres n’ont pas la moindre doc et le développeur doit aller à la pêche sur Internet. En face de ça, la documentation de Spring est exemplaire et a grandement participé à sa large adoption.
Ce constat joue objectivement contre Java EE, mais heureusement de nombreux livres existent et moyennant un investissement modeste on peut acquérir un ouvrage réparant cet oubli. Je citerai l’excellent livre D’Antonio Goncalves : “Beginning Java EE 6 Platform With Glassfish 3: From Novice to Professional” ou ce livre en Français sorti récemment qui je n’ai pas encore lu mais qui à l’aire assez prometteur : “Développements n-tiers avec Java EE”
Les “incohérences” entre les technologies
On ressort régulièrement cet argument qui n’est pas exact. Il existe des confusions possibles dans l’utilisation de certaines annotations principalement dues à l’historique de JSF. Ce post détaille ces zones de recouvrement existantes et donne le moyen simple de trancher. Une fois que l’on a compris qu’il ne faut utiliser les annotations JSF qu’en l’absence de CDI, le problème des “incohérences” est réglé.
On m’a dit que… J’ai entendu dire que…
Il est clair que Java EE traine un gros passif et que notre communauté comporte moins de personnes curieuses ou capable de s’extraire du troupeau que l’on ne peux croire.
Les évangélistes Spring n’ont pas arrêtés de dire que leur framework préféré est plus léger que Java EE. C’était vrai pendant longtemps, aujourd’hui ça ne l’est plus (je serais même tenter de dire que c’est l’inverse). Vous ne me croyez pas ? Vous avez raison : allez vérifier par vous même !
Pourquoi aller voir Java EE 6 alors ?
Parce qu’il y a écrit Java EE sur votre CV (pour ceux qui ont écrit J2EE, je ne peux rien faire pour vous)
Tant que Java EE était défaillant, nous avions l’excuse de picorer dans la stack officielle à la Spring en critiquant les “serveurs lourds”. Maintenant qu’elle est opérationnelle et innovante, il parait difficile de faire l’impasse. Mon propos ici n’est pas de dire qu’il faut passer sur Java EE 6 et abandonner Spring, il est de dire que tout développeur Java consciencieux devrait acquérir une compétence minimum sur l’ensemble de la stack Java EE ou avoir l’honnêteté de retirer cette mention de son CV.
Parce que c’est supporté par presque tous les éditeurs
Pas grand chose à dire là-dessus. Le JCP, ce n’est pas que l’horrible créature d’Oracle que certains dépeignent, c’est aussi plein d’individus et d’entreprises dont certaines concurrentes d’Oracle qui travaillent ensemble à l’établissement d’un standard. A la sortie, une spécification et plusieurs implémentations. L’histoire montre que le cocktail ne marche pas à tous les coups, mais quand ça marche, c’est beaucoup plus puissant qu’une boîte dans son coin qui décide ce qui est bon pour ses utilisateurs.
Aujourd’hui vous pouvez utiliser Java EE 6 directement avec Tomcat grâce à SIwpas ou partir sur Resin reconnu pour sa légèreté ou encore embarquer avec Glassfish ou JBoss. Dans quelques mois, les mastodontes Websphere et Weblogic seront là. Vous n’avez que l’embara du choix et aller du plus léger au plus… complet.
Parce que c’est en grande partie démocratique
Les tech lead et expert group du JCP sont libre d’organiser le travail autour de leur spécification comme ils l’entendent. La plupart sont à l’écoute et rendent plublique leur discussion permettant à des tiers de venir enrichir le débat. C’est le cas de spécifications comme JAX-RS, JPA ou CDI entre autres. Citons par exemple l’initiative de JBoss sur CDI 1.1 qui demande un feed-back à la communauté sur la proposition de JSR qu’ils ont fait.
Parce qu’il y a plein de choses à construire.
J’ai conscience qu’il s’agit d’un argument à double tranchant, mais la jeunesse de CDI et EJB 3.1 ouvrent de grande perspectives sur l’éco système de Java EE. Les communautés CDI d’Apache (CODI), celles de JBoss (Seam 3) ou d’autres à venir accueillent les contributeurs avec enthousiasme et des modules importants sont encore à concevoir. Pour ceux qui cherchent de nouveaux territoires, c’est une aventure rafraîchissante et pas trop risquée.
En voiture
Voilà pour une petite introduction grosses mailles à Java EE 6. Je vous recommande vivement la lecture des livres mentionnés plus haut en attendant le prochain article qui explorera l’une des technologies ayant déclenché le plus de passions de la Javasphère : Java Server Faces