GWT 2016 (English version)

What happened in 2015/2016 for GWT ?

Arnaud Tournier, le 10-04-2016

GWT in 2016

Until the release of the 2.8 version, let’s do a retrospective and look what happens in the past year. A little refreshment is needed. 2015 has not been the GWT 3 release year nor the 2.8’s. Nevertheless the fact remains that the team worked hard and that the community is still active.

Many questions arise for developers and project managers on the direction to be taken to continue using this tool and the ecosystem (the Web) in which produced code runs (HTML / CSS / JS browser or even Node JS, why not ?).

What happened in 2015 ?

Technical changes

Note that the beta version of GWT 2.8 is available on maven central , using the 2.8.0-beta1.

First here are the technical improvements that have been developed. These were presented during the GWTCon 2015 keynote, a conference especially dedicated to GWT which was held in Florence (Italy) for the second consecutive year. A kind of GWT.create organized by the user community.

  • GSS: The replacement of ClientBundle (CssBundle) is now stable (at Google, all the GWT applications were migrated to GSS). The old implementation CssBundle will be deleted right after the release of GWT 2.8. Contrary to what was initially planned, GSS will not be used by default in version 2.8, so as not to block the migration to GWT 2.8. GSS produces much better optimizations than CssBundle, so there is an obvious interest at migrating to it (although in my humble opinion, i prefer to use tools like HexaCss which I find much more flexible).

  • New features have been added to GSS: including the loop for the function concat(), annotation @gen-webkit-keyframes to optimize the generation of CSS keyframe animation.

  • Compilation time: the SuperDevMode is 6x faster than GWT 2.7. For example, compiling Inbox took 30 seconds with GWT 2.7, the time was reduced to 3 seconds with the 2.8 version. 100% of GWT applications at Google use SuperDevMode with incremental compilation. The production compilation has also been improved with the introduction of a new optimization: during GWT compiler optimization phase, only the code that has changed is re-analyzed to find possible new optimizations. This gave a 20% gain on compile time on large applications at Google.

  • JsInterop: the initial specifications were revised and simplified for a more seamless integration with JavaScript. These new specs have been fully implemented in GWT 2.8, are no longer experimental and are enabled by default. Check the thorough presentation of JsInterop at GWTCon 2015. And now that many people are beginning to use it, some interesting discussions will appear for the newcomer. Since JsInterop will be a cornerstone of GWT, it is strongly recommended to understand its operations.

  • Java 8 support : syntax is fully supported (lambdas, reference methods, default methods, …). For JRE emulation, only some parts will be implemented as @FunctionalInterface, Optional and more importantly, the streams will be delivered with official 2.8.

  • Integration IDE (Eclipse): Brandon Donelson is now responsible for the maintenance of the GWT part of the Google plugin for Eclipse.

  • Using Source Maps: The generation of source map files is very important to ensure minimal debugging experience, both on a browser with SDBG. The Chrome Dev Tools team has incorporated many improvements and Java debugging in Chrome has been greatly improved.

  • Web Components: nothing on this side. The gwt team waits for the official release of Web components and their support in Ecma script. The problem is that the specification does not progress much - and it does not give very incredible value over the usual encapsulated object model in GWT (Widgets).

  • Performance: Operations on HashMaps are 2.8 times faster, Long divisions are five times faster. Double and Boolean are no longer boxed, which brings a good performance gain.

  • It may be noted also the possibility to access the GWT compiler properties in the standard Java way, ie System.getProperty("") . The property “” can be defined in a define-propertynode of the gwt module.

Next releases

GWT 2.8 release was announced for mid-December at the GWTCon conference in Florence November 11, 2015. The deadlines have not been held since version 2.8-beta1 is still opened and receives final patches in number proportional to the amount of issues reported by the beta testers… So please do not hesitate to test this version, to check compatibility with your code and especially to report anomalies.

GWTCon 2015 Conference

This conference was held in Firenze (Italy) on 11 November 2015. A day dedicated to GWT. Members of the steering commitee were almost all represented, with Julien Dramaix for Google.

Here are the sessions I attended, there were often two conferences simultaneously. Check the website to see videos and slides.

Here is a video of GWT Con, which has its own channel on YouTube:


Many people ask what happened with this framework … Singular is a project that had been presented and even announced at GWT.create 2014, aimed at cross-compiling a Java code base to both the browser and mobile platforms. All this with the generation of native code on Android and iPhone and a programming style à la Angular - without performance problems because the data bindings are resolved at compile time and do not use dirty-checking to operate. In short, a very attractive project.

A demonstration was conducted by Daniel Kurka and the upcoming release of a beta current 2015 was announced. But it has not happened! Silence…

