I. Pour commencer, peux-tu te présenter pour ceux qui ne te connaitraient pas ?

Je m'appelle Guillaume Laforge. Je travaille sur le projet Groovy depuis fin 2003.
Je dirige le projet depuis 2004, et je suis également le spec lead du JSR-241 qui spécifie le langage Groovy au sein du JCP.

J'ai créé la société G2One, Inc. il y a un an, pour proposer aux entreprises des services professionnels autour du langage Groovy et du framework web Grails.

Et novembre dernier, nous avons été rachetés par SpringSource.

II. En quelques mots, qu'est-ce que Groovy ?

Groovy est un langage dynamique pour la machine virtuelle Java.
Sa syntaxe est très proche de Java, puisqu'elle dérive directement de la grammaire de Java 5.

Mais Groovy apporte quelques simplifications, comme le fait que les parenthèses ou les points-virgules sont optionnels, comme une notation native pour les listes, les maps, les expressions régulières, etc.

En plus, Groovy propose des "wrappers" autour de certaines libraries ou APIs du JDK pour simplifier encore plus des tâches courantes. A noter également des fonctionnalités comme les closures, les propriétés, la méta-programmation, et bien plus encore !

III. Comment t'es venue l'idée de créer Groovy ? Etait-ce pour combler certains manques de Java ? Etait-ce pour répondre à un besoin précis pour un autre projet ?

L'idée originelle était effectivement de simplifier la vie des développeurs Java, en rendant Java plus productif : d'où l'idée de dériver de Java pour la syntaxe générale, mais de s'inspirer d'autres langages comme Smalltalk, Ruby ou Python.

En 2003, je travaillais sur une sorte de générateur d'application Web pour un petit éditeur logiciel.
Il y avait une interface graphique qui permettait de définir des widgets à utiliser pour représenter les données, et il n'y avait aucun moyen de customiser et/ou de créer de nouvelles widgets.

Et c'est là que je me suis dit qu'un langage de script pourrait être bien pratique pour personnaliser les écrans de l'application, et que c'était simple à utiliser et intégrer au sein de l'interface de conception.

IV. Selon toi, quels seraient les principaux avantages de Groovy par rapport à d'autres langages dynamique tels que JRuby ou Scala ?

L'avantage majeur de Groovy par rapport à JRuby et Scala est que Groovy a été inventé avec les développeurs ayant Java à l'esprit.
Donc nous nous intégrons parfaitement et de manière transparente à Java.

On peut avoir des projets complètement mixtes Groovy / Java, faire de l'héritage dans tous les sens (Java -> Groovy -> Java et Groovy -> Java -> Groovy) sans aucun soucis. Toutes les fonctionnalités de Java 5 : annotations, generics, enums, import static, varargs, etc, sont supportées par Groovy, ce qui permet de faire du Spring, de l'Hibernate, du TestNG, du Guice, du JPA, sans aucun soucis.
Alors qu'avec les autres langages, vous serez très rapidement limité dès lors que vous voudrez vous intégrer avec tous ces frameworks d'entreprise.

V. A quoi pouvons-nous nous attendre pour les futures versions de Groovy ? Est-il prévu d'ajouter de nouvelles fonctionnalités ?

