| @plmuirLe 14 juin prochain, le Paris JUG propose une soirée autour de CDI. Le speaker, Pete Muir, n’est autre que le leader du développement de la spécification CDI 1.1 (disponible sous GitHub, la classe!). Actuellement employé par Red Hat Inc. Pete travaille également sur Infinispan, un data grid open source écrit en Java. Auparavant, Pete gérait les projets JBoss Seam et Weld, il est également le fondateur du projet Arquillian. Pete a travaillé sur plusieurs spécifications dont JSF 2.0, AtInject (JSR 330) et CDI. Il est un speaker régulier des JUGs et conférences comme Devoxx, JAX, JSFDays et JBoss World. | Sa session au Paris JUG se déroulera en deux parties. La première sera dédiée à CDI (JSR 299) et aux Managed Beans, spécifications introduites dans Java EE 6 : quand et comment utiliser CDI et les EJBs dans le développement d’application? Pete abordera également la perspective de Java EE 7 et de CDI 1.1. La deuxième partie de sa session sera dédiée aux extensions CDI. Vous découvrirez ainsi comment il devient très facile d’écrire et d’ajouter des fonctionnalités s’exécutant dans n’importe quel conteneur supportant la JSR-299.

Cet interview a été préparé conjointement par Audrey NEVEU, Agnès CREPET et Antoine SABOT-DURAND

Audrey, Agnès & Antoine: CDI 1.0 est en grande partie la standardisation de Seam 2. Quand et comment avez vous décidé d’en faire une JSR et quel fut le travail nécessaire pour réaliser cette spécification ?
Pete: Pour moi CDI n’est pas “en grande partie la standardisation de Seam 2”. Je pense qu’il a reçu les influences de Seam 2 (contextes, événements) et de Guice (injections de dépendances type-safe, cycle de vie des événements) à parts égales, de même que d’autres frameworks comme Spring.
Nous avons décidé de déposer la JSR car à JBoss / RedHat nous croyons fermement au fait de retirer les verrous commerciaux et au fait de fournir la portabilité des applications . Cette influence se retrouve dans plusieurs domaines comme le prouve notre engagement dans le JCP (CDI, Bean Validation), OSGI et le cloud. Quand nous avons développé Seam, nous trouvions qu’il manquait à Java EE un modèle de programmation puissant, moderne, qui viendrait en complément des services fournis par les EJB et que cela réduisait la portabilité des applications, et nous avons décidé d’y remédier.
Nous sommes vraiment heureux du succès rencontré par CDI et enthousiastes de prendre part à la réalisation de Java EE 7. C’est agréable pour nous de voir que CDI est perçu comme puissant et moderne par la communauté.
La JSR a été déposée il y a 5 ans environ et c’est déjà beaucoup de travail investi dedans. Gavin King, spec lead pour CDI 1.0, a travaillé sur CDI environ 18 mois à temps complet. Red Hat a aussi produit une implémentation de référence (Weld) et un Technology Compatibility Kit sur lequel j’ai travaillé 18 mois environ avec une équipe à temps partiel qui de son côté, a aussi travaillé 18 mois en tout. Depuis que j’ai repris le rôle de spec lead pour CDI 1.1, Ales Justin a pris le lead sur Weld et sera responsable de son implémentation dans CDI 1.1.

Audrey, Agnès & Antoine: D’après vous, quels sont, s’il y en a, les obstacles majeurs à l’adoption de CDI ?
Pete: Je pense que, comme avec toutes les nouvelles technologies, l’une des premières difficultés pour l’adoption de CDI a été la documentation, les tutoriels et les guides. C’est pourquoi je suis heureux de voir l’apparition d’initiatives telles que CDISource. Une autre barrière a été la disponibilité de serveurs d’applications certifiés Java EE mais là encore, les obstacles ont été réduits depuis l’année dernière, avec par exemple la sortie de JBoss AS 6 à Noël. JBoss AS7 qui est annoncé pour le mois prochain sera particulièrement attractif pour les développeurs avec un temps de démarrage de 3s.

Audrey, Agnès & Antoine: Il y a plusieurs points d’entrée pour l’injection en CDI : champs, constructeur, setters. Avez vous des recommandations pour chacun d’entre eux ? L’introduction de logique métier est possible avec les constructeur et setters, mais pas avec l’injection par champs, est-ce la seule différence ?
Pete: Mon préféré est l’injection par construction car il permet de créer un objet immutable, ce qui est une des clés techniques pour la programmation concurentielle, qui est quelque chose qui devient de plus en plus important aujourd’hui.
L’injection par champs est préférée par certain car elle est un peu plus propre (pas besoin d’injecter manuellement le constructeur) et qu’elle produit elle aussi un objet immutable, du moins tant que le développeur est discipliné et qu’il ne modifie pas la valeur de l’attribut dans son code.
L’injection par setter peut être utile pour ajouter CDI à du code legacy où ce design pattern a déjà été utilisé, mais je le n’utiliserai en aucun cas dans un nouveau projet.
Enfin, comme vous le disiez, l’injection par constructeur et par setter offre également la possibilité d’insérer de la logique métier lors de l’injection.

