GWT Toolkit：Javaを使用して強力なJavaScriptフロントエンドを構築する

以前はGoogleWebToolkitとして知られていたGWTWebToolkitは、Javaプログラミング言語を使用して複雑なブラウザーベースのアプリケーションを構築および最適化するための一連の開発ツールです。

GWTが「Webアプリを作成するためのもう1つのJavaツール」ではない理由は、ツールキットの中心がJavaをJavaScript（およびHTMLとCSS）に変換するコンパイラーであり、開発者がフロントエンドWebアプリケーションを作成できるようにすることです。 Javaのすべての長所を活用しながら。

GWTにはWebプラットフォームとのインターフェース用の堅牢な相互運用性アーキテクチャーが含まれているため、JavaとJavaScriptを組み合わせて使用​​することも簡単です。 Java Native Interface（JNI）でJava仮想マシン（JVM）がプラットフォーム固有のルーチンを呼び出すことができるように（たとえば、特定のハードウェア機能にアクセスしたり、他の言語の外部ライブラリを使用したりするため）、GWTではほとんどのJavaでアプリケーションを作成し、必要に応じて特定のWeb APIを使用するか、既存のJavaScriptライブラリを活用して、「ネイティブ化」してJavaScriptにジャンプします。

GWTはGoogle製品として生まれましたが、2011年後半にオープンソースに移行し、現在はGWTオープンソースプロジェクトという名前でApacheライセンス（バージョン2）の下でリリースされています。 これは、Google、RedHat、ArcBees、Vaadin、Senchaなどのいくつかの企業の代表者と、コミュニティの独立した開発者からなる運営委員会によって管理されています。

過去と未来のGWT

Google Web Toolkitは、2006年に最初にリリースされました。これは、GoogleエンジニアがAdWords、Google Wallet、Googleフライトなどの複雑なブラウザベースのアプリケーションを開発するのに役立つツールとして作成され、最近では、 Googleシートと受信トレイアプリケーション。

2006年当時、ブラウザー（およびJavaScriptインタープリター）は標準化にはほど遠いものでした。 フロントエンドコードは遅く、バグがあり、確実に使用するのは困難でした。 Web開発用の高品質のライブラリとフレームワークがほぼ完全に不足していました。 たとえば、jQueryは今年まで存在していませんでした。 そのため、大規模なWebアプリケーションを開発できるようにするために、Googleのエンジニアは既存のツールと能力を活用することにしました。 Javaは彼らのニーズに最も適した言語であり、よく知られており、EclipseなどのIDEに完全に統合されていたため、GoogleWebToolkitが誕生しました。

目標は、多かれ少なかれブラウザー間の違いを隠し、Javaコンパイラー内で効率的なJavaScriptを作成するために必要なトリックをカプセル化し、開発者をブラウザー技術の専制政治から解放することでした。

もちろん、過去10年間で、Webは変化しました。 ブラウザはより高速になり、実装標準に収束し、jQuery、Angular、Polymer、Reactなど、多くの優れたフロントエンドフレームワークとライブラリが開発されました。 したがって、自然に尋ねる可能性のある最初の質問は、「GWTはまだ有用ですか？」です。

一言で言えば：はい。

最新のWeb開発のコンテキストでは、ブラウザーのターゲティングは避けられず、JavaScriptはフロントエンドアプリケーションの共通語になっています。 しかしもちろん、さまざまなツールや言語がさまざまなタスクに適しています。 GWTは、いくつかの同様のプロジェクトとともに、開発者をJavaScriptの使用に限定することなくブラウザーをターゲットにすることを目的としています。

GWTのような「ウェブにコンパイル」ツールの開発と採用は、近い将来、ワールドワイドウェブコンソーシアムのいわゆるWebAssemblyグループによって促進されるでしょう。 JavaScriptにコンパイルするツールのための広大なスペースがあるだけでなく、このアプローチは、計算の一部をブラウザーにオフロードする、既存のコードとライブラリを再利用する、バックエンドとフロントエンドの間でコードを共有するなど、さまざまなコンテキストで実際のニーズを満たす可能性があります、既存の能力とワークフローを採​​用し、さまざまな言語の機能を活用します（たとえば、GWTの場合は静的型付け）。

GWTプロジェクトはまもなくバージョン2.8をリリースする予定であり、バージョン3.0は開発中であり、作業が大幅に改善されています。

