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()?
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.