GWT（Google Web Toolkit）とは｜JavaをJavaScriptに変換する仕組みと2.13の現状

GWT（Google Web Toolkit）とは、Javaで書いたコードをブラウザで動くJavaScriptに変換し、JavaだけでWebアプリのフロントエンドを作れるオープンソースのツールキットです。Googleが2006年に公開し、現在はコミュニティが保守しています。最新版は2.13.1（2026年6月19日）です。GoogleのGWTチームは2015年に後継のJ2CLの開発へ移りました。この記事では、仕組みと主な機能、開発の始め方、2.12・2.13へ上げるときの注意点、J2CLとの違いを説明し、GWTで作られた既存アプリを保守するか移行するかの判断材料をまとめます。

まとめ：GWTの役割と採用判断

• 定義：Javaのソースを最適化したJavaScriptにコンパイルするツールキット。UI部品、サーバー通信（GWT-RPC）、履歴管理、国際化までを1つのSDKで提供する。
• 現状：最新は2.13.1。開発はGoogleではなく、2012年発足のSteering Committeeを中心とするコミュニティが担う。J2CLはGmail・Googleドキュメント・スライド・カレンダーなどの基盤に採用されている。
• 使いどころ：GWTで作られた業務システムの保守・延命。新規開発で選ぶ理由は少ない。
• 更新時の要点：2.12以降は開発ツールの実行にJava 11以上が必要。2.13ではDevModeの既定が静的ファイル配信だけになり、String.splitの挙動も変わった。

GWTの仕組み｜JavaをJavaScriptにコンパイルする流れ

GWTの中心はGWTコンパイラです。クライアント側のJavaソースを読み込み、未使用コードの除去やインライン化をしたうえで、ブラウザ向けのJavaScriptを出力します。開発者はUIもロジックもJavaで書き、JavaScriptを直接書く必要はありません。コンパイル対象になるのはJavaのソースコードで、.classファイルではない点がふつうのJava開発と違います。

モジュール定義とエントリーポイントの書き方

GWTのプロジェクトは「モジュール」という単位で管理します。モジュール定義ファイル（.gwt.xml）に、継承するライブラリ・アプリの開始クラス・クライアント側のソースの場所を書きます。

<?xml version="1.0" encoding="UTF-8"?>
<!-- src/main/java/com/example/hello/HelloApp.gwt.xml -->
<module rename-to="hello">
  <inherits name="com.google.gwt.user.User"/>
  <entry-point class="com.example.hello.client.HelloApp"/>
  <source path="client"/>
</module>

開始クラスはEntryPointインターフェースを実装し、onModuleLoadに初期化処理を書きます。次の例はボタンを1つ置き、クリックでダイアログを出します。2.12以降はJava 17までの言語機能を使えるので、recordもクライアント側に書けます。

package com.example.hello.client;

import com.google.gwt.core.client.EntryPoint;
import com.google.gwt.user.client.Window;
import com.google.gwt.user.client.ui.Button;
import com.google.gwt.user.client.ui.RootPanel;

// エントリーポイント：ボタンを1つ表示する最小例
public class HelloApp implements EntryPoint {
    // Java 17のrecordもクライアント側で使える（2.12以降）
    record Greeting(String name) {
        String message() { return "Hello " + name; }
    }

    @Override
    public void onModuleLoad() {
        Button button = new Button("クリック");
        button.addClickHandler(event -> Window.alert(new Greeting("GWT").message()));
        RootPanel.get().add(button);
    }
}

Mavenでビルドするときは、GWTのBOMで版をそろえ、gwt-maven-pluginにコンパイル対象のモジュール名とsourceLevelを指定します。GWTコンパイラの前に通常のjavacも走るため、recordを使う場合はmaven.compiler.releaseも17にそろえます（省くと「レコードは-source 8でサポートされていません」で止まります）。

<!-- pom.xml（要点のみ） -->
<packaging>gwt-app</packaging>
<properties>
  <!-- recordを使うのでjavacもJava 17で動かす -->
  <maven.compiler.release>17</maven.compiler.release>
</properties>
<dependencyManagement>
  <dependencies>
    <dependency>
      <groupId>org.gwtproject</groupId>
      <artifactId>gwt</artifactId>
      <version>2.13.1</version>
      <type>pom</type>
      <scope>import</scope>
    </dependency>
  </dependencies>
</dependencyManagement>
<dependencies>
  <dependency><groupId>org.gwtproject</groupId><artifactId>gwt-user</artifactId></dependency>
  <dependency><groupId>org.gwtproject</groupId><artifactId>gwt-dev</artifactId></dependency>
</dependencies>
<build>
  <plugins>
    <plugin>
      <groupId>net.ltgt.gwt.maven</groupId>
      <artifactId>gwt-maven-plugin</artifactId>
      <version>1.3.0</version>
      <extensions>true</extensions>
      <configuration>
        <moduleName>com.example.hello.HelloApp</moduleName>
        <sourceLevel>17</sourceLevel>
      </configuration>
    </plugin>
  </plugins>
