Fun with Unicode

I've been working on this application that has a Swing frontend which is being generated from Visio diagrams in Visual Basic (don't laugh, it's actually pretty clean code). I need to populate this huge form from our domain objects. The problem is, we don't have all the needed fields in our domain objects (yet). I can make the form come up with all these empty textfields, but it's hard to tell if the fields are empty because we have a null value in the database or it's because I didn't populate it. I need some kind of visual indicator to differentiate the unpopulated fields from null values.

Then I thought to myself, java strings are built on top of Unicode, I am sure there is some kind of Unicode character I can use that'll really stand out. A bit of googling led me to this site, and long behold ✘ would work beautifully. In java, that's "\u2718". Pretty neat, don't you think?

Suicidal code

Have you seen code that's so bad if it had any feeling it would trigger an EMP next to the source control server to commit suicide? Well, I have. And here is an example:

 public synchronized void invoke(AbstractCommand command)
 {
    if (command == null) return;
    remoteDoIt(command);
    if (command instanceof Undo)
    {
       undo();
       return;
    }
    if (command instanceof Redo)
    {
       redo();
       return;
    }
    if (command instanceof Update)
    {
       command.doIt();
       return;
    }
    if (command.doIt())
    {
       history.addLast(command);

       if (redo.size() > 0)
       {
          redo.clear();
       }
    }
    else
    {
       history.clear();
       updates.clear();
    }
 }

To make matters worse, Undo, Redo and Update are all empty "marker" interfaces. Refactor this!

Spring remoting compared

Spring framework supports several remoting mechanisms. I've always wondered how they perform comparing to each other. So today I did a quick a comparison. In the application we are developing, the Swing GUI client retrieves several thousand objects from the server at startup. With straight RMI, the retrieval typically takes 1-2 seconds.

To test the other methods (Spring's HTTP invoker, Hessian, Burlap), I need a web container. It took a while to set up jetty since I haven't used it before, but once I got that going it was trivial to switch the remoting methods.

Here are the numbers:

RMI: ~2 seconds
Spring's HTTP invoker: ~2 seconds
Hessian: 16-17 seconds
Burlap: 16-17 seconds

A few points of note:

• It makes sense that Spring's HTTP invoker performs similarly to RMI since both rely on java serialization under the cover. It's good to know that the HTTP protocol doesn't add much overhead.
• I was a little surprised that Hessian/Burlap performed so badly. The objects we retrieve are detached Hibernate objects. I wonder if that has anything to do with this.
• It's also surprising Burlap and Hessian performed similarly since Burlap uses XML while Hessian is a binary protocol.

This is just a simple test using our codebase in our environment. But still. I wonder if Hessian/Burlap are really that slow or I am missing on something obvious.