Plus Groovy que BeanShell

OCTO développe actuellement deux offres autour des langages dynamiques et des socles de développement rapide d'applications Web. La première offre se propose de développer des langages métier verticalisés à l'aide du langage dynamique Groovy pour représenter des concepts métier complexes, tandis que la seconde est basée sur le framework Grails pour créer des applications innovantes dans un mode itératif pour répondre efficamcent au mieux aux besoins exprimés.

Suite à une avant-vente chez un de nos clients, on m'a posé quelques questions complémentaires concernant un autre langage de script sur la JVM : BeanShell. La personne en question souhaitait mieux comprendre les différences entre ces deux langages en proposant certains axes de comparaisons : la facilité d'apprentissage par rapport à Java, le prototyping rapide, l'écriture simplifiée de règles métier, le déploiement à chaud et le debugging, l'intégration avec les standards. Comme ces questions et ces critères d'analyse sont particulièrement pertinants, je me propose dans cet article de reprendre la comparaison ensemble.

Si l'on devait remplir une grille de choix avec pour critères les différents points énumérés, on s'apercevrait qu'il y a des nuances subtiles.

Reprenons ces différents points un à un.

• L'apprentissage de Groovy comme de BeanShell est identique. Un développeur Java ne sera pas perdu puisque la syntaxe de base est la même. Par contre, Groovy va plus loin que BeanShell en proposant des fonctionnalités plus avancées au niveau du langage, mais apporte également son lot d'APIs simplificatrices. En quelque sorte, BeanShell est " brut de fonderie " comparé à Groovy qui va plus loin sur le langage et les APIs.
• Sur le prototyping, l'un comme l'autre se classerait sur la même marche du podium. J'aurais tendance à donner tout de même l'avantage à Groovy justement grâce aux APIs que le projet fourni : il est par exemple beaucoup plus simple de parser un document XML ou d'accéder à une base de données par JDBC, là où BeanShell ne sera pas plus concis que Java.
• Par contre, pour l'écriture simplifiée des règles métier, là, Groovy va clairement beaucoup plus loin. Avec BeanShell, on a exactement les mêmes limitations qu'en Java pour écrire un DSL (un langage métier verticalisé). Au travers de sa syntaxe malléable et de sa nature " dynamique " (par opposition à " langage de script "), Groovy permettra d'écrire du code moins technique mais plus proche des concepts métier. En Groovy, on peut écrire du code expressif comme 30.kilo.euros, alors qu'en BeanShell il est tout à fait impossible de faire ce genre de chose. Impossible de créer ses propres structures de contrôle, ses propres extensions de langage, etc.
• Sur le déploiement dynamique et le debugging, l'un comme l'autre sont comparables.
• Sur l'intégration avec les IDEs du marché, encore une fois, Groovy a une bonne longueur d'avance sur BeanShell car il existe des plugins pour les principaux IDEs du marché : Eclipse, IntelliJ IDEA, NetBeans, et tout un ensemble d'éditeurs de texte. Par contre, évidemment, le support de ces langages dynamiques est plus limité en règle générale par rapport au support qu'on peut trouver pour le langage Java. A ma connaissance, il n'y a aucun support BeanShell dans aucun des IDEs du marché. Pour information, il y a actuellement 4 développeurs travaillant sur le plugin pour Eclipse, et JetBrains viennent de décider d'apporter un support officiel de Groovy dans IntelliJ IDEA.

Au-delà de ces quelques critères, il y a bien d'autres éléments à prendre en compte. J'en citerai quelques-uns :

• La performance : Groovy peut être compilé comme interprété. Ce mode interprété est particulier en cela qu'il s'apparente au JIT de Java : compilation Just In Time. C'est-à-dire qu'une fois interprété (compilé en mémoire), l'exécution de scripts Groovy sera aussi rapide que s'ils avaient été pré-compilés à l'avance. Hors BeanShell ne propose qu'un mode interprété et ne propose pas de mode de compilation qui permettrait d'améliorer ses performances.
• Ensuite, le second critère que j'aimerais mettre en valeur, c'est la vitalité du projet. Pour connaître la vitalité du projet, il faut se rapprocher de sa communauté, des ses canaux de communication. BeanShell a une communauté de développeurs et d'utilisateurs assez limitée, et son principal acteur et créateur (Patrick Niemeyer) ne maintient plus à jour le projet depuis déjà au moins deux ou trois ans. Le projet stagne, et aucun des patchs de correction de bugs soumis ces dernières années n'ont été réintégrés dans le projet. Malgré l'apparition d'un JSR, le projet est quasiment mort, et le JSR ne sert finalement qu'à apporter une valeur " publicitaire " au projet au travers du sceau du processus de standardisation.

