Dear Google: Please Fork Java

This is an open-letter to anyone at Google with a vested-interest in the long-term survival of Java as a language; and as a viable platform.

Since the early days of Java 7; I’ve been a concerned Java-citizen. Java feels like it’s loosing what made it a great language in the first place. It was the first programming language I ever learned. I more-or-less self taught myself with the aid of a (now very tattered) copy of “Core Java” (first edition). Java was great because it was simple to learn, but an inherently powerful environment to work in. The language (pre 5) was kept extremely simple, with little in the way of syntactic candy. For an analogy: it was Othello; while C++ was (and is) Civilisation. Java’s true power lay in the fact that the language was extremely simple to pick-up and work with, while the platform carried you forward as you built more and more complex software systems.

With Oracle now at the helm of Java; and the community drowning while trying the hold onto the rudder: I finally think that a fork of the code-base; and more importantly the specification is in order. The idea of forking Java makes me very sad; it’s got a special place in my heart (much the way Sun did as a company). However: sometimes you need to settle for the lesser of two evils, and in this case: leaving Java in the hands of Oracle is the greater evil.

Having seen the way Google manages projects such as GWT and Android; I believe (strongly) that Google engineers are in a much better position to steer the way-forward for Java. The fork wouldn’t necessarily be called “Java” any-more; a branding overhaul would be needed to avoid further litigation from a wrathful Oracle. I also don’t believe that in individual or small community forking the code-base and specification would work; simply because they would be unable to attract the required attention.

Google already has many resources invested in Java; some of those resources in areas of Java that few people understand. I strongly feel that a Google guided fork of Java as both a language and platform would not just be in the best interests of Google; but also the best interests of anyone in the Java community.

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! 😉

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.

Summary

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.

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>

<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>

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

<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}"/>
    </java>
<property name="gwt.output.dir" value="${gwt.module}"/>
    <move todir="${build.web.dir}/${gwt.output.dir}">
        <fileset dir="${build.web.dir}/${gwt.module}"/>
    </move>
</target>

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.

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.")) {

                attempt();
            }
        }
    }

    public void onSuccess(T value) {
        try {
            oncapture(value);
        } catch(RuntimeException error) {
            onFailure(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() {
        CONTACT_LIST_SERVICE_ASYNC.getContactList(this);
    }

    public void oncapture(Contact[] data) {
        contacts.populate(data);
    }
}

And then to use this action:

GetContactListAction action = new GetContactListAction(contactList);
action.attempt();

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.

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

      callback.onFailure(error);
     }
    }
   };

   // Start our Thread and return.
   runner.start();
  }
 };

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

  public void onFailure(Throwable error) {
   Window.alert(error.getMessage());
  }
 });

 label.setText("Bar");
}

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.

Why GWT is here to stay

I’ve been developing with plain JavaScript for several years now, long before the AJAX craze started (when my spell-checker posted a hidden iframe back to the server and such). Why would I be an advocate of GWT when I’ve written web-apps that include over 10’000 lines of JavaScript? Lets think of this a slightly different way: Why wouldn’t I be an advocate of GWT when I’ve had to maintain 10’000 lines of JavaScript?

Some of the common misconceptions about GWT:

• GWT is for people who don’t want to or can’t code JavaScript
• GWT is only there to hide browser differences (and there are plenty of JavaScript API’s that do this)
• GWT produces bloated JavaScript files
• GWT doesn’t let a graphic designer produce the User Interface
• GWT takes away the raw power of JavaScript
• GWT is a plain Java to JavaScript compiler

I see these complaints everywhere. Those who make them are mostly PHP developers, or people who have never worked on a commercial browser based system that requires large amounts of JavaScript.

At this point, let me say something about GWT that I don’t see explicitly said often enough:

GWT is a Web Application framework!

