Java: GUI application with a background thread

Question

EDIT: To make things clearer-

I have an application that connects to a remote server and updates a GUI. The application uses the MVC pattern.

1) The remote server may send a message that updates the data model of my application.

2) The GUI controller classes implement the PropertyChangeListener interface, and listen for updates on the model, and update the GUI view classes

3) The application is able to send messages back to the remote server following a user action on the GUI. This uses the same object that receives data from the remote server.

I currently initialise the 'remote server communication' object and the GUI classes in my main method. Since the communication object can update the model independently, should I initialise this object using SwingUtilities.invokeLater()?

Answer 1

My question is this: given the vendor code initialises its own connection thread, should I still put all my remote communication code (parsing events, updating the model, sending messages back to the remote app) in an explicit, separate thread to the code that initialises the GUI?

Yes

If I understand correctly this is what happens.

The vendor library will start its own thread and eventually will callback a given method on your code.

That will update your app. A thread is already used in the 3rd party library and that would be enough.

If your app in turn have to communicate with the vendor remote server, you would need to use your own thread. Then the answer is yes.

If you just "react" to what the vendor library sends you, then a separate thread is not needed.

Answer 2

I'm not completely sure I get you, but I just have one thing to throw in anyway--

Be sure that any time you touch the GUI, it's on the AWT thread. In theory, this means even creating the GUI (Although in practice, there is rarely a problem creating the GUI in the thread given to your main or some other thread, but sun did detect an issue at one point and suggests against it)

Anyway, this implies that you use invokeLater any time you wish to update the GUI from a different thread. Period.

(Note that whenever the GUI calls you via a callback (ActionListener, etc) that will always be the AWT thread so you can do anything you want with the GUI within callbacks.

With your revised message, I might suggest that if you have a chance of a thread contention and are doing GUI I/O anyway, one way to handle it would be to do all your "contentious" stuff in an invokeLater.

Although it's mostly legal to instantiate a GUI in your main thread (everything up to the setVisible(true)--in theory), if there is any chance of a conflict from another thread, invokeLater will take care of it all in a very deterministic way.

Answer 3

SwingUtilities.invokeLater() will run your Runnable directly on the GUI's Event Dispatch thread.

In other words, never use it to run Background tasks, as it will stop the GUI from responding. Subclass SwingWorker instead, as shown in Sun's tutorial, or other background Threads.