Interview de Dubois J. , Retaillé J. et Templier T.

Thierry Templier :
Bonjour Gildas. C'est avec plaisir pour cette interview!
Je suis architecte applicatif spécialisé dans les technologies objet et Web au sein de la société Argia Engineering dont l'activité consiste en de l'architecture, de l'expertise sur les technologies Java/java EE et Web ainsi que de l'assemblage de solutions open source avec une très forte part de modélisation. Je travaille sur ces technologies depuis 8 ans et utilise au quotidien les différents outils et technologies abordés dans le livre, à savoir Spring bien sûr, mais également Hibernate, DWR, GWT, XFire, JMS, JMX...
D'un autre côté, je suis également le co-auteur du livre "JavaScript pour le Web 2.0" aux éditions Eyrolles, ouvrage décrivant les différentes facettes du langage JavaScript et des bibliothèques de ce type afin d'implémenter des applications Web à l'interface graphique riche.

Julien Dubois :
Bonjour et merci également de nous interviewer.
Cela fait maintenant 10 ans que je travaille dans le développement informatique, dont les 8 dernières années à ne faire que du Java/J2EE. Actuellement je dirige une équipe de 25 personnes, chez un éditeur de logiciel français. Nous sommes spécialisés dans le traitement de larges volumes de données et la très grande majorité de nos développements est réalisée avec les technologies décrites dans "Spring par la pratique" : Spring 2.0, Hibernate, ActiveMQ, DWR, Struts...

Jean-Philippe Retaillé :
Bonjour Gildas. Je suis architecte technique au sein d'un grand groupe d'assurance européen depuis plusieurs années. J'interviens essentiellement sur des projets Web J2EE avec des problématiques d'intégration fortes. Je suis également l'auteur de "Refactoring des applications Java/J2EE" et un des co-auteurs de "Programmation orientée aspect pour Java/J2EE", tous deux chez Eyrolles.

Thierry Templier :
L'écriture de Spring par la pratique a été motivé par l'envie de faire partager mon enthousiasme pour ce framework. Nous avions également envie d'adresser des problématiques d'architecture d'applications Java EE ainsi que des bonnes pratiques de développement. Ma rencontre avec Jean-Philippe et Julien a permis de concrétiser ce projet.

Julien Dubois :
Une telle occasion de passer toutes mes nuits et mes week-end devant mon PC, je ne pouvais pas refuser :-)
Plus sérieusement, j'avais déjà écrit plusieurs articles et cela m'avait énormément plu, alors faire un livre était la suite logique. Je souhaitais également faire partager mon expérience, et je trouvais très intéressant de le faire avec Thierry et Jean-Philippe, qui sont deux personnes que j'apprécie beaucoup.

Jean-Philippe Retaillé :
A l'origine, nous avions l'intention d'écrire un livre sur les bonnes pratiques Java/J2EE car nous trouvions qu'il y avait un manque dans ce domaine parmi les ouvrages français. Après avoir rédigé quelques chapitres, nous nous sommes rapidement aperçus que Spring était très souvent cité et utilisé pour implémenter nos exemples de bonnes pratiques. Nous avons donc décidé de réorienter le livre exlusivement sur Spring et de le centrer sur une étude de cas complète afin de nous différencier des approches adoptées par les ouvrages anglo-saxons disponibles sur Spring à l'époque.

Thierry Templier :
J'ai fait la connaissance de Julien par l'intermédiaire de mon ancienne société Sogeti en 2004. Nous nous intéressions à des sujets communs dont Spring... En parallèle, j'étais en contact avec Jean-Philippe qui m'était entré en relation avec moi pour son livre "Refactoring des applications Java/J2EE" afin d'utiliser une application open source que j'avais développée.

Julien Dubois :
Thierry et moi avons travaillé en même temps chez Capgemini (en 2004), on s'est rencontrés là-bas. A l'époque, peu de monde s'intéressait à Spring, et j'ai un collègue qui m'a donné le nom de Thierry.
C'est Thierry qui m'a ensuite présenté à Jean-Philippe, qu'il connaissait déjà pour avoir travaillé avec lui sur son livre "Refactoring des applications Java/J2EE".

