There are lots of snippets out there on the internet telling you how to run GWT code from javascript.  Here’s the canonical one.

I recently did a fair bit of this, calling GWT code from jquery.  Two things jumped out:

• Make sure your jquery method is run in $(window).load(), not $(document).ready(). If you use the latter, your GWT code will not have executed and exported the javascript method to the window object. More on that.
• I couldn’t find a list of valid java type signatures (even in the JVM book) for the longest time, but here they are, at long last.

Update, 2/26: I ran into some issues with using $window.load().  What you have to do instead is create a gwtonload function and call it from your gwt loader via jsni.  This ensures that GWT code is fully loaded, which $window.onload() does not.

I have written before about GWT code splitting, a cool feature available in GWT.  While I am definitely no expert, it seems to be different that options offered by other, comparable web toolkits.  Just doing a quick survey (thanks, Ajaxian!), there seems to be a lot of code compilation happening.  Some of it is at deployment, pruning unused library code (like here, and here).  Some of it is aimed at making whatever javascript you write, better (like this and this).  There’s even tools aiming to document (in json) all javascript features supported by browsers, so that you can intelligently target user agents.

GWT code splitting is different from all of that.  It is developer determined split points in javascript code.  A developer says, essentially, all code after ‘this call’ should be downloaded and made accessible to the runtime when ‘this call’ is made.  More at the canonical reference; you should read this multiple times if you want to really understand code splitting.

As the document above mentions, “effective code splitting requires iteration”.  I’ve spent a fair bit of time in the last week doing some code splitting, and wanted to share my punch list (and build on my previous code splitting post).

First, understand the three major types of chunks your code will be split into.

• Initial download
• Leftover code
• Exclusive fragments

The document above has a great diagram, which also includes other types of code which I have not run into.   The important thing to realize is that minimizing the initial download is important, but if any of the exclusive fragments are download, the leftover fragment will be downloaded.  Therefore, a better goal is to maximize the exclusive fragment size.

Here are places places to put split points, in order of preference

• subsystems easily isolated (encryption library, etc).  Consider using the AsyncProxy, which is a great way to hide a subsystem
• user actions (onclick events, etc).  Be aware of latency when toe code is downloaded and executed
• when enabling spans are present

Use GWT.runAsync directly.  I tried to get all fancy with commands and abstracting it away, and didn’t have much success.  You can surround it with a timer, though, and that
may make sense when you are using an enabling span.

if (span is present) {
Timer t = new Timer() {

@Override
public void run() {
GWT.runAsync(new RunAsyncCallback() {
public void onFailure(Throwable caught) {
// handle error
}

public void onSuccess() {
foo();
}
});
}
};
t.schedule(150); // wait 150 ms before trying to download this code
}

You will spend a lot of time compiling, so only target a few browsers for compilation.  When I added the -compileReport option, the compile time for the main module went from 2 minutes to 8 minutes.  However, once you have the url for the compile report (something like /extras/modulename/soycReport/compile-report/SoycDashboard-0-index.html) you can actually see the results about a minute in.  At that point, you can stop the compile process.

Method call hunting will make you love your IDE java method search (control-H in eclipse–here’s a useful cheat sheet)

Watch out for constants and static methods.  In fact, I end up pulling out my constants to a class shared between GWT and my java server so that I can name spans like this
<div id="<%=Constants.SCROLL_ANCHOR_ID%>"></div> and be assured that GWT components will always be able to attach to those spans.

If module A is called by module B, C and D, avoid putting the GWT.runAsync calls in modules B, C and D.  This would force module A into the leftover code chunk, increases the number of split points, compilation time, and memory needs.  Instead, put the GWT.runAsync calls into module A, which pushes all that code into an exclusive chunk.  If you have a bunch of small splits points in your compile report, look at it carefully, especially if they are in the same class and see if you can push the split points back into the common code.

Code splitting failures (onFailure) should be dealt with the same way any remote access failure is dealt with in your application.  I haven’t found a more intelligent method than informing the user that the operation failed, however.

Set goals for splitting and try to avoid getting sucked in.  Because it is an iterative process, you can end up spending a lot of time with this.  Sometimes changes can have counter intuitive side effects, so make sure you track both total, initial and leftover code chunk sizes.

This post was based on a system with total obfuscated code size of approx 750kb, compiled using GWT 2.1.1.

I just upgraded to GWT 2.1.  Lots of new features, though they are mostly aimed at building webapps (as opposed to enhancing websites).

The upgrade process was pretty painless.  A couple of notable changes (for my app):

• <code>DeferredCommand</code> has been deprecated, and replaced with <code>Scheduler.get().scheduleDeferred</code>.  However, the API didn’t really change all that much, so this update is a simple search and replace (looks like the documentation has not yet been updated).
• <code>HTTPRequest.getAsync</code>, which has been deprecated for years, finally disappeared.

The big win for me was code splitting when using the cross site (xs) linker.  This means that code served from one host can run on other domains and can include code splitting in the same manner as code that runs on the original host.

Why is this a big deal?  Two of our key widgets run on both our main host and subsidiary hosts.  These widgets are relatively complex, and it would be great for performance to split out that code so it wouldn’t be loaded on pages where it wasn’t shown.  This wasn’t really possible before GWT 2.1.  I’m still in the process of putting in the code split calls, but will let you know what the savings are when I’m done.

Update Jan 8, 2011: I was able to cut about 18% off the initial and leftover code download size.

Just a warning, if you build javascript overlay types, you should make sure to only use primitives and strings as primary members of your overlay classes.  I’ve already written about overlay types once before, and here’s the GWT documentation.  If you dig a bit deeper in the GWT documentation, you see this quote:

JavaScript non-string objects always marshal as JavaScriptObject$

I was using a java.lang.Double as the return value for one of my overlay objects, and it was fine until I tried to do any math on it.  Nothing would seem to turn the value into a Double or a double, yet no exceptions were thrown.  After some sleuthing in web mode, it turned out that the value returned when I was trying to parse it was NaN, even though when I output it to the screen, the value looked like a double.  I guess it was being treated as a JavaScriptObject$.

Easily enough fixed, just make sure that you don’t use any objects wrappers of primitives in an overlay type.

Two years ago, I surveyed the state of GWT widgets.  It was pretty fragmented and a bit confusing.  While I haven’t been paying very close attention, I don’t think things have changed much.

I was browsing around the GWT google group, and found this interesting announcement.

I’m a huge fan of GWT and the only problem I have with it is not really a problem with GWT but with the fact that there isn’t a centralized place for registering component and associated tools AFAIK.  I have created an application to do this which is available at http://gwtmarketplace.appspot.com/

I visited the marketplace and while it is currently in its infancy, it could be very useful. If you have GWT code that you want to share with the world, consider registering it. I added gwt-crypto, which I help maintain.

Code splitting is one of the features of GWT that make it worth your while.  See, using GWT is really a choice–do you want to use one of the lightweight javascript libraries like jquery, with all the agility that implies, or do you want to use GWT which lets you leverage all kinds of java tools and optimizations, but saddles you with a compile cycle?

I’ve talked before about the situations that I think are good fits for GWT.  I just re-read that post and don’t feel that things have changed too much in the past 3 years, though I might argue with point 4 of that post.  Code splitting is an optimization that would be hard to do with a more normal javascript library (dojo has something like it, but it looks like you are responsible for maintaining dependencies).

I talked before about code splitting, and how it is a great fit for the widget based html enhancing GWT development that I’ve done a lot of recently.  I wanted to talk a bit more about my process for finding code to split.

With code splitting, the main goal is “never have the user download javascript that isn’t used”.

The first thing to do is run your GWT compile with the -compileReport option, as outlined here. This will show you your module code, and therefore let you focus your effort where it makes sense.

The second thing to do is to find code dependencies.  The compile report shows you that in a text format if you navigate all the way down to the class level in a class that is downloaded in the inital fragment via the “see why” link.  I had a hard time understanding those dependency lists, so I went looking for a tool to help.  After trying a number of open source dependency analyzers, I stumbled on the Class Dependency Analyzer (CDA) which is free as in beer, not as in speech.  The key difference between this tool and others was its included dependency graphs.  You should set CDA up to ignore all the google code, as well as any third party tools you have.  More documentation on CDA here.  (This is another example of leveraging java’s tool set.)

Using CDA, you can see which packages (since modules are grouped in a java package) have dependencies on others.  Packages that don’t have dependencies on any of your other packages are great candidates for code splitting, as well as packages that depend on other packages that are code split.  However, if your packages depend on utility classes, especially those that share business logic between client and server side code, that’s OK.  (This exercise can also help in general code quality.)

Now you have a number of candidate modules.  The next thing to do is dive into the code and see if these modules execute on every page.  If they do, then doing code splitting is not a win.  All you’ve done is forced GWT to make an extra network call.  If, on the other hand, this code only executes when someone clicks a button or takes some other action, then you have a great candidate for code splitting.  And if the module only executes on certain pages (perhaps using a DOM element to signal whether it should execute or not), you have a good candidate–because with splitting that code will never be download on pages where it is not used.

Now, add the following code around the candidates:

GWT.runAsync(new RunAsyncCallback() {
public void onFailure(Throwable caught) {
// handle error
}

public void onSuccess() {
// do something
}
}

I actually added this code block to my eclipse templates ( more on templates here) so it is super easy to set up a split point.  Note that I haven’t found a generic good action to take on failure.  For most widgets providing enhanced functionality, a safe fallback might be to just let the HTML execute.  A custom message display might be ignored, and using Window.alert can confuse your users (and lock up a browser for a time if all of your code or the network suddenly becomes unavailable).

The next step is to run the compile report again and see if the GWT compiler agrees with you that your candidate code is not reachable by any other path.  If it does, you should see split points show up underneath the permutations menu.  (BTW, the -compileReport flag easily doubles or triples the time it takes to compile GWT–I’d recommend focusing on one user-agent and doing other things to speed up your compile, as outlined here.)  You can also test this by just compiling your GWT without the -compileReport switch and looking under the deferredjs directory; it is quicker but doesn’t help you determine which modules are being downloaded.  Firebug also lets you see the files downloaded on demand.

I was able to decrease the initial download size of a project I’m working on by 20%.

I’ve mentioned the caveats before but they are worth mentioning again.

• The XS linker is not supported, so if any of your XS modules depend on a module which has code splitting, you’ll find out when your GWT does not compile.  However, there is hope–code splitting support for the XS linker is apparently coming with GWT 2.1.  If you need this functionality, vote for the bug.  There are some work arounds in the meantime, but they involve a fair bit of hoop jumping so I’m going to avoid documenting them.
• Events that happen before code is asynchronously downloaded are not propagated to that code.

Given the second issue, it’s important to test your code and make sure that the behavior is unchanged.  That’s the final step.

I hope this was a useful tour of the GWT code splitting process.

Among other times, when you’re passing it into a JSNI method in GWT.  From the docs, only a java boolean is translated into “JavaScript boolean value, as in var b = true;”  A Boolean is, like any other Java object, an “opaque value accessible through special syntax”.