I used to use SwingWorker in a swing based application to execute some tasks that, being long lasting ones, I executed as background tasks. With respect to SwingWorker I used to create an anonymous SwingWorker instance, write an doBackground() method and put there all my background task logic. The main problem is that I realized after that I put event updating gui code in doBackground() method, which IS an error because I may cause EDT lock (as far as I understood).
Ok, I'll fix this problem but reading about SwingWorker I read that it should be used for any long-running task, to make GUI responsive. In a lot of GUI-events related methods (I mean methods which handle user's click on a JButton, or a selection in a JComboBox for example) I call a remote service method (exposed via EJB). These businesse methods may required a given amount of time to be performed (generally under a couple of seconds). With try - catch - finally usage I'm able to set a waiting cursor until remote method returns to the caller, and restore default cursor when execution is done, but I wonder if this approach may
create problems with EDT (I mean: to hung EDT) , and, if the answer is yes, if I need to isolate from EDT any remote call by using a SwingWorker.
The normal way is to use 2-3 extra methods: publish, process and optionally done.
publish can be called within doInBackground. Anything you publish (limited to the generic type) will, at some point in time, be sent to process. Since process is executed on the EDT, you can interact with your user interface without any problems. The only thing you need to be careful about is that the arguments to several publish calls may be collected for one single process call. Don't assume that process is called immediately after publish.
done is called on the EDT after doInBackground finished, so you can use that to do some after-work user interface interaction (like possibly re-enabling GUI controls you have disabled just before the SwingWorker started).
Whenever you need to do something in your Swing application that takes longer than a few milliseconds (i.e. that would block your UI if executed on the EDT), it should be executed on a thread that is not the EDT. A SwingWorker is one of the easier ways to do this, but a simple thread could also be used. In that case you can make life a bit easier by using a SecondaryLoop.
Thanks again.... even if I have to admit that I think it's really really unpractical to recur to a SwingWorker every time you need to perform something important in terms of time consumed. For example, even opening a JDialog by pressing a JButton may be "time consuming" if the invoked JDialog requires a quite complex initialization - let's suppose to have a JDialog which executes a query and display its results.
Rob, I really don't want to bother you...but.. What are the risks associated with not using SwingWorker in such cases? An un responsive GUI is what i want - user must wait until method finishes, bit i don't want a lock in EDT which blocks forever my application.