Jean-Philippe Retaillé :
Tout a commencé avec mon livre "Refactoring des applications Java/J2EE". Je cherchais une étude de cas sous forme d'un projet open source existant ni trop complexe, ni trop simpliste et de préférence français. Je suis alors tombé sur JGenea qui a été développé par Thierry (que je ne connaissais pas à l'époque). J'ai donc pris contact avec lui pour obtenir l'autorisation d'utiliser son application et Thierry s'est proposé d'être relecteur technique de mon livre. Cela a suffit pour lui inoculer le virus de l'écriture. Je lui ai tout naturellement proposé de l'accompagner pour son premier ouvrage. D'expérience, je préfère travailler à 3 sur ce genre de projet et Thierry a immédiatement pensé à Julien.

Thierry Templier :
Quelques articles pour developpez.com autour des technologies OSGi, Spring et JavaScript!

Julien Dubois :
Peut-être un article pour Oracle Technology Network d'ici quelques mois.

Thierry Templier :
C'est en 2004 que j'ai commencé à m'intéresser au framework. Nous étions en train de regarder l'impact des tests unitaires dans les applications, ce qui nous a ammené naturellement à regarder l'injection de dépendances. L'approche m'a tout de suite intéressé puisqu'elle permettait de résoudre de manière très intéressante la gestion des relations entre les composants applicatifs. Fort de cette première impression plus que favorable, j'ai regardé en détail la seconde brique de base de Spring, la programmation orientée aspect, puis abordé les différents supports Java / J2EE du framework. Spring m'a permis de mieux (et complètement différemment) penser et structurer l'architecture de mes applications tout en laissant les préoccupations techniques au framework. Enfin un framework permettant de simplifier les développements Java / J2EE!!

Julien Dubois :
Cela fait des années que je m'intéresse à ce type de framework. En 2000 je bossais avec Cocoon 1 (http://cocoon.apache.org), et à l'époque j'avais beaucoup étudié Avalon, le futur noyau de Cocoon 2. Celui-ci a d'ailleurs été remplacé par Spring dans la dernière version de Cocoon (v2.2).
C'est donc tout naturellement que je me suis intéressé à Spring en 2003, lorsque le projet a commencé à être populaire. A l'époque je m'étais embarqué sur les technologies JBoss (EJB 2) et Struts : Spring a été un véritable libérateur pour moi, un retour à un développement propre, pragmatique et intelligent. C'est également ce que je voulais faire partager avec "Spring par la pratique".

Jean-Philippe Retaillé :
Je suis un cas particulier car je ne suis pas un utilisateur de Spring dans le cadre professionnel. La société pour laquelle je travaille impose des contraintes fortes dans l'utilisation de projets Open Source et à l'époque où nous avons dû choisir un framework de type Spring, ce dernier ne les respectaient pas toutes. Heureusement, ces manques ne sont plus d'actualité.

Thierry Templier :
La fonctionnalité que je préfère est le support d'accès aux données (intégration de framework de mapping objet relationnel et transactions). En effet, ce dernier offre la possibilité de structurer les composants de ce type de manière optimale tout en mettant en oeuvre des bonnes pratiques. Le développeur n'a plus à se soucier de la gestion des ressources relatives à la source de données. Le peu de lignes de code a mettre en oeuvre est vraiment impressionnant.
J'affectionne également particulièrement le support d'AspectJ dans Spring afin de mettre en oeuvre la programmation orientée aspect avec l'espace de nommage aop.

Julien Dubois :
Ce que je trouve le plus impressionnant actuellement est le support des transactions. C'est incroyable à quel point il est facile d'avoir une couche de service transactionnelle avec Spring, et ce quelque soit votre système d'accès aux données.
Spring permet ainsi d'avoir de manière transparente des transactions sur un ensemble de DAOs, lesquels peuvent être codés en JDBC pur, en Hibernate, en JPA... En utilisant un gestionnaire de transactions distribuées, vous pouvez également avoir des transactions XA entre vos DAOs et des queues JMS, par exemple. Tout cela n'est qu'une question de configuration, au niveau du code vous n'avez qu'à mettre une annotation pour demander à ce que votre service soit transactionnel.
Je recommande en particulier l'utilisation de Spring 2.0 avec Hibernate pour l'accès JDBC, ActiveMQ pour les messages JMS et Atomikos pour la gestion des transactions XA. C'est un ensemble robuste et performant.
Il faut également noter que Spring 2.5 est capable de découvrir automatiquement le gestionnaire de transactions utilisé sous Websphere et Weblogic, ce qui apporte un certain nombre d'améliorations sur ces systèmes.

