Episode 196: Multi-threaded Swing apps

[Paul]

Hi,

I just listened to the latest Java posse episode and agree with you
guys about multi-threaded Swing. Probably the toughest and most
important part of Swing is using the EDT correctly. I recently found a
Java.NET project that helps a lot, it found some nasty thread
violations in my code that would've taken hours to find without it.

Clicky: https://swinghelper.dev.java.net/

Check out the CheckThreadViolationRepaintManager section. It's just
great. Easy to use and really helpful.

Please keep up the great work. I really enjoy listening to your
podcast on my way to work. You guys do a top job.

Cheers,

Paul.

[Jess Holle]

What I don't get is why the Swing team doesn't just add the correct
assertions to their code so we don't have to guess where we should weave
or hack them in.

--
Jess Holle

[Louis Jacomet]

Hello,

While the repaint manager checking for violations is a really useful
and easy to use techniques, Alexander Potochkin describes it alongside
other ways on his blog in the following article:
http://weblogs.java.net/blog/alexfromsun/archive/2006/02/debugging_swing.html

As a side note, in the podcast, a Posse member talked about
manipulating components before they were "realized" (or another term),
it seems today the current position from the Swing tutorial is to
always deal with components on the EDT, even during creation.
"Why does not the initial thread simply create the GUI itself? Because
almost all code that creates or interacts with Swing components must
run on the event dispatch thread. This restriction is discussed
further in the next section. " (extract from a subsection of
http://java.sun.com/docs/books/tutorial/uiswing/concurrency/index.html)

What are your opinions on this, posse listeners ? How do you manage to
create a big new component while not blocking the UI doing so ?

Regards,
Louis

[Reinier Zwitserloot]

On Jul 17, 1:44 pm, Jess Holle <je...@ptc.com> wrote:
> What I don't get is why the Swing team doesn't just add the correct
> assertions to their code so we don't have to guess where we should weave
> or hack them in.

Indeed. SWT did this from day one, and they had an unhealthy hangup on
performance. I have absolutely zero idea why no one is fixing this
one. It would take one guy perhaps about a week to sort it out and add
the right code. These days you can indeed even restrict the thread
check to an assert statement, though I'd just make it part of the API:

if ( Thread.currentThread() != edtThread ) throw new
NotInDispatchThreadException();

[Vince O'Sullivan]

On Jul 17, 12:44 pm, Jess Holle <je...@ptc.com> wrote:
> What I don't get is why the Swing team doesn't just add the correct

> assertions to their code ...

What Swing team? Is there one?

[Joshua Marinacci]

There are some repaint manager hacks you can install to help you test,
but it doesn't change the core principle: you must do all GUI access
from the GUI thread. If you follow that simple rule then you will
never have problem. The trickiness comes when you want to do something
in another thread who's results show up in the GUI, possibly multiple
times when doing a long process with status updates. These are classic
thread communication issues that all toolkits must deal with. In
Swing's case there are a variety of libraries designed to help you
solve this problem. SwingWorker is one of those. There's also FoxTrot
and JSpin (i think?). There are hooks in the new Swing Application
Framework to do this as well.

- Josh

[Joshua Marinacci]

Indeed there is. Try out JavaSE 6 update 10 and you'll see what
they've been working on.

[Tom Hawtin]

On Jul 17, 8:29 am, Paul <paulmfar...@gmail.com> wrote:

> I just listened to the latest Java posse episode and agree with you
> guys about multi-threaded Swing. Probably the toughest and most
> important part of Swing is using the EDT correctly. I recently found a

Yeah, Swing is really easy. ;)

There was a mistake from someone in the posse (I can't remember which
one is which - sorry). You can't (legally) create your components off
EDT and then realise them. Or at least it's retrospectively not
considered legal. Just do all your Swing stuff on EDT. The trick is to
keep your Swing code separate from your non-Swing code. Good
programming is practically all there is to it. Pity good programming
is so uncool.

Tom

[Reinier Zwitserloot]

On Jul 17, 5:53 pm, Joshua Marinacci <jos...@gmail.com> wrote:
> There are some repaint manager hacks you can install to help you test,  

I'll look into those.

My respect for the swing team is still severely dampened by their
inability to add this simplest of fixes that would clean up
soooooooooo many headaches. What ARE the arguments for this contuining
insistence on insanity anyway? Backwards compatibility? I don't think
that should extend to code which is broken. Besides, you can always
add a command line switch (-Djavax.swing.noThreadCheck) if people want
to continue to run their 6 year old buggy java app as is, but on a
newer VM.

[Jess Holle]

Reinier Zwitserloot wrote:

On Jul 17, 5:53 pm, Joshua Marinacci <jos...@gmail.com> wrote:
  

There are some repaint manager hacks you can install to help you test,  
    

I'll look into those.

My respect for the swing team is still severely dampened by their
inability to add this simplest of fixes that would clean up
soooooooooo many headaches. What ARE the arguments for this contuining
insistence on insanity anyway? Backwards compatibility? I don't think
that should extend to code which is broken. Besides, you can always
add a command line switch (-Djavax.swing.noThreadCheck) if people want
to continue to run their 6 year old buggy java app as is, but on a
newer VM.
  

Backwards compatibility is one big reason I argued for use of assertions here -- the assertions are opt-in rather than opt-out.

--
Jess Holle

[Peter Becker]

I have often wondered why they don't do this myself and so far the
only possible explanation I have come up with is that a plain "-ea" to
enable your own assertions would screw up your application if it has
broken EDT handling. Boohoo. Fix your app or use -ea with your
namespace as parameter.

Maybe there is some other mysterious reason I don't know of, but I
have looked more than once to find that (I nearly wrote "mysterical"
and in a way that might be suitable here -- something that alludes
direct observation and turns out to be rather silly in the end).

Peter

[Anthony Goubard]

> Just do all your Swing stuff on EDT.

Actually it will be more visible with Java 6u10 as the new look and
feel Nimbus uses a shared Map and will throw more often
ConcurentMapAccessException than others L&F when creating Swing
objects in different threads.

Anthony

[blake]

Hey, although there was consensus in the Posse that most UI frameworks
are single threaded, I don't think they mentioned why.

The reason is that there is a nearly unavoidable danger of deadlock.
Events can either come down, from the user doing something, or bubble
up from a change in the model. Since the actions are coming from
opposite ends of the stack, it is very difficult to arrange that so
that locks are seized in a canonical order.

-blake