GWT’s space is not in putting an auto-completing text-input on an otherwise fairly static HTML page. There are plenty of JavaScript API’s that will do that for you. GWT is not “Swing for the browser” either! GWT is more like the Java Desktop Application Framework, or the Netbeans Platform. GWT is not about simply building a user-interface, it’s about reducing the load on your server.

A serious flaw in web frameworks like Struts or WebWork is the amount of data they store in the session. The unfortunate fact is that storing data in your session is very expensive for your server cluster. It’s fine running on a single machine; or if you have very intelligent load balancers, however: running on a larger cluster, or trying to handle tens-of-thousands of simultaneous users becomes really hard.

Why is the session expensive?

In Java you have wonderful Serialization of objects. References are correctly rebuilt when loading a serialized object and so on. Using an HttpSession in a clustered environment however, means that every object in the Session is re-written across the network at the end of every request. Why not just the objects that have changed? The answer is simple: how do you know which have changed?

Struts for example stores all of the Action objects in the Session. Thats potentially a lot of objects to store, and move around between servers. How does this relate to GWT though? In GWT you can place your “index” page behind a standard Filter or a <security> mapping in your Web XML to handle the login of your users, and have GWT work through a service style system, where your servers act in a stateless manor. This drastically reduces the load on your servers, since they no longer need to hold session data in memory or synchronize it with the other servers at the end of each request. In fact, the GWT application can cache the resulting data on the users browser instead of in the Session!

But what about my Graphic Designer?

When developing a desktop application, you generally have a user interface designer working with you (if you don’t, go hire one). Like I’ve already said: GWT is for building applications that happen to run inside a web browser. If you are building a web site, you should probably look at a different technology (though keep GWT in mind all the same). A user interface designer is often not a developer, and so can’t actually write the user interface.

The other side of this argument is: what is your web designer doing writing your HTML?!?!?! In my experience,the web designer produces an image (often in PhotoShop) of the look & feel for the site, and then provides you with the graphical elements you need as you write the HTML for the site. Having a web designer produce HTML is always a bad idea, no matter how much they know about it. If nothing else: HTML limits their creativity.

But I know plenty of JavaScript, why hide it behind Java?

A note to those with this argument:

• Get off your high horse and get back to work

JavaScript is a very powerful language, GWT is not hiding it away behind Java. If you need to code JavaScript in your GWT application: use JSNI, thats what it’s there for. The problem with AJAX is not JavaScript, it’s the way it’s implemented across different browsers. You eventually wind up with loads of “if(browser == IE)” and such all the way through your JavaScript. I won’t even bother to mention the nightmare that is passing events in JavaScript. GWT neatly deals with all of that for you, without any browser checks in the produced code (well, there is one to decide which version of the application to load).

Summary

GWT does not cripple you by having you code Java, it empowers you to do more with less code. The amount of code produced is often smaller than the pure JavaScript API’s that hide browser differences. It’s also a lot easier to work with.

You spend more time working on your application logic and less time re-inventing the wheel.

GWT’s Hidden Strengths

I’ve been working on a particularly complex web interface recently, and have ended up writing tags to check the browsers so that layout and CSS can be different for certain browsers (not just IE, but Firefox as well). It’s plain old JSP’s and Servlets, and it’s a serious headache thanks to the complexity of the page layout. Theres even JavaScript the assists in the layout of each page.

Every-one by now knows that GWT buys you great cross-browser JavaScript (by writing different JavaScript for different browsers). What most people don’t know is that GWT also buys you is a moderately consistent look-and-feel across browsers. If you want to use weird and wonderful CSS, thats your affair, but in terms of the widget layout, it’s very consistent (assuming you don’t use CSS to layout your widgets).

I specifically exclude the use of CSS, since CSS behavior is so different between the different browsers that you almost want a Servlet to serve up different CSS for each browser (something very easily achieved by using the “User-Agent” header).

GWT’s other big strength is the time to market effect. It’s amazing how little code you need to write to get something working out of the door. So: first write in GWT, launch, then back port for older browsers and such.