Jean-Philippe Retaillé :
Pour ma part, je suis assez bluffé par l'intégration des concepts de la Programmation Orientée Aspect dans Spring. En effet, la création d'aspects est loin d'être naturelle pour les développeurs. Avec Spring, ils font de la POA sans le savoir, notamment avec le support des transactions qu'évoque Julien.

Thierry Templier :
Spring 2.5 offre d'intéressantes nouvelles fonctionnalités au niveau de la configuration, notamment avec des annotations. Différents espaces de nommage sont également apparus tels que celui relatif à JMS. D'un autre côté, il me semble important de noter que Spring a pris le virage d'OSGi car, désormais, tous les jar de la distribution correspondent à des bundles OSGi. Spring peut donc désormais être complètement utilisé dans des conteneurs de ce type. En parallèle, le projet Spring Dynamic Modules (ex Spring OSGi) continue son chemin afin de simplifier le développement de bundles et apparaît véritablement comme très prometteur.

Julien Dubois :
Spring 2.5 apporte quelques améliorations en termes de performance, ainsi que quelques nouveautés au niveau de la configuration. En particulier je suis très content du nouveau namespace JMS, qui permet une configuration facilitée.
Concernant les annotations, il s'agit juste d'un nouveau moyen de configurer son application : à mon avis cela n'est pas d'un grand intérêt, si ce n'est pour contrer les arguments de ceux qui trouvent que Spring utilise trop de XML.
Je pense qu'il est important de préciser que Spring n'est pas uniquement configurable via XML : le fichier de configuration XML est juste la manière la plus fréquemment utilisée, et c'est une méthode qui a fait ses preuves. Ce fichier XML est également très bien supporté par les IDEs, il y a des plug in sous Eclipse et IDEA pour vous aider à l'écrire ou le refactorer facilement. Mais rien ne vous force à l'utiliser, si vous préférez utiliser des annotations Spring vous propose désormais également cette option.

Jean-Philippe Retaillé :
Le virage OSGi de Spring qu'évoque Thierry est vraiment fondamental à mon sens avec l'émergence de la SOA (Service Oriented Architecture) dans les architectures d'entreprise. En effet, avec des demandes métiers de plus en plus nombreuses, dans des délais de plus en plus courts, impliquant une flexibilité optimale des systèmes d'information, nous avons besoin de construire des applications composites à base de services réutilisables selon des principes qui ne sont pas sans rappeler la révolution du plug&play que le hardware a rencontré il y a plus d'une dizaine d'année. J2EE n'offre pas en standard une souplesse suffisante dans ce domaine et les conteneurs OSGi semblent bien partis pour participer à relever le défi de ce genre d'architectures.

Thierry Templier :
Personnellement, je trouve qu'il manque un support plus avancé dans les IDE (Eclipse notamment) afin d'améliorer la productivité au niveau du développement, bien que la dernière version de Spring IDE comble un peu cet aspect notamment au niveau de l'AOP avec un support "à la AJDT". D'après ce que j'ai entendu dire, c'est en marche au niveau de SpringSource...

Julien Dubois :
Je sais que ce n'est pas du tout dans la roadmap de Spring, mais un bon gestionnaire de transactions préconfiguré serait le bienvenu pour tous les gens qui travaillent sous Tomcat ou JBoss.

Jean-Philippe Retaillé :
Je ne puis qu'abonder dans le sens de Thierry. Nous rencontrons de véritables problèmes de productivité sur les projets par rapport à ce qu'on a pu connaître avec les L4G par exemple. Nous avons en quelque sorte sacrifié une partie de notre productivité sur l'autel de l'indépendance (toute relative) vis-à-vis des éditeurs logiciels. Tous les développeurs ne sont pas de experts techniques et peu de choses sont faites en terme d'outillage pour leur simplifier la vie. Les apports de frameworks comme Spring ou Hibernate sont indéniables, tout comme l'apparition des annotations et l'ouverture de Java aux langages dynamiques, mais il faut aller plus loin en outillant mieux le développeur "métier". Toute la difficulté de ce genre d'exercice est de ne pas (re)tomber dans les erreurs du passé que nous avons connus avec les L4G à savoir le "vendor lock-in" et la "leaking abstraction" .

