Re: Worker Threads and EDT
i.dont.need@any.more.email wrote:
I have some legacy code to spruce up, and it breaks one of the cardinal
rules of swing: it updates the UI with worker threads (not the EDT).
Finding all of the potential culprits is easy, but there are hundreds of
cases which could be problematic, and the vast majority are fine. It is
quite difficult to determine via inspection whether or not a specific
worker thread will cause problems because dependencies back to the UI
are typically routed through at least one interface, one or more
abstract classes and a chain of one or more listeners (business objects
expose a generic property change event, and all manner of things
register for notifications). How can I figure out which threads have a
transitive dependency back to some UI object? I could easily name worker
threads, but the problems typically manifest themselves on the EDT in
the various paint methods. Is there any way I could instrument the code
so that in development, I could throw an exception any time a component
is touched by a thread other than the EDT?
--
Shane
You appear to contradict yourself so it is difficult to understand why
you can't just put the Swing component method calls on the EDT if the
culprits are easy to find.
That said, most Listeners are going to be called on the EDT so I
wouldn't worry about that code.
If you want to trap calls to the paintComponent() method that aren't on
the EDT, use EventQueue.isDispatchThread() and throw an exception if it
is false. The problem I see with that is that calls to methods that
later call repaint() will not be found.
--
Knute Johnson
email s/nospam/knute2008/
--
Posted via NewsDemon.com - Premium Uncensored Newsgroup Service
------->>>>>>http://www.NewsDemon.com<<<<<<------
Unlimited Access, Anonymous Accounts, Uncensored Broadband Access