Re: File browser
Lew wrote:
[...]
I know what *might* go wrong - you might have an improper value
displayed in a control, for example. You might have a control not be
visible at all - it depends on the work that's being done.
Peter Duniho wrote:
How could those things happen? Specifically, that is, how could those
things happen should I initialize the controls off the EDT?
If you initialize some stuff off the EDT, the changes might not be visible to
the EDT when it renders the window, because the values you set might not
propagate through the memory model for the EDT to know to show them.
This is a standard synchronization issue, the same as in any multi-threaded
program.
But I haven't seen these in practice, which is why I give you what I
*do* have a concrete idea of, and that is that reliable, authoritative
sources have stated that the multi-threaded nature of GUIs requires
the proper synchronization. There's no need to go all snarky on me or
anyone else here for trying to help you with the knowledge that we do
possess.
I don't see how you get "snarky" from my replies. I'm simply asking
questions. If you don't know the answer, that's fine. Don't insist
that the questions or their answers are trivial though. That's just silly.
I never said they were trivial, I said the answers were given.
Misrepresenting my points and calling them "silly" is what I call "snarky".
I know that the link I posted gave *me* some hints as to how to
construct an example that would display problems if the EDT weren't
respected. I'm sorry that you couldn't get the same value.
No, you're not. If you were sorry, you would help by pointing out where
Oh, so now you're a mind reader?
in those articles those hints are contained and how to use them to
produce a working sample.
Here's the part that gave me the hint:
The reason behind the change is simple: while your program might access a
Swing component off of the event-dispatch thread before the component is realized,
OK, so I create components in the main thread, do a whole bunch of stuff to
them (add subcomponents, etc.), then go back around and do more stuff to them
(build up a lot of cross-thread entropy), in a multi-core environment, making
sure that I pack() the thing before finishing my changes.
The same thing I'd do to construct any thread-coordination bug. Of course,
the nature of thread bugs is that they are never guaranteed to show up, even
when present, so I'd run the thing on a multi-core machine to increase the
likelihood of cross-thread inconsistency.
That's the idea that passage gave me, anyway.
I'm not against doing work, and believe me I've done plenty in my
question to get my Java code to work correctly. But when I know the
answer to a question, I don't sit around telling the person asking the
question "I know the answer, but I refuse to tell you, or even help you
understand how to find the answer from the resources you've been
offered". I help the person learn the answer.
When have I ever done that? In the first place, I've never claimed to "know
the answer", instead I pointed you to well-established authorities (e.g., Sun)
who do know the answer. Then you come back and mischaracterize my comments,
and wonder why I call that "snarky".
Nor have I "refused[d] to even help you understand how to find the answer from
the resources you've been offered". /Au contraire/ I have tried repeatedly to
explain how I read these sources, find new sources that confirm the
conclusion, point out how authoritative those sources are, and draw together
information provided by other respondents with the hints that I've repeatedly
researched for you.
So don't straw-man my points by claiming that I claimed to "know the answer"
or get on my case because the resources I find don't speak to you as clearly
as they do to me. I have freely admitted the limits of my knowledge, and I
continue to refer you to more authoritative sources.
If you don't think *Sun* has made the case strongly enough, well, that's
hardly my fault.
I have already read the references offered and not found the information
I seek. You claim the information is there and imply that it's easily
accessible. If it's so easy, why not just say so? Why waste so much
time refusing to help, when you could instead use that time productively
by helping?
Productively for whom? I have tried to help by providing authoritative
sources, as have many others here. You misrepresent my points - I never said
the information was "there and ... easily accessible", only that it's
unequivocal and authoritative and provides hints as to how to construct the
example you keep stubbornly demanding. Somehow I am to be responsible for
your inaccurate representation of what I said?
So, either you don't actually know the answer (which is fine, though you
should just admit it so we can forget about worrying whether you'll
share it), or you do. If you do, it's incredibly useless for you to
pretend that you're interested in helping people when at the same time
you refuse to.
And you say you aren't being snarky. Sheesh.
All I've claimed to know is that authorities from Sun on down have indicated
the dangers of not respecting the multi-threaded nature of the GUI lib. It is
only you who misrepresents my comments as claiming to "know the answer" - the
only answer I claim to know is that it's dangerous to initialize Swing
components off the EDT. I claimed to know that it could cause controls not to
appear on the screen, a claim borne out by the experience of other respondents
on this thread and by the sources cited by those respondents. That claim has
been substantiated. I claimed to know that Google and other searches will
turn up more information, a claim I and others have substantiated by
continuing to search and find references that support the point as you
continue to reject the information we provide. I claim to have found hints on
how to construct examples of this problem, I claim I substantiated /supra/.
It is utterly unfair of you to say I claimed to "know the answer" to your
limited and to my mind superfluous demand for a pre-constructed example.
Certainly many others have chimed in on that question, so why should I retread
what they've said?
You should incorporate the gestalt of the answers the group is providing here.
I feel no need to rehash a point that another has made, such as that
synchronization issues are next to impossible to reproduce reliably and that
seeming to work is no guarantee that code is correct. I'm reading the answers
that others are giving you - and guess what? They're giving you the exact
same advice as I am, with even stronger evidence and more concrete examples.
So why is my advice wrong?
Please be fair.
--
Lew