Les rendez-vous manqués de Spring (une courte histoire de Java EE)

Le 10 décembre 2009, après plus de 3 ans de travail du JCP, les spécifications Java Enterprise Edition 6 sont sorties de leur longue maturation. Cette dernière mouture très prometteuse apporte enfin une solution d’injection de dépendance légère et élégante pour des architectures modernes : la spécification CDI (Context and Dependance Injection) qui permet de travailler avec des « managed beans » (pojos gérés par un conteneur léger) et des EJB 3.1.

Une révolution ? Pas vraiment, puisque depuis près de 6 ans le Framework Spring proposait déjà une solution de ce type. Sachant que Spring source (VMware) est un membre actif du JCP et a participé à l’élaboration certaines JSR, il est légitime de se demander pourquoi l’implémentation de référence de la solution de CDI de Java EE 6 n’est pas Spring. S’agit-il d’une erreur de stratégie de la part de l’éditeur ou d’un calcul délibéré pour rester le challenger d’un standard très proche en terme de simplicité et de fonctionnalités ?

 

Disclaimer

Avant d’aller plus loin dans mon propos et après être retourné sur des threads enflammés de Spring vs JBoss/Java EE de la belle époque, je voudrais juste préciser que cet article n’est pas une critique du Framework Spring (même si j’ai des réserves dans certains choix d’orientation de l’outil) que nous utilisons beaucoup chez Ippon et qui personnellement m’a amené à adopter de meilleures pratiques dans mes développements. Non, il s’agit plutôt d’une interrogation sur la stratégie de Spring VMWare et sur les objectifs recherchés par l’équipe de Rod Johnson. Dans la mesure où, comme des dizaines de milliers d’entreprises à travers le monde, nous utilisons quotidiennement ce magnifique outil, il me paraît légitime de prendre du recul et analyser la direction prise par l’éditeur.

Pour être honnête je dois dire que j’ai mené dernièrement quelques projets sous EJB3 et Seam (avec un peu de Spring pour l’un d’entre eux) et que cette alternative me paraît tout à fait digne d’intérêt voire plus productive dans certains cas. C’est d’ailleurs le point de départ de ma réflexion sur le sujet et l’origine de cet article.

Désolé pour ceux qui n’aiment pas les flashbacks, mais un historique est indispensable pour comprendre la situation actuelle. En route donc, vers l’âge de bronze de Java : 1999.

La génèse de l’IoC et des conteneurs en Java

Les débuts de J2EE en 1999 furent un peu décevants. Si les spécifications servlet et JSP étaient prometteuses et le concept des EJB plutôt bon, la mise en œuvre de ces derniers était extrêmement lourde et contraignante. Ainsi EJB ne rencontra pas le niveau d’adoption espéré par ses concepteurs et c’est probablement de ce loupé qu’est né le schisme entre serveur d’application J2EE « lourd » et Serveur « léger » (n’implémentant que les spécifications Servlet et JSP).

