SwingWorker and the Event Dispatcher Thread

[smokingapipe]

One of the main reason incorrectly-written Swing apps are bad is that people do work on the event disptach thread (EDT). They'll have some event handler which loads and parses the file right within the event dispatcher itself. If the file can load and parse in 0.05 seconds, fine, but if it takes 0.5 seconds or 1 second or longer, you have a frozen GUI during that time and people start repeating all those things they say about Swing. Anyone who is a real Swing developer moves all that work over to a thread, often one that is written with the friendly SwingWorker class, that lets us do the work and then do more stuff on the EDT (where GUI draws are safe) after the work is done.

The exact same problem comes up in Web applications. You get a request from the user to do a batch update. Wrong: do the batch update within the session bean or servlet that is called during the request. It may not look wrong because during testing, when your table has only 100 rows in it, but when it has 100,000,000 rows on the live system, the response to the browser will time out.

What's the JBoss / Seam equivalent of a SwingWorker in this case? Should I create an MDB and queue up the job on it? That seems obvious. It would be cool if there were something as small and light-weight as the SwingWorker though, espeically if it could send "I'm working on it" updates back to the GUI.

This seems to be one of the areas of web app building that isn't built out yet or properly understood by a lot of developers, the way SwingWorker is built out for Swing developers. Or else I've totally missed it in the tutorials I've read. I am a newbie to Seam and JBoss so that's very possible.

[pmuir]

An asynchronous event? You could get it to write out a progress string/number and poll that using ajax (nothing in Seam at the moment to do this easily I think... - but Shane would know better)

[smokingapipe]

Well, SwingWorker itself is a lot different from just handling things asynchronously. It's a thread class that you sub-class, and you have a few methods:

doInBackground: When the SwingWorker is executed, this is the part that starts running. Obviously it happens in a thread so the GUI keeps on redrawing and responding to events. This is the essence of good Swing app building. doInBackground can publish notifications to...

process(): This receives information of various types from doInBackground and CAN safely update the GUI. process() runs on the EDT and must return quickly.

and finally...

done(): this runs on the EDT after everything else is done.

This is the only right way to handle things in Swing (either using SwingWorker or some other similar thread-based model). And many processes on the web are similar. The web request must return promptly, just like things on the EDT must return promptly. Long-running work should not be done either during the web request or on the EDT, for similar reasons. In both cases we would like a publish() method to update the user of the status of long-running work. And in both cases we want a done() method to let the user know that the long-running task is done.

MDBs are not as light-weight or as natural of a fit as SwingWorker, but they're one of the few ways I can see to do things asynchronously within the Seam world. I could be totally wrong on that of course, being a newbie to it.

[pmuir]

Well the main way of doing things asynchronously in Seam is to use @Asynchronous methods. Sure, it's not SwingWorker but it and ajax (and perhaps using Seam events) give you all the tools you need to do what you describe in your first post.

MDBs are for communicating between java programs (JMS) and with legacy code (JCA).

[smokingapipe]

Ahh, ok, I said I was a Seam newbie and now it is confirmed. I need to look up @Asynchronous because from the name of it, that sounds like what I want.

[pmuir]

http://jira.jboss.com/jira/browse/JBSEAM-984