Une image valant souvent plus que des mots, voici un radar synthétisant les notes que l'on peut donner à Groovy et BeanShell en fonction des critères évoqués :

Si vous regardez la vitalité du projet Groovy par contre, vous vous apercevrez rapidement que sa notoriété et sa popularité ne cessent de grandir. Rares sont les conférences où il n'y a pas de session sur Groovy ou sur Grails. Deux livres sur Groovy et deux livres sur Grails sont sortis récemment. Des éditeurs s'intéressent de près à l'intégration de Groovy dans leurs produits (JBoss et Oralce par exemple). Une conférence dédiée à Groovy et à Grails aura lieu fin mai. Le support des utilisateurs sur les listes de diffusion est toujours très rapide et efficace. L'équipe de développement est assez nombreuse pour un projet Open Source, et il y a même un développeur travaillant à plein temps sur le projet.

Maintenant, abordons l'aspect conformité aux standards d'intégration du scripting dans Java.
Il existe bien évidemment une intégration JSR-223 / javax.script spécifique à Groovy. J'ai même personnellement aidé l'ingénieur de chez Sun qui s'est occupé de cette intégration. Donc dans une application sous Java 6 (même sous Java 5 éventuellement), on peut tout à fait intégrer Groovy à l'aide de cette API.

A noter cependant que l'API JSR-223 est finalement assez pauvre en termes d'intégration et ne tire pas parti de tous les atouts du langage. Si l'on souhaite tirer au maximum parti des fonctionnalités proposées par le langage sous-jacent, on a tout intérêt à utiliser les APIs spécifiques de ce langage.
Cette API de scripting n'a vraiment d'intérêt que si l'on souhaite intégrer plusieurs langages différents tout en les utilisant avec une même API, mais malheureusement, l'API en elle-même est limitante par rapport à ce qui est proposé par Groovy notamment.

En résumé, sur ce point, Groovy répond donc parfaitement à ces critères de visibilité et pérennité en ce sens que ce langage s'intègre facilement avec l'API de Java 6. De plus, comme je l'ai évoqué entre parenthèses tout à l'heure, on peut également réutiliser l'API javax.script dans Java 5, sans attendre le déploiement de Java 6 dans nos entreprises.

Mon client mentionnait également un article sur Artima relatant une interview avec Pat Niemeyer.
Le résumé que mon client en faisait était que Beanshell serait plus à même de proposer une implémentation modèle, car plus liée à Java que Groovy qui d'après Niemeyer semble de plus en plus suivre sa voie propre.

Mais il y a plusieurs façons de voir cette conclusion. Je la formulerais différemment. BeanShell se contente de " coller " au langage Java sans apporter de nouvelles fonctionnalités, tandis que Groovy ne s'arrête pas là et va plus loin en proposant une syntaxe malléable et des APIs complémentaires dont vous pouvez tirer parti. Quant à suivre sa propre voie, effectivement, plutôt que de stagner, c'est le choix de Groovy d'aller justement plus loin et d'innover en apportant des solutions plus simples à des problèmes complexes. Suivant de quel côté de la barrière on se place, la vision est tout à fait différente.
Surtout, n'oubliez pas que dans cet article Pat Niemeyer défend son " bébé " également, car c'est le créateur de BeanShell, donc c'est normal qu'il ait cette vision et qu'il se situe de ce côté de la barrière. N'étant pas du même côté, c'est aussi normal que j'ai aussi une vision différente des choses.

Pour conclure, bien qu'ayant évidemment un parti pris pour le langage et la plateforme auxquels je crois, j'espère avoir su montrer au travers de ces quelques explications que Groovy se classe bien mieux dans la grille de critère que l'on évoque par rapport à la concurrence, et en particulier par rapport à BeanShell, et qu'il a bel et bien une véritable longueur d'avance.