... And They Shall Know Me By My Speling Errors

Talk about transparency in process, JSR-296 has hardly conviened and a good idea of what will actually be delivered has already been presented at JavaOne. (Ok, the pedantic folk will argue that this wasn't speced from scratch in public and thus is still closed process, but bringing a functional idea to a standards body is IMHO a better way to get working standards finished in a reasonable amount of time than design by committie. But I digress).

Everything to me looks good, except for one piece. The piece that really will improve the performance of swing applications more than the other items in the framework. Asynchronous actions (starting at slide 45) are too complex for the below average developer (or in other words, half of the developers). What is my arbitrary metric for why it is to complex? The sample code takes two slides in the slide deck. And almost all of it is boilerplate class text for the SwingWorker. SwingWorker is indeed a powerful tool, but too may developer will either (a) not get it or (b) be too lazy to do it when they need it.

So what would I do? First, I wouldn't pitch the "returns SwingWorker" idiom for actions; there are times that is absolutely needed. But what I would do is...

@Action(stage=SyncBefore) List<MyItem> saveItems() {
    return getMyItems();
}
@Action(stage=Async) String saveItems(List<MyItem>) {
    int nSaved = 0;
    for(MyItem myItem : myItems) {
      saveMyItem(myItem);
    }
    return "Items Saved";
}
@Action(stage=SyncAfter) void saveItems(String status) {
    jTextAreaStatus.setText(status);
}

And this is actually the "do everything" example for my pattern. The pattern this is indented to deal with is an action that (a) gets some state from the GUI widgets in the EDT (b) does something with that state and then (c) updates widgets afterwards in the EDT. Clearly not all of the GUI actions will be this simple, but it is the 80% solution. If you need multiple steps of (b) and (c), return a SwingWorker. If you are just refreshing date in a combo box from a database query, this is the one for you. A good portion of actions will do only two or even just one of those steps, so there may be even less overhead.

So how would this be parsed? There would need to be three identically named methods, one that returns type U and takes no params, one that returns type V and takes U as a param, and one that returns void and takes V as param. Each of those are (respectively) the EDT before, the async, and then EDT after portions of the action. If any of the methods are missing, U and or V will become Object, and the missing method will become a no-op.

For all of the moaning and groaning going in in the java blogosphere about JavaDB being integrated into the JDK, I feel a particular nuance needs to be pointed out...

For a great out-of-the-box development experience with database applications, the final Mustang development kit - though not the Java Runtime Environment (JRE) - will co-bundle the all-Java JDBC database, Java DB based on Apache Derby.

[What's New in Java SE 6 Beta 2 (Mustang) bullet point 3]

I will admint I missed that the first few times, and whined about how bad the bloat is becoming, but it is a tool that is going into the Developers Kit, not the Runtime Environment. It's like JConsole, the swing demos, and all of the ohter cool stuff we play with as developers. Joe user won't have to deal with it, unless you bundle it yourself. So take a deep breath, ease of the keyboard, and don't bile it just yet.