• JavaScriptとの相互運用性を再発明
• 改善された（ほぼ完全に書き直された）コンパイラ
• 最先端のJavaサポート（ラムダなど）

実際、GWT 3.0のほとんどの機能は、パブリックGitリポジトリーですでに利用可能です。 ここでトランクをチェックして、ここのドキュメントに従ってGWTをコンパイルしてください。

GWTコミュニティ

GWTが2011年にオープンソースに移行して以来、コミュニティはプロジェクトの進化において極めて重要な役割を担ってきました。

すべての開発はgwt.googlesource.comでホストされているGitリポジトリで行われ、すべてのコードレビューはgwt-review.googlesource.comで行われます。 これらのページでは、ツールキットの開発に関心のある人なら誰でも、コミュニティが取り組んでいることに貢献して見ることができます。 過去数年間で、Google社員以外からの新しいパッチの割合は、2012年の約5％から昨年は約25％に上昇し、関与が高まっていることを確認しています。

今年、コミュニティは米国とヨーロッパでいくつかの大きな会議に集まりました。 Vaadinが主催するGWT.createは、1月にドイツのミュンヘンとカリフォルニア州のマウンテンビューの両方で開催され、数十か国から600人以上の参加者を数えました。 11月11日、イタリアのフィレンツェで、コミュニティ主導のGWTカンファレンスであるGWTconの第2版を開催します。これは、私が主催するのを手伝っています。

GWTは何に適していますか？

VaadinによってリリースされたGWTツールキットに関する年次調査では、GWTの開発の進化、開発者がツールキットについてどのように感じているか、良い点、悪い点などについて説明しています。 この調査では、ツールキットが何に使用されているか、ユーザーコミュニティがどのように変化しているか、開発者がツールキットの将来に期待していることも理解できます。

2015年のGWTレポートの将来はここにあり、GWTが大規模なWebアプリケーションの構築に非常に人気があることを明らかにしています。 たとえば、14ページには、「ほとんどのアプリケーションは、データ量が多く、1日あたり何時間も使用されるビジネスアプリケーションです」と記載されています。

予想どおり、GWTの自然環境は、コードの保守性が重要であり、大規模なチームがJava言語の構造から恩恵を受ける大規模なWebアプリケーションの分野であると簡単に結論付けることができます。

一方、GWTによって生成されたコードのベンチマークを見ると（たとえば、昨年のGWT.createカンファレンスの基調講演の7、8、11ページ）、パフォーマンスとコードサイズ、コンパイルされたJavaScriptは驚くほど素晴らしいです。 正しく使用すれば、得られるパフォーマンスは最高の手書きJavaScriptに匹敵します。 その結果、JavaライブラリをWebに移植するためにGWTを使用することは実際に実行可能です。

これは、GWTのもう1つの理想的なシナリオを明らかにします。 Javaエコシステムは、JavaScriptですぐに使用できるライブラリがない高品質のライブラリでいっぱいです。 GWTコンパイラを使用して、このようなライブラリをWebに適合させることができます。 言い換えれば、GWTを使用すると、JavaとJavaScriptの両方で使用可能なライブラリを組み合わせて、ブラウザーで実行できます。

このアプローチは、PicShareの開発で見ることができます。ここでは、Webで一般的に考慮されていないいくつかのJavaライブラリ（たとえば、NyARToolkit）をGWTを使用してブラウザに移植し、WebRTCやWebGLなどのWebAPIと組み合わせて完全にWebベースの拡張現実ツールを入手してください。 昨年1月の2015GWT.createカンファレンスでPicShareを紹介できたことを誇りに思います。

内部：JavaをJavaScriptに変える

GWT Toolkitは適度に複雑なツールのセットですが、Eclipseとの驚くほど使いやすい統合のおかげで、誰でも簡単に使い始めることができます。

GWTを使用して単純なアプリケーションを作成することは、Java開発プロジェクトのバックグラウンドを持っている人にとっては比較的簡単です。 しかし、「実際に起こっていること」を理解するには、ツールキットの主成分を分析する価値があります。

• JavaからJavaScriptへのトランスパイラー
• エミュレートされたJavaランタイム環境
• 相互運用性レイヤー

GWTの最適化コンパイラ

コンパイラがどのように機能するかについての詳細な説明は、かなり早い段階で高度に技術的になり、それほど深く掘り下げる必要はありませんが、一般的な概念のいくつかは一見の価値があります。

