Norm Shapiro wrote:
> [EMAIL PROTECTED] (Nelson Minar) writes:
> >I'm still getting some occasional instability when disposing of Frames
> >in the Linux JDK - I get IOT trap/Abort. My application is crashing
> >randomly and it's driving me nuts.
> I have had similar problems with JFrame. My workaround, which has been
> generally successful, was to subclass JFrame. In the subclass I override
> dispose (and also setVisible()) with a method that forks off Thread with a lower
> priority than the current thread.
Is Nelson's application multi-threaded?
I'm pretty new to this Java game, but it appears to me that the AWT's
dirty little secret is a lack of thread safety.
The closest thing I've found to relevant information is in the
documentation for Swing -- which states explicitly that Swing is not
thread-safe, and that all GUI access, after the GUI is instantiated,
needs to happen from the AWT Event thread. This means that GUI activity
either has to take place in an event handler, or must somehow be
triggered from the event thread. Swing even provides a trick
(SwingUtilities.invokeLater()) that makes it easy to push an activity
into that thread.
Having said that, I've seen absolutely nothing anywhere claiming
that AWT is not thread-safe. On the other hand, I've found that
adopting Swing's approach has solved my GUI reliability problems.
Norm's approach sounds suspiciously similar.
Nathan Meyers
[EMAIL PROTECTED]
