Pendant la récente GR8Conf Europe 2014, Cédric Champeau, Senior Software Engineer travaillant sur Groovy pour SpringSource/Pivotal, a effectué un merge en direct de la pull request apportant le support de Groovy sur Android.
Les développeurs Groovy attendaient cette option depuis plusieurs années, son implémentation ayant souvent été retardée par les difficultés amenées par le support du format modifié du bytecode utilisé par la VM d'Android, Dalvik, et la nature dynamique du code Groovy. Le support officiel d'Android sera disponible avec Groovy 2.4.
InfoQ a interviewé Cédric Champeau pour avoir plus de détails sur le sujet et sur le futur de Groovy sur Android.
InfoQ : Quelle était l'étape la plus compliquée pour faire fonctionner Groovy sur Android ?
Cédric : Nous avons en fait rencontré plusieurs problèmes, et c'est leur combinaison qui a vraiment compliqué le travail. Le premier problème est que Groovy est un langage dynamique qui génère des classes au runtime. Ces classes sont générées pour le format "standard" de la JVM, alors qu'Android possède son propre format, pour la VM Dalvik. Celle-ci n'est pas pensée pour créer des classes dynamiquement au runtime, et chaque fichier utilisant le bytecode JVM standard doit être traité avec l'outil "dex" pour être chargé. Mais même en passant cette étape, charger une classe au runtime reste complexe. Cela nécessite, par exemple, l'intégration de classes dans un fichier jar, puis le chargement de celui-ci. Au final, nous avons décidé que cela n'était pas la priorité pour le portage de Groovy sur Android, et que nous devions plutôt nous concentrer sur l'écriture d'une application complète en Groovy, sans se soucier du côté dynamique du langage et donc de la création de classes au runtime. Cela implique des limitations, mais elles devraient être invisibles pour la plupart des utilisateurs. Si vous utilisez @CompileStatic pour du code Groovy statiquement compilé sur Android, les performances et la consommation de mémoire sont comparables, voire égales, à ce que l'on obtient avec des applications Android natives.
Le second problème majeur rencontré est lié au build system. Le nouveau système de compilation utilise Gradle et un plugin custom, "android", qui surcharge les plugins standards "java" et "groovy" pour offrir des fonctionnalités comme les variantes d'application. Nous avons dû prendre du temps pour comprendre comment ajouter à nouveau le support de Groovy. Depuis, un plugin Gradle pour Groovy et Android est sorti et a simplifié bien des choses.
Et enfin, je me suis formé à Android en parallèle de l'écriture du support de Groovy. Ce qui était une bonne chose, puisque cela m'a permis de voir immédiatement ce qui pouvait être amélioré, mais cela m'a demandé plus de temps que l'adaptation de Groovy en soi !
InfoQ : Une chance de voir ce support étendu à iOS ou Windows Phone pour avoir une solution cross-platform ?
Cédric : Définitivement, j'adorerais voir Groovy fonctionner sur iOS, mais je n'ai pas le matériel pour pouvoir faire des tests ;) Même si Swift, qui a été annoncé récemment, est très proche de Groovy et bien plus attirant que Objective-C, il y a une chose à prendre en compte : Swift est propriétaire, et fermé par son propriétaire. Groovy est totalement open-source, et si vous pouvez utiliser le même code pour iOs et Android, les développeurs n'auront plus qu'à écrire les parties spécifiques aux interfaces par exemple, ce qui simplifierait le travail à effectuer. En ce qui concerne Windows Phone, je ne sais pas si cela est faisable, je manque de connaissances sur le sujet ! :)
InfoQ : Qu'est ce qu'il manque, actuellement ? Qu'est ce qui ne fonctionne pas encore ?
Cédric : Jusqu'à encore récemment, seules les classes avec @CompileStatic pouvaient s'éxécuter sur Android. Il est maintenant possible d'éxécuter du code dynamique, donc presque tout fonctionne, y compris les builders. Ce qu'il faut savoir, c'est que le code dynamique est limité aux applications nécessitant peu le CPU, car cela implique une forte utilisation de reflection. La limite actuelle est qu'il n'est pas (facilement) possible de générer des classes au runtime, donc des structures particulières comme le mécanisme de coercition de type, ou les runtime traits ne fonctionneront pas. Il existe cependant des manières de contourner ces difficultés. On peut éventuellement citer un autre problème, celui du nombre de descripteurs de méthodes. Android, par défaut, a une limite de 65 536 méthodes au total, ce qui est assez bas, et Groovy utilise à lui seul environ 8k méthodes, sans optimisation (avec Proguard, par exemple). Cela veut dire que vous pouvez atteindre plus rapidement la limite qu'avec une application Java standard. Il est toutefois possible de passer outre cette limite, en utilisant par exemple l'option multidex.
InfoQ : Des plans particuliers pour le futur de Groovy/Android ?
Cédric : Le support officiel d'Android vient avec une première beta de Groovy 2.4. Vous pouvez déjà l'utiliser avec vos applications, comme le montre le premier exemple d'application, basé sur une version snapshot de Groovy. Ce que j'aimerais vraiment voir maintenant, ce sont de nouvelles librairies ou des frameworks utilisant Groovy pour faciliter le développement d'applications Android. Android est très verbeux, et Groovy peut simplifier bien des choses. Nous pouvons compter sur une communauté large qui propose déjà de nombreuses librairies pour Java, ce n'est donc qu'une question de temps. Je suis convaincu qu'une fois que les utilisateurs auront testé Groovy sur Android, ils ne voudront plus retourner vers Java ;)