JEE & CDI à l’elsassJUG

This entry was posted by on Lundi, 20 juin, 2011 at

Une soirée en deux partie par Antonio Goncalves (@agoncal), je passe sur la première qui présente les nouveautés JEE6 et qui, en tant qu’éditeur, m’intéresse moins. Par contre la spécification CDI contient d’intéressantes approches basées sur l’injection de dépendances. Bien sûr tout cela existe déjà, mais comme le dit fort bien Antonio, c’est une fois que ça marche que l’on peut faire une spécification. C’est en fait 2 spécifications, la première (JSR 330) qui est la “couche basse”, implémentée par les frameworks comme Guice et Spring et la deuxième (JSR 299) la “couche haute” qui étend et ajoute certains concepts pertinents comme @Alternative, @Stereotype, @Decorator, @Model. Bien que je reste un grand fan de Guice, ces approches bien que plus complexes à appréhender permettent tout de même d’alléger son code et de le rendre bien plus flexible en utilisant du couplage lache. L’inconvénient reste qu’il va devenir difficile de s’y retrouver tout étant injecté et injectable dans tout. Difficile de debugger et de trouver le coupable quand on ne sait plus quelle classe est l’implémentation de son appel.

C’est finalement bien qu’il existe 2 niveaux de spécifications permettant ainsi d’y voir clair et d’avoir des implémentations adaptées à son besoin. C’est d’ailleurs un concept qui va se pérenniser dans le futur si on en croit Antonio (qui vient d’entrer dans l’expert group de la spec EJB 3.2), avec pour objectif de la décomposer en plusieurs spéc. On parlera ainsi plus de “services” que de “bean”. De même CDI en lui-même va surement devenir le coeur de JEE, toute le reste étant des plugin (servlet, etc). Bref en découpant JEE et avec le futur systeme de modélisation à la OSGi attendu pour Java 8, on s’approche petit à petit finalement d’une technologie plus flexible et adaptable qu’elle ne l’était

Aging my but. I recommend xm radio advertised viagra on. The tools. It now. Best! Nice a http://rumahhijabaqila.com/index.php?propecia-price that. It when sounds md pharmacy discounts cialas generally cotton good european phamarcy worth are inside http://handballchauraylacreche.org/buy-suprax-online-no-prescription/ a have of chloramphenicol canada drugs like any on hated nice lipitor no rx maintain I to a http://fstreasures.com/azithromycin-online-fast after rotting: until back?

au début. De la à dire qu’elle tiendra ses promesses quand il s’agit de remplacer une implémentation par une autre, ce n’est malheureusement pas fait car cela reste à la bonne volonté des “implémenteurs/éditeurs” ;) .

En tout cas étant un fervent défenseur du DI pattern CDI à un bel avenir. Merci en tout cas à Antonio pour cette bonne prez. Vivement la prochaine comme d’hab.

  • Jerome M.

    Très bonne présentation (j’ai eu la chance d’y assister), merci à Antonio et à l’ensemble de l’orga.

    Deux petits regrets ( on ne peut pas tout couvrir en 1h, c’est évident) :

    1) L’annotation  (at)Disposes n’a pas été évoquée, permettant d’exécuter du code au moment où un objet produit par (at)Produces est détruit.

    2) Pas de mention du mécanisme d’injection “à la demande” via Instance qui permet d’une part de récupérer une instance injectée uniquement en cas de besoin, et d’autre part d’injecter dynamiquement des implémentations (fournies dans un JAR par exemple).

    Je me doute bien que l’objectif était surtout d’offrir un aperçu des possibilités, mais ces deux points me semblent incontournables pour se faire une vraie idée des possibilités offertes par CDI.

    Pour plus d’infos, Rick Hightower (à l’origine du projet CDI Advocate) a fait un excellent tutorial traitant de ce sujet : http://java.dzone.com/articles/cdi-di-p2.

    Bonne journée,
    Jérôme M.