</build>

この構成（GWT 2.13.1・gwt-maven-plugin 1.3.0・JDK 25）で2026年10月28日にmvn packageを実行し、コンパイルとリンクが成功してhello.nocache.jsが出力されることを確かめました。JDKとIDEの準備は、VS CodeのJava拡張「Extension Pack for Java」の使い方の手順がそのまま使えます。

開発モード：Super Dev Modeとコードサーバー

開発中は、ソースを保存してブラウザを再読み込みすると差分だけ再コンパイルされる「Super Dev Mode」を使います。2.7からはDevModeを起動すると自動でSuper Dev Modeになり、コンパイル済みのアプリは既定で9876番ポートのコードサーバーから配信されます（公式のSuper Dev Mode解説）。ブラウザのプラグインを使っていた昔の開発モード（Wikipediaなどで「ホステッドモード」と書かれているもの）は2.8で非推奨になりました。

2.12からはソースマップが全ブラウザで既定で有効になり、ブラウザの開発者ツールで元のJavaのコードを見ながらブレークポイントを置けます。Mavenを使うなら、gwt-maven-archetypesのmodular-webappでクライアントとサーバーを分けたプロジェクトを生成し、mvn gwt:codeserver -pl *-client -amでコードサーバーを起動します。アプリをブラウザで開くには、別の端末でmvn jetty:run -pl '*-server' -am -Denv=devを実行し、サーバー側も起動します。

GWTに含まれる主な機能

GWTはコンパイラ単体ではなく、業務アプリを作るための部品をひととおり揃えたSDKです。Javaの型チェックとIDEの補完をフロントエンドにも使えるのが、Javaのチームが選んできた理由です。

Javaの標準ライブラリがすべてブラウザで動くわけではありません。使えるのはJREエミュレーションが用意したクラスだけで、java.io.Fileやjava.lang.Threadをクライアント側で使うと、2.13.1では「No source code is available for type」というコンパイルエラーになります。2.13ではエミュレーションの対応表に「未対応のAPI」とその課題番号も載るようになりました。

JavaScriptの既存ライブラリやDOM・FetchなどのWeb APIを呼ぶときは、注釈で型を付けて橋渡しするJsInteropを使います。古いJSNI（Javaのクラス内にJavaScriptを直書きする方式）も残っていますが、公式のJsInterop解説はJSNIの代わりに注釈で連携する方式として位置づけています。2.9.0からはElemental2（ブラウザAPIの型定義ライブラリ）がGWT 2とJ2CLの両方で使えるようになったため、今から書くならJsInteropとElemental2を選びます。

GWTの歴史と現在の開発体制

GWTの評価が分かれるのは、Googleの位置づけが途中で変わったためです。主な節目を年表にまとめます。

Steering Committeeは「特定の個人や組織がプロジェクトを支配しない」ことを目的に2012年に設けられ、現在の委員はVertispan・Red Hat・JetBrainsなどに所属する開発者です。リリースはGitHubのgwtproject/gwtで公開され、2.12.0（2024年10月）から2.13.1（2026年6月）までの1年8か月に5回出ています。

Google側の事情は、J2CLのREADMEに書かれています。2015年初め、GoogleのGWTチームはGWTを少しずつ改良する道をあきらめ、新しいJava→JavaScript変換器（J2CL）をゼロから作ると決めました。J2CLはGmail・Googleドキュメント・スライド・カレンダーの基盤になっています。GWTの次期版（GWT 3）はJ2CLの上に載る「ライブラリと業務向けツールのSDK」へ方針が変わり、gwt-dom・gwt-httpなどのモジュールがGWT 2とJ2CLの両方で動く形で切り出されています。

GWT 2.12・2.13へ更新するときの注意点

保守中のGWTアプリを最新版へ上げる場合、ビルド環境と挙動の変化を先に確かめます。公式のリリースノートから、更新作業で影響が出やすい点を抜き出しました。

ビルド設定で先に確認するのは、2.10.0のgroupId変更です。2.10.0が旧来のcom.google.gwtで公開された最後の版で、以降はorg.gwtprojectでしか出ていません。依存の座標を書き換えずにバージョン番号だけ上げると、Mavenが新版を見つけられずにビルドが止まります。

2.13.0ではDevModeが内蔵のJetty 9でサーバー側のコードを動かすのをやめ、既定では静的ファイルしか返さなくなりました。旧来どおり動かすには-server com.google.gwt.dev.shell.jetty.JettyLauncherを指定しますが、この仕組みは削除予定です。クライアントとサーバーのクラスパスを分け、サーバーは別に起動する構成へ移すのが正攻法です。

