« Joel's Myopic view on Software Developers as Prima Donnas | Main | JavaDB is not in the Mustang JRE, Stop freaking out! »

If it isn't easy, people won't use it.

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.

Comments (1)

At the last project with Java I worked with, we ended up implementing our own queue system with a parallel worker thread. Having it in the API is the best thing that could ever happen, and it's bound to be less complicated than implementing it on your own...

Post a comment


About

This page contains a single entry from the blog posted on June 5, 2006 9:58 AM.

The previous post in this blog was Joel's Myopic view on Software Developers as Prima Donnas.

The next post in this blog is JavaDB is not in the Mustang JRE, Stop freaking out!.

Many more can be found on the main index page or by looking through the archives.

Powered by
Movable Type 3.33