On Tue, 05 Feb 2008 21:56:35 -0800, Lew <lew@lewscanon.com> wrote:
Running GUI events off the EDT is a known source of bugs. That's why
Sun now uses the word "must" with putting GUI events on the EDT.
You seem to be confusing the general issue of use of components with the
specific scenario I'm talking about: creating the components off the EDT.
I am willing to take as granted that one must always use components after
initialization in the EDT. There are in fact statements to this effect in
the actual Java API documentation, and that's good enough for me.
But as far as initialization goes, there's ample ambiguity here, in the
documentation, in the tutorials, and in sample code I've seen all over the
place. I've been writing Java code for a month, and this is the first
I've seen of any suggestion that _initialization_ is also required to be
done on the EDT. And it's not from lack of exposure to the documentation
or to sample code.
How you interpret that is up to you. But Sun has warned us that running
GUI events *off* the EDT /might/ work.
I'm not talking about "running events".
It's not guaranteed not to work. It's not guaranteed to work. It is
guaranteed to cause trouble under certain circumstances,
Such as? I can reproduce synchronization problems at will in other
contexts, through careful control of the threads involved (i.e. putting in
different synchronization that ensures things happen in the wrong order).
Under what circumstances is it _guaranteed_ that initializing my GUI
components off the EDT will cause trouble? Please provide sufficiently
detailed information such that it would allow me to write sample code to
reproduce the trouble.
circumstances that can occur when a program is ported from an
environment where it appeared to work to a different platform. It's a
bad practice - that is certain.
No doubt. But that's not the question here.
Whether you call it a "recommendation" or an "imperative" is entirely
your choice. But the facts have been laid out, and GIYF for finding
more evidence in that area.
I'm quite familiar with Google. I've been Googling Java issues for a
month now. But Google is not a great resource when one has already
Googled and as a result of failing to find sought-after information has
posted a question to a newsgroup.
If you have a point to make, surely you have some reference that supports
the point. Telling someone to Google for that reference when you already
know what it is is just lame. Asserting a point when you don't actually
have a reference that supports the point is also lame. Making a point and
providing a reference, that's actually quite nice and helpful behavior.
Let's look at a different but related synchronization issue. If two
threads access a common object for both read and write, must you use
synchronization to coordinate the two threads with respect to that
object, or is that a recommendation?
You must use synchronization. So?
After all, on some platforms if you're lucky the program might seem to
work without synchronization.
I can easily write code that will consistently produce wrong results with
incorrect synchronization. It's true that one can get lucky and have it
work without. But it's also true that it's relatively simple to force a
problem in order to demonstrate the risk of failing to synchronize.
Yes, but to do that you need to be in control of the competing threads. With the
You can't force it, you're not in control. The environment is not consistent, so
the results won't be. The problem with threads is that you are not in control
of when they execute, other than via synchronization techniques. Swing is not
synchronized and is therefore not thread safe. You don't control when the EDT
starts and you don't control what it does to the GUI components, or when. It's
not reliably reproducible because you can't control the execution of the EDT.