@Inject standardisation de l’injection de dépendances

Pas mal de bruit la semaine dernière dans la blogosphère Java avec l’annonce par Google et SpringSource d’une nouvelle proposition de JSR dédiée à l’injection de dépendances : @Inject (« Annotations for Dependency Injection »).
Comme le souligne ‘Crazy’ Bob Lee, l’auteur principal de Google Guice, la sortie de Spring 1.0, il y a déjà 5 ans, a apporté l’injection de dépendances aux masses, via un fichier de configuration propriétaire. Il y a 3 ans, Google Guice a proposé la même chose via des annotations (et SpringSource propose la même chose depuis Spring 2.5).

Si le succès de Google Guice est assez limité face au raz de marée Spring, le constat est là : il manque un standard. Comme les deux librairies ne sont pas compatibles, si vous exposez à un autre projet/équipe une librairie contenant des dépendances injectées par Google Guice, et que l’autre équipe utilise Spring, elle devra redéfinir tous les beans et leurs dépendances dans un fichier de configuration Spring (ou des annotations Spring).

@Inject propose donc de standardiser les annotations, afin de rendre portables sur différents frameworks (Guice, Spring, Tapestry IOC, etc.) des classes injectables.

Pourquoi autant de bruit ?

Une autre JSR qui parle d’injection de dépendances a déjà passé le stade de la proposition, la JSR 299, ex-Web Beans, portée en particulier par Gavin King de Red Hat, auteur d’Hibernate. La JSR 299 va beaucoup plus loin (trop?) que l’injection de dépendances, sujet abordé dans de précédentes revues de presse.

La JSR 299 a déjà beaucoup fait parler d’elle, car elle a récemment été remaniée, afin d’être intégrée à temps à Java EE 6 (dont la spécification doit être terminée dans 3 mois). Vous pouvez lire les commentaires sur notre revue de presse du 26 Janvier dernier, dans laquelle nous nous étonnions de l’absence de SpringSource dans la JSR 299.

Quelques extraits de ces commentaires :

Emmanuel Bernard (JBoss) : « …SpringSource n’a jamais demandé à faire partie du groupe d’expertise… »
Emmanuel Bernard : « …JBoss a passé un temps énorme à construire JSR 299… »
Antonio Goncalves (Java EE 6 Expert Group) : « …la JSR 299 ne se transforme pas radicalement, je dirais plutôt qu’elle réduit sa voilure et se concentre sur son but initial : un contexte unifié entre les EJBs et JSF… »
Cyrille Le Clerc (Xebia) : « …une JSR qui se transforme radicalement, au point de changer de nom, pendant la phase de Public Review, après deux années et demie de travail intensif, cela me parait exceptionnel et peu rassurant… »

Bonne idée, mauvais timing ?

C’est dans ce contexte que Google et SpringSource décident de proposer @Inject. L’intention est légitime, et les deux acteurs sont sans aucun doute les plus expérimentés sur le sujet de l’injection de dépendances. Il semble en effet beaucoup plus aisé pour Guice, Spring ou autre framework d’implémenter une JSR de la taille de l’éventuelle JSR @Inject, alors qu’on les voit mal implémenter rapidement la JSR 299. Google et SpringSource suggèrent donc à la JSR 299 de ne plus spécifier l’injection de dépendances, et de réutiliser les annotations définies dans @Inject (extrait de la proposition : « JSR 299 is defining a dependency injection framework for Java EE, and might support these annotations.« ).

En revanche le timing nous semble vraiment mal choisi : cette spécification est proposée à quatre mois de la validation de Java EE 6 (Septembre 2009). Cela semblait déjà compliqué pour la JSR 299 (dont l’inclusion à Java EE 6 n’a toujours pas été votée), et @Inject ajoute très tard son grain de sel.
Même si Bob Lee pense pouvoir faire valider @Inject par le JCP en cinq mois, ou moins dans le cadre de Java EE 6, il est peu probable qu’@Inject fasse partie de Java EE 6 ; on n’a jamais vu de JSR consensuelle validée aussi rapidement, comment ferait une JSR polémique ? La JSR 299 fait quant à elle face à un planning de plus en plus serré. Le résultat des courses est sans appel : on « risque » donc de voir arriver une spécification Java EE 6 sans JSR d’injection de dépendances.

Hormis Gavin King (JSR 299 – JBoss) et Bob Lee (@Inject – Google) qui ont âprement débattu sur la blogosphère, les membres des expert groups de JSR 299 et Java EE 6 sont restés silencieux … comme Rod Johnson, co-inspirateur de @Inject (qui était sans doute bien occupé la semaine dernière).

Enfin, je vous suggère de prendre quelques minutes pour lire le « brouillon » de proposition de JSR @Inject. On y voit de nombreux noms connus et reconnus parmi les supporters de cette JSR (Joshua Bloch, Paul Hammant – ThoughtWorks & PicoContainer founder, Doug Lea, Tim Peierls, James Strachan, Hani Suleiman, Jason van Zyl – Maven Plexus, Thiago H de Paula Figueiredo – Tapestry IoC). @Inject ne propose que de standardiser les annotations, et ne décrit pas la manière dont les dépendances vont être résolues, ce sera à la charge du conteneur. Le périmètre fonctionnel de la proposition est donc très focalisé.

Sous vos yeux ébahis, une injection de dépendance sans Spring, sans Guice et sans JSR

Pour rappel, même si aucune JSR d’injection de dépendances n’est intégrée dans le futur à Java EE 6, vous avez le droit d’injecter vos dépendances vous même, sans Spring, sans Guice, par exemple avec un simple constructeur Java ! :-)

public class MyService {
	private MyDAO myDAO;

	public MyService(MyDAO myDAO) {
		this.myDAO = myDAO;
	}
}

Ce qui vous permettra d’y injecter bouchons ou mocks depuis vos tests unitaires.

Quelques liens sur le sujet

• l’annonce sur le blog de Bob Lee
• la réaction de Gavin King et les échanges avec Bob Lee dans les commentaires
• le projet @Inject sur Google Code
• Proposition de la JSR @Inject
• quelques (rares) commentaires intéressants sur TSS
• @Inject sur twitter