Thursday, May 29th, 2008

GWT 1.5 Release Candidate Announced

Category: GWT

GWT 1.5 has a new release candidate. The 1.5 release is a big one, especially as it includes Java 5 language support!

Since the previous release of GWT, we’ve seen a lot of really great applications that demonstrate what is possible when you are able to focus on the user and stop worrying so much about browser quirks and other Ajax obstacles. Inspired by what we have seen so far, we have continued to concentrate our efforts on enabling developers to use their existing tools to create web apps that users enjoy. GWT 1.5 takes this commitment even further with exciting new features and over 150 bug fixes. And, like all GWT releases, most of the benefits are just an upgrade-and-recompile away.

I have been playing with the 1.5 trunk for awhile, and it has been a pleasure. What other major features does it have?

New compiler optimizations increase performance
With this release of GWT, we’re happy to announce that our compiler produces faster code than you would write by hand! How’s that? A bunch of new compiler optimizations allow us to efficiently inline method calls, even through many layers of indirection. Translation: all the nice abstractions and clean design work that are essential to maintaining a large code base melt away in the compiler’s output, giving your users the fastest possible experience. By contrast, if you were writing JavaScript by hand, you’d have to choose between writing good code and writing fast code — and when your application got to a certain size, maintainability would make the second choice impossible. With GWT 1.5, you don’t have to compromise; just write good code and let the compiler make it fast.

JavaScript Overlay Types
This further enhances GWT’s interoperability with the underlying JavaScript layer. “Overlay type” is a new term we’re using to describe the ability to model JavaScript objects as strongly-typed Java instances with no additional runtime cost. Overlay types make it easy to provide fine-grained interop with handwritten JavaScript libraries as well as providing an optimal way to make JSON structures directly accessible to GWT code.

High-performance DOM API
Up until GWT 1.5, we’ve concentrated mostly on Widget-level APIs, and until the advent of overlay types (above), direct DOM programming wasn’t particularly convenient. GWT 1.5 goes beyond “convenient” and well into “elegant” with an entirely new DOM API that enables type-safe, low-level DOM programming that will be both comfortable to DOM experts and free of any runtime overhead.

Default visual themes
Several default visual themes are now available by default so that developers get an attractive UI out of the box and have a good starting point to create their own custom styles in CSS.

We have seen some great talks on GWT at Google I/O, which should show up online in the near future (I will get them posted as soon as I can). For now, give 1.5 a try.

Posted by Dion Almaer at 8:50 am

3.6 rating from 24 votes


Comments feed TrackBack URI

Any way to make it work with Groovy rather than Java? Java gives me a stomach ache.

Comment by Nosredna — May 29, 2008

A Multi Gazillion Dollar Company, 100,000 employees, obviously spending a LOT of time and effort on creating a RIA Framework, years of releases and *seriously*…!
THIS is the stuff you’re coming out with…?
I am truly amazed…
And I don’t mean that in a good way…
BTW, creating JavaScript from a “lesser language” will never work due to JS having a completely different model with lots of features you don’t have in Java and vice versa, e.g. Closures, Prototype inheritance, functions as first class objects etc…
This is *scientifically prooven* (Google for; “Elephant Footstep” if you don’t believe me which is scientific PROOF of that “creating JS from Java” will never be efficient)
So the stuff that the GWT compiler is writing “better JS than you could do by hand” is *impossible*! Sure it could write better code than “most people” would do by hand, but for the GWT compiler to create better code than the “critical path of execution” is just plain wrong due to the “Elephant Footstep” dilemma…

Comment by polterguy — May 29, 2008

@polterguy: True that human written code *CAN* be more efficient, but efficient code is not always pretty/organized code.

GWT lets you write organized code in Java (and as much as people bash the language, its very organized), which compiles to Javascript >= than most people write.

An example would be anonymous functions, which are very prevalent in Javascript, even libraries like Dojo or jQuery. Perfomance wise, however, they can really hurt. An anonymous function used in a loop or inside of another function has to be “re-interpreted” every iteration/usage.

When analyzing GWT’s output code, I’ve noticed they create these functions in an appropriate outer-closure.

Comment by matanlurey — May 29, 2008

@polterguy, GWT will create more optimal code in general than hand written in JS in non-trivial projects. To beat GWT, you’d have to write ugly, non-idiomatic JS, which would be a pain to maintain.

GWT interns all strings, folds expressions at compile time, devirtualizes polymorphic methods and shortens or eliminates prototype chains, significantly speeding up JS execution. Any hand written JS library that uses mixins or prototype inheritance will be slower. Any JS library that uses closures everywhere will be slower and chew up more memory.

Let me give you a great example. I ported jQuery to GWT, almost line for line. The GWT compiled version is faster. Are you saying John Resig is not a good JS programmer?

Besides performance, JS libraries are guaranteed to be bigger. GWT can aggressively prune and obfuscate in ways that are impossible for JS minifier/packers. My jQuery clone compiles CSS selectors ahead of time, and prunes any method not used. The code output is usually 5x smaller than minified/packed/gzipped jQuery.

Religious zealotry about languages is pointless. GWT is real compiler technology. It can’t be hand waved away without understanding what it does.

Comment by cromwellian — May 29, 2008

That’s pretty interesting. And maybe a good argument for writing libraries like jQuery in Java.

But I prefer writing my code in JavaScript because it’s an environment where I don’t have to compile my code.

I love Firebug. I don’t think I’d like debugging machine generated code in Firebug quite as much.

Comment by Nosredna — May 30, 2008

I can sympathize. Yes, there is a certain pleasure in making a change, hitting reload, and seeing it instantly, and for small ajax apps, I wouldn’t recommend GWT. But on large apps, I’d gladly trade a short compile cycle, to gain all of the advantages of speed, size, package management, refactoring, debugging, testing, and every other part of the mature Java toolchain.

GWT allows you to use any debugger, but you can also use Firebug if you wish, just compile in “PRETTY” mode, and the code output will be quite readable.

Comment by cromwellian — May 31, 2008

>>GWT allows you to use any debugger, but you can also use Firebug if you wish, just compile in “PRETTY” mode, and the code output will be quite readable.

Really? That’s good to know.

I’m seeing a lot of complaints about the slowness of GWT 1.5 compiles. Gives me a stomach ache just thinking about that.

But maybe I’ll give it a try anyway at some point.

Comment by Nosredna — May 31, 2008

GWT’s “Hosted Mode” browser requires no compilation, and gives you a pretty accurate (95%+ IMHO) preview of your application.

Comment by matanlurey — June 2, 2008

Leave a comment

You must be logged in to post a comment.