EoD SQL Applied – Part 5 / 5 (GWT Applications)

The Dreaded “Not Serializable” Problem

GWT turns all of your Java code into JavaScript, but it also obfuscates everything. With this in mind, it makes serialization a bit more complex than usual. GWT generates a serializer and deserializer for each class that could be transported across the wire to an RPC service. The difficulty comes in knowing which types had code generated, and which didn’t. GWT solves this problem for itself with the Serialization Policy file, where the compiler lists all of the classes that the client code will know how to deserialize.

This however leads to another problem: what happens when something unexpected gets in the way. Hibernate is the most used, and thus most complained about when it comes to Serialization problems. Hibernate turns any Collection object into a special “lazy” implementation that will only load your data when you ask for it. All very fine and well for a server bound application, but a GWT application needs all that data up front for serialization. When GWT comes to sending that List<Message> to the client, it chokes. It knows how to serialize an ArrayList, and LinkedList (since you worked with them on the client side), but a Hibernate List or PersistentCollection is a totally unknown type, so it’s not in the Serialization Policy, so the server side throws an Exception at you.

So how does EoD SQL help with these problems? Read on to find out! 😉 Read the rest of this entry »

Eod SQL Applied – Part 1/5 (Introduction)


This is the first part of a series of posts, dedicated to how best to apply EoD SQL in different types of applications. Each post in this series will cover a specific type of application, and the different parts of EoD SQL that generally work best within those applications. The articles may dive fairly deep into the workings of the API, but at the end you’ll have a much better idea of where things fit in, and how they fit together.

EoD SQL well understands that (a) people like to do things differently and (b) one solution is not right for everything. While under the hood: any one part of EoD SQL works much the same way as any other part, as you climb the structural ladder, things begin to behave very differently. These behaviors have a massive performance and memory impact on your application and how you will be treating the underlying database drivers.

What we’ll be covering

  1. Swing Applications
  2. JSP / Servlets and “Related Technologies”
  3. JavaScript / JSON Applications
  4. GWT Applications

Although you could go with the “one size fits all” route (and EoD SQL would still perform wonderfully), the objective of these posts is to expose you to the different flavors of EoD SQL data structures and get you thinking about how you can mix and match them in your application to produce different results.

Why TraceMonkey is maybe the wrong way

With Firefox 3.5 finally out the door and in use I thought it was time to write something about it that’s been bugging me for a while. TraceMonkey (the new FF JavaScript engine) employs a semi-Hotspot approach to JavaScript compilation. Although the approach is quite different under-the-hood, the basic principal is the same: interpret the code until you know what to optimize. This makes abundant sense to me: why go through the expense of native compiling a method that only ever gets run once? However: there is a hidden expense to doing things this way: your compilation unit is often much smaller. Smaller compilation-units means more compiled code that needs to go back and forth to interpreted code. It also means you can’t optimize as heavily (although that optimization has it’s own massive expense).

Where am I heading with this? I think the TraceMonkey approach adds huge value to a language like Java where an application consists of hundreds and / or thousands of classes (both those in the application and all of it’s dependent APIs), in this case: you’re loading time would be abysmal if you pre-loaded all the possibly used code and native compiled it on start-up. However in the JavaScript world we are limited by the connection, and JavaScript applications (even really huge ones like those written with GWT) are relatively small. In this case it makes more sense to me to either compile everything up front; or run everything interpreted and run a massive compilation in the background (hot-swapping the implementations when you’re finished the compile).

It’s just a thought. Maybe FF should adopt v8 and see what happens?

GWT’s new Event Model – Handlers in GWT 1.6

Theres a lot of concern and worry around the “new event model” in GWT 1.6: throwing out Listeners (a well know and used Java construct) and replacing them with Handlers (a GWT team invention). Let me put your mind at rest, Handlers will make your GWT life much easier.

So what are the differences between Listeners and Handlers?

