Groovy 言語のバージョン 1.7 は、ライブラリの拡充と同様に言語それ自身の洗練もサポートしながら最近リリースされた。それに続いて、SpringSource は Groovy Eclipse IDE 2.0 をアナウンスした。それにより、以前は貧弱だった Eclipse の Groovy サポートに、デバッグ、洗練されたコンテンツアシスト、スタブ無しのコンパイルをもたらす。このリリースでは、それとともにコア Groovy 言語とライブラリへ大量のアップデートをもたらす。Java 統合フレンドリーな匿名内部クラスや入れ子クラスのシンタックスが導入される。Java において匿名内部クラスは、Groovy にあったように、他の言語ではクロージャやメソッド委譲が使われるかもしれないところで使われている。これらの新しい機能は、匿名内部クラスを使っている(クロージャを使って動作させることができない) Java のライブラリとの統合をより容易にする。これは、匿名クラスが必要とされるような時でもクラスを記述しなければならなかったことへの改善であり、コードをより自己文書化し続けることを支援する。その実装は、警告されているように、Java 実装と厳密には互換性がない。
Java の匿名内部クラスにおける一つの厄介な側面は、内側の匿名内部クラスからアクセスされる包含しているスコープの変数は final でなければならないことを要求することである。この制限は Groovy で解除される。包含しているスコープの変数の値を匿名内部クラスの中から変更できるようになる。
最もこれを明らかにするために、Java と Groovy の両方で例を使って学習しよう。この例は、リリースノートから(大体を)取り上げている。最初に Java バージョンを示す。
int counter = 0 ;
final Timer timer = new Timer();
timer.schedule(new TimerTask() {
@Override
public void run() {
counter+=1;
}
},0);
例において、私たちは Java の Timer オブジェクトを作り、その後、動作し整数を更新することを – 望む –、TimerTask を作ろうとしている。残念ながら、これはコンパイルできない(動きすらしない)。counter変数は final でない。コンパイラは、それにアクセスさせない。そこで、final にすると、
final int counter = 0 ;
final Timer timer = new Timer();
timer.schedule(new TimerTask() {
@Override
public void run() {
counter+=1; // コンパイルエラー!
}
},0);
今度は、アクセスできる(例えば、読む) しかし変数は final であるから、更新することができない。別のコンパイルエラーだ! そこで整数をオブジェクトにラッピングするような“気の利いた”何かを試す。java.lang.Integer を使うことを試すかもしれない、しかし Integer は不変である。そして変数もまた final でなければならないので、変数をリセットするための方法が無い。そこで、他の何かを試す。Integer を保存しそれを更新するために java.lang.ThreadLocal を使うこともできるだろう。java.util.concurrent.atomic.AtomicInteger を使おうとするかもしれない。
final AtomicInteger atomicIntegerCounter = new AtomicInteger(0);
final Timer timer = new Timer();
timer.schedule(new TimerTask() {
@Override
public void run() {
atomicIntegerCounter.incrementAndGet();
}
}, 0);
これは動作する、しかし何てコストがかかるのだろう？スレッドに関連した導入と(さらに)このコードのユーザにスレッドの強制認識により、とても単純な構築を複雑にしてしまった。
さて、Groovy と使うことでこれをどのようにできるか見てみよう。
int counter = 0
Timer timer = new Timer()
timer.schedule(new TimerTask() {
void run() {
counter += 1
}
}, 0)
コードは予測されたように動作する。コンパイルエラーや問題は無く、そして –ほとんど有効に– コードは自己文書化されている。その意図は明らかである。
新しい繰り返しもまた内部クラスをサポートしている。推奨されるアプローチは、もし内部クラスを使わなければならないならとにかく静的な内部クラスを使うことである。内部クラスを使って包含しているスコープから値にアクセスすることは Java と若干の違いがある。Java においては、内部クラスはコンストラクタへの合成(synthetic)パラメータとして含んでいるクラスへの暗黙的な参照を与えられる。これは実装の詳細であり、まるで現在のクラスの値であるかのように包含しているクラスの変数を単純に参照することができる。Groovy においては、参照を明示的に渡さなければいけない。このコンストラクタを実装する必要はなく、外側のクラスの中から内部クラスをインスタンス化するときに、ただそれを使うだけである。
Groovy スポーツは、Java よりも幅広い言語要素のセットでのアノテーションの使用をサポートする。Groovy のアノテーションは、Java 5 のアノテーションサポートと同じくらい長い間サポートしているその上、Groovy 1.7 リリースは、さらにもっと import 文、package 宣言、変数宣言へのアノテーションへのサポートを導入する。
import 文へのアノテーションの配置は、あなたが Grape(The Groovy Adaptable Packaging Engine or Groovy Advanced Packaging Engine)を考慮するまで明らかなユースケースを気づかないかも知れない。Grape は、拡張された、コードレベルにおける Maven や Ivy の実装のようなものである。他のビルドシステムは、ビルド成果物の依存性を外部化する(Maven の pom.xml あるいは Ant の build.xml ファイルのように)。Grape は、あなたに依存性をコードに注釈をさせる。これは次には依存性のダウンロードのきっかけとなりあなたのコードのビルドをより自己文書化する。以前の Groovy の繰り返しにおいては、アノテーションを使うことは不恰好なタスクであった。アノテーションは Java 5 アノテーションが許されているところでだけ許されていた(例えば、クラスやメソッドなど)、そしてより自然に感じる場所では許されていなかった(例えば、import 文など)。
アップデートは、より表現豊かなアサーション、コンパイル時の言語それ自身(Java においてはバイトコード操作ライブラリを使うことによってのみ得ることができた事を得るため)の抽象文法木(AST)でのメタプログラミング、バッチ更新やトランザクションをサポートするための Groovy Sql クラスの更新を含んでいる。
Grails 1.2 は Groovy 1.7 と同時にリリースされた。Grail は、既存の Spring MVC や Hibernate のような人気のあるオープンソースコンポーネント RAD を可能にするための Ruby on Rails のような開発環境の上に Groovy 言語を使用する Web フレームワークである。ここ数年で驚異的な成長が見られる。最近のリリースは、SpringSource、Tomcat、SpringSource Tool Suite チームの間の親密な共同を楽しむための最初のリリースである。
新しいバージョンは、より親密なサポートと統合 Spring (Spring MVC の @Controller アノテーションの使用を含む)、Groovy オブジェクトリレーショナルマッピング (GORM、Hibernate 上に構築された ORM ソリューション) ツールにおける名前付けされたクエリのサポート、取替え可能な開発のための Web コンテナ (外部での Jetty と Tomcat のサポートによる)、Grails のビュー層技術 (Groovy Server Pages) において著しく改善されたパフォーマンス／メモリ消費を特色としている。リリース発表では 2 、3 倍スループットが向上したと言及している。Grails もまた依存性の宣言のために Domain Specific Language の利用可能にするサポートをしている。
12月に InfoQ は、近々の Groovy 1.7 と Grails 1.2 リリースについて、Groovy と Grails のリーダである Guillaume Laforge 氏と Graeme Roucher 氏へのインタビューを行った。
Groovy 言語、そして周りのエコシステム、は、2008 年 11 月の SpringSource による G2One の買収から利益を得ている。言語の背後の推進力はいつも安定したままであったが、ツールのサポートが無かった。特に Eclipse は、言語のために良いサポートが無かった。Groovy Eclipse IDE 2.0 リリースは、これを変えた。ツールスーツはまだ最近リリースされた Groovy 1.7 コンパイラバージョンをサポートしていないが、デバッガと Eclipse 3.5 との互換性をサポートしている。今やプラグインはより応答の良いコンテントアシスト機能、スタブレスコンパイラ、インクリメンタルに結合するコンパイル(例えば、Groovy プロジェクトにおいて Java コードのコンパイルをサポートしている)機構、言語を横断したリファクタリング、その他をサポートしている。これらのすべての新しい機能は、ほとんど全面的に書き直された Eclipse Plugin Foundation 上に構築されている。リリースについてもっと調べるには、SpringSource リリース発表を訪れて欲しい。