1

I'm just going through a Java course and several weeks before we went through multithreading where it was explained that when two(or more) threads work with the same object, the object has to be locked from all over threads except the one working with it.

Having a GUI I want to write some data from 2 threads to a JTextArea should I bother about locking the object when one thread writes to it or this is handled already by the JTextArea? If I should bother about it, how would I go doing this since I can not declare a Lock inside the JTextArea class definition? If I should not bother about this, does it stays the same with all swing object, if not, what are the exceptions?

mKorbel
  • 109,525
  • 20
  • 134
  • 319
Alexandru Barbarosie
  • 2,952
  • 3
  • 24
  • 46
  • [check this answer](http://stackoverflow.com/questions/2899682/unresponsive-threading-involving-swing-and-awt-eventqueue/20359861#20359861) where i put a discussion about GUI rendering task using `SwingUtilites` for submitting GUI rendering task to `EventQueue` to be performed in EDT(event dispatch thread). If happen before relation is required for the text to appear, you can put this invocation code inside a synchronized function but measure must be taken as described. – Sage Dec 08 '13 at 21:23

2 Answers2

3

In Swing you have to update GUI components only from UI thread. So you have to schedule those updates from your threads to be executed on UI thread.

This is one example with SwingUtilities.invokeLater().

Alex Gitelman
  • 24,429
  • 7
  • 52
  • 49
3

For the most part, Swing is inherently not thread-safe, so you cannot do this - you must update all GUI components from the EDT by wrapping up the call in SwingUtilities.invokeLater(). For example:

SwingUtilities.invokeLater(new Runnable() {
    public void run() {
        textArea.setText("Blah");
    }
});

Although there are technically exceptions to this rule with a few select components, I'd still by far prefer to execute everything on the EDT unless there's a very good reason otherwise (very, very rarely the case.)

Michael Berry
  • 70,193
  • 21
  • 157
  • 216
  • Could you please explain how and\or why wrapping does the trick? I can not see how to match this with my previous knowledge on multithreading. – Alexandru Barbarosie Dec 08 '13 at 21:21
  • Does the wrapper relate to the `.setText` method, i.e. if in my case `run()` calls another method that actually does the writing should I still wrap `run()` or the method that involves the actual writing to the object? – Alexandru Barbarosie Dec 08 '13 at 21:28
  • 3
    This wrapping doesn't execute whatever you put in the `run()` method on the current thread instantly, it queues execution on the event dispatch thread (one thread dedicated to executing all the methods relating to GUI components.) Instead of saying "current thread, do this now" you're saying "hey, thread that executes GUI stuff safely, call this method when you're next free to do something" – Michael Berry Dec 08 '13 at 21:29