Spring Roo は，Javaによる Springアプリケーション開発のためのround-trip形式のコード生成ツールであり，最新リリースではTomcat JMS と Selenium をサポートする。SpingSource開発チームは先週，Roo 1.0 M1 バージョンをリリースした。
Spring Roo フレームワークには，タブキー補完，コンテキスト対応オペレーション，コマンドヒンティング機能を持ったコマンドラインシェルが用意されている。また標準ディレクトリ形式のJavaアプリケーション構築，ビルド・コンフィギュレーションファイル管理，ドメインオブジェクト作成補助，一般的な永続化機構との統合，easy RESTベースWebユーザインターフェースのWeb層自動生成などを行う。さらに，動的検索(finder)メソッドやJUnit統合テストの自動生成機能なども提供する。
RooプロジェクトのリーダであるBen Alex氏は先日，Rooの新リリースに関するエントリをブログにポストした。その中で彼は，フレームワークのインストール方法と，Rooを使用したSpringアプリケーション作成方法を説明するためのサンプルを紹介している。また SpringSource の創設者である Rod Johnson 氏は Roo フレームワーク開発の動機について書いている。InfoQは新しいフレームワークに関して，およびそれがどのようにJavaアプリケーション開発者の役に立つのかを Ben Alex 氏に聞いた。
現実のJavaアプリケーションでは定型コードの自動生成が求められています。Rooがそれにどのように対処するのか，それと同時にカスタム・ビジネスロジックとバリデーションルールを組み込む柔軟性をどのように提供するのかについて教えてください。
Rooではすべての場面で，ユーザ自身がテキストエディタ，IDE，その他のツールを使ってコードを書くことができます。Rooはバックグラウンドでファイルを監視していて，プロジェクトの総合的メタデータモデルを生成します。このメタデータモデルを使って，Rooはユーザ自身が作成したものとRooが作成しなければならないものを判別し，コンポーネントを自動生成します。後になってこのコンポーネントのどれかをユーザが書き直した場合，Rooは再度これを検知して，自動生成したコードを透過的に削除するのです。
ROOフレームワークでは，@Configurableのようなアノテーションを参照するためにアスペクトを使用しています。RooフレームワークでAOPを使用した理論的背景はどのようなものでしょうか。
Javaコード生成の基盤としてアスペクトを使用したことに関しては，背景にたくさんのモチベーションがあります。これについては私のブログの第３編で取り上げるつもりです。しかし実際には，利用可能ないくつかの別のテクニックについてもプロトタイプしました。JSR269，ビルド時ソースコード生成，IDEプラグイン，開発時バイトコード生成，実行時バイトコード生成，SpringフレームワークAOPを拡張した前進的リフレクションアプローチ，DSL等々です。
私が最も重視したのは以下の条件でした。第２の考慮点は次のようなものでした。
- ツールの使用を取りやめた場合でも，ユーザのプロジェクトは有効であり続けなければならない。この条件によって，ランタイム時に実行される方法はすべて候補外になります。
- ユーザプロジェクトの実行時パフォーマンスに影響があってはならない。リフレクション的なアプローチは，この条件によって除外されます。
- 開発者がすでに所持しているJava知識・技術・経験を活用できなければならない。このためにはツールが，一般的なJavaプログラム経験や開発者の普段のスタイルでのプログラミングをサポートする必要があります。いつも使っているIDEが使用できて，使いなれたデバッガやコードアシストなどの機能にアクセス可能でなければなりません。開発者がすでに知っていて，理解していて，経験しているものと一緒に動作しなければならないのです。この条件によって，特殊なバイトコードアプローチや大部分のランタイムアプローチは除外されることになります。
- ツールは自動的に動作し，特別な起動操作やビルドシステムとの統合，特定のIDEを必要としないものでなければならない。また，透過的・即時的なround-tripのサポートが必須である。この条件によってJSR269，およびXDocletのようなビルドシステムベースのアプローチが除外されました。
- ユーザのプロジェクトはJava5以降で動作しなければならない。JSR269はこれによって除外されます。ただしJSR269について言えば，この他にも避けるべき理由はたくさんありました(プロトタイプ時のIDEによるサポート不足など)。
- ツールはエンドユーザが簡単に拡張できるべきである。私たちが使いなれたAspectJによるアプローチでは，これは確かに簡単でした。この条件はIDE固有の機能の利用を防止することにもなります。この手の特殊な技術は一般的に，Rooアドオンが行うよりも開発やデプロイを複雑にする傾向があるからです。
- ツールはアドオンに対して長期間の改良をサポートするべきである。AspectJ ITDによる関心の分離(separation of concern)を使用することによって，これはとても容易になりました。
- ツールは究極的(extremely)に軽量(lightweight)，すなわちダウンロードが早く，学習容易で，操作が簡単であるべきである。この条件は，依存性が最小であるシェルベースのアプローチを支持します。Roo 1.0.0.M1 では，ダウンロードサイズが3Mb以下なのです!
要は AspectJ ITD と自動メンテナンスされるメタデータモデルの組み合わせが，これら条件すべてを満足するものとして私たちが見つけることのできた，ただ１つのソリューションだったのです。もしも条件の中に断念できるものがあるなら，問題に対処する方法は当然他にもあるでしょう。
Rooを他のコード生成ツール，例えばopenArchitectureWare(oAW)やSkyway Software の Skyway Builder などと比較した場合はどうでしょうか。
oAWはアプリケーション開発者に対して，モデル駆動アプローチ(MDA)を提供します。MDAの効果的な状況がたくさんあることは事実でしょう。今のところRooはMDAツールではありません。先ほどRooの背景となった優先度の件で説明したように(そしてROO-1 issueで述べているように)，私たちの最優先事項は押し付けのない，これまでのJava開発者の知識・技術・経験を利用可能な生産的ツールの提供にあります。私たちは，大部分のJava開発者がJavaコード上で作業することを好んでいると信じているので，それを尊重し，コード優先パラダイムを通じて彼らに生産性を提供できるようにRooを開発しました。これはモデル優先パラダイムとはまったく違うものです。
余談になりますが，IDEが今ほど普及した理由がこのコード至上主義にある，というのが私の意見です。自分たちの好きな方法でコーディングできますし，IDEを使わない場合よりも生産的です。その快適さのレベルが増すにつれて，開発者はIDEの機能をより多く利用するようになっていきます。仮に開発者がIDEの使用を止めたとしても，それまでのプロジェクトは有効です。IDEを使い始めるにも止めるにも，"ビッグバン"は必要ないのです。IDEはランタイムコンポーネント(これにはパフォーマンス，互換性，移植性，利用承認などたくさんの問題があります)を必要としません。これらのことは，エンドユーザがプログラムツールから利益を得る上で理想的な特性であるといえます。
Skyway Builder のユーザは通常，必要なアプリケーション機能の図表表現を作成します。そして，これがJavaソースコードに内部的にマッピングされるのです。私はSkywayが，彼らのツールにRooのシンタックスをベースとするスクリプティングサポートを追加する作業をしていると聞いています。
SkywayとoAWはどちらも Eclipse のプラグインとして実装されていて，標準的な Java ソースコードを出力します。一方，Roo は AspectJ ITD を出力しています。私たちはソースコードを出力する方法についても評価しましたが，生成したJavaメンバを別のITDに格納する方法の方が好ましいと感じたからです。この方法はクラスの混乱を抑制し，関心の分離(separation of concern)を確保し，Roo アドオンに将来のバージョンとの互換性を提供します。Rooの配布ファイルが３Mb以下のサイズであって，Eclipseベースのツールに比べてフットプリントも小さくて済む点も強調しておきたいと思います。さらにRooは，テキストエディタとも，Eclipse以外のIDEとも問題なく使用できます。Rooはまた，ほとんどトレーニングなしで使用することができますー開発者は望む場所どこでもソースコードを記述できて，Rooはそれを尊重します。他のツールで自分自身のコードを書こうとすると，開発者はツール利用に必要なことを理解しなければなりません。
ソフトウェア開発プロセスとしてのRooフレームワークの利用に関心を持つJava開発者に対して，あなたが推奨する最良の方法(best practice)と"罠(gotcha)"はどんなものでしょうか。
Rooは開発ステージの初期段階にあります。Spring の好きな数多くのJava開発者には技術面で興味深いものだとは思いますが，今はまだ一般公開されて１ヶ月ほどであるという点は心に留めておくべきと考えています。機能を仕上げる，バグをフィックスする，フィードバックを得る，ドキュメントを書く，1.0.0.GAをリリースする，などを実行するにはもう少し時間が必要です。私たちは，できる限り多くのフィードバックを得ることに力をいれています。それが高品質な1.0.0.GA リリース(2009年８月頃の予定)を提供する上で役立つからです。
"罠(gotcha)"の件に関しては readme.txt に既知の問題のリストがあります。ほとんどの人には影響のなさそうな内容ですが，それでも徐々に解決していくつもりです。また，JIRAインスタンスへの公開も行っていて，そちらでは他の問題もリストされています。
新機能に関して，ROOの今後のロードマップを教えてください。
先ほど話したように，私たちはまだ1.0.0.GAに全力を集中しています。これが公開できたら，Rooのシェル部分を分割して別プロジェクトを立ち上げる予定でいます。おそらくSpring Shellという名称になるでしょう。この Spring Shellは，Shell機能を必要とする他のプロジェクトからも利用可能になります。これとは別に，第４世代Webアプリケーション要件(FlexやGWTなどの技術)についても，対応を進める計画です。また私たちは，機能拡張が必要なアドオンやコミュニティが必要とする新たなアドオンについて，それが何であるかを十分に検討するつもりでいます。コミュニティはRoo コミュニティ・フォーラムや問題トラッカを通じて機能に関するアイデアや提案，経験を提供することで私たちの作業を助けてくれています。私たちはまた #roo Twitter チャネルを通じて，形式ばらないフィードバックを即座に返してくれる人たちにも注意を払っています。