Par Antoine Sabot-Durand (Ippon Technologies) : Les rendez-vous manqués de Spring Sring manque à plusieurs occasions de devenir un standard officiel
Pendant ce temps du côté de chez Spring...
Pendant les années 2005 et 2009, Springsource a beaucoup travaillé sur le lancement de nouveaux produits : serveur d'application basé sur Tomcat (tc Server), serveur d'applications 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, rien de très révolutionnaire.
En revanche, le discours de Spring Source concernant Java EE (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é.
Les rendez-vous manqués de Spring
Il aurait était facile de faire comme JBoss et venir "imposer" Spring comme implémentation du standard
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 les 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 qui est sortie 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 son 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.