GWT:The Road To 1.5, Part 1

The next version of Google Web Toolkit is almost upon us, GWT 1.5, but don't take the minor version bump as an indication of how much it's improved, GWT 1.5 has so many awesome improvements, it would be more proper to call it GWT 2.0. That's one reason why it's been almost a year since the last release.

To celebrate the release, I will be writing a series of brief articles on each of the many improvements of 1.5, hopefully with sample code demonstrations.

Zero Overhead Javascript Interop
One of the cool things about GWT has always been the JSNI concept, or 'Javascript Native Interface', that neatly parallels JNI in ordinary Java, except the 'native' implementation is Javascript.

One of the most common uses of JSNI is to produce wrappers for third party Javascript libraries like Scriptaculous, Dojo, ExtJS, etc. Unfortunately, these wrappers are somewhat expensive prior to 1.5

Common Wrap Patterns
There are two common ways people wrap third party Javascript libraries: Encapsulation of JavaScriptObject ('JSO'), or extension of JavaScriptObject. Prior to 1.5, subclassing of JSO worked, but was not officially supported.

Regardless of which technique is chosen, the wrappers work by providing access to Javascript object properties via JSNI getters and setters, and methods via JSNI methods that delegate to Javascript methods.

Unfortunately, delegation getter methods or other instance methods, were not optimized away or inlined by the GWT compiler. Let's look at an example.

public class TestWrapperEncapsulation {
    private final JavaScriptObject jso;
    public TestWrapperEncapsulation(JavaScriptObject jso) {
        this.jso = jso;
    }
    public native String getFoo() /*-{
      return this.@TestWrapperEncapsulation::jso.foo;
    }-*/;
    public static native JavaScriptObject makeObject() /*-{
      return {foo: 'Hello World'}
    }-*/;
    public static TestWrapperEncapsulation create() {
        return new TestWrapperEncapsulation(makeObject());
    }
}

Given the above wrapper class, if you were to write:

Window.alert(TestWrapperEncapsulation.create().getFoo());

You would not end up with the desired optimal JavaScriptCode, e.g.

$wnd.alert(TestWrapperEncapsulation.create().jso.foo)

rather, this

$alert(this$static, $getFoo(create()));

function $alert(this$static, foo){
 $wnd.alert(foo);
}

function $TestWrapperEncapsulation(this$static, jso){
  this$static.jso = jso;
  return this$static;
}

function $getFoo(this$static){
 return this$static.jso.foo;
}

function create(){
  return $TestWrapperEncapsulation(new TestWrapperEncapsulation(), makeObject());
}

function makeObject(){
 return {'foo':'Hello World'};
}

Now let's take a look at GWT1.5's output:

$wnd.alert($TestWrapperEncapsulation(new TestWrapperEncapsulation(), {foo:'Hello World'}).jso.foo);

function $TestWrapperEncapsulation(this$static, jso){
 this$static.jso = jso;
 return this$static;
}

That's a massive reduction, but still not good enough. There is in fact, no reason to have a wrapper encapsulate the JSO. Instead, with GWT 1.5, we can subclass the JSO and pretend that our Java methods exist on the underlying JSO.

alert(TestWrapper.makeWrapper().getFoo());

public class TestWrapper extends JavaScriptObject {
    protected TestWrapper() { }
    public final native String getFoo() /*-{
       return this.foo;
    }-*/;

    public static native TestWrapper makeWrapper() /*-{
       return { foo: "Hello World" } 
    }-*/;
}

and what does the 1.5 compiler produce?

$wnd.alert({foo:'Hello World'}.foo);

Perfect! Absolutely zero overhead.