Audrey, Agnès & Antoine: Pouvez vous nous expliquer comment vous avez amélioré Weld, l’implémentation de référence pour CDI, au sujet de l’usage de la mémoire, du temps de démarrage et des performances au runtime ?
Pete: Nous avons apporté d’importantes améliorations à Weld et nous constatons maintenant que les performances au runtime sont aussi bonnes que celles d’autres implémentations de CDI ou que d’autres frameworks d’injection de dépendances. Pour ce qui est de l’usage de la mémoire et de l’optimisation du temps de démarrage, nous y avons également consacré du temps mais nous n’avons pas fini pour le moment : nous pensons pouvoir réduire encore l’usage de la mémoire par dix.

Audrey, Agnès & Antoine: Comment avez vous prévu de travailler avec les autres implémentations de CDI : Candi et Open Webbeans ?
Pete: Nous sommes assez proches des membres de ces équipes : les deux participent activement au groupe d’experts de CDI 1.1. Comme nous venons tous du monde de l’opensource, nous sommes habitués à partager notre travail et à nous engager dans la communauté. En pratique, trois équipes d’implémentation collaborent pour améliorer le Technicology Compatibility Kit et discutent au sujet de la spécification. Nous collaborons aussi pour promouvoir CDI de temps en temps : nous avons d’ailleurs proposé quelques sessions en commun à JavaOne cette année.

Audrey, Agnès & Antoine: Vous êtes le leader de la spécification CDI 1.1 qui semble résoudre certains des problèmes rencontrés par CDI 1.0 et standardiser quelques unes des extensions les plus populaires de CDI amenées par la communauté. Pouvez vous nous donner des exemples de ceux-ci ?
Pete: Nous avons identifié trois types de problèmes : des bugs dans la spécification (des erreurs de conception), des besoins de clarification nécessaires (des contradictions dans la spécification ou des implémentations qui ont pris différents chemins) et des nouvelles fonctionnalités, qui sont le plus gros du travail, la majeure partie des bugs et des clarifications ayant déjà été traités. Quelques uns des plus gros problèmes que l’on nous remonte est de revoir l’activation et l’ordre des interceptors, decorators et alternatives, qui contrôlent quelles classes sont scannées.
Nous sommes également en train de nous intéresser à la standardisation de quelques extensions inspirées par les projets de la communauté tels que Seam Solder et MyFaces CODI comme handlers de service.

Audrey, Agnès & Antoine: Le JCP a annoncé à la fin d’avril que la spécification de CDI 1.1 avait reçue une approbation quasi unanime : tout le monde ayant voté oui, excepté VMWare qui n’a pas voté. Quelles sont vos relations de travail avec les gens de VMWare ? Quelle est votre analyse sur le long commentaire fait par IBM sur ce vote ?
Pete: Je ne peux pas vraiment m’exprimer sur l’inactivité de VMWare dans le JCP, nous essayons plutôt de travailler avec IBM sur CDI, car ils nous avaient déjà apporté leur aide sur la version 1.0. Ils avaient quant à eux déclaré que la proposition pour CDI 1.1 inclue un nombre d’améliorations qui sont souhaitables mais dont certaines nécessiteraient un traitement externe à CDI. Les intercepteurs par exemple ne sont pas spécifiques à CDI, ils devraient être considérés comme un problème relatif à la plateforme dans son ensemble ou bien comme une mise à jour à rajouter à leur propre spécification. Pour IBM, faire fonctionner des fonctionnalités déjà implémentées est plus important qu’en ajouter de nouvelles et c’est pourquoi ils auraient été contraints de voter non si ces remarques n’avaient pas été prises en compte.
Red Hat a approuvé cette déclaration et inclu ces éléments dans la proposition pour CDI 1.1 sous un avertissement des spec lead Java EE précisant que nous devrions relever les problèmes qui concernent également d’autres technologies Java EE. Nous pourrons ainsi les affecter correctement au fur à et mesure des progrès de la spécifications de Java EE 7. Nous sommes également d’accord avec IBM que l’alignement avec d’autres JSR est important (la proposition inclue un certain nombre d’éléments avec lesquels s’aligner) et attendonc avec impatience de travailler avec IBM à résoudre les problèmes qu’ils pourraient nous faire remonter.

Audrey, Agnès & Antoine: Avez vous ressenti des changements dans le JCP depuis qu’Oracle a racheté Sun ?
Pete: Pas pour le moment, mais je ne suis pas impliqué dans les activités du Comité Executif du JCP.