And the community seems to wait for it, well at least waited for it. As you can check, the project-related mailing lists are now very inactive - when this is not a message from a person who asks what is happening.

Julien Dramaix clarified the situation at the conference: Singular is indeed on stand-by, at least the time needed to assemble the first version of Jackal (the future GWT compiler 3, see below) which is the number one priority for Google.

So there is nothing to expect on that side for the moment … Nevertheless the project is not necessarily dead so far. In short, those who were impatient to use it to their next application: it’s not for now.

Roadmap for 2016 and beyond

GWT is pulling a lot of burdens. This tool has indeed more than ten years and the architectural decisions made at the design time are no longer necessarily ideal.

In reality GWT actually does too much: permutations, code generation, optimizations, the SuperDevMode server with source files monitoring, logic libraries (widgets, rpc, UiBinder, …), etc.

GWT is loved for the level of performance it provides, and on the other hand he is hated for the slow compilation and therefore has some disadvantages compared with the use of vanilla Javascript.

Google has decided to (re) develop a Java-to-Javascript compiler. Its name is J2CL which is pronounced Jackal, like the animal. This compiler will issue ES6 code featuring jsdoc Closure annotations that will enable the Google Closure Compiler to handle the optimization part.

This compiler will target modern Javascript engines. It will be extremely fast and fully integrated with the Closure Compiler.

What on the other side will not be Jackal :

  • will not be an optimisation engine nor a linker (closure takes this role),
  • will not be dependency injection tool (eg use dagger2)
  • will not have a specific mechanism of code generation (use the standard Java JSR 269 instead)
  • is not a web UI framework. Actually J2CL will not even be designed around the DOM.

The roadmap is not yet fully defined but J2Cl advances quickly. It will be open sourced later, when the first prototypes will have been confronted with internal Google needs.

Note that for example, Julien Dramaix is currently working on integrating this compiler with libraries definition “Definitely Typed” (from typescript), a kind of Elemental to incorporate thousands of existing javascript libraries. This will make integration with existing Javascript libraries trivial.

Meanwhile, GWT is now a mature tool. Version 2.8 will LTR (Long Time Release). There will be more changes, but only fixing bugs.

For GWT 3, the future is not yet decided. J2CL will certainly be independent from GWT. At the same time, nothing will prevent it to be integrated with GWT in the future. Google leaves that decision to the steering committee.

In short, everything is done for GWT remains a competitive product for the next ten years !

Where is GWT going ?

So that’s about it for the “official” information. Let us try to anticipate trends and guess what form will this project take in the coming years.

First, one can notice that programming in Java is still relevant (see TIOBE ranking last year). This is especially true for teams that also use Java on the backend (JEE server, for example), where having the same language on client and server can even have a social impact - developers are using the same language and have a common vocabulary and environment.

Producing rich applications (we do not speak of “to-do list” or form applications, but industrial applications) in the browser still has an interest, obviously. Both in terms of deployment, compatibility (the web runs on PC, Mac, Linux, Smartphones …) and in terms of technical scope offered by the platform (WebGL, access to gps, local storage, webcam, etc.).

Despite these still relevant points, some technical paradigms have evolved over the last ten years:

  • modern browsers are now more standard and compatible, and we no longer need to have the homogenization layer that GWT gives (for another example, the interest of JQuery is no longer the integration of different browsers but a simplified presentation their API). The technical scope achieved without using compatibility layer is now wide enough for most applications. The web platform has become a de facto virtual machine (HTML5 rich APIs), and provided we do it in a good way, an application is able to run on both Mac, Windows, Linux, tablets and smartphones.
  • the ecosystem of the web platform (javascript, css, html) is extremely rich and active (libraries, frameworks, languages). We need an efficient and flexible interoperability. The developer of an application must be able to choose from the countless libraries available on the Web platform.

It is therefore natural that the place and role of technologies like GWT evolve too.

And this movement is accompanied by the announced removal of a large part of the foundations of GWT today.

So where do we go ?

How then anticipate a gradual migration (consistent with the future development of GWT which is not yet fully defined, if not uncertain) when we have a big code base to maintain? What are the challenges? Of course the goal is often not to stagnate on version 2.8 but to follow the development of the tool, as it provides new interresting features. In this spirit, we can see GWT 2.8 as a transitional version, to prepare ourselves for the future.

What will disappear

Let’s examine the parts of GWT doomed to extinction: generators, Widgets, GWT-RPC, UiBinder …

First, the generators can be migrated to the JSR-269. This represents a cost, and sometimes trade-offs, but it remains in the domain of the feasible. As for the other parts, let’s examine them one by one:


It is quite possible to migrate to another RPC layer. Indeed, the functional scope of GWT-RPC is relatively small (it generally boils down to generating stubs and proxy and takes the form of Java interfaces). Migration to the JSR-269 should be possible, dosing with carefully relationship between migration cost and complexity of the solution to mimic the exact GWT-RPC behavior.


There, the integration between the tool and the application code is much stronger, and the object oriented approach they provide is still helpful. Indeed, a GWT application often contains many classes that inherit or use Composite, ComplexPanel or other Widget. All these classes are based on the GWT widgets system which will disappear soon.

Two choices will certainly be possible: gradual transition to presentation tools such as Angular (with JsInterop, Elemental and future automatic imports from definitely typed, integration of a presentation framework should easy enough), or to continue to develop the presentation layer in vanilla GWT, or by relying on libraries (which might manage the migration for you). Others who rely on libraries like GXT will have to wait for decisions taken by these tools.

What is the value of Widgets? An object-oriented view of the hierarchy of the DOM and therefore encapsulation for the DOM, some syntactic sugar, as well as a special management of events. Indeed, created at the time when browsers differed greatly in this respect, GWT provides a unified overlay to the native event management made by browsers. This overlay has now become entirely obsolete with the standardization of browsers.

The added value of Widgets hence is encapsulation and the object oriented approach (for those who love it). To be able to give a code localized in a class the responsibility for a part of the DOM hierarchy is very useful. The value of this may disappear with the domination of web-components, but for now the Web Components is does not bring much more to the practices of GWT developers (CSS encapsulation, object oriented development on the DOM) … The object oriented vision that provides the Widget system makes it very modular programming and assembly of heterogeneous software components easy.

On the other hand, a number of classes are becoming unnecessary as more and more functionalities are handled by the platform. For example, the class TextBox to manage a single <input/> element. The behavior of this tag is standard and advanced enough to rely on the native tag.

From all this, we can draw that to maintain an application one will have to make old Widgets and DOM elements interoperate (in both ways). And it will have to be efficient, fast and easy. Why not imagine writing a manipulation library of object-oriented DOM, x% compatible with Widgets, and based on JsInterop. This would provide both an integration layer and migration, and programming for the DOM object.

In terms of Widgets and managing DOM therefore, it is clear that the number of possibilities grows a lot ! Everyone will be able to choose its client application stack. And it is this question that will arise when creating new projects: what combination to choose? All in Java? Java + JS? Java + Typescript? Java + Coffee + C# + …? GWT-CSS or PostCSS, Less, SaSS? GWT + Angular, GWT + Meteor, GWT + + Redux React, React + GWT + Flux, …?


Regarding UiBinder, the problem is twofold: it is based on GWT generators and the Widgets. The generator part can also be worn to the JSR-269. As for the Widget part, it falls to the problem raised above. Migration therefore has a cost.

Compétences Web

The GWT Java Developer will have certainly to increase his skills Javascript / CSS / HTML in some ways because GWT hid this world which is now revealed more. And the evolution of GWT will have people get more in touch with Javascript (and I think that’s very good, too many people ust think they can forget about the execution platform when using GWT).


In summary changes are afoot for the tool and the developer’s habits. Today a GWT project is pretty standard (JEE backend, Widgets, RPC). But tomorrow nothing will prevent to integrate Java development with some Coffee (!), Typecript, d3.js and web UI components developed with dart. The build can be managed by gulp, development is done with Atom, WebStorm or VS Code. In a today GWT application, GWT is very central (all the code is written in Java for GWT and usually there is not much of JSNI). This might change and GWT will more and more integrate with other Web technologies.

And such applications gravity center should descend to Web standards, which allow you to use Java for specific components (complex UIs, complex business rules, structured processing, reuse server-side code, etc.) and Javascript for others (benefitting of the ease and speed of writing). It will no longer be GWT that integrates the Web, but the Web that incorporates GWT. This is a remarkable and very important change in the evolution of this tool. Hence my heart recommendation to GWT developers: familiarize yourself with the Web platform: Javascript / HTML / CSS!

GWT can also find its place in the mobile development where the issue is in the compilation to native targets such as mobile devices and perhaps even then the IOT: Java as a language, javac, GWT, Android SDK and J2ObjC as compiler to the Java platform, Web, Android and iOs. Inbox has in any case proved this model.

In short, the world is changing and GWT takes a major turn to ensure his place. Opening to standards is the spirit, and two keywords drive the GWT future : integration and performance.

Information collected by different sources: GWT Con 2015, websites, code …

Arnaud Tournier, le 10-04-2016