Prenez le temps de lire les quelques 68 commentaires échangés entre Gavin King (auteur d’Hibernate, spec lead de la JSR-299 WebBeans) et Bob Lee « Crazy Bob » (auteur de Google Guice, lead developer de la librairie Google Android). Je vous renvoie vers le très bon billet écrit par Guillaume Carré sur le blog de Xebia pour le fond du débat, car après avoir lu les échanges, je me suis demandé si quelqu’un s’était déjà posé la question suivante : à quoi servent les JSR (Java Specification Requests) ?
Il y a plus de 10 ans, SUN Microsystems a eu l’excellente initiative de libérer le processus de définition du langage Java. L’objectif à l’époque était de prendre en compte les demandes grandissantes d’évolution des différents éditeurs du tout jeune langage Java. Rappelons que chaque JSR propose une implémentation de référence de la spécification, avec un code source accessible. Il faut aussi mettre au point un lot de tests afin de proposer un TCK (Technology Compatibility Kit).
Un match de boxe
Gavin King est spec leader de la JSR-299, spécification apparue début 2006 et qui est en phase finale, afin d’être livrée d’ici septembre 2009 dans la future version JEE6. Au début de cet année, la spécification initialement présentée comme WebBeans a été renommée « Java Context and Dependency Injection« . Derrière tout cela, les acteurs de la communauté avait noté que la spécification avait en effet évolué vers l’injection de service, le terme WebBeans était alors trop réducteur par rapport à la portée de la spécification. Pourtant en relisant ne serait-ce que les premières lignes de la JSR, on voit que le scope initial, intimement lié à JBoss Seam, était la gestion du cycle de vie dans une application Web…
La spécification a aujourd’hui bien évolué, et propose un standard d’injection de dépendances à Java EE 6. Preuve que le processus communautaire a du bon, il est claire que la future version entreprise de Java sera plus mature et plus flexible que les versions antérieures. L’effort du JCP, et je pense que les standards ont du bon, est que la spec JSR-299 offre un moyen standard donc portable d’apporter de l’injection de dépendance à une application d’entreprise. Je n’ai rien contre Spring, je pense qu’il est plutôt bon et raisonnable de conserver le système libre et d’offrir (tardivement) une spécification d’injection pour les services et les dépendances.
Un petit pavé
Crazy Bob jette un pavé dans la marre en annonçant le 5 mai dernier une proposition de JSR sponsorisée par Google, SpringSource,PicoContainer, Plexus, Tapestry IoC, et Simject en portant l’effort sur un scope plus réduit. Il souhaite proposer une spécification afin que l’injection de dépendance soit un standard dans Java SE 7 par exemple. Il pense même qu’il sera possible en 5 mois de finaliser cette JSR afin de l’inclure dans la future version de Java EE6. C’est tout simplement impossible, voir irréaliste. Cela entraine bien entendu une réaction un peu épidermique des personnes de la spécification JSR-299. Vous suivez toujours ?
Pourtant cette initiative n’est pas inutile car :
– elle offrirait une gestion de l’injection native dans Java
– elle ne nous forcerait pas à utiliser tout Java EE6
– elle reste pragmatique et ne se focalise que sur les points précis de l’IoC que tout le monde utilise (Guice, Spring…)
– elle nous permettrait de rendre portable notre code d’injection (Spring vers Guice, Guice vers Spring, Spring vers Spring…)
JSR-299 une marieuse
Nous avons d’un côté la JSR-299 qui est pour moi une marieuse : faire se rencontrer les différents composants de votre application d’entreprise, vous aider à faire collaborer votre application avec la gestion des sources externes. A ce titre je pense qu’il est indispensable d’avoir cela sous la forme d’une spécification. Cela en fait certainement l’une des JSR les plus complexes.
Le petit nouveau
D’autre part, nous avons des développeurs utilisateurs de Spring et de Guice qui souhaitent rendre standard l’injection de dépendance dans une spécification. Cela revient aussi à dire que tout le monde recevrait le support de l’IoC… même ceux qui s’en passent très bien.
Tout ceci ne vous intéressera que si vous faîtes appel à l’injection de dépendance, que vous le faîtes car vous souhaitez changer de framework d’IoC, que vous vous fichez du reste des excellents fonctionnalités dans Spring comme la gestion des abstractions (JDBC,JMS,Securité…), la programmation orientée Aspect, la gestion des Transactions, bref que vous ne vous intéressez QUE à l’injection de dépendance… Est-ce bien réaliste ?
N’oublions pas aussi les « mauvais » effet de la surinjection de dépendance. Nous avons tous vu une fois une application avec des fichiers de mapping obèses, où le framework d’injection de dépendance est sur-utilisé. Rien ne remplace une architecture propre et une bonne utilisation des patterns. Je ne suis pas un fan du « tout-Spring » comme je n’étais pas fan du « tout EJB ».
Alors à quoi servent les JSR ?
Le principe des spécifications ouvertes a apporté à Java une bouffée d’oxygène. Dès 98 cela a été le moyen de sécuriser les investissements des clients finaux. Grâce à la normalisation et aux standards, un code écrit en Java sur Windows et compilé avec la JVM de SUN fonctionne sur votre serveur Solaris, avec votre serveur d’application Oracle Weblogic et JRockit. Standard est donc synonyme de sécurité, d’indépendance et de pérennité dans le temps. Les JSR sont donc un ensemble de règles appuyées par une implémentation de référence, avec accès libre au code source, ce qui nous sécurise et évite de devenir dépendant d’un éditeur de logiciel.
La dure vérité
Deuxième effet notoire : il y a toujours quelqu’un de plus intelligent que vous. Il y a toujours un petit gars quelque part dans le monde qui a déjà eu cette idée géniale. Il y aura toujours un étudiant prêt à faire 60 heures par semaine pour coder une API. Il y aura toujours un Doug Lea ou un Gavin King avec un oeil d’artiste sur le code.
Java et donc les JSR vous apprennent une chose : vous êtes une m… et il va falloir faire avec. Non vous n’êtes pas génial à avoir pensé vous aussi à un framework d’inversion de contrôle. Le principe a été décrit en 1988 à ma connaissance. Non arrêtez d’écrire des classes comme « SynchronizedHashMap » et reprenez la lecture de la spécification Java.
Les spécifications sont donc un moyen de s’assurer que les meilleurs principes se diffusent et que la plateforme Java évolue. C’est un canal de diffusion de la connaissance, qui permet aux éditeurs et aux acteurs de la communauté Open-Source de travailler main dans la main (ou poing dans figure aussi) mais de travailler ensemble. Quelque part, je vois cela comme les tests indépendants EuroNCAP de crash-test des voitures. Mine de rien, en 10 ans nous avons tous un ABS et bientôt l’ESP sur nos voitures, car un organisme indépendant a décidé de noter les constructeurs sur la sécurité de nos voitures.
Conclusion
Les standards ont du bon, merci à CrazyBob de penser qu’une JSR pour une version light de l’IoC est une bonne idée. Par contre j’ai franchement du mal à me projeter dans 2 ans, et à imaginer un standard de facto pour l’IoC. L’approbation de cette JSR par l’Expert Group, dont fait partie RedHat (Gavin King) pour sortir d’ici 5 mois me semble tout simplement impossible. Mais comme je vous le disais : nous sommes bêtes et nous devons donc attendre patiemment que les gourous du JCP s’organisent afin de s’accorder sur cette JSR.
Messieurs de RedHat, de SpringSource et de SUN-Oracle : respirez un grand coup et revenez vous assoir afin de travailler ensemble, car le plus gros risque que court Java serait que ce processus soit remis en cause. Il faut que la communauté reste prudente et fasse la distinction entre ce qui est important pour faire évoluer Java, de ce qui est purement manoeuvre de noyautage. Il n’y a pas de guerre froide entre les grands acteurs (Oracle/SUN, RedHat/JBoss, Google, IBM et SpringSource) et il serait dommage de commencer à casser ce système.
Pour terminer allez lire les échanges entre Gavin King et Bob Lee :
http://in.relation.to/Bloggers/CommentsOnAnnotationsForDependencyInjection
La page sur la proposition de JSR Light sans sucre d’injection de dépendance :
http://google-code-updates.blogspot.com/2009/05/javaxinjectinject.html
Voir aussi l’article de Rickard Öberg sur @Inject
http://www.jroller.com/rickard/entry/why_inject_is_a_bad
Il trouve que @Inject manque de finesse.
Ce qui rejoint bien le propos de l’article sur le fait qu’il y a toujours quelqu’un de plus malin, plus intelligent …
J’aime beaucoup aussi que tu rappelles le bienfait des standards. (je ne dis pas ça contre Spring mais… en fait si)
Comme dit l’autre, ce qui coûte dans une technologie, ce n’est pas le prix pour l’utiliser, c’est (aussi, et surtout) le prix pour en sortir.
Sinon il reste les bons vieux fichiers de confs en xml pour Spring. On se moque, on se moque, mais ça c’est pas intrusif. Et oui, la programmation xml a de temps en temps quelques (rares mais sûrs) avantages.
Salut gabriel
D’accord avec toi, les annotations ne doivent pas devenir un moyen d’éviter de respecter certains principes d’architectures ou de connaître les designs patterns. La configuration XML de Spring quoique parfois trop lourd, a l’avantage de ne pas s’inviter trop dans le code. Et Spring 3 offre les 2 alternatives.