The GWT Toolkit: Build Powerful JavaScript Front Ends Using Java

The GWT Web Toolkit, formerly known as Google Web Toolkit, is a set of development tools for building and optimizing complex browser-based applications using the Java programming language.

What makes GWT not “yet another Java tool to write web apps,” is the fact that the heart of the toolkit is a compiler that converts Java into JavaScript (as well as HTML and CSS), enabling developers to write front-end web applications while leveraging all of Java’s strengths.

It’s even easy to use a mix of Java and JavaScript, as GWT includes a robust interoperability architecture for interfacing with the web platform. Much like the Java Native Interface (JNI) allows the Java Virtual Machine (JVM) to call platform-specific routines (for example, to access specific hardware features, or use external libraries from other languages), GWT allows us to write most of an application in Java and then, if necessary to use a specific web API, or, leverage existing JavaScript libraries, to “go native” and jump into JavaScript.

GWT was born as a Google product but graduated to open source in late 2011 and is nowadays released under Apache License (Version 2) under the name GWT Open Source Project. It is managed by a steering committee with representatives from several companies, including Google, RedHat, ArcBees, Vaadin, and Sencha, as well as independent developers from the community.

GWT in the Past and in the Future

The Google Web Toolkit was first released in 2006. It was created as a tool to help Google engineers develop their complex browser-based applications, such as AdWords, Google Wallet and Google Flights, and, more recently, is being used at the heart of Google Sheets and Inbox applications.

Back in 2006, browsers (and JavaScript interpreters) were far from standardized. Front-end code was slow, buggy and hard to use reliably. There was an almost total lack of high quality libraries and frameworks for web development. For instance, jQuery did not even exist until this year. So, to be able to develop large-scale web applications, the engineers at Google decided to leverage existing tools and competencies. Java was the best-suited language for their needs, being well known and perfectly integrated into IDEs, such as Eclipse, and so the Google Web Toolkit began its life.

The goal was more or less to hide the differences between browsers, and encapsulate the tricks needed to write efficient JavaScript inside a Java compiler, leaving the developers free from the tyranny of browser technicalities.

Of course, over the last decade, the web has changed; browsers have become faster and have converged on implementation standards, and a lot of awesome front-end frameworks and libraries have been developed, including jQuery, Angular, Polymer, and React. So the first question you might naturally ask is, “Is GWT still useful?”

In a word: Yes.

In the context of modern web development, targeting browsers is unavoidable and JavaScript has become the lingua franca of front-end applications. But of course, different tools and languages are better-suited to different tasks. GWT, along with a handful of similar projects aim to target browsers without confining developers to using JavaScript.

The development and employment of “compile-to-the-web” tools like GWT will, in the near future, be facilitated by the so called WebAssembly group of the World Wide Web Consortium. There is not only a vast space for tools that compile to JavaScript, but this approach may fill a real need in contexts that range from offloading part of computation to browsers, reusing existing code and libraries, sharing code between back-end and front-end, employing existing competences and workflows and leveraging features of different languages (for example, static typing in the case of GWT).

The GWT Project is expected to release version 2.8 soon, and version 3.0 is in development, with great improvements in the works:

• reinvented interoperability with JavaScript
• improved (almost totally rewritten) compiler
• state of the art Java support (e.g. lambdas)

Actually, most, of the features of GWT 3.0 are already available on the public Git repository. Just check out the trunk, here and compile GWT following the documentation here.

The GWT Community

Since GWT went open source in 2011, the community has assumed a pivotal role in the evolution of the project.

All development happens on the Git repository hosted on gwt.googlesource.com, and all the code reviews are done on gwt-review.googlesource.com. On these pages, anyone interested in the development of the Toolkit may contribute and see what the community is working on. During the last few years, the percentage of new patches from non-Googlers has risen from about 5 percent in 2012, to about 25 percent in the last year, confirming the growing involvement.

This year, the community has come together for a few big meetings in the U.S. and Europe. GWT.create, organized by Vaadin, was held in both Munich, Germany and Mountain View, Calif. in January, and counted more than 600 participants from dozens of countries. On November 11th, in Florence, Italy, we will hold the second edition of GWTcon, a community driven GWT conference which I am helping to organize.

What is GWT Suited For?

