Tooling & IDE Support

The IntelliJ IDEA help page for GWT states that support for Google Web Toolkit is not bundled with the IDE and is installed as a plugin from the JetBrains Marketplace. The Marketplace description lists code completion, syntax and error highlighting with quick fixes and refactorings specific to GWT, dedicated run configurations, integration with the GWT compiler and automatic creation of GWT components. The description does not name UiBinder or module XML editing individually, and this page did not run the plugin, so treat the editing support as "what the vendor describes", not as a verified feature list.

The official GWT page for IntelliJ is more modest and says something different: the GWT plugin belongs to the Ultimate edition, but the free Community edition is all you need, because the IDE’s Maven support reads the project class path and creates run configurations for compiling and running a GWT project. Both statements fit together. The plugin adds GWT-aware editing; the Maven integration alone is enough to build, run and debug.

The official page creates two Maven run configurations, one for the code server and one for the application server. Both take their goals in the command line field of a Maven run configuration (Run | Edit Configurations, add a new configuration, choose Maven). For the Bookshelf they are:

Source: GWT — Using IntelliJ: Run locally in Super Dev Mode

The official page contains a detail that is also verified on the command line: outside the IDE the selector is written -pl *-client -am, which fails on Maven 3.9.16 with Could not find the selected project in the reactor: *-client, and the page itself says that inside a run configuration the module name must be written out. In the Bookshelf that is bookshelf-client, and the working form is the one in the table. The page’s own text for the second configuration starts with mvn, which is how it is typed in a terminal; the command line field of a Maven run configuration holds the goals and options after mvn, as the JetBrains documentation for that configuration type describes.

A compound configuration (Run | Edit Configurations, add a new Compound configuration) that starts the two in order is a convenience that this page did not exercise; the ordering matters because the Jetty env-dev profile expects target/gwt/launcherDir to exist, as the table of pitfalls below shows.

To debug server code, run the jetty configuration in debug mode (the Maven run configuration page documents the debugger options of that configuration type) and set breakpoints in bookshelf-server and in shared code that runs on the server, as in any Java project. That route was not exercised here. Breakpoints in client Java do not hit this way, because that code is not running in the JVM.

The JetBrains documentation describes a built-in JavaScript debugger for Chrome and other Chromium-based browsers. It is delivered by the JavaScript Debugger plugin, which the documentation says is available only in IntelliJ IDEA with the Ultimate subscription, and its toolbar has a Disable Source Maps toggle for stepping through the code that actually runs. A JavaScript Debug run configuration has a Remote URLs of local files area that maps local files to the URLs of their copies on the server; the documentation says the mapping is only needed when the local folder structure differs from the server’s. For GWT that is the case, because the code server presents sources as com/example/bookshelf/client/App.java under its own URL. The section on source maps below gives the URLs, and what has and has not been verified.

Source: IntelliJ IDEA Help — Debug JavaScript in Chrome

Source: IntelliJ IDEA Help — Run/Debug Configuration: JavaScript Debug

The plugin’s README lists: GWT SDK selection, a compiler launcher, development mode launchers (a GWT Development Mode with Jetty launcher and a GWT Development Mode launcher that runs the code server, both described as Super Dev Mode, plus a legacy classic Dev Mode launcher), a GWT Java editor, a UiBinder editor, a CSS Resources editor, and Maven integration. The Maven integration supports both the net.ltgt.gwt.maven plugin used in this section and the legacy Mojo plugin; the plugin’s own documentation recommends the net.ltgt one and calls the Mojo plugin deprecated.

Installation follows the official GWT page for Eclipse: the Eclipse Marketplace entry GWT Plugin, or the update site https://plugins.gwtproject.org/eclipse/site/latest, which the official page says installs the plugin and the SDK plugins together. Separate update sites exist for the plugin without SDKs and for the SDK plugins only (https://plugins.gwtproject.org/eclipse/gwt-sdk-plugins/); on 2026-10-09 the latter listed GWT versions from 2.8.2 to 2.13.1.

The official page then walks through File | New | GWT Web Application Project, Debug As | GWT Development mode with Jetty and GWT | Compile. That walk-through creates a project with the plugin’s own wizard (a template-based wizard was added in 4.2.0), not the Maven archetype, and it predates the current layout: it talks about a war/ directory and a boilerplate project with client and server packages. For a Maven project like the Bookshelf the sensible route is File | Import | Existing Maven Projects on the root pom.xml, with the plugin’s launchers or plain Maven launches on top.

