INTERVIEW 
 
Guillaume Laforge
Architecte logiciel
Octo Technology
Guillaume Laforge (Groovy)
"Le framework Grails est certainement la killer application de Groovy"
Le langage Groovy ouvre aux développeurs Java de nouvelles perspectives en permettant d'élaborer des constructions syntaxiques complémentaires. Plus qu'un langage de script, il est qualifié de langage dynamique par le leader du projet Open Source.
03/11/2006
 
JDN Développeurs : Quel est l'intérêt de disposer de langage dynamique sur la plate-forme Java ?
  En savoir plus
 Octo Technoloy
Dossier Les plates-formes applicatives
  Sur le Web
Groovy
Site de Guillaume Laforge
Guillaume Laforge : Vous avez raison de rappeler que Java est plus qu'un langage, c'est une plate-forme, qui propose un langage statiquement typé par défaut qui tourne sur une machine virtuelle, ainsi qu'un kit de développement. C'est un véritable écosystème dans lequel peuvent coexister différents langages, différentes applications et serveurs d'applications. La richesse de cette plate-forme fait qu'il n'est pas très difficile de proposer un langage alternatif pour des besoins auxquels le langage hôte ne saurait répondre.

Groovy peut aussi bien être une glue que s'inscrire au coeur des applications."
Dans le cas de Groovy, on parle d'un langage "dynamique" et pas d'un simple langage de script. Il est dynamique, car il propose d'étendre Java pour supporter des constructions syntaxiques complémentaires, pour lui permettre de ne pas être statiquement typé, pour améliorer et enrichir des APIs existantes. Grâce aux fonctionnalités de méta-programmation, on peut apporter de nouvelles facettes à un langage comme par exemple l'interception de méthode, l'injection de dépendances ou de nouveaux champs virtuels -- à la sauce AOP (ndlr : programmation orientée Aspect).

Donc, grâce à l'écosystème de la plate-forme Java et au travers d'un nouveau langage, on peut apporter des solutions innovantes et élégantes à des problèmes complexes. Groovy se propose aussi bien d'être une glue pour lier des composants entre eux pour apporter de la valeur par leur réunion, que de rentrer au coeur des applications afin d'apporter une expressivité accrue pour exprimer des règles métier complexes.

Avec l'existence de Jython et JRuby, comment motivez-vous la création de Groovy ?

A l'époque de la création de Groovy, Jython et JRuby étaient encore assez jeunes et peu actifs. La vague Ruby on Rails n'avait pas encore réactivé le goût pour ces langages de script de la part des développeurs d'application d'entreprise. Mais le point le plus critique, c'est que ni l'un ni l'autre ne s'intégrait aussi nativement que possible à Java. Passer de Java à Jython / JRuby, ou l'inverse, c'est comme sauter une grande marche : on se retrouve dans un monde et un paradigme complètement différents.

Groovy, au contraire, est un langage dérivé de Java, facile à apprendre pour un développeur Java, car sa syntaxe est très proche, mais qui offre des fonctionnalités complémentaires piochant des idées ça et là dans d'autres langages comme Smalltalk ou Ruby. Les avantages majeurs de Groovy sont donc sa filiation évidente avec Java et son intégration native à la plate-forme Java.

Comment en êtes-vous venu à devenir gestionnaire de ce projet Open Source ?
Je suis arrivé assez tôt sur ce projet, quelques mois après son invention. A l'époque, je travaillais sur une application Web sur laquelle on pouvait créer ses propres widgets graphiques en Java. Mais il fallait développer ses extensions en Java, et re-tester, re-builder, re-packager chaque petite modification ou nouveauté que l'on apportait. Le cycle de développement n'était pas assez souple.

Je me suis alors intéressé à Groovy pour remplacer Java pour ces widgets. J'ai trouvé ce langage très prometteur et répondant bien à mon besoin. Malheureusement à l'époque, il était assez buggué, et par curiosité, j'ai commencé à proposer des corrections. De fil en aiguille, je suis devenu commiter puis, grâce à mon implication et lorsque les fondateurs du langage sont partis vers d'autres projets, j'ai naturellement pris le rôle de chef de projet.

Je coordonne le travail des commiters et des contributeurs, et je m'occupe du support aux utilisateurs. Je décide aussi de la destinée du langage, de sa syntaxe, des features supportées. Je corrige de temps en temps quelques bugs ou j'ajoute quelques fonctionnalités.

Les langages de scripts sont les compléments naturels aux langages historiques."
Avec l'arrivée d'implémentations de langages dynamiques sur les plates-formes Java et .Net, vivons-nous l'avènement des langages dynamiques/de script après les décennies Java, C++ et consorts ?
Clairement, je pense que les langages dynamiques et les langages de script ont le vent en poupe actuellement. Mais je ne pense pas qu'ils remplaceront jamais les "langages plate-forme" tels que Java ou C#. Au contraire, ils les complémenteront à merveille !