La version 1.6 vient tout juste de sortir !
InfoQ devrait publier dans les jours à venir un article couvrant toutes les nouvelles fonctionnalités du langage : amélioration de la performance multiple assignment, AST transformations, un système de dépendances et de modules, diverses améliorations sur l'outillage, sur les interfaces Swing, OSGi, JMX, et j'en passe (cf. l'annonce de la release sur mon blog).

Quant aux versions à venir, nous réfléchissons à une réécriture du runtime dynamique, pour améliorer encore plus la performance et rendre le système dynamique encore plus souple et flexible.

Dans l'immédiat, dans la future version 1.7, nous allons rajouter par exemple le support des classes anonymes internes et des classes imbriquées, et nous pensons également proposer une extension aux annotations pour supporter des types plus riches pour les paramètres des annotations. Mais le plan n'est pas encore gravé dans le marbre, tout peut évoluer, et le feedback des utilisateurs sera prépondérant.

VI. Penses-tu que la multiplication des langages dynamiques tournant sur la JVM est un danger pour la communauté Java ?

Non, pas vraiment, c'est plutôt une chance.
De toute façon, de réellement utilisés dans la nature, il n'y en a même pas une poignée. Il n'y a pas loin de 200 langages pour la JVM, dont une centaine, à la louche, qui a déjà de nombreuses années derrière eux, et cela n'a pas pour autant chamboulé le paysage du monde Java.

Par contre, c'est tout de même grâce à cette impulsion (mais aussi grâce à la concurrence de Microsoft) que le langage Java est poussé à évoluer encore plus et emprunter de bonnes idées aux autres langages de la JVM. Par exemple, pour Java 7, Sun pense rajouter la "safe navigation" (pour éviter les NPE) qui provient tout droit de Groovy !

La copie est bien la meilleure forme de flatterie, comme on dit.

VII. Quel est ton langage de script préféré, Groovy mis à part ?

Hmm, bonne question. Groovy s'est pas mal inspiré d'autres langages comme Python, Smalltalk ou Ruby. J'aurais du mal à en choisir un, dans le sens où je ne suis pas un expert ni dans l'un ni dans l'autre, mais tous ces langages sont fascinants et méritent d'être explorés.

VIII. Penses-tu que cela peut finalement être une bonne chose pour l'écosystème Java que des fonctionnalités telles que les closures ne soient pas intégrées au langage Java ?

Au départ, j'étais un fervent partisan des closures en Java ! Puis petit à petit, en voyant par exemple une présentation de Joshua Block sur le côté obscur des closures (BCGA en particulier), je me suis rendu compte que rajouter les closures aujourd'hui dans Java (et non pas à l'origine du langage), ce serait peut-être une erreur, car Java n'est pas prêt à recevoir cette complexité additionnelle que représente les closures.

Quand on doit faire cohabiter les checked exceptions, les generics, les annotations, les closures...
Je pense qu'un développeur Java lambda aura du mal à appréhender toutes les complications que celà impose.

Donc oui pour les closures, mais pas forcément aussi complexes que celles proposées par BCGA.

IX. L'usage de Spring comme brique de base pour Grails a-t-il pu influencer le rapprochement et rachat par SpringSource ? D'autres alternatives étaient-elles possibles ?

Oui, bien évidemment. Groovy était également un des langages privilégiés par SpringSource pour Spring et pour d'autres projets du portefeuille SpringSource.
Donc aussi bien Groovy que Grails étaient en adéquation avec la philosophie de Spring / SpringSource.

Au départ, nous avions simplement pensé à mettre en place une sorte de partenariat entre nos sociétés, et puis finalement, un rachat était encore plus intéressant pour pouvoir travailler de manière plus étroite ensemble, sur nos projets respectifs.

X. En quoi ton quotidien change depuis le passage G2One => SpringSource ?

Et bien en fait... ça n'a pas changé grand chose !
Je continue à travailler de chez moi sur Groovy, Grails et autres projets dérivés. Je suis totalement libre de travailler comme je l'entends.
Par contre, ce qui est sympa, c'est que se retrouver dans un plus grand groupe, cela ouvre des portes, des opportunités d'intégration de Groovy dans d'autres projets, etc. C'est assez motivant.

Et puis en France, j'étais seul, maintenant j'ai également des collègues SpringSource France avec qui papoter et refaire le monde ensemble !

XI. Un livre sur Groovy/Grails en français ?

Il y a quelques efforts dans cette direction à l'heure actuelle, justement, mais l'écriture d'un livre est très exigeante en temps personnel, et c'est difficile de se lancer.
En tout cas, il y a effectivement un projet en cours. Mais je n'en dis pas plus pour le moment.

XII. Comment juges-tu l'adoption des langages dynamiques ? Quel est pour toi le domaine d'application le plus porteur ?

Il y a bien évidemment un très fort regain d'intérêt pour les langages dynamiques, c'est agréable à voir.
Donc on peut bien évidemment s'attendre à ce que les langages dynamiques deviennent de plus en plus mainstream.

Un langage comme Groovy est vraiment génial pour tout ce qui est extension d'un logiciel, pour offrir une manière aux utilisateurs d'étendre les fonctionnalités de base, mais c'est aussi un langage très adapté pour définir des Domain-Specific Languages, ces langages customisés pour définir des règles métier.

XIII. Seras-tu présent lors de SpringOne Europe ?

Je crois que le planning des sessions n'a pas encore été défini, mais je serais très certainement là pour parler de Groovy.
Au passage, je suis en train de coorganiser une conférence dédiée à Groovy, Grails et Griffon : http://www.gr8conf.org. Ce sera à Copenhague, au Danemark, les 18 et 19 mai. Ca vaut le coup, pour découvrir et approfondir toutes ces technologies !

XIV. Remerciements

Je tiens tout d'abord à remercier particulièrement Guillaume Laforge d'avoir accepté cette interview, mais aussi Ricky81 et romaintaz de m'avoir aidé pour celle-ci.