A yearly survey on the GWT toolkit, released by Vaadin, discusses GWT’s development evolution, how the developers feel about the toolkit, the good, the bad, and so on. This survey also lets us understand what the Toolkit is being used for, how the community of users is changing, and the expectations that developers have for the future of the toolkit.

The Future of GWT Report for 2015 can be found here, and it makes it clear that GWT is very popular for building large-scale web applications. For example, on page 14, it states, “Most applications are business applications that are data heavy and are worked with for many hours per day.”

As expected, it is easy to conclude that the natural environment for GWT is the field of large-scale web applications, where maintainability of the code is important, and large teams benefit from the structure of the Java language.

On the other hand, looking at the benchmarks for code generated by GWT (for example, in the keynote of last year’s GWT.create conference, on pages 7, 8, and 11) it is easy to see that, in terms of performance and code size, the compiled JavaScript is stunningly awesome. If used correctly, the performance obtained is comparable to the best hand-written JavaScript. As a result, it is actually feasible to employ GWT to port Java libraries to the web.

This illuminates another ideal scenario for GWT. The Java ecosystem is full of high-quality libraries that have no ready-to-use counterpart in JavaScript. The GWT compiler can be used to adapt such libraries for the web. In other words, GWT lets us mix libraries available in both Java and JavaScript, and run them in the browser.

This approach can be seen in the development of PicShare, where we show how several Java libraries not generally considered for the web (NyARToolkit for instance) can be ported to the browser using GWT, and combined with web APIs, including WebRTC and WebGL, to obtain a completely web-based Augmented Reality tool. I was proud to present PicShare at the 2015 GWT.create conference last January.

Under the Hood: Turning Java into JavaScript

The GWT Toolkit is a moderately complex set of tools, but anyone can start to use it in a jiffy, thanks to a surprisingly easy-to-use integration with Eclipse.

Creating a simple application with GWT is relatively easy for anyone with a background in Java development projects. But to understand what’s “really happening,” it’s worth analyzing the principal components of the toolkit:

• Java to JavaScript Transpiler
• Emulated Java Runtime Environment
• Interoperability Layer

GWT’s Optimizing Compiler

An in-depth description of how the compiler works becomes highly technical quite early, and we don’t need to dig that deep, but some of the general concepts are worth looking at.

The first thing to understand is that GWT compiles Java into JavaScript by translation at the source code level. That is, the Java source is translated (transpiled is the technical term) into JavaScript. This is in contrast to having some sort of Java Virtual Machine written in JavaScript, that executes Java bytecode. (This is actually possible, and is the approach used by Doppio, but it is not how GWT works.)

Instead, the Java code is broken down into an abstract syntax tree (AST) representing the syntactic elements of the code. It is then mapped to an equivalent (and optimized) Javascript AST, which is finally converted back to actual JavaScript code.

Weighing the pros and cons of transpilation is far from the object of this post, but let me observe that with this method, GWT can directly leverage the garbage collection services of the JavaScript interpreter, along with any other features native to the browser.

There are some tricky parts, of course. For instance, JavaScript has only one numeric type, which cannot contain Java’s 64-bit long integer type, so long types require some special treatment by the compiler. In addition, Java static typing has no direct meaning in JavaScript, so special care must be taken to keep, for instance, typecasting operations equivalent after the transpilation.

On the other hand, an easily appreciated advantage of transpilation is that GWT can perform optimizations (for both size and performance) at the Java level and at the JavaScript level. The resulting standard JavaScript code can even be further processed in your deployment pipeline. For example, a common practice that has now been integrated into the standard GWT distribution involves optimizing the JavaScript output by the transpiler using the highly-specialized JavaScript-to-JavaScript Closure Compiler (another gift from the Google gods).

The most in-depth description of the GWT compiler that I know of can be found in this slide deck, and the original talk that it comes from. Here, you can find details about other cool features of the compilation process, such as GWT’s ability to do code splitting, generating multiple separate script files to be loaded independently by the browser.

The Emulated JRE

The Java-to-JavaScript compiler would be little more than a novelty if not supplemented by an implementation of the Java Runtime Environment (JRE), which provides the core libraries relied upon by almost any Java application. Roughly speaking, working in Java without, for instance, Collections, or String methods, would be frustrating, and of course, porting these libraries is a titanic job. GWT fills this hole with the so called Emulated JRE.

