Gradle adopte Kotlin comme langage de script

Voilà une nouvelle qui est tombée il y a quelques jours et qui a visiblement provoqué quelques vagues dans la communauté Groovy. Gradle Inc., l’entreprise qui développe le moteur de compilation Gradle, a décidé d’adopter Kotlin comme langage pour les scripts de compilation.

Bon, puisque je sais que tous les lecteurs de ce blog ne sont pas d’aguerris développeurs et que je me soucie de proposer une lecture agréable à tous, la première partie de ce billet va vous expliquer ce qu’est un moteur de compilation. Si l’honorable lecteur sait déjà ce qu’est un moteur de compilation, ou qu’il n’en a rien à carrer de ce que j’ai à expliquer sur les moteurs de compilation, ou encore sait déjà ce qu’est un moteur de compilation et qu’il n’en a rien à carrer de ce que j’ai à expliquer sur les moteurs de compilation, il peut passer directement au paragraphe suivant.

Et s’il n’en a rien à carrer de ce billet, il peut aussi se barrer, je ne me vexe pas. Promis.

Bon, nom d’une pipe à crack qu’est-ce que c’est quoi un moteur de compilation ventrebleu !?

Un moteur de compilation, c’est un outil utilisé en développement logiciel pour automatiser un certain nombre de tâches, au premier rang desquelles, la compilation du code source. Les moteurs de compilation sont nés à partir du moment où les projets ont commencé à devenir beaucoup plus complexes et où compiler un projet ne s’est plus limité à un coup de gcc. Et entre les années 70 et aujourd’hui, on peut compter plusieurs générations de moteurs de compilation.

Tout d’abord il y’a le bon vieux script shell. C’est un peu l’ancêtre australopithèque des moteurs de compilation : c’en est pas vraiment un, mais on commence à distinguer quelques caractéristiques de ce que ça va devenir ; en particulier, l’automatisation des tâches.

Ensuite vient le pépé grabataire, make. make, c’est le premier outil véritablement conçu pour automatiser la compilation. Il jette quelques bases qui seront reprises par tous les autres moteurs de compilation par la suite ; notamment la notion de cycle de vie du projet qui se découpe en plusieurs phases ou buts (nettoyage, compilation, installation, etc.). La phase, pour ceux qui ont déjà compilé un projet C/C++, c’est ce que vous tapez juste après la commande make : make clean, make install, etc. C’est un très bon outil mais plus le temps passe et plus les projets sont complexes. Les développeurs se rendent comptent qu’ils réécrivent souvent les même scripts (les makefiles) et décident d’automatiser l’automatisation (automatiception).

Vient donc les papis moteurs. C’est la génération Ant, CMake, Automake, etc. Et là, il faut distinguer un peu deux familles de moteurs. Il y a les enfants modèles et les prodigues, ceux qui veulent tuer le père. Les enfants modèles, ce sont ceux qui permettent d’écrire des scripts plus concis mais qui ne servent, en dernier lieu, qu’à générer des makefiles et dépendent toujours de make pour compiler. Ce sont ceux qui son, généralement, toujours utilisés aujourd’hui sur les projets C/C++ — l’inertie technique, je suppose ? — et qui font que quand tu compiles des sources C/C++ trouvées sur le web, y’a intérêt à ce que ça se passe bien parce que sinon, tu sens que t’es parti pour quelques heures de crise de nerfs à tenter de comprendre pourquoi ça merdouille. Je déteste make.

Les enfants prodigues, ce sont ceux qui se débarrassent de make pour suivre leur propre voie, comme Ant, très rependu dans le monde Java au début des années 2000. Bon, j’ai jamais utilisé Ant donc j’en dirais pas grand-chose.

Vient ensuite l’entrée dans le monde moderne avec les moteurs à papa. Ça, c’est la génération Maven. On peut arguer tant qu’on veut sur le succès de Java en entreprise, à la fin, s’il y a une chose de certaine, c’est que Java ne serait pas ce qu’il est aujourd’hui sans Maven. Maven, c’est le moteur de compilation qui te compile le projet, te fait le café et une petite gâterie au passage si t’as ajouté le plugin qui va bien dans les dépendances. Sur le plan technique, Maven a tranché radicalement d’avec ses prédécesseurs en apportant deux innovations majeures :

  1. l’approche convention plutôt que configuration,
  2. une gestion automatisée des dépendances.

L’approche convention plutôt que configuration est ce qui a permit de rendre les scripts Maven extrêmement simples à écrire. Dans un projet Maven, les sources se trouvent toujours dans src/main/<langage>, les tests unitaires dans src/test/<langage>, les ressources (les images, par exemple) dans src/main/resources, etc. Les projets Maven ont une structure qui reste la même d’un projet à l’autre et ça, c’est kool.

