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.

GWT turns Java into beautiful JavaScript, HTML, and CSS code.

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.

GWTcon 2015 in Florence, Italy

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.

GWT is great for building powerful, large-scale web applications.

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.

JavaScript front-ends with the power of Java apps? Yes, you too can have it all, with GWT!

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. 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.

GWT transpilation of Java source code to JavaScript source code using abstract syntax trees.

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.

About the author

Alberto Mancini, Italy
member since August 5, 2014
Alberto is a full-stack developer with over 20 years’ experience. He started coding while studying for his PhD and moved on to web-related technologies from there. He has been described as very competent and consistent in his programming, and is an excellent communicator. [click to continue...]
Hiring? Meet the Top 10 Freelance Front-End Developers for Hire in December 2016

Comments

brianm101
Only comment is - It sounds too good to be true! Must try it :) Be nice if something similar was available for C++ as well (?)
Robert
To each their own, I guess, but my opinion is if you have to ask, Is [some web technology] still useful, then it probably isn't. I've been maintaining a legacy GWT application for about a year, and I hate it. Back in the days when there weren't good javascript unit testing frameworks, and no great solutions for browser incompatibility issues, GWT may have been a godsend. Those days are long gone.
Lautaro Brasseur
You still have a lot of advantages when using GWT. For instance, strong typing detects some errors on compile-time, so you don't need unit tests for those scenarios. Code reuse is another good thing. You can reuse Java code on GWT, server-side Java or Android. You can even reuse it on iOS using RoboVM.
Lautaro Brasseur
There is something similar, but for Java to Objective C: * http://j2objc.org/docs/index.html * https://github.com/google/j2objc It has a similar approach to GWT. You can even put native code, pretty much like JSNI. To convert from C/C++ to JavaScript, you can use emscripten: * https://github.com/kripken/emscripten which compiles from LLVM to JavaScript.
brianm101
Thanks
Lautaro Brasseur
Welcome :)
Alberto Mancini
Glad you like GWT :) As Lautaro says there are some similar tools. J2OBJC is also used jointly with GWT for google inbox; it worth a try. https://drive.google.com/file/d/0B3ktS-w9vr8IS2ZwQkw3WVRVeXc/view
Alberto Mancini
Well, it depends IMHO, when used in the right way GWT let you get the best of both worlds. You can even compile the java part of your application (where, for instance, static typing or core reuse is important) and then use your preferred js-framework where (an if) it fits better for your application.
Hinotori
thanks alberto, good post
Oscar Marquez
GWT can be used for Native Mobile? I know that Facebook developed React Native, an idea I get is that it would be possible to build Native Mobile UI using GWT with React Native.
metelesku33
gwt is dead
Alberto Mancini
Hello, If you do not want to stay 'HTML5ish' you have some options. You can use Titanium4j that is , well, Appcelerator's Titanium for GWT or you may follow the same path that Google uses for Inbox: http://gmailblog.blogspot.it/2014/11/going-under-hood-of-inbox.html and https://drive.google.com/file/d/0B3ktS-w9vr8IS2ZwQkw3WVRVeXc/view
Alberto Mancini
Sure, if you are satisfied at client side with Spring you can use together. Look at Errai too, may fit for you.
Alberto Mancini
lol
Vladimir Bystrov
GWT is undead :) The walking dead :)
david Forneron
Excellent post. In my opinion, people should try to use the proper language with the proper frameworks, and not use wrappers like this all the time, you are limited, and extra complexity is added. Java developers should try to learn JS.
James Nelson
Very nice. You can also use projects like PlayN if you want games/graphics https://github.com/playn/playn , or as in the articles Alberto linked to, you can use J2ObjC to get iOS, Android is java already, and Gwt for web, and you get code reuse across all platforms... The only "native" bits you would write would be to talk to whatever UI frontend you want. Even if you have a UI framework that will target all layers, having an application framework to do the same for your business logic is priceless.
Alberto Mancini
Hello, i completely agree that web developers need to learn the platform (not just js though but at least html and css are part of the picture). On the other hand I cannot follow you on the meaning of 'wrapper'. GWT is a wrapper as much as a C compiler is a wrapper around assembler: they have different application area but both of them have their meaning and both can be used the right way or terribly wrong.
Yuriy Nakonechnyy
"The GWT Project is expected to release version 2.8 soon, and version 3.0 is in development" - this sounds really awesome, can't wait to switch my projects to 2.8.0-rc version and convert everything to lambdas :)
vitaly goji
Love GWT! Just don't tell them too much about GWT. We don't want competition to learn GWT. Let them write with JavaScript:)))
vitaly goji
Java on a server side is good for corporate managers to divert revenue from shareholders. Developers don't want JVM on a web server when they do their own projects. Spring =Legacy=Corruption
vitaly goji
Use JavaScript on large projects instead of GWT:))) Good luck!!)))))))) What a blissful militant ignorance.. Sometimes I wish to be 15 years old and naive..
vitaly goji
GWT is too hard on a simple brain. Avoid it at any cost. Use JQuery instead.
vitaly goji
If you have access to the cash cows go with a Spring and let them hire large team for you to support it. Don't forget to put it under JBoss cluster, develop schedule to restart JVMs and beat/intimidate Indian developers into submission. That will make you a hero with big wallet bozos. Problem with let's say PHP is that now one knows that it is running on your servers. It just works. No shutdowns, no emergencies..Boring life..
vitaly goji
In my humble view the only good thing which came out of Java world is a GWT. Most of other Java stuff is good to bring a paycheck home and that's about it. After 20 years core Java still does not even have string methods needed by developers. Who wants to use Java collections after you tried PHP arrays? For the most part Java, excuse my language, is a sh*t. Anyway, LONG LIVE GWT!!
Gopal Allu
Any one familiar with Bhalu library comprising simple reusable Java classes for presenting over 100 GUI components. Using the reusable Java class form the Bhalu library is not much different from any other reusable Java class. It is highly flexible, because you can add your own custom GUI components. Also looks like highly saleable, while very light weight (since all the code stays at server). Each reusable Java class generates very optimal SVG/JavaScript code. Because the code stays at server, the size of the library is irrelevant, so they claim, they can support a dozen reusable Java classes, for example, to present a dozen different data-grids. Web site pioneer-soft.com However Bhalu library don’t support reusable Java classes for HTML elements such as Label, Text or Check-boxes because, they feel, there is no need for replacing two-lines of simple open HTML-code by 5 lines of more complex Java code, which is proprietary to respective frameworks such as Vaadin or ZK. Their goal is one-line of simple Java code should generate at least hundred lines of complex X3D/SVG and JavaScript code. Their goal is to help even Junior Java developers to create more complex GUI applications than practical for senior JavaScript developers.
Eric Nissan
I've been using GWT for years. As a developer, it allows me to concentrate on 1 language (Java) while allowing me to create fully immersive web applications. That being said I can pull in any Javascript library I need and easily integrate it. As a development manager, I am able to hire more core Java developers, and create the same quality UI's as if I had a dedicated team of javascript developers. Great Article. To each his own, but, for many reasons detailed here (and there are more actually), it is the premier programming framework.
comments powered by Disqus
Subscribe
The #1 Blog for Engineers
Get the latest content first.
No spam. Just great engineering and design posts.
The #1 Blog for Engineers
Get the latest content first.
Thank you for subscribing!
You can edit your subscription preferences here.
Trending articles
Relevant technologies
About the author
Alberto Mancini
C Developer
Alberto is a full-stack developer with over 20 years’ experience. He started coding while studying for his PhD and moved on to web-related technologies from there. He has been described as very competent and consistent in his programming, and is an excellent communicator.