Audrey, Agnès & Antoine: Y a t’il quelque chose de prévu pour fédérer tous les contributeurs de l’écosystème autour de CDI (Seam 3, Codi, CDI Source par ex.) afin d’assurer l’intéropérabilité et éviter le développement en double d’extension ?
Pete: Nous n’avons pas de projet de la sorte et nous sommes persuadés que la compétition dans l’écosystéme reste une bonne chose pour amener de l’innovation. Cependant, nous voulons garantir l’intéropérabilité et la meilleure façon de le faire, c’est de s’assurer que CDI offre les facilités nécessaires pour développer des extensions qui intéragissent au dessus de lui et pas à travers ses propres interfaces. Nous encourageons d’ailleurs toute personne qui rencontre des problèmes de la sorte à les faire remonter, de façon à ce que nous puissions les prendre en compte pour CDI 1.1. Il y a aussi des rumeurs à propos de JSRs qui auraient été proposées pour standardiser des fonctionnalités qui viendraient au dessus de CDI (pour la sécurité par exemple).

Audrey, Agnès & Antoine: Est il prévu d’intégrer des modules CDI (Seam Solder ou Seam configuration par ex.) dans la spécification, et si oui, lesquels ?
Pete: Nous réfléchissons à standardiser certaines fonctionnalités développées dans Solder, cependant de manière générale nous pensons que si une extension peut être développée facilement, il n’y a pas de réel besoin pour la spécification de se s’en mêler car cela risquerait d’étouffer l’innovation.
Il faut se souvenir que le but premier pour la standardisation de CDI était de produire des applications portables, et les extensions n’empêchent pas ça !

Audrey, Agnès & Antoine: L’instantiation de Bean étant déjà possible au runtime, pensez vous qu’il soit possible que CDI évolue de façon à permettre aussi l’enregistrement de Bean au runtime ? Avec cette possibilité, nous serions capable par exemple de créer un bean avec Groovy, comme nous le faisions avec Seam 2.x.
Pete: Les langages dynamiques deviennent de plus en plus populaires et il est important que CDI soit compatible avec eux. Seam 2 offrait la possibilité de “redémarrer partiellement” le container pour les classes Java et Groovy, une partie seulement des beans étaient redéployés. CDI a une validation du graphe de dépendances beaucoup plus stricte, ce qui autoriserait une solution plus complète : CDI pourrait ainsi voir quels beans sont affectés par des changements et ne redéployer que ceux là. L’expérience montre que les gens ont tendance à construire des modèles fortement interconnectés (il est très difficile de parvenir à construire des modèles efficaces et utiles sans qu’ils aient de nombreuses interconnexions) ce qui ferait qu’un tel redémarrage causerait le redéploiement de la quasi totalité de l’application. Bien sûr vous pouvez continuer à utiliser des classes Groovy avec CDI, vous ne pourrez juste pas changer les classes au déploiement.
Nous n’avons pas prévu d’ajouter quoi que ce soit là dessus à la spécification pour le moment et je pense personnellement qu’il est préférable de le laisser pour l’instant comme une implémentation à rajouter. Nous avons prévu d’expérimenter une fonctionnalité comme celle ci dans Weld (notez au passage que c’est un outil orienté SPI (Service Provider Interface), et non un utilisateur orienté SPI !) Il y a aussi quelques alternatives : l’excellente équipe de Serli travaille avec nous et les équipes d’experts OSGi de JBoss pour tenter de définir comment CDI et les services OSGi pourraient interagir, ces derniers permettant le redémarrage partiel de votre application. JRebel travaille déjà avec Weld et si nous fournissons une API de redémarrage partiel, il n’y a qu’eux que ça pourrait aider. JBoss AS 7 quant à lui a un temps de démarrage vraiment minime (2.3s) ce qui réduit le besoin de redémarrage partiel.
En conclusion, il est important de signaler que TorqueBox, le projet de JBoss, qui propose Ruby on Rails avec la puissance de JBoss AS, supporte CDI, ce qui offre la possibilité d’injecter vos services CDI écrit en Java dans Ruby, pour ceux qui veulent tester ce langage.

Audrey, Agnès & Antoine: Avec tous les progrès de CDI 1.1, est il plausible d’imaginer que de nombreuses personnes vont délaisser le container d’ejb dans le futur ?
Pete:EJB offre un set de “entreprise services” essentiels tels que la déclaration des transactions donc je ne vois pas le besoin de s’en débarrasser. Cependant ce que je vois, c’est un mouvement vers cette idée que les services EJB peuvent être appliqués à chaque bean managé, et pas seulement les EJB; les EJB et CDI seront ainsi dans la continuité l’un de l’autre. Red Hat encouragera certainement cette décision et je suis impatient de voir cela avoir lieu pendant le développement de Java EE7.

Merci Pete!

Les inscriptions seront ouvertes à partir du jeudi 9 juin 7H00! Rendez-vous sur le site du Paris JUG