先日のGR8Conf Europe 2014期間中，SpringSource/PivotalでGroovyを担当する上級ソフトウェアエンジニアのCédric Champeau氏は，GroovyのAndroidサポートを実現するプルリクエストのマージ作業をライブで実演してみせた。
Groovy開発者たちはこのオプションを何年も前から待ち望んでいた。しかし，AndroidのDalvik VMの使用する独自のバイトコードフォーマットや，Groovyのコードが持つダイナミックな特性による困難さのため，実装が遅れていたのだ。Androidの公式サポートはGroovy 2.4で提供される。
InfoQではAndroid用Groovyの現状と今後について詳しく知るべく，Champeau氏にインタビューした。
InfoQ: GroovyをAndroid上で動作させる上で，もっとも難しかった部分は何ですか？
CC: 本当にさまざまな問題があって，それらが絡み合うことでさらに難しくなっていました。まず問題になったのは，Groovyが実行時にクラスを生成する動的言語である点です。このようなクラスは”標準的”なJVMフォーマットで生成されるため，Androidが使用している独自のクラスフォーマット(Dalvik VM用)が問題になりました。Dalvik VMでは，標準JVMバイトコードを使用した個々のファイルを“dex”ツールでローダブルにする処理が必要です。実行時のクラス生成は想定されていませんし，非常に難しいのです。仮にこれをデバイス上でうまく処理したとしても，実行時にクラスをロードするという問題が残ります。例えばクラスをjarファイルに書き込んでおいて，実行時にこのjarをロードしなければなりません。最終的に私たちは，この件をGroovy on Androidのテーマにはしないことに決めました。それよりも実行時にクラスの生成を発生させずに，完全なアプリケーションをGroovyで記述することに注力したのです。これによっていくつか制限は発生しましたが，ほとんどのユーザの目には留まらないと思います。最終的にGroovy on Androidでは，@CompileStaticを指定して静的コンパイルを行うことで，パフォーマンスやメモリ消費量の面でネイティブなAndroidアプリと同等か，あるいは全く同じものになりました。
第２の問題はビルドシステムに関するものです。Androidの新しいビルドシステムではGradleと，通常の”java”あるいは”groovy”プラグインをバイパスする独自の”android”プラグインを使用することで，アプリケーションバリアントなどの機能を提供しています。この方法のため，Groovyサポートをプラグインに組み込む方法を見付けるのに多少の時間を要しました。ありがたいのは今回の発表後，GroovyとAndroid用のGradleプラグインがリリースされたことです。これで状況はかなりよくなります[1]。最後に重要なことをひとつ。私はGroovyのサポートを開発するためにAndroidを学んだのですが， おかげでGroovyを使うことのメリットがはっきりと理解できました。ただし実際には，Groovyの対応作業よりもこちらの方が大変でした！
InfoQ: 今回の成果をクロスプラットフォームソリューションとして，iOSか，あるいは少なくともWindows Phoneに展開する予定はありますか？
CC: iOSでGroovyを動かしてみたいとは思うのですが，テスト用のハードウェアを持っていません;) 先日発表されたSwift言語はGroovyに非常に近く，Objective-Cよりもはるかに魅力的ですから，Groovyの代用として利用できるでしょう。ただし考慮すべき点がひとつあります。Swiftがクローズソフトウェアであり，ベンダロックイン路線にあることです。Groovyは完全にオープンソースですから，例えばアプリケーションのUI部分を書き直すだけでiOSとAndroidで同じコードを使用することができます。汎用性のあるモバイル開発にはこちらの方が適切でしょう。Windows Phoneについては，可能かどうか分かりません。プラットフォームのことを全然知らないのです :)
InfoQ: 現時点で不足しているのは何ですか？まだ動作しない部分はあるのでしょうか？
CC: つい最近まで，Androidでは@CompileStaticなクラス以外は実行できませんでした。ですが現在は，動的なコードも動作するようになっています。ビルダを含めて，ほとんどすべてが動作しています。ただし動的コードの使用にはリフレクションが伴うため，アプリケーションでCPU負荷の高くない部分に限定する必要があります。要するに現時点での制限は，実行時のクラス生成が(容易には)できないため，クラス型強制(coercion)へのマップや実行時トレイト(trait)など一部の構造は動作しなくなる，ということです。ただし，ありがたいことに，これには回避策があります。さらに将来的には，メソッドディスクリプタの数も問題になるでしょう。Androidにはデフォルトで最大65536メソッドという制限があります。これはかなり低い数値で，Groovyならば最適なしで(ProGuard)8k程度のプログラムでも，この程度は消費してしまいます。回避策がある(multidexオプションを使用するなど)にせよ，これは通常のJavaアプリケーションに比べて，早く限界に達するということを意味しています。
InfoQ: Groovy/Androidの今後の計画を教えてください。
CC: Groovy 2.4の最初のベータ版から，Androidが公式にサポートされる予定です。現時点でもアプリケーション開発に使用することは可能です。最初のサンプルアプリで分かるように([2])，実際にそれで開発されたプロダクトもあります。ただし現在は，Groovyのスナップショット版がベースになっています。ですが，私が本当に期待しているのは，Groovyで記述されたライブラリやフレームワークを利用することによって，Androidアプリケーションの開発が容易になることです。Androidは非常に冗長ですが，Groovyを使えばずっと簡単に記述できるようになります。そのためには，このようなJava用ライブラリをすでに数多く開発した，大規模な開発者コミュニティに頼る部分が大きいのですが，それも時間の問題でしょう。一度Android上でGroovyを試してみれば，Javaに戻りたいと決して思わなくなるのは確実ですよ ;)
[1] https://github.com/melix/groovy-android-gradle-plugin
[2] https://play.google.com/store/apps/details?id=me.champeau.gr8confagenda.app