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 4 / 5 (JavaScript)

JavaScript vs. Web Applications

So far in this series we’ve discussed using DataSets for Swing applications and DataIterators for web-applications. Why would I now bring in JavaScript as something outside of “web-application”? JavaScript applications have very different requirements to a normal web-application. Where a normal web-application has little ability to do things like preload data (like the next page), a JavaScript application may (for example) download the entire data-set and then display it in pages. This next section is about binding to JSON for JavaScript applications.

First thing to remember here is that an EoD SQL DataSet is a List and thus compatible with the Collections API. For this example we’re going to be working with the outstanding GSON API from our friends at Google. Our objective here is to minimize the amount of time spent between the Database and pushing the data to the client. Because GSON doesn’t appear to support Iterable object out-of-the-box, we’re going to start off using a DataSet.
Read the rest of this entry »

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?

Simple Credit Card Fraud Checks

Credit Card Fraud is one of the hardest problems to deal with as an online business, in many cases it comes down to a human check to ensure that the credit-card in valid before accepting it. Using automatic scoring services certainly helps, but doesn’t by any means eliminate the problem (since they can sometimes be horribly inaccurate).

Here are a few additional checks you can do from inside your system:

  • Blacklist card-numbers
    Some people have real plastic fake card and will re-use the number again and again. Blacklisting the number eliminates the need for a human check later down the line.
  • Blacklist email addresses
    If you have an email address verification (you may require a valid email address to distribute your product) you can easily blacklist an email address. It’s not 100% effective because people can get free email addresses, but most of these sorts of fraud transactions are done by hand, and it often takes some time for the person to figure out whats gone wrong.
  • Score based on previous transactions
    If you can identify the user (by name, email, or some other means) you can see how reliable they have been in the past.
  • Address Verification
    There are several services out there that will provide you with the billing address registered with the bank for a card-number. This will also determine whether such a card even exists.
  • Human Verification
    At the end of the day, there is no substitute for calling the person up and talking to them (and maybe getting a photo of the card faxed to you). However, this is costly and should only be done with the most suspect cards.

An automated JSON Encoder and Decoder for Java

I posed a little while ago that I’d implemented a JSON Encoding that worked a bit like Java Serialization. It works as such in that you don’t need to encode the objects by hand. As long as you follow some basic rules, the code will automagically turn your Java objects into JSON, and the JSON back into Java objects again. Well, I finally got my act together and the implementation is below. Consider this Public Domain code now! If it doesn’t work for you, it’s not my problem (that said, I’d like to know if it doesn’t work).

Before The implementation, heres a few things to know about it:

  1. It solves the Date problem in such a way that it’s transparent to the JavaScript code!
    1. Dates are encoded as “new Date(UTCTime)”
    2. They are decoded against a collection of date-formats (listed at the top of the JSONDecoder class)
  2. The encoding and decoding work against Reader and Writer objects, and thus have declared IOExceptions
    1. They expect to be closely tied to the Reader and Writer provided by the Servlet Container
  3. They both conform to the Java Beans specs, so if it’s not a bean property, it’s ignored
  4. The decoder can handle both the abstract Collection types and concrete types
    1. public void setUserList(List<User> users)
    2. public void setUserList(ArrayList<User> users)
    3. The Collections must have a solid type declared as their content (in the generic)
  5. Map objects are encoded as JavaScript objects
    1. Map keys must therefore be Strings
    2. The Map keys should be valid JavaScript identifiers

If you are going to use this code, I would appreciate a comment here (just to let me know).

Read the rest of this entry »

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

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.

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.

Backwards Content Compression

You don’t see it nearly as much as you should, but some web developers and server administrators are intelligent enough to put a compression filter (or module) in front of their web servers. When a browser that supports compression, the filter / module kicks in, and compresses the HTML, Image, Video, Flash or whatever is being fetched. The compression means that the file moves over the wire faster. Or at least thats the theory.

The fact is that for some instances (generated HTML code for example), the effort of compressing the file is more than it’s worth. In other instances (large images, or any static content for that matter), compression can make a huge difference. So I’ve started working with the idea of “Backward Compression”. The files are stored as “GZIP” files on the disk, if a browser that does not support compression requests the file, my filter decompresses it and sends it to the client. This has several advantages over compressing the files:

  • Most browsers support compression, so the file can be sent as is
  • GZIP decompression is cheaper than compression
    • Less effort is expended by decompressing for the browsers that don’t support GZIP
  • You can decide up front what should be compressed and what shouldn’t

How do you drink coffee?

I love coffee, I used to hate it, but now I simply can;t live without it. Like so many people in my line of work, I’m a caffeine addict. If I don’t have a cup of coffee or two in the morning, I get a splitting headache (tend to happen on Sunday when I forget to make myself a cup in the morning).

So how coffee do you drink?

  • Not at all?
  • Every now and then?
  • Lots of it?
  • Total addict?
  • Give me an IV dammit! 😛

And how do you drink it?

  • With milk and sugar?
  • With just milk?
  • Black?
  • Strong and Black?
  • Through a needle in my arm!

Yes this looks like a poll, but I prefer comments.