実行時の挙動が変わる点もあります。String.splitが空の要素を含むJava 8の仕様に合わせられ、Collectors.toMapはnull値を入れると例外を投げるようになりました。どちらもコンパイルは通るのに結果だけ変わるため、文字列処理とStream処理の単体テストを更新前に用意しておきます。なお、リリースノートは「2.13がJava 11でコンパイラと開発ツールを動かせる最後のリリースになる見込み」としています。次の版ではCIのJDKを上げる必要が出ると見ておくのが安全です。

J2CL・GWT 3・モダンなフレームワークとの違い

GWTの比較相手は、Googleの後継J2CLと、ReactやAngularなどのJavaScript/TypeScriptのフレームワークです。役割の範囲がまったく違います。

J2CLはJavaをJavaScriptへ変換する「変換器」で、UI部品やRPCを持ちません。ただし、配列アクセスの境界チェックやfloatの演算精度など、Javaとの動作上の違いがあります。出力はClosure Compilerで最適化する前提で、ビルドはBazelが標準です。WebAssemblyへの出力（J2WASM）にも対応していますが、READMEでは開発途上と書かれています。JavaのロジックをJavaScriptやWebAssemblyのアプリへ組み込む道具であり、GWTのように画面までJavaで完結させるものではありません。WebAssemblyとJavaScriptの役割分担はWebAssembly(Wasm)とは？JavaScript連携とMemory・Table操作の実装で詳しく扱っています。

ReactやAngularとの比較では、必要なUIライブラリへの対応状況と、担当チームが保守できる技術を確認します。業務システムをSPAで作る場合の一般的な選択肢はSPAの事例と業務システムのSPA化の判断基準にまとめています。

GWTを使い続ける場面と移行すべき場面

結論は「動いているGWTアプリは2.13系で保守を続け、新規開発では選ばない」です。

使い続けてよいケース：GWTで作った社内システムや管理画面が安定して動いていて、画面の大幅な刷新予定がない場合です。サーバーもクライアントもJavaのチームなら、GWT-RPCでつないだ構成をそのまま保守できます。2.13.1はJava 17の言語機能に対応し、リリースも年に数回続いているので、保守継続を第一候補にし、更新・運用・人員確保にかかる費用を再構築費用と比較します。

移行を考えるべきケース：UIを頻繁に変えたいプロダクト、外部のUIライブラリを多く使いたい画面、GWT経験者を確保できない体制です。ウィジェットやGWT-RPCに強く依存したアプリはJ2CLへそのまま移せないので、画面の再実装を前提に、必要なUI部品と保守体制に合うフロントエンドを選びます。サーバー側をJavaで続けるなら、Javaバックエンドとフロントエンドの分担を先に決めてから画面を移すと手戻りが減ります。

移行は一度に全面刷新せず、画面単位で置き換えます。まずGWT-RPCをJSONのREST APIに置き換えてサーバーとの境界を切り、次に新しい画面だけを新しいフロントエンドで作り、古い画面を順に減らしていく進め方が破綻しにくい手順です。GWTで作った業務システムの置き換えは、システムマイグレーション・リプレイスとして相談を受け付けています。

よくある質問

GWTは今も使えますか？開発は終わっていませんか？

使えます。最新の安定版は2.13.1（2026年6月19日）で、GitHubでのリリースが続いています。開発を離れたのはGoogleで、GWT自体はコミュニティが保守しています。

GWTとJ2CLの違いは何ですか？

J2CLはJavaをJavaScriptへ変換する機能だけを持つ変換器で、GWTのウィジェットやGWT-RPCはありません。GWTは画面・通信・履歴管理まで揃ったSDKです。J2CLはGmailやGoogleドキュメントなどの基盤に採用されています。

GWTは無料で使えますか？

無料です。Apache License 2.0のオープンソースで、商用利用もできます。

GWTを動かすにはどのJavaのバージョンが必要ですか？

2.12以降、コンパイラと開発ツールの実行にはJava 11以上が必要です。クライアントのコードにはJava 17までの言語機能を使えます。2.13がJava 11で開発ツールを動かせる最後の版になる見込みです。

新しくGWTのプロジェクトを作るにはどうすればよいですか？

Mavenならmvn archetype:generate -DarchetypeGroupId=net.ltgt.gwt.archetypes -DarchetypeVersion=LATEST -DarchetypeArtifactId=modular-webappで、クライアントとサーバーを分けたプロジェクトを生成できます。依存はorg.gwtprojectのgroupIdで指定します。

関連記事

• VS CodeのJava拡張「Extension Pack for Java」の使い方｜自動ビルドの停止と6拡張の構成・JDK設定【2026年10月】
• Javaバックエンド開発の始め方｜他言語との比較とSpring Boot 4.1の構成・フロントエンドとの分担
• WebAssembly(Wasm)とは？JavaScript連携とMemory・Table操作の実装
• SPAの事例｜Gmail・GitHub・freeeに学ぶ業務システムのSPA化の判断基準と移行手順
• JavaScript API一覧｜DOM・Fetch・WebSocketの使い方と外部APIの呼び出し方