I recently wrote an introduction to the Google Web Toolkit based on Lars Rasmussen’s session at the Google Developer Day 2008 in Sydney. Following the introductory session Lars gave us a deeper insight into GWT, particularly what’s new in version 1.5.

The features that are worth mentioning are the new DOM API and JavaScript overlay types.

DOM Programming

GWT DOM programming allows you direct access to the DOM layer. Version 1.5 makes DOM programming a lot easier, than it was in 1.4. There are a number of new DOM classes encapsulated in the com.google.gwt.dom.client package. The classes support the W3C standard bindings for programming the HTML DOM using Java. Its cross-browser capabilities allow you to write just one code base that will work across different browsers.

You will now be able to write better looking, more strongly typed code. The previous version of GWT contained just one, ambiguous DOM class with a set of static methods, and only one Element. Now each DOM element is represented by a class of its own.

Lars showed a code example to illustrate how the code you write now, differs from the code you would have produced in 1.4.

Before: Element table = DOM.createTable();
Now: TableElement table = doc.createTableElement();

You can use these classes as an alternative to writing JSNI methods.

However, there is a naming issue that might cause some confusion. There are now two different Element classes in two different packages. When the DOM library was created, a type element already existed in user.client package. The Google team was thinking of naming the new Element, Abstract Element, but decided against it, so there are now two Elements. The Element in user.client package extends the DOM Element, but doesn’t add any methods.

Overlay Types

This is probably the most notable feature of GWT 1.5. You are now able to create a Java type and at runtime overlay it onto a JavaScript object, such as HTML DOM elements, XML DOM nodes and JSON structures. You get all the benefits of coding in Java, such as IDE support with no overhead, which makes it really fast.

There are a number of rules you need to follow when using overlays, because the JavaScript object cannot be altered:
|> Extend JavaScriptObject, even if it’s indirectly
|> Use an empty, no parameter, protected constructor, since you cannot instantiate the overlay type yourself
|> Similarly, you cannot use the “new” keyword to construct JSO subclasses
|> You cannot use declared instance fields – you have no means of storing the state of the instance fields, because you’re dealing with an overlay type only. The JavaScript object itself cannot be modified.
|> Ensure methods are final to prevent polymorphism – there cannot be polymorphism, since the Java type of the JavaScript object is unknown. No type information exists at all, because again we cannot change the underlying JavaScript object.

As a final note, at runtime there is no way to tell the difference between one overlay type and another. The responsibility lies on the programmer to write things that make sense.

A similar presentation was given at this year’s Google I/O by Bruce Johnson: