2

I want to use this Swing snippet to create an image from a text label from a non-Swing based app (a web service written using Play Framework, to be specific).

I've never used Swing, and saw that "it is not thread safe". Does this apply to the minimal code that I'm planning to run? Should I synchronize access to this code?

If I understand the answers about Swing thread-safety correctly, then unless a method explicitally says it's safe, then it isn't ... and the methods I use (specifically BufferedImage.getGraphics() don't seem to have this piece of javadoc). So, unless shown otherwise, I'm going to synchronize.

Community
  • 1
  • 1
ripper234
  • 222,824
  • 274
  • 634
  • 905
  • 2
    Why are you concerned about thread-safety? Do you intend to create the image from outside the event dispatch thread? – JB Nizet Jan 23 '12 at 17:08
  • @JBNizet - I'm not writing a full-fledged swing app. I intend to use this method in a Play web server to create images. – ripper234 Jan 23 '12 at 17:09

2 Answers2

2

"Not thread-safe" means that you must not access the same thing from multiple threads at once.
There is nothing wrong with running that code on a background thread, as long as you don't share the objects across threads.

Note that most (non-UI) objects are thread-safe for read-only operation.

SLaks
  • 868,454
  • 176
  • 1,908
  • 1,964
  • I doubt they will still be thread safe if something else wants to write to them. As you are missing a `const` keyword in Java I don't know how you'd be sure it was a read only op. Sometimes older is better. – John Jan 23 '12 at 17:10
  • 2
    Err, no. Swing components must be accessed from the EDT. And no, most objects are not thread-safe for read-only operations. – JB Nizet Jan 23 '12 at 17:10
  • Right, I was worried that something might be shared between the different object. I will be using a new object per thread, so I guess I shouldn't worry. Thanks. – ripper234 Jan 23 '12 at 17:11
  • @JBNizet: AFAIK, these components would not be attached to the EDT. – SLaks Jan 23 '12 at 17:11
  • @JBNizet - "must be accessed from the EDT" - if I'm not writing a standard Swing GUI app ... can't I just use them from whichever thread I want? – ripper234 Jan 23 '12 at 17:12
  • I don't know the swing internals enough to guarantee that no shared object is used when using and painting swing components. If such a shared object, supposed to be used from the EDT, is used by multiple threads, you'll have problems. And you could also have internal objects using SwingUtilities methods to check that the current thread is the EDT, or to submit task using SwingUtilities.invokeLater() or SwingUtilities.invokeAndWait(). Unless it doesn't sustain the load, I would only use the EDT, even at server-side. Post your tasks to the EDT using SwingUtilities.invokeAndWait/invokeLater. – JB Nizet Jan 23 '12 at 17:23
  • An example of a shared object is the UIManager which manages the look and feel, the UI defaults, etc. I doubt it's thread-safe. – JB Nizet Jan 23 '12 at 17:26
1

EDIT: actually, you can cut out all the Swing related parts in your "Swing snippet" since you really only care about the image manipulation part, which has nothing to do with Swing.

Don't worry about anything: your code is not multi-threaded.

Where it gets complicated with Swing is when you have some actual interface. The interface is run from a special thread (the event-dispatch thread or EDT), which is a different thread from the main thread where you program runs. If you update some value in your main program, you have to be careful with multi-threading issue otherwise your updated value will never show on screen.

Since you are just using some methods from the Swing library without having any EDT it's just like using any method from a normal library.

toto2
  • 5,306
  • 21
  • 24