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