最初に理解することは、GWTがソースコードレベルでの変換によってJavaをJavaScriptにコンパイルすることです。 つまり、JavaソースはJavaScriptに変換されます（トランスパイルは技術用語です）。 これは、Javaバイトコードを実行するJavaScriptで記述されたある種のJava仮想マシンを持つこととは対照的です。 （これは実際に可能であり、Doppioで使用されているアプローチですが、GWTの動作方法ではありません。）

代わりに、Javaコードは、コードの構文要素を表す抽象構文木（AST）に分解されます。 次に、同等の（そして最適化された）Javascript ASTにマップされ、最終的に実際のJavaScriptコードに変換されます。

トランスパイルの長所と短所を比較検討することは、この投稿の目的からはほど遠いですが、この方法を使用すると、GWTは、ブラウザーに固有の他の機能とともに、JavaScriptインタープリターのガベージコレクションサービスを直接活用できることに注意してください。

もちろん、いくつかのトリッキーな部分があります。 たとえば、JavaScriptには数値型が1つしかないため、Javaの64ビットlong整数型を含めることはできないため、 long型にはコンパイラによる特別な処理が必要です。 さらに、Javaの静的型付けはJavaScriptで直接的な意味を持たないため、たとえば、トランスパイル後に同等の型キャスト操作を維持するために特別な注意を払う必要があります。

一方、トランスパイルの簡単に理解できる利点は、GWTがJavaレベルとJavaScriptレベルで（サイズとパフォーマンスの両方について）最適化を実行できることです。 結果の標準JavaScriptコードは、デプロイメントパイプラインでさらに処理することもできます。 たとえば、現在標準のGWTディストリビューションに統合されている一般的な方法では、高度に専門化されたJavaScriptからJavaScriptへのクロージャーコンパイラ（Googleの神々からのもう1つの贈り物）を使用して、トランスパイラーによるJavaScript出力を最適化します。

私が知っているGWTコンパイラの最も詳細な説明は、このスライドデッキと、それが由来する元の話にあります。 ここでは、コード分割を実行するGWTの機能、ブラウザーによって個別にロードされる複数の個別のスクリプトファイルの生成など、コンパイルプロセスの他の優れた機能の詳細を確認できます。

エミュレートされたJRE

JavaからJavaScriptへのコンパイラは、ほとんどすべてのJavaアプリケーションが依存するコアライブラリを提供するJavaランタイム環境（JRE）の実装によって補完されない限り、目新しいものにすぎません。 大まかに言えば、たとえば、CollectionsやStringメソッドを使用せずにJavaで作業することは苛立たしいことであり、もちろん、これらのライブラリーの移植は大変な仕事です。 GWTは、この穴をいわゆるエミュレートされたJREで埋めます。

エミュレートされたJREは、Java JREを完全に再実装したものではなく、クライアント側で役立つ（そして使用できる）クラスとメソッドの一種の選択です。 Java JREにはあるが、エミュレートされたJREにはない機能は、次の3つのカテゴリに分類されます。

• クライアント側に移植できないもの。 たとえば、 java.lang.Threadまたはjava.io.Fileは、Javaと同じセマンティクスを持つブラウザーに実装することはできません。 ブラウザページはシングルスレッドであり、ファイルシステムに直接アクセスすることはできません。

• 実装することはできても、コードサイズ、パフォーマンス、または依存関係の点で「コストがかかりすぎる」ため、コミュニティはGWT内に配置しないことを好みます。 たとえば、このカテゴリにはJavaリフレクション（ java.lang.reflect ）が含まれます。これは、トランスパイラーが各タイプのクラス情報を保持する必要があり、コンパイルされたJavaScriptのサイズが膨らむ原因になります。

• 誰も興味を持っていなかったため、実装されていません。

エミュレートされたJREがニーズに合わない場合（たとえば、提供されていないクラスが必要な場合）、GWTを使用して独自の実装を作成できます。 タグ<super-source>を介して利用できるこの強力なメカニズムにより、エミュレートされていないJREの一部を使用する新しい外部ライブラリを適応させる際の問題を回避できます。

