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.
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.
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.
The GWT Project is expected to release version 2.8 soon, and version 3.0 is in development, with great improvements in the works:
- improved (almost totally rewritten) compiler
- state of the art Java support (e.g. lambdas)
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.
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.
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:
- 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.
long integer type, so
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 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.io.Filecannot 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 (
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.
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.
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.
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.
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.
Located in Florence, Metropolitan City of Florence, Italy
Member since September 29, 2014
About the author
Dr Alberto spent 20 years working as a researcher in Applied Math & is experienced in managing large computational infrastructures.