
I have seen the GWT team working very hard indeed on GWT 1.5, and they must be very happy to see the final release shipped and complete:
GWT 1.5 delivers what we think are an impressive number of improvements, about four hundred issues if you're counting. We're also happy that one of those is issue 168, our most-requested feature, Support for Java 5.
The high level new feature sets are:
You can see a lot of this at work in the showcase area. There you will see all of the widgets and examples that come out of the box, and the community has developed even more for you. In particular, Ray Cromwell has some great real world examples that he shares in his book and talk.
Download GWT and take a look.
GWT has long had a project that aimed to give rich support for Google APIs called GALGWT, or "Google API Libraries for Google Web Toolkit".
This project has stepped up to higher gear recently, and we have seen the GALGWT 1.0 release candidate appear.
What is in GALGWT?
The project is a collection of libraries that provide Java language bindings
and API specific 'plumbing' for some Google JavaScript APIs. The goal is to
make it easy for developers to use these JavaScript APIs with GWT. Libraries
available at this time include a new version of Gears, as well as new
libraries for Gadgets and the Google AJAX Search API.Gears 1.1 Library
A new version of the Gears library is available. In addition to the earlier
version's support for the Gears LocalServer, Database, and WorkerPool, 1.1
adds integrated support for offline applications and updated sample
applications. The bindings have also been refactored to use GWT 1.5
JavaScript overlay types and a new package hierarchy.Gadgets 1.0 Library
The Gadgets library simplifies gadget development with GWT by automatically
generating a Gadget specification from Java source and inserting a selection
script in the specification much like a regular GWT project. After compiling
your gadget with GWT, all files are in place to publish your gadget. This
version currently supports the legacy Gadgets API based on the _IG_...
namespace.Google AJAX Search 1.0 Library
The Google AJAX Search API lets you put Google Search in your web pages,
including Web, Local, and Multimedia searches. This library allows you to
access the API from Java code compiled with the GWT compiler without having
to write additional JavaScript code.
Sanjiv Jivan, original creator of GWT-Ext, posted on SmartGWT, a new wrapper on top of SmartClient.
Charles Kendrick of Isomorphic, creator of SmartClient, announced the new project as well as the approach they have taken:
we’ve taken an approach of generating GWT code from SmartClient’s documentation, combined with hand-coding portions that can’t feasibly be generated. By tweaking our documentation set to contain additional metadata (some of it GWT-specific), we’ve been able to generate code you might not otherwise expect, including things like enumerated constants and convenience constructors.
What this means is that the first release of SmartGWT will provide the complete SmartClient API, fully documented.
You can now write code such as:
Sanjiv Jivan joined the project under the terms that Isomorphic sign a document that said:
The founders of Isomorphic Software are committed to keeping a complete, up-to-date version of SmartClient available under an LGPL license.
We continue to invest heavily in building new features, skins, tutorials, and tools for SmartClient LGPL.
We think it's normal and expected that some people receive great benefit from LGPL software and do not pay. The spirit of open source, in a nutshell, is that releasing free software creates so much wealth that the portion that flows back to you is more than enough.
Sincerely,
Charles Kendrick
Alex Shvedoff
Bruce Johnson of the GWT team has continued the deep dive into GWT with a posting on a new GWT 1.5 feature: JavaScript overlay types. This feature goes beyond the JNSI technique to "make it easy to integrate entire families of JavaScript objects into your GWT project. There are many benefits of this technique, including the ability to use your Java IDE's code completion and refactoring capabilities even as you're working with untyped JavaScript objects."
The first example that Bruce gives is to mix JSON objects with Java:
Bruce then shows us some performance wins that you get, as GWT gets to do a lot of inlining:
A quick digression for compiler geeks. Another neat thing about overlay types is that you can augment the Java type without disturbing the underlying JavaScript object. In the example above, notice that we added the getFullName() method. It's purely Java code — it doesn't exist on the underlying JavaScript object — and yet the method is written in terms of the underlying JavaScript object. In other words, the Java view of the JavaScript object can be richer in functionality than the JavaScript view of the same object but without having to modify the underlying JS object, neither the instance nor its prototype.
(This is still part of the digression.) This cool wackiness of adding new methods to overlay types is possible because the rules for overlay types by design disallow polymorphic calls; all methods must be final and/or private. Consequently, every method on an overlay type is statically resolvable by the compiler, so there is never a need for dynamic dispatch at runtime. That's why we don't have to muck about with an object's function pointers; the compiler can generate a direct call to the method as if it were a global function, external to the object itself. It's easy to see that a direct function call is faster than an indirect one. Better still, since calls to methods on overlay types can be statically resolved, they are all candidates for automatic inlining, which is a Very Good Thing when you're fighting for performance in a scripting language.
From this Java code:
The compiler inlines away to get to the followinig (not obfuscated to see):
Alex Moffat has written up an exploration of GWT linkers. It looks at the linking part of the GWT compilation step using as an example a linker that creates a sort of manifest for the JavaScript files created by compilation so that you can easily tell which file goes with which browser/locale/etc. combination.
In GWT 1.5 the build process is internally divided into two phases, compilation, which creates JavaScript from Java, and linking, which takes the JavaScript and other resources produced by the compilation phase and packages it for deployment. I wanted to understand a bit more about the linking process after seeing Bob Vawter talk about Resource Bundles and Linkers in GWT at the Google I/O conference. To try and help me do that I’ve created a linker that you can include in you build process to create a sort of manifest file listing which generated JavaScript file applies to which permutation of browser, locale etc.
To create a linker and have it called during the build process you need to do four things
- Create a class that implements
com.google.gwt.core.ext.Linker- Add a
LinkerOrderannotation to the class to define whether the linker should run before the primary linker, after the primary linker or instead of the primary linker. You’re allowed as many linkers before and after the primary as you like but only one primary linker.- Define and add the linker in a <module>.gwt.xml file.
- Include the new class in the classpath when running the gwt compiler.
The 1.5 RC1 build provides three different primary linkers that produce three different ways of packaging the compiler output for loading by the browser. The standard linker produces the familiar <module>.nocache.js file that loads the correct <strong name>.cache.html for the target browser. This is the linker that is added in Core.gwt.xml and so is the default linker that is used. Also provided are a cross site linker that creates a <module>-xs.nocache.js and a single script linker. You use the cross site linker if you need to host the GWT generated artifacts on a separate domain from your main site, for example if you use www.mysite.com for serving dynamic content and put all the static stuff, including JavaScript, on static.mysite.com. The single script linker can be used when the compilation process always creates a single JavaScript file that is applicable to all permutations.
Darrell Meyer has announced Ext GWT 1.0. This is the first fully stable release of the product and it includes a lot of goodies including:
Looks like a very solid release indeed. Congrats to the team.
Darrell Meyer has announced Ext GWT 1.0. This is the first fully stable release of the product and it includes a lot of goodies including:
Looks like a very solid release indeed. Congrats to the team.
Alex Moffat has written up an exploration of GWT linkers. It looks at the linking part of the GWT compilation step using as an example a linker that creates a sort of manifest for the JavaScript files created by compilation so that you can easily tell which file goes with which browser/locale/etc. combination.
In GWT 1.5 the build process is internally divided into two phases, compilation, which creates JavaScript from Java, and linking, which takes the JavaScript and other resources produced by the compilation phase and packages it for deployment. I wanted to understand a bit more about the linking process after seeing Bob Vawter talk about Resource Bundles and Linkers in GWT at the Google I/O conference. To try and help me do that I’ve created a linker that you can include in you build process to create a sort of manifest file listing which generated JavaScript file applies to which permutation of browser, locale etc.
To create a linker and have it called during the build process you need to do four things
- Create a class that implements
com.google.gwt.core.ext.Linker- Add a
LinkerOrderannotation to the class to define whether the linker should run before the primary linker, after the primary linker or instead of the primary linker. You’re allowed as many linkers before and after the primary as you like but only one primary linker.- Define and add the linker in a <module>.gwt.xml file.
- Include the new class in the classpath when running the gwt compiler.
The 1.5 RC1 build provides three different primary linkers that produce three different ways of packaging the compiler output for loading by the browser. The standard linker produces the familiar <module>.nocache.js file that loads the correct <strong name>.cache.html for the target browser. This is the linker that is added in Core.gwt.xml and so is the default linker that is used. Also provided are a cross site linker that creates a <module>-xs.nocache.js and a single script linker. You use the cross site linker if you need to host the GWT generated artifacts on a separate domain from your main site, for example if you use www.mysite.com for serving dynamic content and put all the static stuff, including JavaScript, on static.mysite.com. The single script linker can be used when the compilation process always creates a single JavaScript file that is applicable to all permutations.
Some good stuff came out from my employer. First, we have the Gears 0.3 release which includes support for Firefox 3! I have been using it for awhile, and it has been great. The team wanted to get it out before the Firefox 3 launch (planned for June 17th). A plugin like Gears can get deep into browser internals, so it is a challenge to keep up to date as APIs change in beta releases, so it is great to be out there now and I we will take a close look at the final release!
As well as Firefox 3 support, Gears 0.3 includes:
Then, all of the videos from Google I/O sessions have been published.
I put together a playlist that includes Ajax and Gears related content:
Check out the great talks such as:
Gears
GWT
General Ajax
Wow, a lot of material there!
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.
OpenKM is a multi-platform application for document management based on GWT, JBoss, and Jackrabbit (the content repository API).
Version 2.0 has been released, which you can test drive to see the application-style interface. The new features in 2.0 include: the previsualization of multimedia elements as images and videos, an improved an rewritten administration interface, a centralized management of templates, an exclusive area to allow users to store their private documentation, a tool for massive import and output data from ZIP files, searches by date ranks as well as translations to more languages.
However, one of the more relevant functions to mention is the indexing of the most common types of files: text, Office, Office 2007, OpenOffice, PDF, HTML, XML, MP3, JPEG, etc.
Today we have Bruce Johnson of the GWT team talking to us about GWT 1.5. He discusses the new features, such as the long awaited Java 5 language support, performance improvements, and much more.
It is very nice to take an application, run it through the new GWT 1.5 compiler, and get an instantly faster running application "for free".
Previously on Ajax Pioneer Week...
XSketch is "a multiplayer word sketch game. It is programmed in Adobe Flash, Java, Ajax, and GWT. Gameplay is similar to Pictionary where you sketch a picture with the goal of having other players guess your word and vice versa."
Ryan Dewsbury creator this game, which he adds to his collection of GPokr and KDice.
This one is particularly addicting!
One part of the Ext JS 2.1 release was the prominence of the sub project Ext GWT, a project that lets you code in Java with GWT while using the Ext components and framework.
But wait a minute, I thought that that project was GWT-Ext? Or wasn't there something called MyGWT too? Confused?
Didier Girard has come to the rescue. He has discussed the different projects, how Ext GWT (the new one) is actually a repurposing of MyGWT. He also lists the differences, in his opinion, between the two projects (noting that the latest one is going to be rev'ing quickly):
Bob Lee is a co-worker of mine at Google (He is actually the lead on core Java APIs for Android), and he happened to create a cool little GWT application called Twubble, which he explains:
If you use Twitter, Twubble can look at your existing friends' friends and recommend new people for you to follow. It's a stupid simple idea, but I think the execution and fun factor have won people over.
I wrote Twubble in a couple nights of hacking in bed after the kid went to sleep. I used the latest Google Web Toolkit milestone which supports Java 5 (flawlessly from my experience). I was writing Javascript code (server and client side) for years before I ever got into Java, but I have to say, you'd be crazy to write AJAX apps any other way than GWT nowadays.
This is Bob's first GWT application, so I wanted to sit down and talk to him about why he built the application, his experience with GWT, how he integrated with Twitter, and any other nuggets of information that I could get out of him:
Are you a fan of GWT but would like toms jQuery magic mixed in? Ray Cromwell has your back, as he has created GQuery, an implementation of jQuery for GWT.
This means that you can write code like this:
I decided to demonstrate some of the huge benefits of 1.5 by implementing a type-safe JQuery clone in GWT.
That's right, for all those folks who don't want to deal with GWT Widgets, but just want to query, wrap, and manipulate plain old DOM elements in GWT, this article is for you. I'm talking to you, you self-hating Java programmer with an inner Javascript Ninja begging to be let out.
After the GWT compiler gets its hands on it, the example comes in at 5459 bytes. This library can only be achieved with GWT 1.5 features, and gives you:
Fun little feature, $$
jQuery contains a lot of methods which take essentially property/value pairs in a Javascript object literal. Emulating this with Java syntax would be too tedious (Scala frontend to GWT, please!), however, to ease this use case, I added a global $$ function for manipulation JavaScriptObject/JSON objects easily.
Version 2.0 of GChart has been released:
The main idea behind GChart is simple: You can make very nice charts efficiently out of a reasonably small number of 1-cell Grids (for the aligned labels) and (empty) Images (for everything else), styled and positioned appropriately on an AbsolutePanel. Not surprisingly, bar charts don't suffer at all under the limitations imposed by this strategy--but (as long as you don't mind using dotted connecting lines or banded-filled pie slices) line and pie charts also do remarkably well.
With version 2.0 the library adds support for pie, line, and area charts, baseline-based bar charts, and more.
John Gunther wrote up some of the technical details:
Squaring the Pie Slice
Some of you may recall the original GChart 1.1 post/discussion:
Reading this, you may wonder how I ended up implementing pie slices
and arbitrary angled connecting lines. Did I use the "transparent
border triangle trick" and/or clever algorithms from walterzorn.com?Though I tried to use these, I reverted to something a lot simpler:
dotted connecting lines and banded-filled pie slices. Two new Symbol
class properties, fillSpacing and fillThickness, let you control the
spacing of the dots/bands and their size/thickness.Though this approach means you may sometimes have to choose between
visual chart quality and speed, these new properties make it easy for
you to control this tradeoff. Besides, I like to think that dotted
connecting lines and banded fill pie slices really don't look all that
much worse than the solid fill variety. But then again, I could never
understand why no one ever used square pie charts...In any case, the whole point of GChart is to layer the chart on top of
standard GWT Widgets, so, since those Widgets can only really draw
rectangles efficiently, I decided to make a virtue of necessity and
whole-heartedly embrace this dotted/banded look.CSS Convenience Methods: A cure for "CSS anxiety disorder"?
For many months I suffered from "CSS anxiety disorder": a condition
arising from one's desire to use CSS to specify an attribute (and thus
conform to a GWT best practice) while simultaneously wanting the same
property in the Java API (so that it would not be unnaturally
segregated from closely related features).To address this (possibly imaginary) problem, the GChart 2.0 Java API
includes "CSS convenience methods" that can (optionally) override
traditionally CSS-based attribute specifications for certain selected
CSS attributes.To some, this may seem like a fine point, since you could easily do
the same thing via a GWT DOM class method call, but to me, once you
invoke a DOM method you are thinking of the GChart as an HTML element,
and for some usage scenarios, that just isn't logical.For example, for some applications, the background color of a GChart
is mainly about how the color-scheme of the chart blends in with the
surrounding page, and for these applications a CSS-based specification
makes good sense. Yet, for other applications, it is mainly all about
how well background color matches with, say, with the pie slice
shading pattern. That is, in some cases, background color is better
viewed as a feature of the GChart considered as a Java object
independent of its connection to any web page. So why can't you just
call GChart.setBackgroundColor in such cases? With GChart, you can.To assure that the two specification methods can exist harmoniously
together, GChart recognizes a special property value, GChart.USE_CSS,
which instructs GChart to stand aside and allow the traditional CSS
cascade to define the attribute. For all such "dual access" GChart
Java properties (which are simultaneously also CSS attributes),
USE_CSS is the default property value. This assures that you can use
CSS just as you would with a standard GWT Widget whenever it makes
more sense to control that attribute from the "GChart as HTML element"
perspective.Thanks to these CSS convenience methods, I have attained inner peace
through Java/CSS redundancy. I recommend the same treatment for anyone
else suffering from "CSS anxiety disorder". See the GChart.USE_CSS
javadoc comment for more information.
I am sure that John will be porting this to the GWT for JavaScript 2 at some point soon!
The Google Web Toolkit has long been a bastion of Java developers who are able to chant "We don't want your stinking JavaScript!"
GWT is a lot more than a client side framework that allows you to write code in Java. It is a productivity tool that lets you developer and test a solution that performs well and works cross browser (huge wins). In fact, when I talk to people that are using GWT, the most common comment that I hear is how happy they are with:
Why should this just live in a Java world? Today, it breaks out. Google has released GWT for JavaScript 2.
With the upcoming birth of JavaScript 2 hopefully hitting our browsers, wouldn't it be nice to build your Ajax applications using JavaScript, but also having the cross browser helpfulness that GWT gets you.
How does it work?
You write an application using JavaScript 2, and you then run it through a compiler which spits out the same optimized JavaScript source code that works for the various browsers.
Why write cross browser JavaScript when you can just write JavaScript?
This fits in perfectly with Steve Yegge releasing js2-mode, a new JavaScript 2 module for Emacs that has a lot of great features:
Also, Didier has posted the news that GWT has been submitted to the JCP as JSR 404.
When making ChartMaker on the plane, I was tempted to use GWT Ext, but it didn't support Ext 2.0 yet so I held off. However, at JavaPolis I was told about the work being done by Sanjiv Jivan, and he has just released GWT Ext 2.0 which "is a powerful widget library that provides rich widgets like Grid with sort, paging and filtering, Tree’s with Drag & Drop support, highly customizable ComboBoxes, Tab Panels, Menus & Toolbars, Dialogs, Forms and a lot more right out of the box with a powerful and easy to use API."
Sanjiv actually added a partial port of Chart Maker as one of the demos. There are a couple of nice touches in there. The one that jumps out at me is the way you add data. Instead of my cheesy textarea, he added a really nice data entry system. Thanks Sanjiv!
If you are a GWT developer that loves staying in Java land, you can continue to do so knowing that you will be getting fantastic looking widgets via Ext 2. A nice pairing.
Laurent Nicolas has created an analytics solution, using GWT, that tracks fine grain access from users on a page.
It tracks:
There is also a nifty widget that allows you to shrink and grow the div size of comments.

