Google Web Toolkit(リンク)（GWT）のバージョン1.5(リンク) がリリースされた。GWTはJavaセントリックなコンパイラであり、JavaScriptベースのWebアプリケーションを作成する。InfoQでは技術リードのBruce Johnson氏(リンク)と話し、このリリースの詳細とGWTに新たに追加された機能について聞いた。
GWT 1.5の主な新機能には以下のものがある。
- Java 5のサポート－ジェネリクスやenum型、アノテーション、オートボクシングや変数パラメータのリスト等のJava 5の機能のサポートが追加された。
- コンパイラの最適化－コンパイルされたアプリケーションの性能が改善され、既存のアプリケーションはGWTのコードを変更せずに1.5でリコンパイルするだけで処理速度が改善するだろう。
- JavaScriptの拡張－JavaScriptのOverlay型と新しい高性能なDOM APIは、強く型付けされたJavaScriptのオブジェクトとDOMプログラミングを実行時のオーバーヘッド無しで提供する。
- デフォルトの外観テーマ－いくつかのCSSベースのUIテーマが利用可能であり、アプリケーションのルック・アンド・フィールの出発点として提供されている。
変更内容の全リストはリリースノート(リンク)とともに入手可能である(リンク)。
Johnson氏は1.5のいくつかの変更点について説明した。
RPC のためのJavadocベースのメタデータ[として前のバージョンまでは@gwt.eventArgsが使われていました]。これはきわめて貴重な例です。なぜなら、GWT 1.5にアップグレードしたときに、ほとんどの人が早い時期にこの変更に出会うと思われるからです。RPCのインタフェースは簡単にジェネリックなコレクションを指定できるので、RPCは今ではずっとシンプルでリッチになりました。他に知っておくべきことは、GWT 1.5は今ではプリミティブなデータ型の「long」を完全にサポートしていることです。GWT 1.5の前までは、「long」は厳密にはサポートされていませんでした。JavaScriptには64ビットの整数型が無く、フルレンジの「long」はネイティブなJSのnumberでは表現できなかったからです。GWT 1.5で私たちはその問題に取り組み、longの振る舞いが完全に正しいことを保証するための追加のコードを作成しました。しかし、性能はGWT 1.4よりも幾分悪くなりました。最大の性能と正確さとのどちらかを選ばなければならないというのは残念な状況でしたが、言うまでも無く正確さが勝ったのです。もしあなたがGWT 1.4でlongを多用していて、数値域よりもスピードのほうが重要な場合は、GWT 1.4と同じ速度を保つために、それらの変数を「int」あるいは「double」に変えることを検討してください。
Johnson氏は、1.5のサポートに必要となったコンパイラの変更の詳細についても説明した。
GWT コンパイラのフロントエンドでは、Eclipseの一部である優れたJavaコンパイラを再利用しています。解析と意味的なチェックはすべて行い、それから抽象構文木（abstract syntax tree：AST）を構築するのです。次に、そのASTを最適化し、JavaScriptの出力を生成します。Eclipseのコンパイラを利用することで、私たちの作業は非常に簡単になりました。なぜなら、多くの作業が既に行われていたからです。まだ、enum型や拡張forループ等の新しいコンセプトをJavaScriptで効果的に表現する方法を見つけるためには、かなりの作業が必要でした。新しい言語機能には、GWTのライブラリのいたるところで前向きな連鎖反応もありました。RPCでジェネリクスを使うための新発見の機能が最も目立っていますが、私たちは国際化やイメージのバンドル、ベンチマーキングなどにおけるJavadocベースのメタデータを置き換えるために、アノテーション広く活用してもいます。
Johnson氏はGWTのWeb開発で競合する主なものを、以下の３つのカテゴリで説明している。そしてGWTがそれらの競合するものとどのように差別化しているかを説明した。
- FlexのようにDOMではないUIモデル－GWTはブラウザのDOMモデルを置き換えるよりもむしろ受け入れている。そしてJohnson氏は、いくつかの非常に強力なFlashやDOM UIの統合が、GWTを使用して行われたことを指摘した。
- JSFのようなサーバサイドのHTMLジェネレータ－（RPC から離れた）純粋にクライアントサイドの技術であり、サーバサイドのコンポーネントとうまく統合するので、GWTはこれを補完するものである。しかしながらJohnson氏は、よりリッチでもっとステートフルなGWTクライアントコードは、サーバサイドのクリックして待機するコードの制限を減らしつつ、もっと応答性がよく可変性の高いUIの構築を促進することに気づいている。
- DojoやjQueryのようなAJAXライブラリ－ここでの大きな違いは、プログラミング言語の選択である。GWTは既存のJava開発ツールやコンパイラの能力を利用して、高度に最適化された JavaScriptを生成している。JavaとJavaScriptは一緒に使うことができるが、Johnson氏は、Javaをもっと使用すると、さらにGWTコンパイラの最適化が役に立つと言っている。
GWTはどのように他のGoogleのコードベースと統合されているのかを尋ねたところ、Johnson氏は次のように答えた。
キーポイント：GWTはたくさんのものをもたらしますが、「塀で囲まれた庭」にしようとしているわけではありません。抽象化には漏れがあるものであり、その事実を受け入れたほうがよいのです。私たちはわざと、簡単にその抽象化をついて基本のJavaScript環境に取り組めるようにしています。そうすることで、あなたはあなたの好きなどんな技術とでも統合できるのです。この柔軟性は、GWTとGWTユーザの双方にとって一種の保険です。あなたはどんなクライアントサイドの技術でもGWTと組み合わせられることを確認することができます。そして私たち（GWT開発チーム）は、変更可能な一連のものとの統合を明白に提供しなければならないとは思っていません。なぜなら、みなさんは私たちを待たずに、自分でできるからです。私が話している類の柔軟性の例としては、Ray Cromwell氏のSyndroid(リンク)をご覧ください。
Johnson氏は、Spring、Flash、多数のGoogle Codeプロジェクト(リンク)との統合を含め、数々のGWT統合が存在しているとも述べた。
今後のGWTの計画について尋ねたところ、Johnson氏は次のように答えた。
私たちは、日付ピッカーや手の込んだ新しいテーブルウィジェットを含むいくつかの新しいウィジェットをGWTのインキュベータから次の段階に進めることはもちろん、飛躍的に性能を改善させる作業を続ける予定です。また、私たちはその他にも新しいことを行っており、例えば宣言型のXHTMLベースのUIテンプレートの仕組みがあります。まだ全てがスケジュールされているわけではありませんが、次かその次のリリースには入るのではないかと思います。いずれにしろ、GWT 1.5のときよりももっと短いサイクルになることを期待しています。
Johnson氏はGoogle App Engineの開発環境としてのGWTの統合のサポートについても話し、「クールなアイデア」と呼んでいる。