Par Antoine Sabot-Durand (Ippon Technologies) : Les rendez-vous manqués de Spring La JSR 330 : un exemple de la stratégie mal ficelée de SpringSource

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.

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.

L'équipe Spring s'est contentée de rester sur "le standard de fait"

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 frameworks ou de technologies mis en œuvre 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égre 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 3 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 accepté 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.