The Emulated JRE is by no means a full re-implementation of the Java JRE, but is rather a sort of selection of classes and methods that can be useful (and usable) client-side. The functionalities that are in the Java JRE but which you will not find inside the Emulated JRE fall into three categories:

• Things that cannot be ported client-side. For instance, java.lang.Thread or java.io.File cannot be implemented in a browser with the same semantics of Java. The browser page is single-threaded and has no direct access to the filesystem.

• Things that could be implemented but that would “cost too much” in terms of code size, performance, or dependencies, and which the community thus prefers not to have inside GWT. Included in this category, for instance, is Java reflection (java.lang.reflect) which would require the transpiler to keep class information for each type, and that would cause the size of the compiled JavaScript to balloon.

• Things nobody had interest in and therefore have not been implemented.

If it happens that the Emulated JRE does not fit your needs (e.g., you need some class that is not provided), GWT allows you to write your own implementation. This powerful mechanism, available through the tag <super-source>, makes it possible to circumvent problems when adapting new external libraries that use parts of the JRE not emulated.

It may be overly complex, or even impossible, to provide a full implementation of some parts of the JRE, so for specific tasks your own implementations may not strictly follow the semantics of Java’s JRE, even though they work in your specific case. Indeed, if you are considering giving your classes back to the project, remember that it is of paramount importance for the Emulated JRE that each class included follows the very same semantics of the original Java JRE. This ensures that anyone can recompile Java code into JavaScript and trust that they will get the expected results. Always make sure your code is thoroughly tested before giving it back to the community.

Interoperability Layer

To be an effective tool for production of real-world web applications, GWT must allow developers to interact easily with the underlying platform. That is, the browser and the DOM.

From the very beginning, GWT was built to support such an interaction through the JavaScript Native Interface (JSNI), which makes accessing in-browser APIs a breeze. For instance, using syntax features unique to the GWT compiler, you can write the following Java code:

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

and you are free to implement the body of the method in JavaScript. You can even wrap JavaScript objects in a JavaScriptObject (JSO) and make it accessible in your Java code.

An example of where this layer comes into play can be found in the context of UI composition. Mainstream Java has always used the standard Widgets toolkit to build UI elements, leveraging the Java Native Interface to access the underlying operating system’s windowing and input systems. GWT’s interoperability layer does the same thing, so that traditional Widgets work seamlessly within the browser. The only difference is that, in this case, the underlying system is the browser and DOM.

However, native front-end frameworks have rapidly improved in recent years, and nowadays offer significant advantages over GWT’s Widgets. As these frameworks have grown in sophistication, attempts to implement them in the JSNI have exposed shortcomings in the interoperability layer’s architecture. Starting with version 2.7, GWT introduced JsInterop, a new approach based on Java annotations, which allows you to quickly and easily integrate your GWT classes with JavaScript. It is no longer necessary to write JSNI methods or JSO classes. Instead, you can simply use annotations such as @JSType or @JSProperty, allowing you to work with native JavaScript classes as if they were Java.

The full specification of JsInterop is still in progress, and the latest updates can only be tried out by compiling the source from the GWT repository. But it is already clear that this is this the new direction that will allow GWT to keep up with evolving web platforms.

One ongoing project taking advantage of JsInterop is the recently released gwt-polymer-elements, which makes all the Iron and Paper elements from Polymer available to GWT. What is interesting in this library is that the developers do not need to generate the Java API by hand. The project uses gwt-api-generator to generate most of the interfaces directly by parsing the Polymer library and the JSDoc annotations. This makes it easy to keep the bindings up to date.

Final Words

With the improvements to the compiler, the interoperability layer, and the performance and size of the generated code over the last two years, it’s clear that GWT is not just “another web development tool,” but on track to become a major reference toolkit for the development of large-scale, complex web applications, and could even be an excellent choice for making simpler apps awesome.

I use GWT daily in my work as a developer and consultant, but mostly I love GWT because it lets me push the limits of browser capabilities and show that modern web applications can be as powerful as desktop applications.

The GWT Project’s community is really active, and new libraries, projects, and applications based on GWT are constantly being proposed. In Florence, the community-driven GWTcon2015 will meet on November 11th. If you are in the region, I hope you will come and meet some of the core developers, and learn about all the opportunities to be part of the evolution of this amazing toolkit.