We posted about JSTM for GWT back when I saw it at JavaPolis.
Now, the project has been renamed to XSTM which comes with a new book, and a new form example:
The data entered in the form is automatically replicated on the server. If you launch two browsers and modify the same field concurrently, the conflict is detected and the last modification is cancelled.
The undo button aborts the current transaction, which cancels the modifications that where done to the form.
You can see the bulk of the code.
What is XSTM?
XSTM is a library which enables high performance object replication between processes. With it you can set a value to a field of an object in one process and see the value changing on an object in another process. This can be very useful in scenarios where the same data is present on several machines like client-server communication, application clustering, peer to peer etc…
In a client-server configuration, XSTM can replicate changes made to an object to and from selected clients. This simplifies a lot for example Ajax applications where clients interact with the server in complicated ways. Using XSTM, you can forget all the error-prone code to call the server or notify the clients of a data update. No more intermediary objects you send back and forth. No useless copying of fields from objects to objects. No call to the server sending a whole form when only one field has been changed. Model your application in the usual object oriented way, write the code that creates and modifies those objects on the server and the clients, and let XSTM handle the synchronization.
XSTM is symmetric, which means you can put the code which modifies your shared objects on the machine that's best suited. For example form validation code would be identical on a server or on the clients so you can choose the best solution for your application.
Pearson put on a GWT Conference that had a lot of great content.
Fortunately, video cameras were running, and the video has been edited and posted:
You may want to check out Kelly's talk on usability, as well as Bruce and Dan's overview of how GWT can improve productivity. There's also the conversation with Josh Bloch and Joel's presentation on architecture design. And a panel of app developers talks about their firsthand experiences with GWT.