Dossier Par Antoine Sabot-Durand (Ippon Technologies) : Les rendez-vous manqués de Spring
Java EE6 intègre enfin un conteneur léger pour l'injection de dépendance. Une spécification qui a été pilotée par JBoss et non SpringSource. Retour sur une décennie de stratégie Open Source et de bagarre technologique.
Le 10 décembre 2009, après plus de 3 ans de travail du JCP, les spécifications Java Enterprise Edition (Java EE) 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 SpringSource (VMware) est un membre actif du JCP et a participé à l'élaboration de 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 termes de simplicité et de fonctionnalités ?
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 d'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.