このニュース記事は動的言語向けIDEに関するシリーズもの1つである。シリーズ初の記事ではRuby IDEを扱い(参考記事)、その他の記事についてはDynamicLanguageIDEsタグ(参考記事リンク)で検索できる。
SpringSourceがGroovyとGrailsの開発会社を買収したからには、今後Groovyの人気が高まり、その結果、GroovyはJava開発者にとっていっそう魅力的な存在になるだろう。
Groovy EclipseプロジェクトのリーダーであるJames Ervin氏(リンク)と話し、現在何に取り組んでいるかをたずねた。
現在、私と数名がプラグインに取り組んでいます。Guillaume La Forgeが私をプロジェクトリーダーにしたので、プラグインの公式リリースを更新し、しばらく棚上げ状態になっていた問題に対処する修正を入れられるようになりました。現在は安定性や簡略化、定期的なリリースに焦点を合わせており、私たちのJIRAサイト上で重要視されている複数の問題に取り組んでいます。たとえば、Groovyコンパイラで共同コンパイル機能（必要に応じてjavacに権限を委ねることにより、JavaとGroovyの両ソースファイルをコンパイルする機能）を使用中止にしようと努めています。この機能がなくなれば、余計なbin-groovyターゲットディレクトリや、GroovyとJavaで書かれたコード間の相互依存性に関連した頭痛の種から、いくらか解放されるはずです。Michael Klenkのグループが、リファクタリングをサポートするGroovy Eclipseのバージョンを作るという素晴らしい仕事をしてくれました。手持ちの仕事を片付けたら、Michaelたちの作業を統合することが私の1番のプライオリティになります。
Groovy-EclipseにはすでにGroovyの実装が入っているので、外部の実装は必要ない。
Groovy Eclipseには埋め込みのGroovyランタイムライブラリが付属していますが、このライブラリはそれ自体がEclipseプラグイン（OSGiの言葉でいうなら「バンドル」）として分離します。これから説明しますが、ライブラリを入れた理由はいくつかあります。まず、埋め込みランタイムにより、腕試しにGroovyでプラグインを部分的に書き始めるチャンスが得られます。これまで言われてきたように、「自分のドッグフードを食べろ」（自社製品を使え）ということほどよいことはありません。私としては元々の表現の方が好みで、「自分のドッグフードを食べてみませんか」の方が適切と思いますが、ここは家族的なフレンドリーな環境ですからよしとしましょう。第二に、埋め込みランタイムライブラリを入れることにより、「何をするにもまずGroovyランタイムをインストール」というステップをユーザーに省略してもらえるようになるのは言うまでもありません。最後になりますが、そしてこれは実は弱点なのですが、埋め込みgroovyランタイムはプロジェクトのコードのイントロスペクトとコンパイルの両方に利用します。最後の点は私にしてみれば不満の種であり、Groovy Eclipseのロードマップ(リンク)に入れてあります。
ロードマップ(リンク)を一読すると、興味深い見解が見えてくる。
- [...] Grailsの開発に少なくとも基本レベルのサポートを提供。Grailsのサポート提供にはこれまで多少の作業があったことを知っていますが、とても基本的な種類のサポートだけであり、GrailsにはIDEのサポートがとても必要なことがわかっています。
- [...] Groovy言語を使ったEclipseプラグインの開発を可能に。実際のところ、これは個人的願望の感が強く、Grailsのサポートやこれまでにリストアップしたその他の点の方が、はるかに多数の人々に影響を与えると思います。それでも、Groovyを使ってGroovy Eclipseの作業をもっとたくさん行うことができれば、すてきではないでしょうか。そうでしょう？ 私はそう思います。この取り組みの一環として、GroovyのEMFに対するサポートのてこ入れと改善を試みることができると思います。
- [...] groovyコンパイラとEclipse JDTサポートのより望ましい統合。Scala Eclipseプラグインで例を見たところ、ScalaのプロジェクトではEclipse Javaの特質をプロジェクトに追加していましたが、Java Builderは追加されていませんでした。これによりScalaプラグインがscalaツールを提供し、クラスファイルを構築できます。特に今ではgroovyコンパイラがjavaもコンパイルするようになっているので、Scalaと同様のことをGroovy Eclipseで行うべきであると考えています。
Groovy IDEのその他の実装でも間違いなく同様の問題と格闘しているが、なんらかの協力体制はとられているのだろうか。
GROCIDEプロジェクトについての議論に参加していますが、この件はGroovy Eclipseのプライオリティリストでも上位を占めています。私たちが抱えている一番の問題は、プロジェクトに割くリソース（つまり、マンパワー、特にフルタイムのマンパワー）がないことですが、個々のIDEサポートツールでは共有できるものがたくさんあります。とりわけ、Groovy向けのIntelliJとNetBeansの両ツーリングサポートでは、すばらしい仕事をしているすばらしい人たちがいるので、この件については関与する必要があります。
次のように締めくくりたいと思います。CodehausにあるGroovy Eclipseプロジェクトのメインページに次のようにつけ加えました。
「Groovy Eclipseプラグインの目的は、Eclipse SDKで作業しているJava開発者に、存続可能で生産性の高い開発環境としてGroovyプラットフォームとGroovyエコシステムを奨励することです」
以上の文言が、考えられる限り最も的確に私の目標を要約しています。今日、少なくとも北米では、Java開発のほとんどがEclipse SDK上で行われています。私はGroovyの成功を願っているのですが、成功させるには、Eclipse向けのGroovyプラグインが単に優れているだけではもの足りず、素晴らしくなければならないのです！
Ervin氏が触れていたリファクタリングについて、Michael Klenk氏に話を聞いた。
手始めに、Extract Methodリファクタリングの実装から始めました。最初のごく小さな段階を済ませた後は、Inline Method、メソッドや変数、フィールド、クラスのRenameといった他のリファクタリングの実装を開始しました。さらに、ソースコードフォーマッターと階層ビューを提供し、開発者の日々の作業を支援しました。
Klenk氏の言うリファクタリングは、たとえばリネームを単に手動で行うより、どの程度優れているのだろうか。
一見すると、検索と置き換えが望ましいやり方であるように思われますが、プログラム内の名称には常にコンテキストがあり、これを把握しておくことが非常に重要です。まったく同じ名称を使って、それぞれロケール変数を宣言するメソッド2つを記述すると想定してください。単純な検索と置き換えでは、どの場合をリネームすべきかを手作業で決めなければなりません。
リファクタリングがどれほどインテリジェントかを示す例をもう1つ。抽象メソッドを宣言するインターフェースを作成します。このメソッドを複数のクラスに実装します。このメソッドをリネームしたい場合、継承階層内で全クラスをチェックして、変更しなければならないコード内の全位置を見つける必要があります。
Groovyコードの抽象構文ツリーを分析することにより、必要とするすべての関連情報を収集できます。
例に挙げられたことだけで見事と思うが、こうした機能が搭載されるのはどのバージョンになるのだろうか。
Groovy Eclipseプロジェクトの開発トランクに全リファクタリングを統合しました。このプラグインの安定バージョンは間もなくリリースされる予定なので、全開発者がリファクタリングを使えるようになるでしょう。多数のユーザーが最初のリファクタリングを使用し、今後の改良のためにフィードバックを返してくれるよう願っています。現在実装を検討中のすてきな機能に、JavaとGroovy間の相互言語リファクタリングがあります。
Groovy-Eclipseの公式Webサイト(リンク)とリファクタリング専用のGroovy-Eclipse Refactoringサイト(リンク)。
このニュース記事は動的言語IDEに関する継続中のシリーズの一部である。他の記事については、InfoQでDynamicLanguageIDEsタグ(参考記事リンク)を検索すれば見つかる。