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.

I want to go shoot some photo’s, but it’s cold.

If anyone sees my gloves, please let me know where they are.

Thanks.

As anyone who has coded with GWT will know, it includes some basic “emulation” of a few of the core JRE classes. The classes included are from: java.lang, java.util, java.io; and as of 1.5 java.sql (just the date related classes).

The reason it’s called emulation is that most of these classes back onto JavaScript types and structures using JSNI, and so are not entirely written in Java. Some of them also deliberately violate the contracts of their normal Java peers. For example, ArrayList has a constructor that takes an initial capacity. In JavaScript an Array object automatically resizes itself, so there is no gain in trying to pre-allocate the capacity. So GWT’s version of ArrayList ignores this parameter.

If you go and look at the list of supported JRE classes, you’ll notice many normal JRE classes missing. You’ll also notice many classes in GWT (under the com.google.gwt.* packages) that least fit the same role as a missing JRE class. For example: GWT has no java.util.Random class; it does however include the com.google.gwt.user.client.Random class. GWT’s Random class looks nothing like the JRE version, all it’s methods are static (nextBoolean, nextDouble and nextInt), and it has no constructors.

Why doesn’t GWT include the java.util.Random class, but instead has it’s own Random class? java.util.Random supports a specified seed and is based on a specified Pseudo Random Number algorithm (therefore any two instances with the same seed will produce the same sequence of numbers). However, JavaScript’s random number generation doesn’t. In order to keep code-size down (and speed up) GWT’s Random number generator backs directly onto the JavaScript Math.random() function, which has no way to provide a seed, and you don’t know for sure what the backing algorithm will be.

In short: the JRE emulation in GWT provides a small set of commonly used classes that map well to JavaScript structures. For those JRE classes that don’t map well, or are less likely to be used in a client-side web application (think MessageDigest, or UUID), GWT doesn’t provide an alternative.

The Advert (or ‘In Conclusion’): Because there are many useful classes in standard Java that are not in GWT, I’ve started implementing GWT friendly versions of several (ie: java.util.Random, java.util.UUID, java.security.MessageDigest). Once they are more complete I will be releasing them under an Apache style license. Several of these classes will include multiple implementations with different goals (the default being to keep the size down). You’ll be able to select alternative implementations by using GWT module properties.

Watch this space for more info.

A common problem in Java is Exceptions in static initializers. What on earth do you do with them? This has been discussed a bit on my local JUG recently, and here’s a bit of a summary.

Common solutions:

• Wrap the Exception in an ExceptionInInitializerError and re-throw it
  • This causes the entire class to be marked as “errored”, as though it didn’t validate
  • Any further use of the class will result in a NoClassDefFoundException, which can be confusing
• Log the Exception and continue as normal
  • If the log levels are set to high, nobody will ever see the Exception
  • Some Loggers get configured to drop stack traces
  • Sometimes the normal execution of code should stop
    • Someone configured something badly
    • The database is not running
• Both of the above is a common pattern as well, and is generally considered “best practice”

One solution mentioned is to lazy-instantiate the static fields in the class. This is a nice idea, but has a few flaws:

1. A synchronized block is needed, where static initializers are inherently very thread-safe
2. It incurs an additional expense in methods that will be using these fields
3. In the case of a singleton, it’s likely that the first method that will be called will cause the “lazy” code to run. Since classes are generally lazy-instantiated by the VM, a static initializer would achieve the same thing.

My solution was this one:

public class StaticInitializerExample {
 private static final Wrapper WRAPPER = createWrapper();

 private static abstract class Wrapper {
  private abstract StaticInitializerExample get();
 }

 private static Wrapper createWrapper() {
  try {
   final StaticInitializerExample c =
     new StaticInitializerExample();

   return new Wrapper() {
    public StaticInitializerExample get() {
     return c;
    }
   };
  } catch(final Exception e) {
    return new Wrapper() {
     public StaticInitializerExample get() {
      throw new RuntimeException(e);
     }
    };
  }
 }

 public static StaticInitializerExample getInstance() {
  return WRAPPER.get();
 }

 private StaticInitializerExample() throws Exception {
  // do code that could throw an exception
 }
}

So here’s the question (and first post in a very long time):

Who would like to see EoD SQL opened up even more?

EoD SQL at the moment is open-source, but even an open-source project is in a way: closed. To add new functionality to EoD SQL you need to climb into the source code. So here’s the idea:

A new MethodImplementationFactory interface that you can implement to provide functionality for a single type of method that could exist in a Query interface. It would look something like this:

public interface MethodImplementationFactory {
    public Class<? extends Annotation> getAnnotationType();

    public void validate(Method method) throws InvalidQueryException, InvalidDataTypeException;

    public MethodImplementation create(QueryImplementation implementation, Method method);
}

