Question

For my current application, I am struggling with identifying the Swing threads in my application. With Swing threads I mean:

• Initial threads
• The event dispatch thread
• Worker threads

My application:

• simple user interface which is supposed to display data received on a socket
• the data is described by many model classes
• the received data is XML which is parsed and the model objects are instantiated
• the user interface is supposed to display the received data
• these data is updated very frequently, which means the XML messages are short, but there are many of them
• to put it into context: I am programming a Java profiler.

I have read the Swing tutorial so far, so here are my guesses and questions:

The background task is the server socket, respectively the background tasks are the number of opened connections on which the application receives data.

1. The tasks have no final result, so I guess the SwingWorker<T,S> should only define the generic type for the Interim Result? For every parsed XML I would make a call to publish. But how do I distinguish which data I have received? Maybe the XML data contains only enough information to build a class A or maybe the data contains enough information to build class A and class B, but how do I wrap both into one Interim Result? A wrapper class?

2. The process() method invokes changes to make it visible to the user interface, doesn’t it? I don’t see how this works. Where do I launch my tasks? Is it in order to invoke the SwingWorker.execute() in the JFrame constructor?

3. Should the XML Reader be the Task or should each Thread which handles an incoming connection be the task?

Answer 1

In the context you describe, I am not sure I would use SwingWorker.

My basic idea would be:

• from your main(), start several threads for serving sockets (standard Thread API)
• when one such socket thread gets some input, it parses the XML right away (as you describe it, parsing should be very fast, hence I don’t think you would need to start a new thread just for that)
• once the XML is parsed, the socket thread creates some “result object” to be displayed, declare this object in a final variable, and call SwingUtilities.invokeLater() to display this result in your UI

Another alternative that I have used successfully in the past would be to use an EventBus that would take care of callingthe UI update method in the EDT, your socket threads would send the “result object” to that EventBus.

About SwingWorker use, I would say the main use is when the end user starts an action (e.g. by clicking a button or a menu item) and this action is long and should be processed in background, the background processing method would then have to feed back information to the UI.