Google Web Toolkit (GWT), a Java-centric compiler which creates JavaScript-based web applications, released version 1.5 today. InfoQ spoke with tech lead Bruce Johnson to learn more about this release and what new capabilities it adds to GWT.
Major new features in GWT 1.5 include:
- Java 5 language support - Support for Java 5 features such as generics, enumerated types, annotations, auto-boxing, and variable parameter lists has been added
- Compiler optimizations - Performance of compiled applications has improved once again, and existing apps will notice a speed improvement after recompiling their unchanged GWT code with 1.5
- JavaScript enhancements - JavaScript Overlay types and a new high-performance DOM API provide strongly-typed JavaScript objects and DOM programming with no runtime overhead
- Default visual themes - Several CSS-based UI themes are now available to provide a starting point for application look-and-feel
A full list of changes is also available along with release notes.
Johnson described a couple of the changes which are present in 1.5:
[@gwt.eventArgs was previously used as] javadoc-based metadata for RPC. It's a great example because it's a change most people will encounter early on as they upgrade to GWT 1.5. RPC is now so much simpler and richer now because your RPC interfaces can simply specify generic collections. Another thing to be aware of is that GWT 1.5 now fully supports the 'long' primitive data type. Prior to GWT 1.5, 'long' wasn't really properly supported because JavaScript doesn't have a 64-bit integral type, so the full range of a 'long' couldn't be represented using a native JS number. In GWT 1.5, we worked around that by generating extra code to ensure that the behavior of longs is now totally correct, although the performance is somewhat worse than in GWT 1.4. This was a unfortunate situation where we had to choose between maximum performance and correctness, and obviously correctness had to win. If you used longs heavily in GWT 1.4 and speed is more important than the numeric range, consider switching those variables to 'int' or 'double' to maintain the same speed as GWT 1.4.
Johnson also went into detail about the compiler changes which were required to support 1.5:
The GWT compiler's front end reuses the great Java compiler that's part of Eclipse. It handles all the parsing and semantic checks and then builds an abstract syntax tree (AST). We then take that AST and perform optimizations and produce JavaScript output. Using the Eclipse compiler made our lives a whole lot easier, because much of the work is already done. Still, it took a fair amount of work to find ways to represent new concepts such as enumerated types and enhanced for loops efficiently in JavaScript. The new language features also had positive ripple effects throughout the GWT libraries, most obviously in the newfound ability to use generics in RPC, but we also are making extensive use of annotations to replace javadoc-based metadata in things like internationalization, image bundles, and benchmarking.
Johnson described GWT's major web development competitors as falling into three categories, and described how GWT differentiates itself from those competitors:
- Non-DOM UI models, e.g. Flex - GWT embraces the browser's DOM model rather than trying to replace it, and Johnson pointed out that some very compelling Flash and DOM UI integrations have been orchestrated using GWT
- Server-side HTML generators, e.g. JSF - GWT is complementary to this as it is purely a client-side technology (apart from RPC) and it integrates well with server-side components, however Johnson has found that the richer, more stateful GWT client code encourages building more responsive and fluid UIs with less requirement for server-side click-and-wait code
- AJAX libraries, e.g. Dojo and jQuery - The primary difference here is the choice of programming language; GWT leverages the existing Java development tools and compiler's ability to generate highly optimized JavaScript. Java and JavaScript can be used side-by-side, but Johnson said that the more Java is used, the more the GWT compiler optimizations help you
When askeed how GWT integrated with other Google codebases, Johnson said:
Key point: GWT gives you a lot of leverage, but it isn't intended to be a "walled garden" in any way. Abstractions always leak, so it's better to embrace that fact. We intentionally make it easy for you to punch through the abstractions and get down to the nuts and bolts JavaScript environment so that you can integrate with any other technology you like. That flexibility is a sort of insurance policy for both GWT itself and GWT users: you can be sure that you'll be able to combine any client-side technology you want with GWT, and we (the GWT development team) don't feel as if we have to explicitly provide integrations for an open-ended set of things, because you can always do it yourself without waiting on us. For an example of the kind of flexibility I'm talking about, check out Ray Cromwell's Syndroid work.
Johnson also said that numerous integrations for GWT exist including integrations into Spring, Flash and numerous Google Code projects.
When asked about plans for the future of GWT, Johnson said:
We are going to continue to focus on dramatically improving performance as well as graduating several new widgets out of the GWT Incubator, including a date picker and some fancy new table widgets. We also have other totally new things in the works, such as a declarative XHTML-based UI templating mechanism. Not everything has been scheduled yet, though, but I'd expect those in the next release or two. Which, by the way, I would expect to be a much shorter cycle than GWT 1.5 was.
Johnson also expressed support for the inclusion of GWT as a development environment for Google App Engine, calling it "a cool idea".