- Apache Avalon et dérivés ont montrés la voie, même s'ils étaient sans doute un peu trop précurseurs et largement sous-documentés ;
- Spring a enfoncé le clou et définitivement imposé l'idée grâce à une documentation rarement égalée dans le monde opensource et aux qualités de pédagogue de son créateur ;
- Google Guice a marqué une étape en proposant une solution légère basée sur les annotations ;
- JBoss ne s'y est pas trompé en renommant "sa" JSR299 de Web beans en Java Context and Dependency Injection
Comment éviter d'être lié à un framework donnée ? Via une spécification officielle Java (JSR) !
La JSR299 a cet objectif mais ne remporte pas les suffrages. Ni Google Guice, ni SpringSource n'ont répondu à l'appel ... et on sait enfin pourquoi : Google Guice et SpringSource collaborent à l'élaboration d'une nouvelle JSR, permettant en théorie de passer de Spring à Guice au runtime sans toucher à votre code.
Malgré ses limitations, j'étais jusqu'ici un défenseur de l'injection via l'annotation @Resource (jsr250). Bien que supportée uniquement par Spring (et les EJB3) elle avait au moins l'avantage d'être non liée à un framework. Avec cette nouvelle JSR, on aura donc un moyen de spécifier clairement l'injection de dépendance sans se lier à un framework et une réelle alternative au runtime.
Quel intérêt ? Après tout, c'est vraiment rarissime de passer une appli de Spring à Guice juste pour le fun ! Pensez aux frameworks et bibliothèques, qui vont pouvoir exposer leurs composants et dépendances via cette API. C'est déjà le cas pour l'écosystème Plexus, et j'ai développé une passerelle pour pouvoir les utiliser dans un contexte Spring, mais ça reste du bricolage.
A l'avenir, on pourrait donc imaginer récupérer une bibliothèque utilitaire de type "accès à Google Map en Java" utilisant cette JSR et pouvoir l'exploiter depuis Spring ou Guice sans intermédiaire. Un retour des composants de haut niveau "sur étagère" ?
0 commentaires:
Enregistrer un commentaire