Listeners Handlers
Have one Listener per event source (ie: “mouse”, “keyboard”, etc) Have one Handler per event type (ie: “mouse press”, “mouse down”, “mouse up”)
Are uncategorized, and the Widget is responsible for sinking / un-sinking the DOM events Are categorized into 2 types: DOM and Logical, adding a DOM Handler to any Widget deferrers to Widget.addDomHandler which sinks events as required
Each Widget uses a ListenerCollection for each class of Listener added All Handlers are stored with a HandlerManager which also manages dispatching any type of event (including new ones you create yourself)
Listeners are removed with the pattern Button .removeClickListener(listener); Adding a Handler returns a HandlerRegistration object, removing a Handler is done by calling HandlerRegistration .removeHandler();
GWT Listeners accept a parameter for each bit of relative event information (ie: sender, mouse x, mouse y) Handlers (more like normal Java Event Listeners) are passed an Event object with all the Event details as their only parameter

So what do Handlers actually buy you in code?

Possibly the most important thing to notice is they take up a lot less space when compiled to GWT. This in mainly due to the fact that their management is centralized in HandlerManager instead of requiring a separate ListenerCollection for each Listener type, and that an implementation only needs a single method overridden (instead of having to listen for events you’re not interested in).

Another point to take note of is that all DOM related Event objects extend from DomEvent. Why is this important? Because DomEvent includes the methods:

  • preventDefault()
  • stopPropagation()
  • getNativeEvent()

I find the last (getNativeEvent()) to be the most useful, it works much the same as Event.getCurrentEvent() and returns a NativeEvent (the new parent class to Event). The advantage of this mechanism over Event.getCurrentEvent() is that you have all the access to the underlying event information (mouse button, modifiers, etc) but attached directly to the dispatched event.


Handlers are a good step forward for GWT, and make abundant sense in a Web environment where code size is very important. They also make it much easier to add you own events since you no longer need to manage your own Listener registration / deregistration cycle or firing of the events to all of the registered Listeners (HandlerManager does it all for you). I think there will be some interesting new patterns emerging with regards to managing events on generated structures (built based on data fetched from the server for example).

I’m looking forward to seeing what comes of these changes.

Easy GWT Database Binding with EoD SQL

Connecting Java to a Database effectively can be a lot of work at the best of times. Sure JDBC does make life easy for us, but theres still turning to ResultSet into nice Java Objects. When you throw GWT into the mix, what was a lot of work becomes a bit of a nightmare (especially when you’re trying to work with JPA or Hibernate). Fortunately EoD SQL comes to the rescue!

For those of you who are either new to my blog or new to EoD SQL, go check-out this little snippet of code over on the EoD SQL homepage. You can think of EoD SQL as a very lightweight Hibernate. It’s also the perfect way to connect you GWT application to your database. Unlike Hibernate and JPA, EoD SQL requires no modification or work-arounds to get it to work perfectly with GWT.

You do need to keep to 2 very simple rules however:

  1. Your Query interfaces may not return DataSet or DataIterator objects (since they require a working JDBC Connection)
  2. You will still need an RPC Servlet between GWT and EoD SQL

That said, there are strong upsides to these “limitations”:

Instead of returning a DataSet or DataIterator: have your Query interfaces return single objects, or arrays of objects. Arrays are heavily optimized by EoD SQL and since your application is actually running in a browser somewhere, you want to provide it with the entire ResultSet (and not lazy-load the data, which is where the default Hibernate and JPA models fall over).

Instead of exposing your database methods directly to the client: you should place the functionality behind a RemoveServiceServlet anyways! Why? Because it gives you a good chance to verify that the user is allowed to take the given action on the database. If, for example, you wrote a forum application, and you had an admin-only “deleteForum” method that you exposed. If the RPC Servlet just deleted the forum and returned, anyone who got hold of the URL and knew anything about GWT RPC could delete every forum in the database. Not really something you want to allow.