Cependant le besoin d’un conteneur léger pour gérer des composants métiers ou techniques était bien réel et comme aucune solution standard n’existait, des initiatives privées commencèrent à apparaître. Le premier fut probablement le projet Apache Avalon (1999) qui introduisit ces concepts bien avant 2004 et l’article fondateur de Martin Fowler (http://martinfowler.com/articles/injection.html) sur le sujet. Cette même année 2004, Rod Johnson et Juergen Hoeller publiaient le célèbre : « J2EE Development without EJB » et la version 1.0 de Spring voyait le jour. Cette solution rencontra très vite un succès important (preuve de la réalité du besoin et de la malformation congénitale d’EJB) et est encore aujourd’hui la solution phare en la matière.

Les frameworks web et leur besoin de « managed beans »

Parallèlement à ces concepts très élaborés, le besoin de disposer de composants plus évolués que de simples classes Java en terme d’interopérabilité ou de cycle de vie, s’est rapidement fait sentir pour les frameworks Web naissant. Les formBeans de Struts, apparu en 2000, constituent probablement la première solution de ce genre. Craig R. McClanahan, le papa de Struts s’embarqua dès 2001 dans la JSR 127 qui devait donner naissance trois ans plus tard au très controversé JSF 1.0 qui fut le premier Framework UI à introduire explicitement la notion de « managed bean » que l’on retrouvera dans Java EE 6 et CDI en 2009.
De son côté Spring, adressa ce besoin dès la version 1.0 (2004) par des classes permettant de mettre à disposition de la couche Web des beans du conteneur. Tout ça devait évoluer plus tard vers Spring MVC qui deviendrait un concurrent sérieux de Struts dès 2005.

Le besoin de persistance et l’arrivée des ORMs

Un autre aspect absent d’EJB 1.X et maltraité par EJB 2.X était la persistance. Ce concept d’association d’Objet à un modèle de base relationnel (Object Relational Mapping), n’était pas nouveau, et avait déjà été pas mal exploré avec des langages comme Smalltalk.

En Java, beaucoup de projets se sont formés pour répondre à ce besoin d’ORM. On peut citer par exemple JDO, iBatis ou Toplink. Mais, l’acteur majeur dans le domaine fut sans conteste Hibernate. A l’instar de Rod Johnson, Gavin King le père d’Hibernate est lui aussi une star du monde open source Java et l’affrontement entre les deux hommes et de leurs disciples, à défaut de leur donner une bonne image, occupa une bonne partie de la communauté des développeurs à partir du moment où Hibernate racheté par JBoss fin 2003 fit le choix d’une stratégie beaucoup plus ambitieuse que Spring pour tenter d’imposer ses outils…

EJB est mort, vive EJB !

C’est fin 2003 que Sun forma le groupe d’expert autour d’EJB 3. A cette occasion, Gavin King et Emmanuel Bernard éminents membres du projet Hibernate rejoignirent le JCP et participèrent à l’Expert Group d’EJB3. Leurs travaux débutèrent mi 2004 pour s’achever le 11 mai 2006.

Cette nouvelle version d’EJB fut une refonte totale (n’ayant en commun avec la version 2.1 que le nom) intégrant les concepts d’injection de dépendance et d’AOP rendus populaires par Spring. Ni Interface21 (la société qui devait devenir Springsource fin 2007), ni Rod Johnson (pourtant membre du JCP suite à sa collaboration à la spécification servlet 2.4) ne furent membre de l’expert group EJB3.
L’une des grosses innovations de cette nouvelle mouture fut la spécification JPA (Java Persistence API). Cette API de persistance totalement calquée sur Hibernate réussi même le tour de force de s’extirper de la spécification EJB3 pour pouvoir être exploitée directement sous Java SE et des frameworks léger comme Spring.

A travers sa participation à l’expert group EJB3, JBoss réussit a promouvoir son Framework Hibernate au rang d’implémentation de référence de JPA et à l’intégrer avec une solution standard et alternative à Spring : EJB3. Belle réussite, mais la moitié du chemin restait à faire pour sérieusement contre-carrer Spring.

Java EE5, une nouvelle ère pour le JCP

Java EE 5 dans lequel s’intègre EJB 3.0, marque un tournant important dans l’approche générale du JCP. L’entité pilotée par Sun intègre maintenant plus d’individus et d’entreprises issues du monde Open Source. La principale conséquence de cette ouverture c’est la création d’implémentations avant les spécifications. Ainsi Hibernate fut adapté au fur et à mesure par JBoss pour devenir à terme l’implémentation de référence de JPA 1.0 et JBoss commença à travailler sur des betas d’EJB3 et de JPA dès octobre 2004 (plus d’un an et demi avant la sortie de la spécification).

Ces premières versions permettent à JBoss de commencer à proposer une alternative à Spring pour exploiter Hibernate. Avec l’arrivée de cette nouvelle solution JBoss ouvre les hostilités en dénonçant la façon dont Spring exploite la session Hibernate et en expliquant qu’avec EJB3 ce sera tellement mieux. De son côté, Spring n’hésite pas à montrer Hibernate du doigt quand des utilisateurs du Framework viennent sur les forums Spring poser des questions au sujet des exceptions de type LazyInitializationException en expliquant que c’est la faute d’Hibernate si ces exceptions surviennent. Ce n’est clairement pas l’objet de cet article de prendre parti, mais on peut dire que côté agressivité et mauvaise foi les deux parties firent match nul. On pourra revoir certaines de ces passes d’armes qui ne font pas franchement l’honneur des deux camps ici : http://houseofhaug.wordpress.com/2005/08/12/hibernate-hates-spring/ ou là http://blog.springsource.com/2007/11/09/a-response-to-ejb-3-and-spring-comparative-analysis/
Sur le fond, avec 5 ans de recul, on peut quand même dire sans trop de subjectivité que l’attitude de JBoss était plutôt offensive et celle de Spring défensive. Ce qui résume plutôt bien le rapport de ces deux compagnies au marché des technologies Java.

Quoiqu’il en soit, il était évident que Spring était de loin une solution plus mature et plus complète pour couvrir toute la pile applicative du front à la persistance en passant par la couche métier. EJB3 de sont côté remplissait le contrat côté couche métier et persistance mais son exploitation à travers une webapp restait assez compliqué de par la différence entre les cycles de vie des EJB3 et ceux des servlets, sans parler du recours systématique à JNDI pour interagir avec les EJB3 qui n’était pas popur faciliter la vie du développeur. Gavin King avait manifestement réalisé cette grosse lacune (même si officiellement il clamait qu’EJB3 remplaçait avantageusement Spring) et décida dès 2005 de se lancer dans la réalisation d’un nouveau framework pour la combler.

Et Seam fut…

A la base Seam est un sacré pari, car l’objectif annoncé du framework était de faciliter l’intégration de deux standards mals aimés du monde Java : JSF et EJB. Nous avons déjà évoqué EJB3 dans les lignes précédentes, mais il faut garder à l’esprit que le nom EJB était (et est encore parfois) associé à la calamité des versions 2.1 et précédentes. Donc EJB3 a mis du temps à percer, handicapé par le fait qu’il partage le patronyme de ses prédécesseurs.

Concernant JSF (Java Server Faces), pour faire court, cette spécification inclus des idées très innovantes (développement d’interface web par composants et programmation événementielle), mais sa version 1 fut entachée par des partis pris malheureux et limitations incompréhensibles qui ont fait couler des flots de haine sur pas mal de blogs comme le célèbre : http://ptrthomas.wordpress.com/2009/05/15/jsf-sucks/. Si on additionne ces ratés à la résistance naturelle de toute communauté au changement, autant dire que JSF fut accueilli froidement par la majorité des développeurs Java et qu’aujourd’hui encore l’image de cette technologie est assez négative parmi une grande partie des développeurs qui ne l’ont jamais utilisé.
Néanmoins, un certain nombre de personnes décidèrent qu’il y avait « du bon en JSF » et qu’on pouvait travailler à en corriger ses défauts sans remette en cause ses principes fondamentaux. Ce fut le cas de Gavin King qui imagina en 2005 un framework pour faciliter l’utilisation des EJB3 avec une application utilisant JSF comme technologie de présentation. JBoss Seam était né.

En route vers la standardisation

Dès le début de Seam (avant la version 1.0), King élargit la portée du Framework. L’histoire ne dit pas vraiment comment c’est arrivé ni si tout ça était prévu dès le départ, mais on peut deviner qu’en essayant de mieux contrôler les managed bean de JSF, Il a étendu Seam au support de composants définis sous forme de simples pojo en plus des EJB et a finalement ajouté le support de la technologie concurrente : Spring. Puis, constatant la polémique autour de JSF et ne voulant pas hypothéquer le succès de son Bébé, il a ouvert Seam à d’autres technologies de front comme les simples JSP puis plus tard, GWT, Flex ou Wicket (pour ce dernier, c’est la communauté Wicket qui étendit Seam pour assurer ce support, JBoss se contenta de l’intégrer officiellement au framework).

La version 1.0 de Seam sort en juillet 2006 mais c’est deux mois avant, en mai 2006 que Redhat (qui a définitivement racheté JBoss en Avril) soumet au JCP le projet de standardisation de Seam sous le nom de Web Beans. C’est le début de la fameuse JSR 299 qui prendra au final le nom de CDI pour sortir en décembre 2009 comme nouveauté dans Java EE 6.

Dès le démarrage de l’Expert Group, Gavin et son équipe commence à travailler sur l’implémentation de référence de CDI sous le nom de Weld.

Pendant ce temps du côté de chez Spring…

Pendant les années 2005 – 2009, Springsource a beaucoup travaillé sur le lancement de nouveaux produits : serveur d’application basé sur Tomcat (tc Server), serveur d’application supportant la technologie OSGI (dm Server), développement d’un atelier logiciel entièrement AOP (Spring Roo), absorption du langage Groovy et du Framework Grails. Plein de choses très intéressantes en fait, mais pour le Framework Spring, rien de très révolutionnaire.

En revanche, le discours de Spring Source concernant JEE (qu’ils continuent à appeler J2EE) ne bouge pas d’un iota. Comme si JEE 5 n’était jamais sorti. Preuve en est cette keynote de Rod Johnson datée du 5 décembre 2009 (5 jours avant la sortie officielle de Java EE 6) dans laquelle il continue à expliquer que JEE c’est compliqué : http://www.infoq.com/presentations/Lessons-Learned-from-Java-EE

Les Rendez-vous manqués de Spring

En déroulant à nouveau toute cette histoire on remarque un certain nombre d’occasions en or manquées par Springsource pour dépasser son statut de standard de fait et devenir un standard tout court. Lors du design d’EJB3 par exemple ou lors du lancement de la spécification CDI, il aurait était facile de faire comme JBoss et venir « imposer » Spring comme implémentation du standard. Au lieu de ça, Rod Johnson et son équipe sont restés sur une attitude très défensive et un discours de moins en moins crédible de dévalorisation du standard JEE au fur et à mesure que celui-ci devenait une alternative de plus en plus réelle à Spring.
Ce qui suit est très subjectif, mais voici les points qui selon moi ont fait défaut à Spring pour pouvoir jouer cette partition :

1. L’adoption tardive des annotations

Spring a attendu sa version 2.5 en novembre 2007 pour commencer à utiliser (et encore partiellement) les annotations introduites par java SE 5.0 en septembre 2004. Soit plus de 3 ans pour adopter ce complément à la pure configuration XML. Je ne vais entrer dans débats XML vs annotations, pour moi les deux sont utiles et ont leur cas d’utilisation. Spring se voulant un Framework ouvert et laissant le choix à ses utilisateurs, ils auraient du adopter les annotations dès la version 2.0. L’absence d’annotation rend les gros projets Spring assez compliqués à appréhender par des nouveaux venus. Le fait d’avoir la configuration séparée du code c’est un peu comme monter un meuble en ayant scotché le plan de montage sur le plafond de la pièce voisine : pas très pratique.

2. La négation d’EJB 3

La première version de Spring supportant EJB3 est la version 2.51 de début 2008. Les versions antérieures ne supportent que EJB 2.X. Quand on sait que les premières versions stables d’EJB3 sont apparues courant 2005, on constate là aussi un décalage de trois ans pour prendre en compte une technologie majeure qui plus est partiellement concurrente. Quand on compare avec les quelques mois qu’il a fallu à JBoss pour intégrer un vrai support Spring à Seam, ça laisse rêveur.

3. La posture anti Stateful

Une grosse différence entre les EJB3 / CDI et Spring c’est l’existence de composants stateful dans EJB3. Sans rentrer dans les détails, l’approche stateful permet de décorréler le cycle de vie du composant de celui de l’application, permettant de créer facilement des contextes différents comme le contexte conversation ou le contexte Business dans Seam. Spring permet d’obtenir à peu près le même résultat mais sans technologie stateful, pourtant l’équipe a passé beaucoup de temps à décrier l’approche d’EJB3 pour valoriser leur produit. S’embarquer dans des débats obscurs et manifestement idéologiques quand on doit donner une lecture claire de sa stratégie et de ses outils ne paraît pas être la meilleure stratégie qui soit.

La stratégie Spring ?

On peut se demander si tous les choix de Springsource participent d’une stratégie et si le fait se tenir à l’écart de JEE est un choix murement réfléchit. On trouve un début de réponse à cette question ici : http://blog.springsource.com/2007/11/09/a-response-to-ejb-3-and-spring-comparative-analysis/

En gros pour résumer ce long échange, Spring ne souhaitait pas s’intégrer dans le JCP pour ne pas figer leur Framework. En effet, vu le rythme de livraison des nouvelles spécifications (en moyenne 3 ans), on pourrait craindre en s’attachant au JCP de ne plus avoir le contrôle sur son produit ou devoir attendre 3 ans avant de faire normaliser ne nouvelle version. L’approche de JBoss avec Hibernate puis Seam montre qu’il est parfaitement possible de jouer sur les deux tableaux en faisant normaliser un sous ensemble de l’outil et en ayant des extensions que l’on eut faire évoluer en dehors de la spécification. Seam 3.0 est un parfait exemple : le framework devient une collection de modules d’extension à CDI pour reproduire ce que faisait Seam 2.X mais sur la base de spécification CDI. Ces modules constituant Seam 3 semblent en théorie pouvoir interagir avec n’importe quelle implémentation de CDI et ne seraient donc pas spécifiques à l’implémentation de référence Weld.

De plus Java EE6 adresse cette problématique de “lenteur” dans le cheminement des spécifications en intégrant désormais la notion de “profiles”. Un profil est grosso-modo est un ensemble de technologie et de framework ou de technologies mis en oeuvre de manière conjointe pour créer un environnement applicatif bien spécifique. La création d’un nouveau profil au sein de Java EE6 se fait indépendamment de l’évolution de la spécification Java EE, on peut donc en quelques mois créer et proposer un nouveau “profile”. Les risque de “figer” son framework pour 3 ou 4 ans en l’intégrant a Java EE disparaît totalement si on intégrer celui-ci dans la logique des “profiles”.

L’équipe Spring n’a manifestement pas envisagé les choses sous cet angle et s’est contentée de rester sur « le standard de fait » sans se donner la peine d’aller plus loin.
En fait il s’avère qu’en la matière Spring ne semble pas avoir de stratégie ou alors une stratégie très brouillée. La meilleure illustration de cet à-peu-près est certainement la péripétie de la JSR 330 (@inject)

La spécification @Inject, panique ou obstruction ?

Petit rappel des faits : en mai 2009 soit 3 mois avant la release de JEE 6, Rod Johnson et Bob Lee (de Google) interpellent le JCP concernant la spécification CDI (démarrée 3 ans auparavant), la décrétant trop lourde et ne prévoyant pas une solution simple d’injection de dépendance. Ils proposent une autre spécification basée sur un ensemble d’annotations simples dont le fameux @Inject pour normaliser l’injection de dépendance en Java. Dans l’absolu, on ne peut évidemment pas leur donner tort : Gavin King a bien mené sa barque et a piloté une spécification très (trop ?) complète allant même jusqu’à intégrer un mécanisme évènementiel pour dispatcher des messages au sein des composants. On est bien au delà de l’injection légère que des frameworks comme Spring ou Google Guice proposent.

Là où l’initiative de Rod Johnson et Bob Lee est franchement discutable, c’est qu’elle intervient 3 mois avant la date de sortie de Java EE 6. Là où la plupart des spécifications de Java EE 6 ont mis trois ans à cheminer. De plus, Google et Spring avaient toute latitude de se joindre à l’expert group de CDI en 2006 plutôt que de débouler avec une spécification express au moment de la livraison.
Le résultat est une spécification @Inject mal ficelée, dont les implémentations risquent de diverger et un retard de 3 mois pour JEE 6. On a évité la catastrophe d’avoir deux spécifications sur l’injection de dépendance incompatibles puisque l’expert group de CDI a accepter de prendre en compte @Inject dans CDI.

Cet épisode qui pourrait être considéré au pire comme du sabotage ou au mieux comme une réaction de panique, n’est vraiment pas très glorieux pour Spring (et Google dans une moindre mesure) et a globalement eu pour effet de jeter le discrédit sur les commentaires négatifs de Rod Johnson concernant Java EE 6.

Spring pas un standard officiel et alors ?

Aujourd’hui, Spring est un standard de facto. Des centaines de milliers de développeurs dans le monde utilisent cet excellent Framework avec beaucoup de succès. Pourquoi se soucier de sa standardisation ?
Le premier point de réponse est lié à l’historique de Spring : cet outil est né pour palier à un gros défaut dans le standard officiel et proposer une vraie solution de conteneur de composants léger. Dés lors que le standard est corrigé, la raison d’être de l’outil s’estompe et même si sa popularité et sa qualité en font toujours un choix de prédilection, il rentre en concurrence avec une solution officielle équivalente, là où il aurait pu être ce standard.

Le deuxième élément est lié à la gouvernance de Spring. Comme on l’a vu la stratégie de Vmware n’est pas très claire et aujourd’hui seule une demi douzaine de cerveaux géniaux contribuent réellement à ce Framework. Tout cela apparaît plutôt fragile et à partir du moment ou une alternative plus universelle existe, il paraît raisonnable de s’y intéresser pour éviter d’être captif d’une société en l’occurrence, VmWare.
En prenant, le problème par l’autre bout on peut s’interroger sur les raisons qui ont pu retenir Spring de prendre cette voie de la standardisation. Franchement, en dehors du boulot énorme que doit représenter l’animation d’une telle spécification, je ne vois que des points positifs : l’évincement d’une solution concurrente, le ralliement des personnes n’ayant pas choisi Spring et la réassurance des utilisateurs existants. Bien sûr en transformant Spring en spécification, la société prenait le risque de voir d’autres implémentations concurrentes apparaître, mais avec l’avance de l’équipe de Rod Johnson, Spring aurait gardé le lead sur cette technologie comme Hibernate reste l’implémentation de JPA la plus utilisée même si eclipse link est l’implémentation de référence de JPA 2.0.

Quel avenir pour Spring ?

Bien sûr, il n’est pas question de prédire la fin de Spring. Le Framework est bien implanté et continu à remplir sa mission avec succès. Néanmoins, il est toujours mauvais signe quand un outil de ce genre n’est pas choisi parce qu’il constitue la meilleure solution mais parce que prendre une autre solution couterait trop cher en formation et en gestion du changement.

Quoiqu’il en soit Java EE 6 et CDI ont beaucoup de chemin à parcourir pour devenir populaire. L’hostilité d’un certain nombre de développeurs aux productions de Redhat et l’inertie naturelle des organisations pour adopter de nouvelles technologies sont ses pires ennemis. Mais il est tout de même fort probable que cette spécification rencontre un beau succès, la taille de la communauté Seam en est la meilleure preuve.
Concernant Spring si CDI parvient à convaincre et commence à prendre de l’ampleur, le Framework de VMware risque d’avoir à s’aligner sur cette spécification pour en devenir une implémentation au risque de se marginaliser. Auquel cas, il perdrait une partie de son leadership et deviendrait suiveur sur une technologie dans laquelle il était l’un des premiers acteurs.

Si CDI reste lettre morte, Spring pourra poursuivre sereinement sa carrière de leader dans le monde des conteneurs légers sous Java. Mais le pari est très risqué et au vu du besoin d’avoir une pile de framework officiels sous Java, Vmware n’est pas du tout assuré de le gagner.

Remerciements

Merci à Emmanuel Bernard (@emmanuelbernard) qui a bien voulu répondre à mes quelques tweets sur la genèse d’EJB3.

Bibliographie

  • Le site de picocontainer et surtout sa section « Inversion of Control History » : http://www.picocontainer.org/inversion-of-control-history.html
  • Le site du JCP :
  • http://www.jcp.org
  • Présentation Paris JUG JEE6 & Spring (08/12/09) par Antonio Goncalves et Michael Isvy :
  • http://www.parisjug.org/xwiki/bin/download/Meeting/20091208/JavaEE6Spring3.0.pdf
Tweet about this on TwitterShare on FacebookGoogle+Share on LinkedIn
  • http://www.antoniogoncalves.org Antonio Goncalves

    Très bon post, bravo. Il y a un point que tu n’abordes pas, les profiles.

    Java EE 6 vient avec la possibilité de créer des profils, c’est à dire des sous-ensembles (ou sur-ensembles) de la plate forme. Pour ouvrir la voie, Java EE 6 vient avec un profile web (Web Profile 1.0) qui est un sous-ensemble de Java EE 6 destiné aux applications web (JPA 2.0, JTA, EJB 3.1 Lite, JSF 2.0, Servlet 3.0…).

    Il y a plusieurs avantages à ces profiles (ex. moins de spec à connaître pour le développeurs) et l’un d’eux est que les profiles évoluent à leur rythme. Par exemple, on peut imaginer un Java EE 7 dans 3 ans. Par contre, rien n’empêchera le Web Profile 1.1 de sortir dans 6 mois. Ceci pour dire que la standardisation d’une nouvelle version de Java EE est longue, par contre, celle d’un profile peut être beaucoup plus rapide. Si SpringSource (VMWare maintenant) voulait vraiment jouer la carte des standards, ils pourraient, par exemple, travailler sur un @Inject 1.1 et l’intégrer au Web Profile 1.1 qui pourrait sortir dans 6 mois. Les délais de sorti d’une spec ne sont donc plus aussi longs que par le passé.

    Antonio PS : une petite coquille "Petit rappel des faits : en mai 2009 soit 3 mois avant la release de JEE 5". C’est bien entendu JEE 6 (préfères quand même l’acronyme Java EE 6)

     

    pariviere:mise en forme

    • asabotdurand

      Merci Antonio pour ton retour. J’ai encore pas mal de choses à apprendre sur Java EE6 (il paraît qu’il y a un excellent livre sur le sujet 😉 ) et si j’avais lu pas mal de choses sur les "profiles" je n’avais pas compris cet apport vraiment intéressant.

      J’ai intégré ta remarque à l’article dans le paragraphe "La stratégie Spring ?". Merci encore.

  • http://spring.developpez.com Gildas Cuisinier

    Hello,

    Franchement, très bon article, qui résume très bien la situation actuelle. Je suis globalement d’accord avec toi.

    Pour ma part, plutôt partisan de Spring, je trouve franchement dommage que SpringSource soit resté sur sa position sans participer activement à cette spécification. Comme il a été dit (je ne retrouve plus la source), JEE est la pour faire de la consolidation et non de l’innovation. Il aurait été plus normal que cette consolidation se fasse autours du framework Spring qui est certainement plus utilisé que Seam.

    Je ne doute pas que Seam soit un bon framework également (je n’ai pas encore eu l’occasion de l’utiliser), mais avec CDI et Spring, il y a une scission importante pour l’heure. Ce qui de manière général n’est pas une bonne chose. D’un coté, nous avons Spring, utilisé depuis maintenant un certains temps, et connu par la plupart des dévelopeurs. De nombreux frameworks interne au entreprise l’utilisent certainement comme socle. De nombreux outils et produit également (Mule, Alfresco, CXF, .. ). De l’autre un framework et standard imposé, moins connu des développeurs je pense. Et les deux, incompatible.

    Nous avons donc à faire un choix :

    • Continuer avec Spring, au risque de rater la nouvelle vague.
    • Choisir CDI, mais perdre l’existant (connaissance, outils, habitude, best practice) et donc nécessiter un investissement plus important.

    Franchement, j’espère que SpringSource finira par accepter d’implémenter CDI de manière correcte qui donnerai la possibilité si nécessaire de faire appel au fonctionnalité propre de Spring si nécessaire. Un peu comme ce que l’on pouvait faire avec JPA 1.0 et Hibernate. Cela pourrait réunifier un petit peu ces deux mondes.

     

    pariviere: mise en forme

    • asabotdurand

      Je suis tout à fait d’accord. La JSR 299 aurait vraiment gagnée en richesse et en crédit avec l’implication de Springsource et de Google (pour Guice). Je pense que c’est mauvais pour tout le monde (même pour Redhat) que cette spécification porte comme surnom "Gavin Specification".

      Concernant Seam c’est en effet un bon framework mais nettement moins généraliste et développé que Spring. C’est d’ailleurs la raison pour laquelle j’ai utilisé des composants Spring dans des développement Seam. La synergie des deux outils est réjouissante, c’est d’autant plus rageant que les idées des deux ne soient pas fusionnées dans une même spec.

  • http://blogs.sun.com/alexismp Alexis Moussine-Pouchkine

    Manifestement l’article est très bien documenté.

    Je regrette simplement l’absence de mention faite de Sun qui laisse entendre que JBoss a fait tout le boulot. JBoss est probablement le meilleur élève du JCP en prenant en charge des JSR (avec le travail de spécification, de suite de tests et d’implémentation de référence que ça représente), mais la volonté politique, l’implémentation de référence complète Java EE 5 et maintenant Java EE 6 c’est Sun qui les a produit…

     

    pariviere: mise en forme

    • asabotdurand

       Alexis. Loin de moi l’idée de diminuer le travail énorme fait par Sun (et demain par Oracle ?) sur Java EE5 et 6. Ne serait-ce que le fait d’avoir admis s’être trompé sur la manière dont les spécifications précédentes étaient menées et de corriger le tir, mérite vraiment un coup ce chapeau : peu d’organisation sont capable de montrer publiquement qu’elles ont appris de leur erreurs.

      Quoiqu’il en soit, dans ce billet, je fais un gros plan sur une spécification qui est quand même très marquée Redhat, et même si je pense que c’est un bon travail, je ne suis pas vraiment fan de l’entrisme dont Redhat a fait preuve vis à vis du JCP sur cette JSR particulière. 

       

       

  • http://blog.xebia.fr/ Erwan ALLIAUME

    Bien que je sois d’accord avec le fond de l’article, ça me piquait d’y apporter cette petite modération.

    La stratégie de Spring de ces dernières années était claire, occuper un maximum de place dans le but de se faire racheter. Fort d’être devenu un standard de facto, SpringSource a décidé de diversifier ses solutions pour toucher le plus de monde possible. N’oublions pas que la partie IoC n’est que le coeur d’une stack de solutions permettant d’adresser un large éventail de problématiques : "build, run and manage". Adresser toutes ses problématiques a demandé (et demande toujours) un effort gigantesque, celui-ci s’est matérialisé par divers rachats, développements de produits et a permis d’en sortir des … innovations.

    C’est à mon sens ce qu’il est important de retenir dans cette histoire. Laissons de côté la guerre des chapelles un petit moment, Spring est l’un des moteurs de nouveautés pour le monde Java au sens large (over JVM), ce n’est évidemment pas le seul. Les idées sont reprises à dans un sens comme dans l’autre (pour peu qu’il y ait un sens) et c’est l’essentiel. Concernant les points abordés dans cet article (annotation, négation des EJB, problématiques stateful), je ne les trouve pas forcement révélateur d’un rendez-vous manqué. Le titre de l’article est volontairement polémique, il serait drôle de continuer sur cette même lancée en inversant l’angle d’attaque. Merci pour cet article.

     

    pariviere: mise en forme

    • asabotdurand

      Effectivement un des objectifs de Springsource était de se faire racheter, mais n’était-ce pas aussi celui de JBoss ?

      Cela illustre une nouvelle fois la différence d’approche des deux société. Les deux ont des produits géniaux (et des responsables aux égos bien développés).

      Les rendez-vous manqués sont surtout ceux des groupes de travail sur Java EE5 et EE6, je reconnais volontiers que les autres points sont plus secondaires et discutables.

      L’attitude de Springsource par rapport au standard et à son frère ennemi JBoss me fait penser à cette citation de Gandhi (ou de Robbie Williams pour les plus jeunes 😉 )

      "First they ignore you, then they laugh at you, then they fight you, then you win."

      Evidemment Spring n’a pas perdu loin de la mais ils auraient franchement pu gagner et être dans une position encore plus confortable aujourd’hui.

  • http://www.quentinadam.com Quentin ADAM – waxzce

    petite coquille :

    "Petit rappel des faits : en mai 2009 soit 3 mois avant la release de JEE 5, Rod Johnson et Bob Lee (de Google)" à remplacer par "la release JEE 6".

    Sinon, cet article est vraiment très bon, utile et formateur pour les jeunes en java

     

    pariviere: mise en forme

    • asabotdurand

       Coquille corrigée. Merci pour le retour.

  • http://blog.xebia.fr Guillaume CARRE

    Très bon article, il y a un gros travail de documentation effectivement et certainement de longues heures de travail ! Merci.

    Un peu frustré toutefois par "cette alternative me paraît tout à fait digne d’intérêt voire plus productive dans certains cas" dans l’introduction (en parlant de Seam), j’aimerais beaucoup en savoir plus !! :)

     

    pariviere: mise en forme

    • asabotdurand

      J’envisage de faire quelques articles sur CDI et Seam 3, bientôt. J’espère que ça apaisera ta frustation :-). Merci encore pour le retour, c’est effectivement beaucoup de travail : à quand des historiens de la technologie ?

  • Bruno Leroux

    Félicitations pour cet article bien riche !

    Sur le fond, je pense que si Spring n’a pas suivi la voie de la standardisation c’est que leur position d’origine anti-J2EE ne pouvait  être, vicéralement, conciliée avec une standardisation dans le cadre du JCP. Et ce aussi bien pour eux (ce qui aurait nécessité de revenir sur leur propre raison d’être) que pour les autres membres qui ont subi les attaques répétées pendant des années. A priori, sur le principe SpringSource semblent bien avoir finalement compris la nécessité de devenir un standard formalisé, c’est en tout en cas ce qu’ils ont fait avec la spécification OSGi Blueprint Services, mais ça reste forcément en-dehors du JCP et ça arrive bien tard.

    D’un point de vue cynique et purement business, la stratégie de Spring peut être considérée comme une réussite puisqu’ils ont réussi à trouver acheteur pour le même prix que JBoss… Et concernant VMWare, il est difficile d’avoir une idée précise sur leur stratégie Java et notamment sur le rôle qu’ils veulent donner à Spring.

     

    • asabotdurand

      Je suis d’accord avec ta remarque, le seul hic c’est l’implication de Spring Source dans le JCP. Rod Johnson a même été élu "executive member" du JCP. Pourquoi s’impliquer dans cet organisme si ce n’est pas pour participer aux JSR concernant les conteneurs de composants ou l’injection ?

      Concernant l’aspect business, JBoss et Springsource ont atteint le même objectif, JBoss est parvenu en même temps à injecter un travail colossal dans le JCP. Il aurait été, selon moi, très bénéfique que Springsource en fasse de même pour faire bénéficier les standards de leur savoir faire. 

  • http://blog.octo.com Christian Blavier

    Bravo et merci pour cet excellent article ! 

    • http://blog.octo.com Christian Blavier

      Une remarque quand même sur la posture anti-stateful de Spring : il faut bien reconnaitre que c’est JBoss qui est allé dans une direction opposée au marché en investissant sur les architectures stateful.

      Les exemples d’archis très scalables récentes investissent massivement sur le stateless, et il s’agit aussi d’un pattern d’archi poussé par des technos comme Ruby On Rails ou Google App Engine … En effet le problème avec le stateful est la scalabilité de l’archi. On pourra me rétorquer que JBoss possède des mécanismes de réplication super sophistiqués :

      1. Ca reste moins scalable qu’une archi stateless avec un memcache pour stocker l’état
      2. C’est pas très KISS tout ça (et quand ca plante …)

      Donc je ne suis pas certain qu’il faille jeter la pierre à Spring sur ce choix

      • asabotdurand

        Je ne vais pas rentrer dans un débat stateful contre stateless ici. D’autant plus que j’ai pratiqué les deux approches et trouve intéressant de pouvoir les utiliser en fonction du besoin : j’aime que la visite du catalogue produit soit stateless mais j’aime aussi que mon tunnel d’achat soit stateful.

        Plus que JBoss, c’est EJB qui a fait la promotion d’un mode stateful. JBoss s’est juste calqué dessus et a généraliser son utilisation dans Seam et CDI.

        De son coté Spring qui a longtemps expliqué que le stateful était un anti-pattern s’est retrouvé à fournir des scopes à ses Beans dans la version 2 et a même participé (sans trop de publicité) à un projet de conteneur EJB3 avec BEA (projet pitchfork) . Que d’énergie perdue à lutter contre une conception alternative pour finalement rendre son framework compatible avec elle et arriver à la conclusion : le stateful c’est parfois plus puissant et pratique que le stateless.

  • Michael Isvy

    Bonjour,

    tout d’abord bravo pour ce bel article. On voit que tu l’as écrit avec beaucoup de recul. J’en profite pour apporter quelques commentaires sur la partie Spring (puisque Chuck N… pardon Emmanuel l’a fait côté JBoss 😉 ).

    Concernant les annotations, nous avons commencé à introduire les annotations sur les transactions, la sécurité etc à partir de Spring 2.0. Donc quand tu dis qu’on a attendu Spring 2.5 pour les introduire, je pense que tu fais référence à @Autowired, @Qualifier et @Component. Il est vrai qu’on aurait pu les introduire plus tôt. Mais en même temps, tu utilisais peut-être déjà Spring en version 1.x. Si oui, tu as dû voir à quel point il était verbeux de paramétrer les transactions ou la programmation par aspects (Xml hell, comme on disait à l’époque). En 2.0, on a introduit les namespaces qui ont permis de simplifier grandement la config, et un premier volet d’annotations. Il faut du temps pour construire un beau framework et je suis plutôt d’accord avec la façon dont les priorités ont été gérées.

    Concernant l’implémentation CDI, il a été choisi de ne pas l’implémenter parce que celà aurait nécessité un changement de syntaxe compliqué qui aurait cassé la compatibilité ascendante. Il est toujours possible d’utiliser Spring aujourd’hui comme on l’utilisait en 1.0 (à quelque pouillèmes près) et je pense que c’est une des forces de ce framework (il était bien pensé dès le départ). En revanche, je présume que si on constate un très fort intérêt pour notre communauté d’utilisateurs envers CDI, les choses seront différentes. Il faut donc voir avec un peu de recul, dans 1 an ou 2.

    Concernant l’acquisition par VMware, celà fait maintenant plus de 6 mois que le rachat a été enterriné et les choses se passent bien. Aucun des dévoloppeurs sur les frameworks open-source n’ont quitté le navire. Bien au contraire, nous avons plus de budget et les équipes se sont agrandies sur les projets Spring et sur Groovy/Grails.

     

    Pour finir, puisque tu parles de "standardiser Spring", il ne faut pas oublier qu’il ne s’agit pas uniquement d’un choix idéologique. C’est un travail énorme de standardiser un framework, surtout quand il s’agit de quelque chose d’aussi central que l’injection de dépendances et l’AOP. Les ressources n’était pas infinies, on aurait certes pu mobiliser une partie des équipes pour les faire bosser sur des specs. Mais le framework serait beaucoup moins complet aujourd’hui. Par ailleurs, j’aime beaucoup notre mode de fonctionnement avec notre JIRA. N’importe qui peut nous soumettre des idées d’amélioration sur nos frameworks. Avec le JCP, c’est une vision beaucoup plus élitiste et beaucoup moins transparente.

    Just my 2 cents comme on dit :).

     

    • asabotdurand

      Bonjour Michael et merci pour ton commentaire. Je craignais beaucoup que ce billet puisse être vu comme une attaque contre Spring ce qu’il n’est absolument pas : j’apprécie beaucoup ce framework et lui garde une certaine forme "d’affection" (je ne sais pas comment dire autrement) particulière puisque c’est l’outil qui m’a aidé à réellement comprendre l’architecture logicielle.

      Concernant les annotations, je sais qu’un certain nombre d’entres elles ont commencée à poindre leur nez dans la 2.0 mais les annotation permettant de définir un bean et ses méta-données ne sont apparues qu’en 2.5. J’ai commencé à travailler avec Spring dans la version 1.2.0 et ai beaucoup travaillé avec jusqu’à la version 2.0.5. J’ai en effet grandement apprécié l’allégement des fichiers de config avec les espaces de noms en 2.0 mais encore une fois, avoir la configuration dissociée du code lorsque le projet est gros ou éclaté ça complique la compréhension ou impose des outils comme Spring IDE qui bien très bons peuvent avoir des impacts sur les performances du poste développeur. A l’époque (en 2005) j’ai utilisé XDoclet pour pallier à ce problème sur certains projets, mais c’était loin d’être satisfaisant. 

      J’ai dernièrement participé à un gros projet utilisant un logiciel s’appuyant sur Spring 2.5. Cette solution logicielle pour des raisons historiques avait hérité d’une configuration spring 2.0, donc toute la définition des beans se trouvait dans des dizaines de fichiers fichier XML. Autant dire que lorsqu’un nouveau développeur arrivait sur le projet, sa courbe d’apprentissage était plutôt élevée.

      Concernant CDI, mon propos n’est pas de dire qu’il faut que Spring l’implémente (même si je pense qu’à un moment le framework sera peut être obligé de le faire) mais plutôt que Spring aurait du être partie prenante dans la définition de CDI. J’apprécie beaucoup Seam mais franchement j’aurais préféré que tous les acteurs du domaine arrivent à collaborer sur cette spécification. Maintenant je ne sais pas si c’est si facile que ça de faire collaborer Rod et Gavin et de les réunir dans la même pièce ;-).

      J’imagine ce que doit être le travail de Spec Lead sur une JSR : tout bonnement monstrueux. Je pense que tous les utilisateurs de Seam se sont sentis abandonnés pendant la grosse année ou l’équipe de développement bossait sur CDI et Weld. Il est clair que seule une boîte riche comme Redhat pouvait se le permettre et qu’a l’époque Springsource n’avait peut être pas les moyens de le faire, mais sans aller jusque là, on pouvait imaginer une collaboration sur CDI pour être partie prenante plutôt que spectateur de la standardisation.

      • Michael Isvy

        Bonjour Antoine,
        je n’ai pas un avis aussi tranché sur l’approche XML. Pour moi, l’approche annotations est à réserver à un public "averti", et ce pour plein de raisons :
        – Les annotations, et surtout le component-scanning, impliquent que tu as de bonnes conventions de nommage sur ton projet (ce n’est pas toujours le cas)
        – L’Autowire reste quelque-chose de difficile à comprendre pour des débutants (en tout cas beaucoup plus difficile qu’une déclaration XML explicite)
        – Les annotations sont mal supportés par les plugins graphiques de type STS et IntelliJ, alors que la façon XML marche très bien. Bref, avec les annotations on perd une très grande partie de la complétion de code.
        – Avec un mauvais paramétrage des annotations tu peux faire des catastrophes, comme plomber le temps de démarrage d’une appli. Côté XML, on a beaucoup plus de garde-fous.
         

        Bref, les annotations ça va plus vite à écrire, mais il faut bien comprendre ce qu’on fait parce que c’est plus dangereux. En général, je conseille les annotations pour les projets où l’ensemble de l’équipe est très à l’aise avec Java.
        Par contre, il m’est arrivé récemment de passer sur un projet où l’équipe était composée de 20 personnes dont 10 anciens cobolistes fraîchement reconvertis à Java. Pour moi, dans ce type de contexte, il faut oublier les annotations.

        Celà rejoint un point que je trouve dommage avec Java EE6: tous les exemples que tu trouves sur le web parlent des annotations. Il existe certes un moyen de faire du XML, mais il est très minimaliste et il est clair que l’effort a été porté sur les annotations. En Spring, on a développé un maximum de fonctionnalités pour vous offrir le meilleur confort quelle que soit l’approche choisie (avec le p:namespace, avec une multitude de schemas xml etc).

        Concernant notre non-implication sur CDI, il faut aussi voir le contexte historique. Je n’ai pas tout suivi en détail, mais si j’ai bien compris cette norme ne traitait pas d’injection de dépendance à la base, puisqu’elle s’appelait Web Beans. Elle n’a été renommée que très tard en "Dependency Injection …". Bref, si nous avions participé, ce n’aurait été que très tard. Par ailleurs, comme tu l’as très bien dit, nous devions faire des choix au niveau de l’affectation de nos ressources, et il a été choisi de bosser sur Spring 3.0 plutôt que de friser ou ralentir les projets pendant 1 an. JBoss a fait un choix différent puisqu’ils ont été très actifs sur les standards l’année dernière (avec forcement moins d’activité sur leurs projets open-source). Chaque boîte fait ses choix, ça me va très bien :).

  • Sébastien Lorber

    Merci. Pour un junior comme moi, ca fait plaisir d’y voir un peu plus clair dans tout ce bazar :)

     

     

    • asabotdurand

      Ravi que mes histoires d’ancien combattant soient compréhensibles, intéressantes et utiles aux Juniors :-). Pour ma part j’ai toujours pensé qu’on comprend mieux un outil ou une technologie quand on sait pourquoi elle a été crée et le cheminement qu’elle a suivi.

      Merci

  • piloupy

    Merci Antoine pour cet article. Tu as du y passer du temps, car il est très bien rédigé, tant sur le contenu que la forme. Il y a des titres, des paragraphes, un bon enchaînement dans les explications. Bravo !

    Je tente de m’auto-former actuellement aux technologies Java SE/EE, et j’avoue que toutes ces technologies sont difficiles à absorber. Un article comme le tien ne résout pas le problème de l’apprendtissage, mais il aide à mieux comprendre des termes que l’on rencontre par-ci par-là, et ce qu’il y a derrière !

  • Nicolas

    En tant que développeur, la ou je trouve l’injection de dépendance vraiment utile, c’est en rendant le code totalement indépendant de l’instance et de la classe d’implémentation utilisée.

    Je dois dire que je n’ai jamais abordé à fond les anotations sur ce sujet, mais dans cette optique, j’aurai tendance à préférer la notion XML. La notation XML permet de changer la configuration sans changer le code. A l’inverse, autant que je puisse le comprendre, les annotations faisant partie du code, eh bien tout changement requiert une recompilation…

    Alors en a t’on souvant besoin ? Je dirai que non ! Mais a t’on si souvant que cela besoin d’injection de dépendance ? Je dirai que non de la même façon. Dans beaucoup de cas, un simple singleton, un new explicite suffisent.

    Nous définissons des interfaces pour nos services, mais au mieux à part faciliter la création des tests unitaires, il ne reste en général qu’une seule implémentation du service en question au moins dans le code de production.

    Ne se retrouve t’on pas au final avec un "sur spec", comme cela est souvant le cas dans le monde java ? Je veux dire, tout cela est bien utile, et pour une API par exemple, ou un standard modulable et autement configurable (ou la je pense qu’on échapera pas à un peu de XML…), c’est très bien. Pour le commun des programmeurs qui doivent simplement créer une appli web, tout cela est bien complexe…

  • Pingback: Les tweets qui mentionnent Les rendez-vous manqués de Spring (une courte histoire de Java EE) « Ippon Technologies -- Topsy.com()

  • jeanphi

    Excellent article. Merci !

  • Pingback: Erreur 404 - Page non trouvée « Ippon Technologies()

  • Fabien

    chapeau l’artiste pour cet article !!

  • Pingback: Java EE 6 ici et maintenant ! « Ippon Technologies()

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

  • vbino

    Bonjour

    Je me permets de vous contacter car nous recherchons pour
    l’un de nos clients un expert Java – Spring.

    Pour un projet de très longue durée (au moins un an), il
    recherche cette expertise dans le cadre de la refonte du SI. Vous devrez, en
    binôme, avoir un recul technologique pour pallier aux difficultés liées aux
    complexités des frameworks. Il faut être capable de développer et de rechercher
    des solutions fiables aux différentes problématiques.

    Si ce projet est susceptible de vous intéresser, vous pouvz
    me contacter directement à l’adresse mail suivante : v.baron@inovans.fr ou au
    02.99.22.46.24

    Le poste est situé à Brest (Bretagne / france)

    Excellente journée,