Eclipse Junoのリリーストレインに新しいプロジェクトEclipse Code Recommendersが加わった。
その背景にあるアイデアは、コードプロポーザル・キーシーケンスがトリガーされたらプロポーザルリストを調整、フィルタリングするというものだ。Eclipseはデフォルトで、パブリックメソッド（もしくはフィールド）をアルファベット順にリストする。しかし、見知らぬAPIをコーディングしているときや、複数オーバーロードされたメソッドがあるときには（さて、6つの Date コンストラクタのどれを使えばよいでしょう？1）、どれが呼ばれるべきか必ずしも明確ではない。
Code Recommendersは、過去のコード事例データベースをメソッドの呼び出し頻度とともに保持しており、それを使ってどのメソッドやコンストラクタを提案すればよいか順位付ける。もし、Date コンストラクタの多くが引数なし（もしくは単一の long 引数）で使われるなら、これら2つの選択肢が最初に提示され、ほかはフィルターアウトされる。さらに文脈依存情報をプロポーザルに活用することも可能だ。たとえば、timezoneOffset = date.get でメソッド呼び出しを補完するときには、最初の選択肢として getTimezoneOffset() メソッドを提示できる。
このプロジェクトは文脈依存のコードスニペットのリストも提供する。これらは手動で構築したり、既存のコード事例から推測することもできる。ほかのJavaテンプレート（main や syserr）と同様、コードをすばやく実装するのに活用できる。
InfoQでは、このプロジェクトの作者であるMarcel Bruch氏にコンタクトし、まずプロジェクト作成のきっかけから話を聞いた。
Marcel Bruch氏: Code Recommendersはダームスタット工科大学の研究プロジェクトとして、約3年前にスタートしましたが、そのルーツは2006年までさかのぼります。当時私は初めてのEclipseプラグインを開発しようと、ほかのプラグインのソースコードを読んでEclipse APIの使い方を学んでいるところでした。その頃、研究コミュニティや博士志願者のあいだではソースコードマイニングがかなり人気を集めており、ソースコードに機械学習を適用することで、開発者（私）のAPI学習を支援するというのは当然の成行きでした。
2009年に、私はRecommenders Intelligent Code Completionの最初のバージョンをEclipse PluginCentralに公開しました。これは開発者が何とか使えるレベルの、かなり制限のあるものでしたが、私は地元のEclipse DemoCampでプレゼンしました。プレゼンはまあ平均レベルでしたが、そのイベントから次へとつながって、2011年1月にEclipseプロジェクトになりました。
最終的に、EclipseにおけるCode Recommendersプロジェクトを私に始めさせたのは、ソフトウェアの開発方法を変えるパワーのあるものを作るという考え、そして、適切なタイミングでEclipseの人たちからフィードバックがもらえることです。
InfoQ: このプラグインはどんなレコメンドをしてくれるんですか？
Marcel Bruch氏: Code Recommendersの1.0では、オブジェクトで呼び出したいであろうメソッド、フレームワークのベースクラスを拡張するときにオーバーライドすべきメソッドを開発者に提案したり、コードの現在の場所から指定される型のインスタンスを取得する方法を開発者に教えたりできます。
基本的には、これを使うことで新しいAPIの使い方の学習を支援し、不要な間違いを避けられます。すでにあなたがそのAPIのエキスパートで、どう書けばよいか知っていたとしても、あなたが考える前にすばやくやってくれます。
これらの情報はすべて、Eclipse JDTのコードコンプリート機能、そしてExtended Javadocビューに密接に統合されています。すべてのレコメンドはきれいに一箇所にまとめられます。
InfoQ: もとになるデータはどこから得るのですか？
Marcel Bruch氏: Code Recommendersは、過去にうまくAPIを使っている既存のアプリケーションのソースコードを分析することでレコメンデーションを学習します。Recommenders 1.0のデータは、Eclipse Junoリリーストレインリポジトリをもとにしています。このコードリポジトリには全部で72プロジェクト、50百万行以上のコードがあります。
現時点でCode Recommendersは、多数のEclipse APIと一部のJava標準ライブラリ、具体的には
java.*にある主要なパッケージとjavax.*にある一部のパッケージをサポートしています。レコメンデーションモデルはEclipse Junoのリリーストレインコードリポジトリからのみ生成されているため、java.awtやjavax.swingのようなパッケージは生成時に利用できるデータがなく、まだサポートされていません。今後のリリースに向けて、Recommendersのスコープを広げて、よく使われるApache Commonsといったライブラリをサポートできるよう、もっと大きなデータソースを探しているところです。もうひとつサポートしたいと思っているのは、Androidプラットフォームです。これはJavaに非常に近く、セミプロ開発者にも非常に人気があるので、本プロジェクトにはうってつけです。
しかしながら、非常に巨大なJavaとAndroidのエコシステムをサポートするには、膨大なデータを必要とします。大量のAndroidおよびJavaアプリケーションのデータにアクセスできるよう、いくつかの大規模ソフトウェアリポジトリのメンテナーたちと議論しているところです。まだ何も決まっていませんが、納得してもらって近い将来サポートできることを期待しています。
InfoQ: カスタムAPIやまだ今はないAPIで動きますか？
Marcel Bruch氏: Code RecommendersはカスタムAPIを含め、任意のJava APIの利用パターンを学習できます。Eclipse Code Recommendersチームは現在Recommenders Developer Kitに取り組んでいます。これを使うと開発者はEclipseワークスペースにある自分のAPIをRecommendersに組込むことができます。
ところが、すぐれたRecommendersを構築するのは、そう一筋縄ではいかないことがわかってきました。（ソフトウェア工学的）ビッグデータと大規模機械学習と静的コード解析をうまく組合せて扱おうとすると、とたんに大変になります。そこで私たちは近い将来、商用サービスを提供することに決めました。自社開発したAPI用にCode Recommendersを動かして、そのAPIを利用する開発者や顧客をサポートしたいという会社を支援できるようにします。
InfoQ: プロポーザルのリストはクライアントの利用頻度分析からやってくるのですか？
Marcel Bruch氏: はい、そうです。ただし、クライアントで使われているメソッドの利用頻度を調べただけでは、あまり役に立ちません。たとえば、テキストウィジェットで
setText()をいつも呼び出すよう提案するコード補完エンジンを考えてみてください。確かに、Dialog.createContents()のようなメソッドを扱っているときには意味があるかもしれませんが、Dialog.close()では意味がありませんよね？text.getText()への呼び出しは、おそらく開発者がテキストウィジェットからユーザ入力を読み書きしたいときにだけ意味があります。スマートな補完エンジンはこれについても考慮しなければなりません。そしてRecommendersはそうしています。インテリジェントな呼び出し補完について、たとえばオブジェクトがどこで使われているか、オブジェクトがどう定義されているか、どのメソッドが実行されてきたかをトラックし、最も可能性の高いレコメンドをします。
現在はさらに先進的なレコメンドができるよう拡張されており、ほかのオブジェクトが現在の文脈でビジブルかどうか、それらがこれまでどう使われてきたかといった情報まで考慮しています。エンジン内部ではベイジアンネットワークが動いており、こうした計算はほんの数ミリ秒で行われます。
InfoQ: 現在サポートしているのはJavaだけですか？ ほかの言語をサポートする予定はありますか？
Marcel Bruch氏: はい、現時点ではJavaだけです。しかし現在、Code RecommendersをCファミリー(C/C++/C#)にも適用できないか、さらには非常にエキサイティングですが、動的言語にまで適用できないか、調査を進めているところです。型システムの安全性なしに予測するのは非常に難しいことですが、JavaScriptのような言語を同じように（正確には似ていないが）サポートするためのエキサイティングなアイデアがあります。
しかし正直なところ、ほかの言語をサポートするにはまだ長い道のりが必要です。まずはJava用のCode Recommendersの改善にすべての時間を費やします。ほかの言語をすぐにサポートするには、外部からの投資やチームリソースが必要になるでしょう。
InfoQ: Code Recommendersの研究開発パイプラインには、どんなものがあるのですか？
Marcel Bruch氏: まず最初に、新たなメソッド引数推測機能を加えることで、インテリジェントなコード補完の開発を進めます。SWTに馴染みのある開発者であれば、たとえばリスナーの登録時やテキストウィジェットの作成時に、SWTのスタイルがどんな問題を引き起こすのか知っているでしょう。しかし、メソッド呼び出しにどの定数やオブジェクトを渡すべきかは、上海大学のCheng Zhang氏が最近示したように、私たちがどのメソッドを呼び出すべきかを学習するのとほぼ同じ方法で学習できます。Cheng氏は現在、彼のツールのEclipse Code Recommendersへの統合に取り組んでいます。
エキサイティングに進歩しているもうひとつの領域は、コード事例にないコードスニペットです。開発者であればみな、配列をイテレートしたり、型キャストするようなスニペットを提供するIDEのテンプレート補完をご存知でしょう。しかし、私たちがもっと必要としているのは、オブジェクトをどう使うのか、オブジェクトをほかのオブジェクトと組み合せてどう使うのかを示したコードスニペットです。Eclipse SWT Templatesは、どのようにSWTウィジェットをインスタンス化しコンフィグレーションするかを示すサンプルを提供してくれます。しかし、こうしたテンプレートを作るのはかなり大変で、ほんのわずかなコードテンプレートしかありません。Code Recommendersで私たちは、コード事例から頻出するコードパターンを発見し、これらのパターンをIDEに統合するツールに取り組んでいます。Google Summer of Codeプログラムでクイーンズ大学のDough Wightman氏とChen Cheng氏によって開発されたSnipmatch補完エンジンは、発見したスニペットを新しいテンプレート補完に統合してくれます。
3つめの領域はスタックトレース検索エンジンの開発です。Mavenユーザであれば、すでに馴染みのあるアイデアでしょう。Mavenビルドが例外で失敗すると、出力行の最後で開発者に例外の原因を説明するであろうWikiページを見るよう提案してくれます。残念なことに、これらのページはたいてい空です。でもアイデアはすばらしいと思います。スタックトレースにはあなたが期待する以上にいろいろな情報が含まれています。ランタイムで利用可能な暗黙の情報をすべて活用することで、あなたが直面している問題について議論し解決するWeb上のリソースを見つけて、どうすればよいか簡単にわかりるようになります。現在、ダームスタット工科大学のJohannes Lerch氏がこのプロジェクトに取り組んでいます。ほかの人が過去に解決した問題を解決することで、将来私たちがどれだけ時間を節約できるのか、気になるところです。
最後に、私たちはスニペットコード検索エンジンにも取り組んでいます。これは開発者が取り組んでいるタスクに関連した、関心のあるコードスニペットを見つけるものです。
これらは、2013年に登場予定のEclipse 4.3 (Kepler) に導入しようと考えている機能の候補です。その一方で、私たちはひそかに、もっと大きなもの、IDE 2.0のビジョンにも取り組んでいます。
Code Recommendersプロジェクトについて、詳しくはプロジェクトのホームページを見てみよう。そして、Junoパッケージの一部としてダウンロードしよう。Eclipse Marketplaceからインストールすることも可能だ。
Code Recommendersプロジェクトについて、あなたはどう思いますか？
1 - いずれでもなく、代わりにJSR 310を使おう。Dateクラスはこれまでで最悪のAPIのひとつだ。