2

I have written a GUI for operating a card reader - mainly consisting of an ADD button that brings up a FileChooser dialog and queues the chosen File onto a CardHopper, which is displayed visually as a JList.

Now I want for the CPU (another JFrame, on another thread) to be able to make requests of the card reader; e.g. read a card and send it to me. Before the card reader had a GUI, it was just a model that ran on the same thread as the CPU, so I could just call its readCard() method. Now that it's on a separate thread, it seems like the right way to communicate is with message-passing.

I was about to implement something using a PriorityBlockingQueue, whereby the CPU would put a read-card command on the queue and the CardReader would take and execute the command, until I realized that the CardReader thread would normally be blocked somewhere within its NetBeans-supplied Swing code, waiting for a GUI event and blind to the arrival of anything on my event queue. Moreover, this "back end" request would alter the data model - so even if I could somehow execute some code in the model, would it be kosher to "fire" notifications to the GUI's ListDataListeners while the GUI is waiting for GUI events?

I hope this isn't too cryptic - I'm still trying to get my arms around the mechanics of GUIs and threads.

Chap
  • 3,649
  • 2
  • 46
  • 84

1 Answers1

4

Would it be kosher to "fire" notifications to the GUI's ListDataListeners while the GUI is waiting for GUI events?

Absolutely not.

What you want to do is perform all tasks that directly manipulate your UI's models (or call UI functions) on the Swing event thread.

Essentially, when you're ready to post an event that will perform some UI task, do it like:

SwingUtilities.invokeLater(new Runnable() {
  public void run() {
     ...
  }
}

You can fire all your listeners, and do whatever you want to your ListModel (or your other UI models) there since it will only get run in the Swing thread.

Otherwise, you risk Swing trying to read you data while it is painting and you are updating your data. You'll start getting NullPointerException, ArrayIndexOutOfBoundExceptions, ConcurrentModifictionException, etc.

Ideally, you would perform all of your background work in a separate thread (or under SwingWorker), and then when everything is ready, push an update via invokeLater.

Reverend Gonzo
  • 39,701
  • 6
  • 59
  • 77
  • 1
    +1 - Doing the OP's behavior is a common (all too common) problem in Java programs. Note that you can also use SwingWorker thread classes (depending on your version of Java of course) to do the same thing. – aperkins Jul 18 '11 at 20:28
  • It's worth noting SwingWorker is included by default from 6 onwards but SwingX provides a backport for previous Java versions - so you can still use it! – Michael Berry Jul 18 '11 at 20:34
  • `SwingUtilities.invokeLater()` sounds good; does this mean there is only ever **one** AWT event dispatching thread, and when it dispatches my run() method, no other events on _any_ of my JFrames will be handled until my run() finishes? (Not that that would be a problem; I had just assumed that each GUI had its own EDT.) – Chap Jul 18 '11 at 22:10
  • 1
    (Followup) I just found a very good article that clears up a lot of my confusion: (http://www.javaworld.com/javaworld/jw-06-2003/jw-0606-swingworker.html). – Chap Jul 18 '11 at 22:58