Thierry Templier :
J'utilise couramment des framewoks tels qu'Hibernate pour la persistence des données et DWR afin de mettre en oeuvre Ajax en environnement Java EE.
Au niveau sécurité, j'utilise Acegi qui a l'avantage d'être très flexible et peut être mis en oeuvre sans trop d'impact sur les applications existantes.
Je commence également à utiliser des technologies prometteuses telles que GWT (interfaces Web riches), JPA (persistance des EJB 3) et OSGi dans des prototypes et des projets de veille.

Julien Dubois :
Hibernate, pour la persistance, comme 95% des gens... Dans le "portefeuille Spring" il y a Spring Security (anciennement Acegi Security), qui est utilisé sur presque tous mes projets au boulot, et que je recommande toujours très fréquemment autour de moi. Comme gestionnaire de cache je suis un grand fan d'ehcache : c'est une solution assez simple, mais elle fait bien son boulot. Elle est facile à mettre en œuvre, performante, et ne m'a pour l'instant jamais causé le moindre souci. Pour tout ce qui est AJAX j'aime bien DWR et GWT (encore que ce dernier soit plus qu'une API...). DWR, en particulier, permet de publier automatiquement un bean Spring en JavaScript : vous pouvez ainsi appeler ses méthodes directement depuis le JavaScript de votre page Web. Si vous voulez plus d'informations sur ce sujet, le chapitre de "Spring par la pratique" qui traite de DWR et Spring est téléchargeable gratuitement sur le site d'Eyrolles : http://www.eyrolles.com/Accueil/Livre/9782212117103/

Jean-Philippe Retaillé :
Essentiellement Struts et Hibernate car ce sont des frameworks éprouvés (voire vieillisant pour le premier) et bien maîtrisés par de nombreux développeurs. Beaucoup d'applications dans le domaine de l'assurance ont des durées de vie très longues et par sécurité nous misons sur des "valeurs sûres" (malheureusement parfois au détriment de solutions plus innovantes)...

Thierry Templier :
Non, je ne pense pas car Spring a un périmètre beaucoup plus large et offre une véritable plateforme afin de développer des applications Java EE plus facilement et de manière très flexible. L'injection de dépendance ainsi que le support de la programmation orientée ne sont que les fondations de cette plateforme.

Julien Dubois :
Il n'y a pas vraiment de rapport entre le système d'IoC relativement simple proposé dans JEE et le portfeuille complet de solutions que propose Spring.
D'autre part, il n'y a pas de concurrence à ce sujet : par exemple les gens de SpringSource ont été depuis le début très impliqués dans l'utilisation de JPA, en particulier via leur travail avec BEA et le projet OpenJPA.

Jean-Philippe Retaillé :
Non car l'intérêt pour Spring ne se limite pas à l'injection de dépendance. Je pense que SpringSource saura bien se positionner par rapport à ce nouveau standard quand il sortira. Par ailleurs, quand un framework rencontre un tel succés, il est très difficile de le remplacer, même par un standard : il suffit de regarder JSF par rapport à Struts.

Thierry Templier :
L'approche de Google Guice d'utiliser des annotations afin de paramétrer l'injection de dépendances me semble intéressante, cette approche existant cependant maintenant dans Spring. Ce framework ne va néanmoins pas aussi loin que Spring afin de tirer parti de l'injection de dépendances et la programmation orientée aspect pour faciliter les développements Java EE.

Julien Dubois :
Il a permis à l'équipe de SpringSource d'améliorer deux points qui n'étaient pas auparavant prioritaires dans leurs développements :

• Le temps de construction d'un Bean a été très largement amélioré, et aujourd'hui les deux frameworks ont grosso modo le même niveau de performance. Il faut cependant voir que les Beans Spring sont presque toujours des Singletons, et que gagner quelques nanosecondes à la création d'un Singleton n'est pas d'un intérêt majeur.
• Les Beans Spring peuvent désormais être construits via des annotations (cf. la question plus haut sur les annotations), ce que demandaient certains utilisateurs

A part cela Guice semble être un bon framework d'IoC, plutôt spécialisé dans la couche de service. C'est une initiative intéressante, mais ce framework reste néanmoins nettement moins complet que Spring, et n'a bien évidemment pas une pénétration équivalente en entreprise.