Source: GWT — Using Eclipse: Install the Plugin

Source: GWT Eclipse Plugin — README (features, update sites, Maven support)

Source: GWT Eclipse Plugin documentation — Maven

The plugin has not had a release since February 2025, and two things in its open issue list are worth knowing before you rely on it. Plugin version 4.2.0 refers to a class that the Equinox runtime removed (PluginVersionIdentifier, issue 521 in the plugin repository), so on the newest Eclipse platform builds it fails to load. A user also reports that the plugin’s launchers do not honour the project’s Java level, so record types fail in the plugin’s compile but not in Maven (issue 520, not reproduced here); the workaround the reporter used was to give the launcher an explicit -sourceLevel. Another open pull request adds a Jetty 12 launcher with Jakarta Servlet support (issue 523), which tells you where the plugin stands against the Jakarta servlet generation this section targets: the built-in server of the shipped launcher is Jetty 9.

For a Jakarta-era project the pragmatic Eclipse set-up is therefore: import the Maven project with m2e, run gwt:codeserver and Jetty as Maven launches, and use the plugin only for the editors if it installs on your Eclipse release.

Source: GWT Eclipse Plugin — issues

The plugin’s documentation pages for debugging date from November 2023; one of them describes a separate "SDBG" JavaScript debugger for Eclipse that has to be installed first. That debugger was not looked into for this page.

Against the running code server (port 9962 in the run below, started with codeserverArgs in the root POM), the compiled *.cache.js ends with a sourceMappingURL comment, and the map it points to is plain JSON. These are its fields on the Bookshelf, after a successful compile:

Source: GWT — Super Dev Mode: How sourcemap-based debugging works

Three facts matter to an IDE. The sources are package-relative paths, not absolute ones, and there is no sourcesContent: the debugger gets the Java text by requesting sourceRoot plus the path, and the code server answered with status 200 for .../sourcemaps/bookshelf/com/example/bookshelf/client/App.java, for a shared class (.../com/example/bookshelf/shared/Book.java) and for a GWT library class (.../com/google/gwt/user/client/ui/Button.java). The map lists the GWT library sources too, so stepping into Button shows GWT’s own Java. And the map belongs to one permutation: the file name contains the permutation’s hash, which changes when the code server recompiles with other binding properties.

To set a breakpoint in the local file bookshelf-client/src/main/java/com/example/bookshelf/client/App.java, an IDE has to translate between the two spellings of the same file. That is what the two path-mapping features are for, and it is the part of this page that has the least verification behind it: the attributes below are documented by their vendors, but the mapping was not run in either IDE.

Source: IntelliJ IDEA Help — Run/Debug Configuration: JavaScript Debug

A VS Code launch.json that follows the documented shape, with a chrome entry that opens the application served by Jetty on port 8080 and the two overrides from the table:

Source: Visual Studio Code — Browser debugging

The VS Code page documents type values msedge and chrome, url, and webRoot ("used for sourcemap resolution"); the sourceMapPathOverrides option is listed in the vscode-js-debug options reference. Whether a breakpoint set in the local .java file binds with these patterns, in the current VS Code release, is not established here: if it stays grey, the fallback that works in any browser is to set the breakpoint in the Sources tree of the devtools, where the code server’s own copy of the file is shown, and to read the local file beside it.

Source: vscode-js-debug — Options

Because the browser and the code server must both be running, the debugging session has more parts than a Java one. A checklist that matches the architecture:

Code in the server module, and shared code running on the server, is ordinary JVM code and uses the IDE’s normal Java debugger. In IntelliJ IDEA that is the Debug button of the Maven run configuration shown above; in VS Code and Eclipse it is a launch or attach configuration for the JVM Maven started. The generic attach recipe, which does not depend on any IDE, is the JDWP agent in MAVEN_OPTS, as the development mode page shows. The same page explains why a JUnit test of a presenter with a fake view (see Testing) is usually the best IDE debugging experience for client logic: it runs in a JVM, where every IDE feature works without a browser.

Source: GWT — Compiling and Debugging: Super Dev Mode

The code server serves the sources of the module to anyone who can reach its port, so keep the debugging session on localhost, as the security section of the development mode page explains. The map and the Java files it references contain your source code.