EoD SQL works with GWT without any modifications. This is mostly due to the fact that EoD SQL is designed to be a “what you see is what you get” API. The fact that it doesn’t manage parent-child relationships automatically is also advantages in that it forces you to think about what data is going to be needed on the client side. Bare in mind that GWT by it’s very nature runs in a limited environment on the client, sending and receiving complex object graphs is never a good idea. It’s better to lazy-load child relationships when there is a strong chance the child data will not be needed.

I may consider an eod4gwt API which includes a special RPC Servlet implementation for handling EoD SQL requests (which would allow you to put the @Select and @Update annotations in your RemoteService interface). There would need to be a demand for it though 😉

Using PropertyChangeListeners to ease GWT Async Calls

A while back I blogged a simple set of classes to make Property Binding easier in GWT, it’s also tied to GWT’s RPC system. I did not, however, provide an example of how this worked. The GWT list sees a lot of questions around asynchronous behavior, so heres an nice little example of how the Property pattern can be used to simplify RPC:

public class MyModule implements ModuleEntryPoint, PropertyChangeListener {
	private final Property<User> user = new Property<User>("user");

	private final TextBox username = new TextBox();

	private final Label firstName = new Label();

	private final Label lastName = new Label();

	private final Label dateOfBirth = new Label();

	public void onModuleLoad() {
		// we need to listen for change events on the "user" Property

		// make a GUI to search and display the User data with
		final Grid grid = new Grid(4, 3);

		grid.setWidget(0, 0, new Label("User Name: "));
		grid.setWidget(0, 1, username);
		grid.setWidget(0, 2, new Button("Load", new ClickListener() {
			public void onClick(final Widget sender) {
				// we need an instance of our pretend RPC service Async interface
				final UserManagerAsync manager = GWT.create(UserManager.class);
				// we ask it to find the user by the name typed into the TextBox
				// and we pass the AsyncCallback as the "user" Property object
				manager.findUser(username.getText(), user);

		grid.setWidget(1, 0, new Label("First Name: "));
		grid.setWidget(1, 1, firstName);
		grid.setWidget(2, 0, new Label("Last Name: "));
		grid.setWidget(2, 1, lastName);
		grid.setWidget(3, 0, new Label("Birth Date: "));
		grid.setWidget(3, 1, dateOfBirth);


	public void propertyChanged(final SourcesPropertyChangeEvents source, final String propertyName,
			final Object oldValue, final Object newValue) {

		if(propertyName.equals("user")) {
			// if the service returned null (no User found) we clear the labels
			if(newValue == null) {
			} else {
				// otherwise fetch the new User object and fill in the labels
				final User u = user.get();

To understand this code better you should look at the original post where I detailed the supporting
classes (PropertyChangeListener, Property, etc.).

Fixing Compilation in GWT4NB

By default GWT4NB recompiles all of your client code with the GWT compiler whether or not you’ve changed it. This is a time consuming (and sometimes irritating factor). After a recent discussion on the GWT dev mailing list (which I was away for most of), I decided to post the solution I use here and on the mailing list.

In your projects build.xml, just copy-and-paste the following:

<target name="-post-compile">
<property name="output.js" location="${build.web.dir}/${gwt.module}/${gwt.module}.nocache.js" />

<target name="debug" description="Debug project in IDE." depends="init,compile,compile-jsps,-do-compile-single-jsp" if="netbeans.home">
<property name="gwt.compile.unneeded" value="true" />
    <antcall target="dist"/>

    <nbdeploy debugmode="true" clientUrlPart="${client.urlPart}"/>
    <antcall target="connect-debugger"/>
    <antcall target="debug-connect-gwt-shell"/>

<target name="-pre-dist">
    <condition property="gwt.compile.unneeded">
            <available file="${output.js}" />
                <srcfiles dir="${src.dir}" includes="**/client/**/*.java" />
                <mergemapper to="${output.js}" />
    <antcall target="do-gwt-compile" />

<target name="do-gwt-compile" unless="gwt.compile.unneeded">
    <!-- You can override this property in the 'gwt.properties' file -->
<property name="gwt.compiler.output.style" value="OBFUSCATED"/>
<property name="gwt.compiler.logLevel" value="WARN"/>

    <java classpath="${javac.classpath}:${src.dir}" failonerror="true"
      classname="com.google.gwt.dev.GWTCompiler" fork="true" maxmemory="512m">
        <arg value="-out"/>
        <arg path="${build.web.dir}/"/>
        <arg value="-style"/>
        <arg value="${gwt.compiler.output.style}"/>
        <arg value="-logLevel"/>
        <arg value="${gwt.compiler.logLevel}"/>
        <arg value="${gwt.module}"/>
<property name="gwt.output.dir" value="${gwt.module}"/>
    <move todir="${build.web.dir}/${gwt.output.dir}">
        <fileset dir="${build.web.dir}/${gwt.module}"/>

What does it actually do? It checks to see if the client side code is newer than the module.nocache.js file in the web output. Since GWT overwrites this file every-time it compiles (and in GWT 1.5 actually deletes it first), it will only be older if one of your source files has changed.

Hope this helps you out, happy coding!

Edit 11/14/08: The script is now fixed to only build using normal javac when run in debugging mode.

Easy Property Binding and Aync Callbacks in GWT

This is a little technique I came up with a few days ago that makes Async Callbacks a lot easier. It also adds something a lot like Property Bindings to GWT with very little work.

public interface PropertyChangeListener {
    void propertyChanged(SourcesPropertyChangeEvents source, String propertyName, Object oldValue, Object newValue);

public interface SourcesPropertyChangeEvents {
    void addPropertyChangeListener(PropertyChangeListener listener);

    void addPropertyChangeListener(String propertyName, PropertyChangeListener listener);

    void removePropertyChangeListener(PropertyChangeListener listener);

    void removePropertyChangeListener(String propertyName, PropertyChangeListener listener);


public class PropertyChangeListenerCollection extends AbstractCollection<PropertyChangeListener> {
    private final Map<String, Set<PropertyChangeListener>> listeners = new HashMap<String, Set<PropertyChangeListener>>();

    private Set<PropertyChangeListener> getListenersForProperty(final String name) {
        Set<PropertyChangeListener> set = listeners.get(name);

        if(set == null) {
                set = new HashSet<PropertyChangeListener>();
                listeners.put(name, set);

        return set;

    // this is a simple utility method that avoids duplicate copies of the same
    // PropertyChangeListener
    private Set<PropertyChangeListener> getAllListeners() {
        final Set<PropertyChangeListener> all = new HashSet<PropertyChangeListener>();

        for(final Set<PropertyChangeListener> set : listeners.values()) {

        return all;

    public void add(final PropertyChangeListener listener) {
        add(null, listener);

    public void add(final String property, final PropertyChangeListener listener) {
        if(listener != null) {

    public void remove(final PropertyChangeListener listener) {
        if(listener != null) {
            for(final Set<PropertyChangeListener> set : listeners.values()) {

    public void remove(final String property, final PropertyChangeListener listener) {
        if(listener != null) {

    // although unused I've provided a simple implementation of the size method
    public int size() {
        return getAllListeners().size();

    public Iterator<PropertyChangeListener> iterator() {
        return getAllListeners().iterator();

    public void firePropertyChangeEvent(final SourcesPropertyChangeEvents source, final String name,
            final Object oldValue, final Object newValue) {

        final Set<PropertyChangeListener> propertyListeners = new HashSet<PropertyChangeListener>();

        for(final PropertyChangeListener l : propertyListeners) {
            l.propertyChanged(source, name, oldValue, newValue);

public class Property<T> implements SourcesPropertyChangeEvents, PropertyChangeListener, AsyncCallback<T> {
    private final String name;
    private T value;
    private PropertyChangeListenerCollection listeners;

    public Property(final String name) {
        this(name, null);

    public Property(final String name, final T initialValue) {
        this.name = name;
        this.value = initialValue;

    public void set(final T newValue) {
        final T oldValue = value;
        value = newValue;

        if(listeners != null) {
            listeners.firePropertyChangeEvent(this, name, oldValue, newValue);

    public T get() {
        return value;

    public void onSuccess(final T newValue) {

    public void onFailure(final Throwable error) {
        if(GWT.getUncaughtExceptionHandler() != null) {

    public void propertyChanged(final SourcesPropertyChangeEvents source, final String propertyName,
        final Object oldValue, final Object newValue) {


    public void addPropertyChangeListener(final PropertyChangeListener listener) {
        if(listeners != null) {
            listeners = new PropertyChangeListenerCollection();


    public void addPropertyChangeListener(final String propertyName, final PropertyChangeListener listener) {
        if(listeners != null) {
            listeners = new PropertyChangeListenerCollection();

        listeners.add(propertyName, listener);

    public void removePropertyChangeListener(final PropertyChangeListener listener) {
        if(listeners != null) {

    public void removePropertyChangeListener(final String propertyName, final PropertyChangeListener listener) {
        if(listeners != null) {
            listeners.remove(propertyName, listener);


Instead of storing your bindable properties as normal fields: you simply wrap them in Property objects. You can then use the fact that Property objects both produce and consume propertyChangeEvents to bind them together, and even pass them into RPC methods to be set when the server hands the data back to you.

They rely on a PropertyChangeListenerCollection class that I haven’t given here, but it’s a simple enough class to write.

11-November-2008: I added in an implementation of the PropertyChangeListenerCollection class.

Give it a try, it makes life a surprising amount easier considering it’s size.

A useful GWT RPC pattern I’ve been using

GWT RPC calls can wind up all over your code, doing all sorts of weird things. If you’re not careful about how you code them you can end up with bugs and other problems cropping up. The other part of RPC calls is that some of them are actually recoverable, and may even be retried a few times before giving up.

I developed the following little bit of code recently that may be useful to anyone doing RPC in GWT:

public abstract class RetryAction<T> implements AsyncCallback<T> {
    public abstract void attempt();
    public abstract void oncapture(T value);

    public void onFailure(Throwable error) {
        try {
            throw error;
        } catch(InvocationException invocationException) {
            Window.alert("A fatal error occurred, you should login " +
                "again or contact Technical Support");
        } catch(IncompatibleRemoteServiceException remoteServiceException) {
            Window.alert("A fatal error occurred, you should login " +
                "again or contact Technical Support");
        } catch(SerializationException serializationException) {
            Window.alert("A fatal error occurred, you should login " +
                "again or contact Technical Support");
        } catch(Throwable throwable) {
            String message = throwable.getLocalizedMessage();

            if(message == null) {
                message = throwable.getMessage();

            if(message == null) {
                message = throwable.getClass().getName();

            if(Window.confirm("An error occured:\n" + message + "\n" +
                "You may retry this operation by clicking 'OK'.\n" +
                "However if the error persists, contact Technical Support.")) {


    public void onSuccess(T value) {
        try {
        } catch(RuntimeException error) {

The way this structure works is that you implement your RPC call in the “attempt” method, and the callback in the “oncapture” method. If a “non-fatal” error occurred, the user is given the opportunity to “Retry” the operation (resulting in another call to “attempt”). The pattern groups the RPC invocation nicely with it’s response logic. Here’s a little example:

public class GetContactListAction extends RetryAction<Contacts&#91;&#93;> {
    private ContactList contacts;

    public GetContactListAction(ContactList display) {
        contacts = display;

    public void attempt() {

    public void oncapture(Contact[] data) {

And then to use this action:

GetContactListAction action = new GetContactListAction(contactList);

GWT RPC is (?:called) Aynchronous for a reason

GWT RPC is totally asynchronous. You have no option to implement a synchronous call to the server. Many people find passing a callback to every remote method in order to receive the return value frustrating, and the fact that it returns immediately decidedly strange.

For those new to GWT, here’s a description of GWT RPC in pure Java terms. Read the code carefully and things will make a lot more sense.

First the definition of the service. Think of this like an RMI service interface.

public interface MyService extends RemoteService {
 public String getText();

This is the interface the GWT client (Javascript) side of things will be using. The reason GWT makes you use this interface in because on the client side we need to call the method, and then receive the response some-time in the future. You can think of an AsyncCallback as an EventListener, when the server sends the response back, you get an event containing the success or failure data.

public interface MyServiceAsync {
 public void getText(AsyncCallback<String> callback);

Now our Servlet is the implementation of the MyServer interface. You can think of this like the implementation of an RMI service or an EJB. The reason you extend RemoveServiceServlet is two-fold: (1) You need an HTTP path that the client can send data to. (2) Rather than forcing you to decode GWT’s flavour of Serialization and invoke the methods by hand, RemoteServiceServlet does it all for you (so all you do is implement the actual methods).

An important note here. This code runs on the server, under a real Java VM. It’s not compiled by GWT, it’s not even looked at in fact. You can use any classes here (surprisingly, this is something that catches a lot of people out).

public class MyServiceImpl extends RemoveServiceServlet implements MyService {
 public String getText() {
  return "Hello World";

Now for our implementation on the client side. This is not how you would code this method call in GWT, this is a normal Java representation of what happens.

public void onModuleLoad() {
 // This is a purely local representation of what
 // GWT.create(MyService.class) would do for you
 MyServiceAsync async = new MyServiceAsync() {
  // Our pretend implementation. In real GWT,
  // this object would be on the other side of the network
  MyServiceImpl impl = new MyServiceImpl();

  public void getText(final AsyncCallback<String> callback) {
   // When this method gets called, we spawn a
   // Thread to make the call to the server.
   // In JavaScript the call is often put in a queue,
   // by the browser and executed in a pool.
   // However, whichever way things happen the
   // method call returns immediately and does
   // not wait for the server to respond.

   Thread runner = new Thread() {
    public void run() {
     try {
      // Once we have the content, pass it
      // to the AsynCallback we were given.

     } catch(Exception error) {
      // If an Exception occurs (unlikely in our
      // little example here), we pass it to the
      // AsyncCallback to deal with.


   // Start our Thread and return.

 final Label label = new Label("Foo");
 asyn.getText(new AsyncCallback<String>() {
  public void onSuccess(String message) {

  public void onFailure(Throwable error) {


So you can see from the example above that “Bar” may appear on the label, but it’s not likely. Far more likely is “Hello World” coming from our “server”.

There are a good reasons why GWT only allows for this sort of call.

  1. JavaScript has no threading model in place. It’s impossible to Object.wait() for something to Object.notify() you, which would be exactly how you would implement this sort of invocation in normal Java (if only under the hood)
  2. Anyone who has used Swing extensively will know that doing lots of work in the event-dispatch-thread is a disaster. It stops repaints from happening, the application is basically unusable until you’re “event” in complete.In order to get around race-conditions and such multi-threading problems, JavaScript is all executed from within the browser event-queue. So if we sent a request to the server synchronously, the user wouldn’t even be able to open the file menu until the server gave us a response. “But I’m in a LAN” I’ve heard some say. GWT’s RPC mechanism is built for general consumption. Lazy Developers + Synchronous Calls + Open Internet is a recipe for disaster (and a lot of complaints on the mailing-lists), and the GWT devs know it.

Asynchronous RPC with callbacks can be considered a small price to pay for an amazing amount of power. Personally I see it as even more power, as is breaks your code into smaller modules. I often have a single AsyncCallback class handling many different invocations from the server. Using this technique helps make your code smaller to deploy, and easier to maintain.