Je vois ces langages comme des compléments naturels aux langages historiques. Ils vont permettre de faire ce que les autres ne peuvent pas. Ils sont donc naturellement des alliés, et non pas des concurrents ou des ennemis.

Concevoir un langage dynamiquement typé pour une platef-orme historiquement fortement typée, a-t-il représenté un challenge difficile à surmonter ?
Ce n'est pas toujours évident, effectivement. L'aspect dynamique nous pose des problèmes parfois complexes. Le compilateur Java sait toujours quelle méthode appeler au moment de la compilation, alors qu'en Groovy, le choix de la méthode peut-être dynamique, au runtime, et du coup, le bytecode que l'on génère est différent de ce qu'un compilateur Java doit faire. Ce sont souvent des problématiques assez avancées qui sont comme des puzzles intellectuels à résoudre : comment arriver à développer telle fonctionnalité en s'appuyant sur une plate-forme qui ne la supporte pas nativement ?

Heureusement, Sun ne fait pas la sourde oreille et a lancé récemment un JSR pour ajouter de nouvelles instructions au bytecode de la machine virtuelle, et supporter les langages dynamiques. Nous verrons bien si ces efforts portent leurs fruits !

Comment un développeur Java peut-il profiter au mieux de Groovy ?
L'aspect le plus intéressant d'un langage comme Groovy, c'est lorsqu'on l'intègre à une application Java. On pourra exprimer des règles métier avec plus d'expressivité et moins de boilerplate code - ce code qui nuit à la lisibilité et la compréhension. On pourra même écrire en Groovy de véritables Domain-Specific Language grâce à sa syntaxe malléable. Ce code métier pourra même être externalisé dans des fichiers de configuration, dans une base de données ou ailleurs, afin que la logique métier puisse évoluer plus facilement ou être plus paramétrable pour qu'elle s'adapte d'un côté aux besoins d'un client X et de l'autre au client Y.

Avec Grails, au contraire de Ruby on Rails, on conserve l'avantage de son investissement dans des serveurs d'application."
L'un des projets majeurs liés à Groovy reste son framework Web Grails, qui cherche à être l'alternative Java de Ruby on Rails. Est-ce là la "killer application" de Groovy ?
Grails est certainement la killer-app de Groovy. C'est un framework Web MVC basé sur des composants très solides et éprouvés. Grâce à Groovy, on se concentre juste sur l'essentiel : les classes du domaine, les services, les contrôleurs et les vues. Avec Grails, plus besoin de cauchemardesques fichiers de configuration XML d'un bras de long, de beaucoup de classes pour mettre en place toute une infrastructure de développement.

Mais par rapport à RoR [ndlr Ruby on Rails], le gros avantage que je vois, c'est qu'avec Grails, on fait tourner nos applications sur la plate-forme Java. On conserve l'avantage de son investissement dans des serveurs d'applications, dans la formation des développeurs à Java et à ses frameworks. A tout moment, avec Grails, on peut facilement s'intégrer avec un SI d'entreprise, grâce au medium Java. Et on peut aussi configurer plus finement Spring et Hibernate quand le besoin d'extension se fait sentir pour aller au-delà de ce que propose Grails de base.

  En savoir plus
 Octo Technoloy
Dossier Les plates-formes applicatives
  Sur le Web
Groovy
Site de Guillaume Laforge
Java 6, avec la JSR 223, semble vraiment prendre la direction des langages de script. Voyez-vous ces types de langage devenir des composants majeurs de la plate-forme, face à un Java vieillissant ?
On pourra effectivement se passer de Java si on le souhaite. Mais je dirais que c'est dans la complémentarité des langages que l'on va gagner le plus et apporter le plus de valeur aux utilisateurs finaux de nos applications. Au travers du JSR 223, Sun reconnaît justement cette complémentarité en proposant une API pour intégrer facilement des langages de script dans une application Java.

Les langages de script et les langages dynamiques ont un bel avenir devant eux, mais le grand frère Java sera toujours son allié !

 
Propos recueillis par Xavier Borderie, JDN Développeurs

PARCOURS
 
 
Guillaume Laforge, 29 ans, est architecte logiciel chez Octo Technoloy.

2006 Architecte logiciel chez Octo Technology.
2005 Développeur chez Alten SI.
2004 Développeur chez Axway.
2001 Développeur chez Reflexe Technologies.
2000 Développeur chez IBM.

Et aussi participe au projet Open Source Groovy depuis décembre 2003, et co-organise la réunion mensuelle des développeurs Open Source Java OSSGTP.