Google Web Toolkit 評価

picture

開発本部アルバイトの海野です。

JavaScript 開発フレームワークである、Google Web Toolkit(以下、GWT)の評価報告についてお話ししようと思います。

近年、JavaScript + AJAX を駆使した Web 上のアプリケーションの流行があります。
一方で、開発環境の貧弱さや、多様な動作環境(ブラウザ)の存在により、開発は困難という現実があります。

そこで、開発を促進するためのライブラリ群がたくさん生まれてきましたが、その中でも GWT は、Java でプログラムを書いて、JavaScript にコンパイルするという異色のライブラリです。

GWT の持つ3つの顔

GWT の主要な機能は、コンパイラ、ライブラリ、エミュレータに集約されます。
これらからなる開発環境が GWT といえるでしょう。

コンパイラ

Java から JavaScript へのコンパイラです。
これが GWT をもっともよく特徴づけている機能です。
これには、たとえば以下のようなメリットがあります。

  • 既存の強力な Java の開発環境がそのまま使える
  • ブラウザに応じた JavaScript コードが生成することで、ブラウザ間の差を吸収できる
  • JavaScript よりも強い型制約で、多くのバグを未然に防げる
生成した JavaScript コードと CSS とひな形の HTML をあわせることで一つの Web アプリケーションが完成します。

ライブラリ

GWT での開発では JavaScript のライブラリはほとんど使いません。
代わりに、それに応じた Java ライブラリが提供されています。
主なものは以下の3つです。
とりわけ、GUI ライブラリと RPC ライブラリは、面倒な画面デザインと非同期通信機能を強力にサポートします。

  • 標準ライブラリ
    java.util と java.lang のサブセットを提供する
  • GUI ライブラリ
    Java 風 の Event + Listener 型のイベント通知機構からなる
    Java で GUI を書いたことがあれば、すぐに使える
  • Remote Procedure Call(RPC)ライブラリ
    通信部分を、Java のメソッド呼び出し風にラップする
    Servlet 側と同一の Java ソースを使えるので、ソースの一部を共有できる

エミュレータ

コンパイル作業には少なからず時間がかかります。
そこで、修正したソースを JVM 上で実行するエミュレーション環境が提供されます。
既存のブラウザのコントロールをラップして実装しているらしく、ブラウザとほぼ同一の動作をします。
このおかげで、修正 → 即確認というサイクルができます。

また、これと連動して Java のデバッガを使うことができます。
今回は Eclipse を使用しましたが、ブレークポイントの設置やステップ実行といったデバッガ機能を存分に使うことができます。

実際のソース

ソース片を見ることで、実際のソースがどんなものなのか、そのイメージを紹介します。

GUI

GUI ライブラリは Java のそれと酷似しています。そのため、Java プログラマならすんなりと使えるようになるでしょう。

Button ok = new Button("OK");
 ok.addClickListener(new ClickListener() {
  public void onClick(Widget sender) {
   ...
  }
 });
panel.add(ok);

とても簡単 :-)

RPC

ふつうにサーバーと通信するなら、送信したいデータを文字列なりにエンコードして、POST するなり GET するなりし、返ってきたデータをまたパースするという処理が必要かと思います。

RPC ライブラリを使うと非常に簡単。 たとえば、こんな感じ・・・

userService.getUserInfo(name, new AsyncCallback() {
 public void onSuccess(Object result) {
  UserInfo info = (UserInfo)result;
  ...
 }
 ...
});

まるで、サーバー側の getUserInfo を呼び出しているかのような感覚で使えます。
実際には、初期化処理やサーバーを指定する処理がありますが、通信部分は上のような感じです。
この例では、name をサーバーに送って、result として UserInfo 型の info が返ってきます。
文字列をパースする必要はありません。ライブラリ側が自動でやってくれます。

評価用開発

今回、評価用にカレンダーアプリケーションの一部を作ってみることにしました。
具体的には Goole Calendar のようなイメージです。

この狙いは、スケジュール管理画面などの自由にコントロールを配置しなければならないアプリケーションでも、GWT が強力に機能するのか確認することです。

ちなみに、作者は Java は書けますが、JavaScript を全く知らない(for 文の書き方も知らない)ような人です。果たしてそれでもうまく作れるのか・・・。

成果 ( 画像をクリックすることで拡大表示します )

全く無知の状態からでも、かなり短期間で開発が進みました。
時間がかかった問題の多くは、ライブラリの詳細な挙動がわからなかったために、間違った使い方をしたようなところです。
ドキュメントは十分ではないように感じましたが、これはブラウザによっても挙動が異なると思われるので、難しい要求かもしれません。

JavaScript 文はほとんど書いていません。

マウスのドラッグ処理で、1カ所どうしても JavaScript native を呼ばないと解決できなかった問題があったので、その修正箇所の2行だけが JavaScript になっています。
ほぼ、Java のみの開発となりました。

問題点は?

いくらかの不安材料はあります。

コンパイラにバグはないの?
少し不安が残るが、作業中には見あたらず
コンパイラの効率は?
かなり無駄の多そうな JavaScript ソースを生成している
現実的にはブラウザのインタプリタエンジンの性能差の方が大きそう
ブラウザ間の差は?
少なからずあるようだ
JavaScript を直接書いたときも同じ(あるいは、それ以上に)問題がありそう
情報が少ない
日本語情報は皆無です
Goolge のフォーラム中に情報があるが、未解決のまま放置された話題も多い ;-(

いろいろありますが、クリティカルな問題は少ないように思います。
それ以上の、生産性と保守性の向上が期待されます。
非常によくできているので、一度使ってみる価値のあるツールですね。

以下は、成果発表の時に使用したスライドです。


PPT 版 : Google Web Toolkit 評価報告 ( 490 KB )

PDF 版 : Google Web Toolkit 評価報告 ( 365 KB )



関連するエントリー