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

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

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

GWTはGoogle製品として生まれましたが、2011年後半にオープンソースに卒業し、現在はApache License（バージョン2）の下で名前でリリースされています。 GWTオープンソースプロジェクト 。それはによって管理されています 運営委員会 を含むいくつかの企業の代表者と グーグル 、 RedHat 、 ArcBees 、 雌のトナカイ 、および Sencha 、およびコミュニティからの独立した開発者。

Javaでメモリリークを見つける方法

過去と未来のGWT

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

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

目標は、多かれ少なかれブラウザー間の違いを隠し、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をコンパイルします ここに 。

偽のクレジットカード番号2017

GWTコミュニティ

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

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

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

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

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

GWTレポートの未来 2015年の ここに 、そしてそれは、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ライブラリを示します（ TheARToolkit たとえば）GWTを使用してブラウザに移植し、WebRTCやWebGLなどのWeb APIと組み合わせて、完全にWebベースの拡張現実ツールを入手できます。 PicShareを紹介できたことを誇りに思います 昨年1月の2015GWT.createカンファレンスで。

Javaアプリの力を備えたJavaScriptフロントエンド？はい、GWTを使用すれば、あなたもすべてを手に入れることができます！ つぶやき

内部：JavaをJavaScriptに変える

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

GWTを使用して単純なアプリケーションを作成することは、 Java開発プロジェクト 。しかし、「実際に起こっていること」を理解するには、ツールキットの主要なコンポーネントを分析する価値があります。

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

GWTの最適化コンパイラ

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

最初に理解することは、GWTがソースコードレベルでの変換によってJavaをJavaScriptにコンパイルすることです。つまり、Javaソースが翻訳されます（ トランスパイル は専門用語です）JavaScriptに。これは、Javaバイトコードを実行するJavaScriptで記述されたある種のJava仮想マシンを持つこととは対照的です。 （これは実際に可能であり、によって使用されるアプローチです ダブル 、しかしそれはGWTがどのように機能するかではありません。）

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

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

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

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

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

エミュレートされたJRE

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

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

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

  ノードjsのメモリリーク検出

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

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

  企業がサプライヤーの力を減らすことができる最も一般的な方法の1つは何ですか？

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

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

相互運用性レイヤー

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

GWTは当初から、このような相互作用をサポートするために構築されました。 JavaScript Native Interface（JSNI） 、ブラウザ内APIへのアクセスが簡単になります。たとえば、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を使用すると、ネイティブJavaScriptクラスをJavaであるかのように操作できます。

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

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

最後の言葉

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

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

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