The GWT.create 2014 conference – Day 1 : The Opening Keynote

What is the GWT.create conference ?
GWT.create is a two-days GWT-only dedicated conference hosted by Vaadin and organized at San Francisco (USA) and Frankfurt am Main (Germany). Since the first version of GWT was released in 2006,  a very few Java and Google conferences dealt with GWT. In the 2014 edition, speakers from Google, Vaadin, Sencha, RedHat (etc.) have held a lot of conferences and workshops about the GWT ecosystem. This conference is a great opportunity to follow its latest news, to meet the GWT community and to exchange with others who live and breathe GWT. Thanks to Palo IT, I attended the 2014 Frankfurt edition.

The opening Keynote
After a short introduction given by Joonas Lehtinen from Vaadin, Ray Cromwell delivered his keynote. He works at Google and he is a member of GWT Steering Committee. He has contributed a lot to the compiler part. He dealt with the three following key points :

1. The state of the Community

Since GWT has been created, many fears appeared among the community. GWT was an internal framework of Google. Its evolution was fully dependent on Google products which made the test suits and other validation very long. In the meanwhile, there are more and more external active committers in GWT and its ecosystem development, as it is an open source project. So giving leadership to the community was the best choice. Ray Cromwell assured us that GWT was not abandoned by Google at all. It counts thousands of users inside Google, and many Google apps are based on GWT, like the brand new Google Sheet and Google Shopping Express’ ones which are not yet available.

2. The state of GWT

keynote2GWT will release the 2.6 version soon. The idea is to release one major version per year and several intermediate versions. The coming 2.6 version will integrate a full Java 7 support. It also will offer a better code splitter and other optimizers which might reduce the code size by about 10%. Ray also briefly dealt with the history of GWT, from its foundation in 2006. Since then, many things have changed:

  • JavaScript is much faster than before. The Kraken profiling shows that in Firefox and Chrome, it is about 2200% faster!
  • The browser’s multimedia, I/O, layout and rendering capabilities have improved.
  • Flash is not required anymore for functions suchs as video and camera.
  • The compatibility between the last versions of browsers is really good.
  • Mobile market’s influence is more and more growing :  now 50% of global Web traffic comes through mobile.

3. GWT 3.0 and beyond

GWT 3.0 has two keywords:

Lightweight Syntax
In 3.0, GWT will offer a full Java8 support, which means a lightweight syntax. The callback block might be obviously simplified. Ray Cromwell gave an example of the creation of a button. Today, the code should be like :

Button b = new Button(new ClickHandler(){

In the future, the code with Lambda might look like this:

Button b = new Button("Click me", (e) -> alert("Hello"));

This is even shorter than a JS code.

Lightweight Interop
GWT will also introduce the new concept of fast Interop with js without using JSNI. Two new annotations will be added:

@JsInterface and @JsProperty

Ray gave a code example for a JS library:

function MyClass(){
this.answer = 12;
MyClass.prototype.whatIsTheAnswer = function() {
return “The answer to life, the universe, and everything is …” + this.answer;

Here is the way this library is often used in GWT:

interface MyClass{
int getAnswer();
String whatIsTheAnswer();
final class MyClassImpl extends JavaScriptObject implements MyClass{
public native int getAnswer() /*-{
return this.answer;
public native String whatIsTheAnswer() /*-{
return this.whatIsTheAnswer();

With the help of JS Interface, the Java code becomes really easy:

interface MyClass {
int getAnswer():
String whatIsTheAnswer();


We can see that an efficient callback can make the Java code very shorter. But that is not all: we can expect an even easier way. The idea is just to take a JavaScript library third party, and then to drop it into the project, letting the framework generate the interfaces and use it directly (Zero work interop). Two live coding sessions about JS Interface have been given by Ray, showing the simplicity of development. As an “accident” occurred in the second coding, he invited the public to see Daniel’s session for more details.

With today’s GWT structure, there are limits on using external JS libraries:

  • JS libraries must be un-minified to have predictable symbols,
  • It lives in a separate execution context,
  • Dead or unused libraries from  the JS library third party are not removed. It means that if we only want to use one method of JQuery, we must accept that all the library will not be removed.

So the future radically better interop should be able to combine JS and Java in GWT structure, to type check between JS and JAVA, to optimize JS and Java codes together, and finally build one single optimized application. In fact, all of these technologies lead us to the Web Components. Ray gave a short introduction to them : basically, the Web components are native in a Web template. They allow developers to create customed and reusable HTML widgets. They offer a safe way to use a third party widget by encapsulating the Dom and CSS, so that user does not need to worry about the effect that it could do to the other part of the application. Ray also mentioned that the Web components are a part of parcel in the prospect of GWT. According to him, it will be the future of the Web technologies. Thus, the Community wants to be ready for its coming.

Code Splittering
While the number of applications that aim at mobile phone and tablet increases, code splitting becomes a unignorable part in the development. Although CodeSplitter does allow reducing the initial download size, shared code (leftover fragment) may inhibit this benefit. Even if the splitted part is small, we can always have a large share lib which makes the code splitting finished without gain. Another problem today is that we don’t have any control of in which files will the splitted code be. The next generation of CodeSplitter tries to resolve these problems:

  • Force choice of a split point will be possible
  • Splitted codes which are “too small” will be automatically merged.
  • Multiple share codes between parts of the split points avoids one large leftover fragment.

Improvements of several fields are going on:

  • Array: Experience of profiling showed that creation of array in JavaScript is really slow. GWT tries to move to typed array which is much faster and is supported by most of the latest browsers.
  • CodeGen: Many optimizations to improve the code generation will be done, such as tune JS output for morden JS VMs, generate smaller js codes.
  • Layout: Actually, most of the layout works are done by JavaScript which slows the browser a lot. GWT should try to make the layout done natively by browsers. CSS3 support is an important point as well.
  • Compilation: Incremental compilation will be used to increase compilation speed. That means in drap compile mode, only changed files will be recompiled instead of recompile the whole project like today. For the production compile, split code for local and global purpose makes local splits possible to be compiled in parallel and optimize the compile time.

SuperDev mode
As we are losing Dev mode, SuperDev mode need to be improved. It need to be faster at refreshing, better at debugging, and maybe have IDE integration. Ray announced that GWT 3.0 is tentatively scheduled for middle of 2014. He also reminded even though many wishing are made, not everything will be ready for 3.0. He invited everyone to get involved and contribute.

To conclude
The first day of the GWT Create conference was dedicated to GWT itself. Lots of future features in GWT 3.0 were presented. For further information about the others sessions, please read the related articles on the Palo IT Blog.




  1. Mark Sasler Says: September 6, 2014 at 7:11 am

    There is an alternative tool similar to GWT called Dragome. But this one is about compiling bytecode to js, and it also has UI components support. Things like Incremental compiling, Java 8, HTML template are already supported.
    And there is no need to wait to ECMAScript 6 to be standardized because it already allows use of dynamic proxies continuation (js yield), classes, lambda (arrow functions).

    Project URL:

Leave a Reply

Your email address will not be published. Required fields are marked *