Java EE 6 ici et maintenant !

Logo JavaUtilisateur de Java EE 6 depuis quelques mois et de certaines technologies comme EJB 3 et JSF depuis plusieurs années, j’ai décidé de faire un petit retour d’expérience et de me lancer dans une série de posts sur les principales spécifications de Java EE 6.
J’étais en train de concevoir une ébauche de plan pour mes articles lorsqu’une question s’imposa à moi : “comment se faisait-il qu’en 2011, après plus d’un an d’existence, on en soit encore à essayer de convaincre la majorité des développeurs à prendre connaissance de cette technologie ?”. Cette question constitue un point d’entrée intéressant pour l’ensemble des spécifications en particulier et pour la spécification Java EE en général. C’est donc en évoquant les multiples freins, idées reçues et obstacles réels à l’adoption de Java EE que je me propose de vous présenter ce standard (encore) confidentiel.

Des erreurs de jeunesse

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
(inclus Managed Beans 1.0)
JSR 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 JSR 311
Implementing Enterprise Web Services 1.3 JSR 109
Java API for XML-Based Web Services (JAX-WS) 2.2 JSR 224
Java Architecture for XML Binding (JAXB) 2.2 JSR 222
Web Services Metadata for the Java Platform JSR 181
Java API for XML-Based RPC (JAX-RPC) 1.1 JSR 101 deprecated
Java APIs for XML Messaging 1.3 JSR 67
Java API for XML Registries (JAXR) 1.0 JSR 93 deprecated
Web Application Technologies
Java Servlet 3.0 JSR 315
JavaServer Faces 2.0 JSR 314
JavaServer Pages 2.2/Expression Language 2.2 JSR 245
Standard Tag Library for JavaServer Pages (JSTL) 1.2 JSR 52
Debugging Support for Other Languages 1.0 JSR 45
Enterprise Application Technologies
Contexts and Dependency Injection for Java (Web Beans 1.0) JSR 299 utilise la JSR 330 pour l’injection
Dependency Injection for Java 1.0 JSR 330
Bean Validation 1.0 JSR 303
Enterprise JavaBeans 3.1 (includes Interceptors 1.1) JSR 318 Les Entity Bean (Context Manged Persistence) sont deprecated
Java EE Connector Architecture 1.6 JSR 322
Java Persistence 2.0 JSR 317
Common Annotations for the Java Platform 1.1 JSR 250
Java Message Service API 1.1 JSR 914
Java Transaction API (JTA) 1.1 JSR 907
JavaMail 1.4 JSR 919
Management and Security Technologies
Java Authentication Service Provider Interface for Containers JSR 196
Java Authorization Contract for Containers 1.3 JSR 115
Java EE Application Deployment 1.2 JSR 88 deprecated
J2EE Management 1.1 JSR 77
Java API for XML Processing (JAXP) 1.3 JSR 206
Java Database Connectivity 4.0 JSR 221
Java Management Extensions (JMX) 2.0 JSR 255
JavaBeans Activation Framework (JAF) 1.1 JSR 925
Streaming API for XML (StAX) 1.0 JSR 173

La notion de “profile” pour alléger la stack

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
JavaServer Faces 2.0 JSR 314
JavaServer Pages 2.2/Expression Language 2.2 JSR 245
Standard Tag Library for JavaServer Pages (JSTL) 1.2 JSR 52
Debugging Support for Other Languages 1.0 JSR 45
Contexts and Dependency Injection for Java (Web Beans 1.0) JSR 299 utilise la JSR 330 pour l’injection
Dependency Injection for Java 1.0 JSR 330
Bean Validation 1.0 JSR 303
Enterprise JavaBeans 3.1 lite JSR 318 sans backward compatibility, sans remote EJB ou MDB
Managed Beans JSR 316
Interceptors JSR 318
Java Persistence 2.0 JSR 317
Common Annotations for the Java Platform 1.1 JSR 250
Java Transaction API (JTA) 1.1 JSR 907

Notez que ce profil n’est pas restrictif : d’autres technologies peuvent s’y ajouter. Par exemple Glassfish et JBoss ont eu la bonne idée d’enrichir le profil web avec JAX-RS.

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 !