Jean-Philippe Retaillé :
Je n'ai pas eu le temps de m'y pencher donc je n'ai pas d'avis sur le sujet. Ceci étant dit, je suis assez impressionné par les innovations que Google apporte dans le monde Java. J'espère qu'il s'agit bien d'un mouvement de fond et pas d'un feu de paille. De mon point de vue, la stratégie de Google par rapport à ses produits open source n'est pas claire, ce qui est assez gênant quand il s'agit de construire des solutions d'entreprise les utilisant. Veulent-ils être un éditeur logiciel à la JBoss qui construit une offre commerciale axés sur le service autour d'une gamme de logiciels open source ou s'agit-il plus d'une "expérimentation" à grande échelle susceptible de s'arrêter ?

Thierry Templier :
Spring Modules est un sous projet de Spring visant à mettre à disposition des intégrations d'outils ou de technologies autres que ceux déjà présents dans le framework Spring. Ce projet a été initialement créé afin de ne pas surcharger le projet Spring lui-même, projet qui contient déjà un panel de technologies importants. Je peux citer quelques modules de Spring Modules tels que les supports des moteurs de règles, des moteurs de workflow, de Lucene, de la technologie JCS ainsi que le framework AJAX XT. Ce projet est néanmoins beaucoup moins actif que le projet Spring lui-même mais les supports mis à disposition sont très intéressants.
Personnellement j'ai contribué sur le support des moteurs de règles par l'intermédaire de la spécification JSR94, de Lucene ainsi que sur des parties de la documentation.

Thierry Templier :
Je pense que c'est effectivement un plus. En effet, ce framework permet de structurer les applications et d'adresser les préoccupations des architectures applicatives. Néanmoins, les technologies sous jacentes ainsi que les préoccupations doivent être comprises en dehors du framework.

Julien Dubois :
C'est clair! Dans mon cas, il faut savoir que le framework utilisé dans ma société est basé sur Spring, donc toute expérience Spring est bien entendu un facteur déterminant.

Jean-Philippe Retaillé :
Pour moi, c'est un plus mais ce n'est pas suffisant. De toute façon, je préfèrerai toujours une tête bien faite à une tête bien pleine car c'est un gage de pérennité sur le long terme. Je vois trop de profils avec des CV ressemblant à des listes à la Prévert au niveau des technologies mais qui ne maîtrisent pas suffisament à mon goût des choses aussi essentielles que les design patterns ou les différentes formes de transactions..

Thierry Templier :
Je pense que les certifications permettent de garantir un certain niveau de compétence mais la pratique d'une technologie ou d'un framework reste primordiale. Cela s'applique bien évidemment au framework Spring. Par contre, dans le cadre de ce framework, je pense que plusieurs certifications seraient nécessaires suivant les briques du frameworks (par exemple, fondation du framework, accès aux données, MVC...).

Julien Dubois :
SpringSource, l'entreprise qui développe Spring (et anciennement connue sous le nom d'Interface21) est en train de préparer une certification, mais je n'ai pas plus d'information à l'heure actuelle. Je crois qu'ils vont l'annoncer à JavaPolis, le mois prochain.
Je vois énormément de candidats à l'embauche qui mettent "Spring" sur leur CV sans en avoir une réélle compréhension, une telle certification permettrait d'assurer un niveau de compétence reconnu qui serait très utile aux employeurs.
Quant à faire plusieurs niveaux de certification : le portefeuille Spring est tellement large que cela serait sans doute une bonne idée.

Jean-Philippe Retaillé :
Je suis assez dubitatif face à un système de certification. Celui-ci garantit un certain niveau de connaissance du sujet mais ne garantit pas une réelle compétence. A quoi cela sert de connaître un outil si on ne sait pas l'utiliser de manière efficace ? Beaucoup d'excellents développeurs ne sont pas certifiés... Ceci dit, il me semble tout à fait pertinent pour SpringSource de proposer ce genre de certifications, très prisées notamment par les entreprises anglo-saxonnes.

Thierry Templier :
Malheureusement non.

Julien Dubois :
J'aurais adoré mais non! Il faut savoir que SpringOne et Javapolis sont deux conférences montées par la même équipe, le BeJUG (le Belgium Java User Group), et qu'elles ont 6 mois de décalage environ. Bref je vais privilégier SpringOne, bien entendu.
Par contre il devrait y avoir du monde de SpringSource à Javapolis : il y aura un stand Spring, ainsi qu'une conférence de 3 heures détaillant toutes les nouveautés de Spring 2.5.

Jean-Philippe Retaillé :
Malheureusement non.