The MethodImplementation itself will be an interface (in a way) a lot like java.lang.reflect.Invocationhandler, as it will be the object called to fulfil a method invocation on the implementation object. The MethodImplementation will be provided with plenty of support methods for handling Connection objects correctly and so on, making development of new method implementations much easier.

Why make this change?

This change would allow for easy development of new Annotation instructions, for example: @BatchUpdate or @Call (both requested features). The new instructions could be mixed in with existing annotations such as @Select and @Update without any additional code.

Any thoughts on this? Comments are welcome!

EoD SQL 1.1 was released this morning. There are no major new features, but it’s well worth the download.

Included in the release:

• Updatable DataSet objects
• GeneratedKeys.RETURNED_KEYS_FIRST_COLUMN to work around a bug in Derby, or improve performance
• SPI query-generators (only available under Java 6)
• Improved DataSet documentation
• Lots of internal cleaning up
• Several small bug fixes

I’ve had a few (ie: 2) requests and inquiries for new features on EoD SQL. Here is the list so far:

1. The optional ability to use JDBC batch functionality (optional because not all drivers support it)
2. A way to use stored procedures from your query interface (probably a new annotation)

I will be working on these features soon (hopefully), although I’d like some input on the first one. How should this be implemented? You don’t want to force batching on a specific query. One option I thought of is a new “BatchUpdate” return type:

public interface MyQuery extends BaseQuery {
    @Update(sql="INSERT INTO users (name, password) VALUES(?{1.name}, ?{1.hashedPassword})",keys=GeneratedKeys.RETURNED_KEYS_COLUMNS_SPECIFIED)
    public BatchUpdate<User> createUser(User user);
}

Which you could then use as:

MyQuery query = QueryTool.getQuery(MyQuery.class);
BatchUpdate<Update> update = query.createUser(null);
query = update.getQuery();

for(User u : users) {
    query.createUser(u);
}

query = update.commit();

getQuery() acts a bit like a “Stack.push()” operation, while commit() acts like the “pop()”. There are loads of other possibilities on implementation here. Haven’t really gone into how the keys will work here, but you can imagine. Let me know what you think!

If you have a feature request, or if you are using EoD SQL for anything: comment! I’m always looking for feedback.

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.

A few days ago I released EoD SQL 1.0, and moved the project to Java.net. So now that 1.0 is out the door, where to next? There are several developments that will be taking place in EoD SQL land, and I’m looking for:

• People interested in developing on the codebase
• Input!
  • Bug Reports
  • Feature Requests
  • Ideas
  • What do you use EoD SQL for?

As of now, the next set of developments on EoD SQL include:

1. Writable DataSet objects
2. Internal optimizations
   1. Reuse PreparedStatements
3. Batch Processing (using the JDBC addBatch() methods)
   1. This will be an optional operation in order to cater for JDBC drivers that don’t support batches
4. Custom QueryFactory objects
   1. Based on the ServliceLoader class
   2. Only available for Java 1.6 or higher
   3. Those running 1.5 will not be able to use Custom QueryFactories
   4. Will be the base for an EoD SQL Query compiler

Let me know what you think of the upcoming feature set, what other features would you like to see, and if you’re interested in working on the EoD SQL project.

You often hear how much Linux like memory, and how much it eats up compared to Windows. It’s true! Linux eats into your memory, no matter how much you have, you never seem to have any free for applications to run in! I recently read an article where the author was complaining how Firefox ate into his memory under Vista. The sad fact of it is:

While Linux appears to eat more of your memory, it manages it much better than Windows does.

I have Firefox open right now, I have 10 tabs open with graphics intensive web sites. Firefox is claiming 200Mb of my precious memory… or is it? Actually no: real size in memory 90Mb.

The current list of the most memory intensive applications I’m running, and their “supposed” memory usage:

• Java (Netbeans) 600Mb
• Xorg 380Mb
• Firefox 200Mb
• Thunderbird 130Mb
• Amarok 120Mb
• Kwin (KDE) 120Mb

Now considering I only have 1.5Gb of memory in this machine that 50Mb to much, and considering there are a total of 120 processes running, I haven’t even started to cover the list. Now as any knowledgeable person will tell you, Linux is using some of the hard-drive and pretending that it’s memory, but since a hard-drive is slow, my computer will be running awfully slow.

Wrong! Yes, a disk is much much much slower than memory (especially a laptop drive like this one). However, my computer is running very very fast. Why? Linux’s memory manager notes what parts of memory are used frequently, and what parts are seldom accessed. This means that the parts that are used frequently stay in real memory, and the stuff no-one is using gets stored on the disk.

Translation: Linux will run much faster, and keeps things in memory in such a way as to speed things up! Under Windows, more free memory is better, under Linux it’s the opposite! Less free memory is better, since it means Linux is doing it’s job better.