JREの一部の完全な実装を提供することは、非常に複雑であるか、不可能でさえある可能性があります。そのため、特定のタスクでは、特定の場合に機能する場合でも、独自の実装がJavaのJREのセマンティクスに厳密に従わない場合があります。 実際、クラスをプロジェクトに戻すことを検討している場合は、含まれる各クラスが元のJavaJREとまったく同じセマンティクスに従うことがエミュレートされたJREにとって最も重要であることを忘れないでください。 これにより、誰でもJavaコードをJavaScriptに再コンパイルして、期待どおりの結果が得られると確信できます。 コミュニティにコードを返す前に、コードが徹底的にテストされていることを常に確認してください。

相互運用性レイヤー

GWTは、実際のWebアプリケーションを作成するための効果的なツールであるために、開発者が基盤となるプラットフォームと簡単に対話できるようにする必要があります。 つまり、ブラウザとDOMです。

当初から、GWTは、ブラウザー内APIへのアクセスを簡単にするJavaScript Native Interface（JSNI）を介したこのような対話をサポートするように構築されていました。 たとえば、GWTコンパイラに固有の構文機能を使用して、次のJavaコードを記述できます。

 public static native void nativeMethod(T1 a1, T2 a2, ...) /*-{ //place your JavaScript code here }-*/;

また、JavaScriptでメソッドの本体を自由に実装できます。 JavaScriptオブジェクトをJavaScriptObject（JSO）でラップし、Javaコードでアクセスできるようにすることもできます。

このレイヤーが機能する場所の例は、UI構成のコンテキストで見つけることができます。 主流のJavaは、常に標準のウィジェットツールキットを使用してUI要素を構築し、Java Native Interfaceを利用して、基盤となるオペレーティングシステムのウィンドウシステムと入力システムにアクセスしてきました。 GWTの相互運用性レイヤーも同じことを行うため、従来のウィジェットはブラウザー内でシームレスに機能します。 唯一の違いは、この場合、基盤となるシステムはブラウザとDOMであるということです。

ただし、ネイティブフロントエンドフレームワークは近年急速に改善されており、今日ではGWTのウィジェットに比べて大きな利点があります。 これらのフレームワークが高度化するにつれて、JSNIにフレームワークを実装しようとすると、相互運用性レイヤーのアーキテクチャーの欠点が明らかになりました。 バージョン2.7以降、GWTはJsInteropを導入しました。これは、Javaアノテーションに基づく新しいアプローチであり、GWTクラスをJavaScriptとすばやく簡単に統合できます。 JSNIメソッドやJSOクラスを作成する必要がなくなりました。 代わりに、 @JSTypeや@JSPropertyなどのアノテーションを使用するだけで、JavaのようにネイティブJavaScriptクラスを操作できます。

JsInteropの完全な仕様はまだ進行中であり、最新の更新はGWTリポジトリーからソースをコンパイルすることによってのみ試すことができます。 しかし、これがGWTが進化するWebプラットフォームに追いつくことを可能にする新しい方向性であることはすでに明らかです。

JsInteropを利用する進行中のプロジェクトの1つは、最近リリースされたgwt-polymer-elementsです。これにより、PolymerのすべてのIronおよびPaper要素をGWTで使用できるようになります。 このライブラリで興味深いのは、開発者がJavaAPIを手動で生成する必要がないことです。 このプロジェクトでは、gwt-api-generatorを使用して、PolymerライブラリとJSDocアノテーションを解析することにより、ほとんどのインターフェイスを直接生成します。 これにより、バインディングを最新の状態に保つことが容易になります。

最後の言葉

コンパイラ、相互運用性レイヤー、および生成されたコードの過去2年間のパフォーマンスとサイズの改善により、GWTが単なる「別のWeb開発ツール」ではなく、の主要なリファレンスツールキットになる予定であることは明らかです。大規模で複雑なWebアプリケーションの開発であり、より単純なアプリを素晴らしいものにするための優れた選択肢になる可能性もあります。

私は開発者およびコンサルタントとして毎日GWTを使用していますが、ブラウザー機能の限界を押し広げ、最新のWebアプリケーションがデスクトップアプリケーションと同じくらい強力であることを示すことができるため、GWTが大好きです。

GWTプロジェクトのコミュニティは非常に活発であり、GWTに基づく新しいライブラリ、プロジェクト、およびアプリケーションが絶えず提案されています。 フィレンツェでは、コミュニティ主導のGWTcon2015が11月11日に開催されます。 この地域にいる場合は、コア開発者の何人かに会いに来て、この素晴らしいツールキットの進化の一部となるすべての機会について学ぶことを願っています。