A *.gwt.xml file is XML, and GWT publishes a DTD for it. The DTD for 2.13.1 is at https://www.gwtproject.org/doctype/2.13.1/gwt-module.dtd; its text is the file distro-source/core/src/gwt-module.dtd of the 2.13.1 source tree (compared byte for byte, the copies at the versioned URLs for 2.9.0 to 2.13.1 are identical, while those for 2.8.0 to 2.8.2 differ, and 2.8.0 lacks when-linker-added). Add it as a DOCTYPE and any editor that validates against a DTD can complete and check element names. This is the form webAppCreator writes:

Source: GWT 2.13.1 — WebAppCreator.java (the DOCTYPE it writes)

The DOCTYPE is for editors only, which two checks confirm. With the system identifier pointing at an unreachable address (http://127.0.0.1:9/doctype/gwt-module.dtd), the compiler (Compiler -validateOnly -failOnError) still exited with status 0, because the module parser disables external DTD loading (its source sets the Xerces feature load-external-dtd to false). The compiler also checks element names itself: a typo in the module file stops it with a message in GWT’s own words. A DTD-aware editor reports the same typo earlier, as xmllint --dtdvalid does on the command line (the xmllint run used a copy of the file without the DOCTYPE, because xmllint could not fetch the https address itself, and the middle of the first message is abbreviated):

Source: GWT 2.13.1 — gwt-module.dtd

The Bookshelf’s own module.gwt.xml (without a DOCTYPE) validated against the 2.13.1 DTD with xmllint --noout --dtdvalid, which printed nothing and returned 0. The DTD knows the elements the page on project structure and modules describes (inherits, source, public, super-source, entry-point, set-property, set-configuration-property, add-linker, collapse-property and the others). It cannot know your own property names or module names, so a misspelt inherits name still reaches the compiler, which reports the missing module when it loads it.

Visual Studio Code with the Red Hat XML extension (0.29.2026100808 on 2026-10-09) lists DTD validation, completion and formatting among its features, and a setting (xml.downloadExternalResources.enabled, default true) that lets it download a referenced DTD. A module file with the DOCTYPE above is therefore the simplest way to get completion there; the extension’s documentation also describes binding a grammar to files without touching them. This was read from the extension’s README and not run.

Source: Red Hat — XML Language Support for VS Code

A *.ui.xml template is XML in two namespaces (urn:ui:com.google.gwt.uibinder for the ui: elements and urn:import:<package> for widgets), and GWT ships schemas that IDEs can use. The gwt-user-2.13.1.jar contains, under com/google/gwt/uibinder/resources/, UiBinder.xsd and com.google.gwt.user.client.ui.xsd (the schema for the urn:import:com.google.gwt.user.client.ui widgets), and xhtml.ent (the entity definitions that the template DOCTYPE refers to). The comments inside UiBinder.xsd are specific about its purpose: the schema is a temporary implementation detail, it is not meant for validation (it is not even a valid schema, in the author’s words, and its constraints regularly differ from the real parser’s), and it was written to give Eclipse autocompletion proposals, with required attributes marked so that completion can insert them.

Take that at face value. An IDE may offer completion for widget and attribute names from these schemas, but only the GWT compiler decides whether a template is valid: a template with {msg.title} and no <ui:with field="msg" .../> is accepted by an editor and rejected when the generator runs, with the no field named msg message that the UiBinder page lists. The named HTML entities ( ) are the one case where the template needs a DOCTYPE (<!DOCTYPE ui:UiBinder SYSTEM "http://dl.google.com/gwt/DTD/xhtml.ent">); the compiler resolves that file from the jar, and an IDE may try to download it.

Source: GWT 2.13.1 — UiBinder.xsd

The ui:field to @UiField connection, the @UiHandler references and the ui:style class names cross between XML and Java, and that cross-navigation is the kind of coding assistance a GWT-aware plugin provides. The GWT Eclipse Plugin lists a UiBinder editor, and the IntelliJ IDEA plugin’s description is generic ("coding assistance specific to GWT"). With neither plugin, or with VS Code, those links are text: build errors from the generator are the safety net, and the UiBinder page shows the messages.

The IDE checks Java against the full JRE. The GWT compiler checks client and shared code against the emulated one, so code that is correct to the IDE can be rejected by GWT. The standard demonstration is a client class that imports java.io.File:

Source: GWT — JRE Emulation

javac compiled this class without a message; the GWT compiler (-validateOnly) reported:

Source: GWT — Developer Guide: Compatibility

The IDE cannot know which source folders belong to the client, so it cannot warn you: the <source path="client" /> declaration in the module file is what turns a folder into "client code". The JRE emulation and shared code page lists what the emulation supports, and the compiler and compilation page shows how to run the compiler for validation only.