La gestion automatisée des dépendances, ça, c’est l’autre truc qui fait le café. Parce que gérer l’utilisation d’une bibliothèque externe dans un projet en C++, faut avouer que c’est une plaie. Si la bibliothèque n’est pas dans les dépôts de la distrib que le développeur utilise, il est bon pour se la télécharger et se la compiler à la main. Avec Maven, les dépendances se déploient dans des dépôts centraux (comme mavencentral, le dépôt officiel de Maven) ou dans vos propres dépôts locaux (comme ceux qu’on a au boulot). Il suffit de déclarer l’identifiant et la version de la dépendance et Maven la télécharge automatiquement à la compilation.

La dernière génération de moteurs, c’est celle du fils qui se la raconte, comme Gradle. Maven est un outil fabuleux, c’est sans appel. Mais Maven possède un tout petit défaut : toute tâche de compilation dépend de l’existence d’un plugin. Un script Maven se résume grossièrement en la configuration d’une chaîne de plugin là où make obligeait le développeur à écrire toutes les instruction à la main. C’est très bien et, dans 98% des cas, il existe un plugin pour ça. Mais dans 2% des cas, il faudra écrire son plugin soi-même là où on aurait aimé pouvoir le faire à l’ancienne comme on le faisait dans Ant ou make. C’est précisément ce problème qu’adresse Gradle.

En Gradle, les scripts sont écrits en Groovy ce qui permet d’adopter soit une approche déclarative à la Maven, soit une approche impérative à la Ant. Ah, et puis les scripts en Groovy, c’est quand-même grave plus simple à lire et à écrire que les script en XML dégueulasse d’Ant ou Maven…

Gradle : entre Groovy et Kotlin…

Bon, tout ça, c’est bien beau mais qu’est-ce que Kotlin vient foutre là-dedans !? Hé bien c’est Cédric Champeau, employé de Gradle Inc. et l’un des principaux contributeurs de Groovy qui nous l’explique dans un billet en anglais : Groovy est un langage nativement dynamique. En fait, il n’est possible de compiler statiquement Groovy que depuis peu. Et la nature dynamique pose visiblement quelques menus problèmes en termes d’auto-complétion aux IDE. Cela rend l’écriture de scripts Gradle un peu ardue étant donné que l’IDE propose parfois des résultats complètement stupides dans l’auto-complétion voire ne propose pas de résultats du tout. Il n’est donc pas possible de savoir si un script Gradle écrit en Groovy est vraiment valide tant qu’on ne l’a pas exécuté. J’en ai fait les frais une fois ou deux sur Phœbius.

Le gros problème, c’est que la grande majorité des développeurs repose énormément sur l’auto-complétion pour déterminer si ce qu’ils écrivent est débile ou pas, ou pour avoir un aperçu de la documentation d’une fonction ou d’une variable. En Gradle, on ne peut pas. Ou du moins, on ne le peut pas nativement[1].

Gradle Inc. a donc prit une décision radicale pour régler ce souci : ajouter le support de Kotlin pour écrire les scripts Gradle. Kotlin est un langage tout neuf apparu en 2011 et très largement inspiré de Groovy et de Scala[2]. Et Kotlin est un langage… statique. Personellement, je considère ça comme une très bonne nouvelle. Kotlin est un très bon langage développé par JetBrains, la société qui édite le meilleur IDE du monde : IntelliJ. JetBrains a donc les ressources nécessaires pour développer et maintenir un très bon langage et la preuve en est que Kotlin est déjà mature, malgré sa grande jeunesse.

Mais dans la communauté Groovy, l’annonce du support de Kotlin pour écrire les scripts Gradle a fait grincer une ou deux dents. Certains ont visiblement argué que JetBrains essayait de tuer Groovy au profit de son propre langage, ce qui est, faut l’avouer un peu con puisqu’IntelliJ est en partie composé de Groovy. De plus, le support de Groovy dans Gradle n’est absolument pas abandonné, loin de là. Ce qu’annonce Gradle, ce n’est qu’un simple ajout de fonctionnalité. Mais comme on dit sur internet : haters gonna hate.

Groovy est un très bon langage. Mais il accuse malheureusement le coup de son histoire. L’arrivée prochaine de Java 9 et du projet de modularisation de Java a l’air de poser quelques problèmes techniques à la communauté. Il s’est récemment posée la question de développer une version 3 de Groovy pour assainir le langage et ajouter des fonctionnalités qui sont restées longtemps en suspend. À côté, la compilation statique de Groovy pose souvent problème parce que le compilateur est incapable de deviner correctement le type d’un objet et oblige le développeur à transtyper manuellement. Et l’annonce de l’arrêt du financement de Groovy et Grails par Pivotal il y a un peu plus d’un an n’a pas eu l’air d’arranger les choses.

Notes de bas de page :
  1. Dans son blog, Cédric Champeau explique qu’il est possible d’explorer une voie pour écrire des descripteurs de DSL. Ce n’est visiblement pas la voie choisie par Gradle Inc.
  2. Scala est un autre langage pour la JVM apparu 2 ans avant Groovy. C’est l’une des alternatives à Java les plus populaires.

Aucun avis pertinent dans Gradle adopte Kotlin comme langage de script

Laisser un commentaire

indique des champs obligatoire.