Simpsons already did itC’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

TwitterFacebookGoogle+LinkedIn
  • http://twitter.com/loic_d Loic Descotte

    “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 !”

    C’est clair! Il est temps de tordre le coup à ces vieilles idées…
    Ne pas avoir a géré toutes les versions des lib spring, hibernate etc. quand on se base sur un glassfish est vraiment sympa aussi

  • Luc

    Bonjour,
    je suis d’accord que JavaEE6 permet de se passer de Spring mais je trouve CDI encore limité par rapport à Spring. Je me suis construit une petit application exemple avec Weld et certaines fonctionnalités me manquent. Peut-être me trompe-je (j’avoue ne pas avoir trop creusé) mais voici quelques points que j’aimerais bien voir côté CDI :
    - le mécanisme d’interception est assez limité car si j’ai bien compris il faut annoter le bean à intercepter avec une annotation. Je trouve que ça limite l’intérêt si l’on souhaite écrire des couches techniques transverses appliquées par configuration.
    - tous les beans semblent être lazy-loadés même les beans de scope application.

    Sinon la lenteur d’adoption de la spec des gros serveurs commerciaux fait qu’aujourd’hui encore, je partirai encore sur une solution Spring (que je trouve toujours + portable que JavaEE à cause de zones d’ombres parfois dans les specs).

    • http://www.next-presso.fr Antoine Sabot-Durand

      Pour être franc si on se limite à CDI tout nu on rencontre des manques assez vite qui sont comblés par EJB 3.1 dans la stack officielle. Maintenant si on ne veut ou ne peut pas faire des EJB, les extensions CDI comme Seam comblent ces vides. Je reviendrait dessus dans mon article sur CDI.

      Je ne suis pas sûr de comprendre ce que tu entends par “Bean Lazy-loadé”.

      Enfin pour ce qui me concerne les raisons sui feraient que je partirait encore sur Spring sont plus liées aux compétences des équipes qu’à la non portabilité de EE 6 qui est portable puisque tu peux utiliser toutes ces briques (excepté les EJB dans une certaine mesure) avec n’importe quel serveur supportant Servlet 2.5 et 3.0. Tu seras peut être amené un faire un mix avec une adhérence à une implémentation mais mieux vaut adhérer pour 10% de ton code que pour 100% :-).

      • Luc

        > Je ne suis pas sûr de comprendre ce que tu entends par “Bean Lazy-loadé”.

        Ce que je constate avec Weld (dans Tomcat) c’est que même les beans de scope application sont instanciés à la première invocation. J’aurais pensé qu’ils soient initialisés au déploiement de mon WAR (lorsque le servlet context listener Weld est initialisé) Je ne sais pas encore si c’est configurable. (Je découvre Weld et CDI).

  • Pingback: Java EE 6 ici et maintenant ! — Graine de kawa.

  • http://twitter.com/wdrai William Draï

    Le modèle CDI est assez différent du modèle Spring et il est relativement difficile de trouver un ‘mapping’ un à un des fonctionnalités de Spring dans CDI (et inversement). Par contre, le mécanisme d’extension de CDI est d’une puissance assez bluffante et permet d’adapter CDI à ses besoins très facilement voire de faire son propre framework à la carte.
    Pour prendre ton exemple, on pourrait ajouter des intercepteurs programmatiquement depuis une extension en utilisant n’importe quel critère (une conf xml, un nom de package, une règle de nommage…) en plus du mécanisme par défaut avec les annotations.

    • Luc

      Effectivement le mécanisme d’extension permet programmatiquement d’ajouter des intercepteurs (un exemple avec la librairie solder: http://www.warski.org/blog/?p=372) mais j’aurais aimé pouvoir configurer mes intercepteurs dans le beans.xml. Ce qui me fait penser qu’avec EBJ3 les intercepteurs ne s’appliquent qu’au jar d’ejb dans lequel il sont déclarés.
      Je n’ai pas essayé avec CDI si l’intercepteur déclaré dans le beans.xml ne s’applique qu’aux beans du jar mais avec le mécanisme d’extension c’est de toute façon contournable.

      • http://twitter.com/wdrai William Draï

        Je n’en suis pas absolument certain mais il me semble que tous les jars contenus dans un war sont considérés comme faisant partie du même module. C’est seulement dans un packaging ear qu’on peut avoir plusieurs modules et donc plusieurs Bean managers et des injecteurs indépendants.

  • http://twitter.com/hikagebe Gildas Cuisinier

    Hello,

    Bon, il est de notoriété que je suis plutot un pro-Spring.
    Cela dit, je regarde ces temps-ci à CDI afin de mieux connaitre l’ennemi ! ;-)

    Blague à part, comme je l’ai déja dit, le gros soucis avec CDI et Spring, c’est qu’autant le JCP que SpringSource aurait clairement dû travailler ensemble afin d’avoir une seul “spec”. Ici on a CDI, un standard qui tente de s’imposer, face à Spring, un standard de fait et qui est clairement encore la pour plusieurs années au minimum …
    En pratique, c’est encore nous les utilisateurs/développeurs, qui allons devoir jongler entre les deux, qu’on le veuille ou non :)

    Mes premières conclusion avec CDI sont plutot positive. Ca marche pas mal. L’utilisation basique (je n’ai pas encore poussé très loin non plus) est assez intuitive.
    Pour l’heure, j’ai seulement deux points que qui me dérange un peu.

    Le premier, c’est le testing.
    Comme toute classes de l’archive est potentiellement un bean, pour limiter les beans disponibles, si j’ai bien compris avec Arquillian, on crée une nouvelle archive par programmation en ajoutant manuellement les classes deans ?
    En pratique ca fonctionne bien ! Mais ca me fait juste bizarre :)

    Le deuxième est la limitation d’injection.
    Corrigez moi si je me trompe, mais il n’est pas possible de définir un bean genre “MaClasseUtilitaire” dans un jar, et de l’injecter via @Inject dans une servlet (contenue dans un war, mais dont le jar serait dans web-inf/lib) car celle-ci n’est pas dans le même module ?
    Si c’est exact, est-il possible de contourner cette limitation ?

    • http://www.next-presso.fr Antoine Sabot-Durand

      Salut Gildas,

      Je partage tout à fait ton point de vue sur le fait qu’il aurait été vraiment bien que Spring ait été partie prenante dans CDI voir EJB3. Maintenant, leur prolifique de la chaise vide au JCP semble démontrer qu’il s’agit d’une attitude délibérée et c’est ce que je leur reproche. Je ne vais pas refaire mon article sur les rendez-vous manqués de Spring, mais ce sont clairement les développeurs qui en feront les frais. C’est cette attitude déplaisant qui m’a poussé à laisser Spring de côté et à regarder Java EE 5, puis Seam et logiquement EE 6.
      Au cas où ça ne serait pas clair, mon propos n’est pas de dire “Spring c’est pas bien” mais plutôt d’inviter les gens à poser leur marteau doré 5 minutes et regarder autre chose pour s’ouvrir des horizons comme tu l’as fait.

      Sur le testing je ne pourrais pas te répondre tout de suite, je n’ai pas encore assez d’expérience sur la question mais je crois qu’il y a des solutions pour débrancher les beans via la confit XML (le module Seam config fait ça par exemple) . Je vais pas mal manipuler Arquilian dans les jours qui viennent pour mon projet Seam Social, donc je devrais pouvoir te répondre quand je ferais mon article sur CDI

      Concernant ton deuxième point, je pense que tu as du manqué quelque chose. Je n’ai pas injecté de bean dans un servlet, mais dans un contrôleur JSF sans encombre avec le cas de figure que tu mentionnes. Je vais faire un test dans un servlet et vérifier la limitation que tu évoques.

      Je reviendrais là-dessus quand je parlerai de CDI.

  • http://www.mazamalikhan.net Mazam Ali Khan

    Merci pour les informations et les ressources mais où peut on trouver des tutoriels ?

  • Gurkan Erdogdu

    Checkout http://siwpas.mechsoft.com.tr for fast and lightweight web server.

  • Pingback: JSF je t’aime, moi non plus « Ippon Technologies