What is the reason SwingWorker?

Question

For what I can read, it is used to send a new thread in a swing application to do some “background” work, but what is the use of using this rather than a “normal” thread?

Not the same with using the new thread, and when does it end the invocation of some GUI method using SwingUtilities.invokeLater? ...

What am I missing here?

http://en.wikipedia.org/wiki/SwingWorker

http://java.sun.com/products/jfc/tsc/articles/threads/threads2.html

Answer 1

Yes, you can accomplish what SwingWorker does with vanilla streams + invokeLater. SwingWorker provides a predictable, integrated way to perform tasks in the background thread and the result of an EDT report. SwingWorker additionally adds support for intermediate results. Again, you can do it all yourself, but it is sometimes easy to use an integrated and predictable solution, especially when it comes to concurrency.

Answer 2

Code example:

import org.jdesktop.swingx.util.SwingWorker; // This one is from swingx // another one is built in // since JDK 1.6 AFAIK? public class SwingWorkerTest { public static void main( String[] args ) { /** * First method */ new Thread() { public void run() { /** Do work that would freeze GUI here */ final Object result = new Object(); java.awt.EventQueue.invokeLater( new Runnable() { public void run() { /** Update GUI here */ } } ); } }.start(); /** * Second method */ new SwingWorker< Object , Object >() { protected Object doInBackground() throws Exception { /** Do work that would freeze GUI here */ return null; } protected void done() { try { Object result = get(); /** Update GUI here */ } catch ( Exception ex ) { ex.printStackTrace(); if ( ex instanceof java.lang.InterruptedException ) return; } } }.execute(); } } 

The choice always depends on personal preferences and use.

The second method has the advantage of refactoring. You can more easily convert an anonymous class to an inner class if the method in which it is used is too large.

My personal preferences relate to the second, as we have created a framework in which SwingWorkers can be added and executed one by one ...

Answer 3

SwingWorker is an implementation of a common template (in .Net I read that GuiWorker BackgroundWorker is used for this), where you need to do some work in the GUI, but support the GUI. The problem is that often GUI libraries are not multi-threaded, so a common way to implement such workers is to use the library's message loop to send messages to the application event loop.

These classes make it easy to update the GUI. Usually they have an update(int status) method that is called by the thread, dispatched by the class and processed by the graphical interface, and the thread continues to work.

Using regular streams, you will need to code your own events or some other messaging engine for this task, which can be painful if you need this feature often. For example, using invokeLater in Java, you have to mix code to update gui in code to get the job done. SwingWorker lets you keep things separate.

Answer 4

To answer your question, you haven’t missed anything. this class is just a convenient utility for wrapping the functionality that you described (run another thread to do the background job and then invoke the final action on the EDT with the results).

Answer 5

When working with Swing, it is important to know that the main swing processing (i.e. rendering) takes place in one thread (which is not your main thread). This is often called a Swing or awt event flow. Those familiar with the JDK pre 1.6 will remember the gray rectangle error if you spent too much time on the event dispatcher for the swing component. What does it mean. In any swinging application, you will have 2 threads that you have to solve. Usually, if all the operations in the event manager (the code that is activated when the button is pressed) is short (i.e. changes the state of the siwng button), you can simply run this inside the event manager. If your application calls a web service or a database, or your application state is controlled by external events (for example, jms) or you just want to make your interface more interactive (i.e. create a list of elements and be able to do something else), you should use a thread other than awt event stream (main swing). Therefore, in these cases, you create a new thread and do what you need, and when the results finally return, then you need to create an event that can be executed by the awt / swing dispatcher. SwingWorker is a great design that allows you to do this (SwingUtilities is another way). This is especially useful for obtaining data from external sources or for lengthy calculations (rendering of a graphic scene). This helps automate the sending and subsequent re-integration of results from an external stream (except for the awt stream). For asynchronous events (i.e. an event from JMS should update the result, use SwingUtilities).

Answer 6

SwingWorker makes trivial sample code much more concise. However, it creates a ball of dirt. Communication with the graphical interface and using the executed logic is welded together. Therefore, I would not want it to be used in real production code.

Answer 7

SwingWorker is much easier than dropping your own threads, because it gives you two things that are painful for manual, the interaction of threads between the user interface and the background process and efficient looping, the background work that continues to work and send updates back to the UI step by step for example, process a large amount of data or load a large list. The disadvantage (or advantage) depends on how you look at it, that it hides the underlying implementation, so the future version may have different behavior, performance, etc., which may be undesirable. I found this quite useful as a glue between a UI event and my own command code, SwingWorker maintains a link to the user interface and my code data.