Re: SwingWorker.execute() does nothing

On Wed, 08 Oct 2008 20:49:18 -0700, Ben Phillips <b.phillips@xxxxxxxxxxxxxxxxx> wrote:

Peter Duniho wrote:
Please do not post unconstructive material, particularly personal attacks.
You would do well to follow that advise as well, being the person who started the "bonehead" theme, as well as calling the person who was involved in the design decision an "idiot".

That was not directed at a participant here in this newsgroup,

So, it's okay to be disrespectful to people as long as you do it behind their back?

Too bad. I don't buy that logic. Disrespectful is disrespectful, and whether the person you were disrespecting was here to read your post or not, your comment was still "unconstructive material".

Don't tell other people to behave in ways you're unwilling to behave in yourself.

and it did involve violating the principle of least surprise in designing the API. None of the other setFoo, getFoo, and the like methods block, after all, including (most of the time) setVisible.

Inasmuch as the setVisible() method is the Java equivalent to showing a window in any number of other APIs, the behavior is very consistent and would only surprise a person without much experience writing GUI applications. In all of the mainstream GUI APIs, whatever method displays a modal dialog does not return until the dialog has been dismissed. Java works just like any other API and its behavior isn't surprising at all.

[more personal attacks]

Please do not post unconstructive material, particularly personal attacks.

Ah. I'm starting to see the light. Not only would you get along famously with "zerg/Twisted/Paul/etc.", you _are_ one of the personalities of that person. That makes things a bit more clear.

[...]
Obviously, documentation of a "gotcha" is not very useful if it is not located where the user is most likely to look for it.
When dealing with the behavior of a Dialog, I would expect the rational user to be most likely to look in the documentation for the Dialog class.

I was not, however, dealing with the behavior of a Dialog, at least not apparently.

It was only unapparent to you. Had you bothered to step through the code in the debugger, you would have seen that the setVisible() method wasn't returning and you'd never gotten as far as the SwingWorker.

All that was missing here was your own due diligence. For you to argue that you had no reason to be able to figure this out is absurd.

I was dealing with the behavior of a SwingWorker, at least apparently. The dialog appeared correctly. The SwingWorker task did not appear to execute. Ergo, the SwingWorker appeared to be the source of the problem.

Yes, I understand how you made the mistake. And frankly, we all make mistakes. You should not be embarassed just because you overlooked the obvious. It happens to everyone.

But don't compound the error by insisting that you didn't yourself make a mistake, and by insisting that Java itself is flawed. You did, and it's not.

I do not understand why you and other people are arguing with me, and even attacking me personally.

There's very little in the way of attack here, and as far as arguing goes, that's a natural consequence when you say something that's incorrect. You can't expect to make false statements without having someone dispute them.

[...]
It does too make sense. Your attitude is what makes no sense. Especially since you've never, to my knowledge, replied to one of my posts before, and now you do so in a manner tinged with hostility, as if I'd affronted you personally in the recent past, though I know I've done no such thing.

Whatever hostility may exist in my post is prompted by your own hostile and hypocritical statements. You reap what you sow.

Whether I've replied to other posts of yours is irrelevant, though since I suspect you're just "zerg" in some other persona, I probably have in fact replied to you, or at least one or more of your other personalities.

The logical conclusion from your assertion is that every single class method in the Java API should include documentation that says "if placed after a call to Dialog.setVisible(), this method will not execute until after the user has dismissed the Dialog".

Nonsense. Only the specific case that's especially likely to trip people up, which is where they pop up a progress dialog and then launch a SwingWorker to do a background task that will report progress.

All due respect, that's an idiotic opinion. Your use case of the Dialog is hardly the most common, so claiming that's the only specific case in which documentation such as you propose would be needed is absurd.

After all, Dialogs are presented to the user in a practically infinite
variety of situations.

Actually, dialogs are typically presented in about four situations:
* To present a message. Usually right before a method returns or continues to propagate an exception.

Correct. And in that situation, how do you think the code is blocked until the dialog is dismissed?

* To ask a question. Typically using one of the JOptionPane static methods that obviously block, because they return a value that depends on the user's input. The assumption is that the JOptionPane method does something special. In particular it isn't just a bald setVisible(true).

Correct. And in that situation, how do you think the code is blocked until the dialog is dismissed?

* To present a more complex, interactive UI, often in response to a menu item selection. Typically right before a method returns.

Correct. And in that situation, how do you think the code is blocked until the dialog is dismissed?

* To display a wait message or a progress meter during a lengthy I/O operation, calculation, or what-not. Typically adjacent to a SwingWorker.execute().

You are being deliberately obtuse, with the only apparent reason being that to do otherwise would admit that you should have been able to predict the behavior of the setVisible() method.

How is it that you can be aware of all these other use cases for Dialog, with the implied behavior of the setVisible() method, and yet you can't extend that awareness to the particular use of setVisible() that you ran into?

Only in the fourth case is anyone likely to notice any problem resulting from setVisible(true) blocking.

Well, except that in the other three cases, if setVisible(true) didn't block, everyone would notice a completely different problem: showing a modal dialog failing to block the calling code.

Add that the Java Tutorial makes no mention of this in the section on Swing concurrency, and it's not hard to understand how this can cause a difficult-to-diagnose problem.

It's not a Swing concurrency issue. There's no reason for the Swing concurrency section to mention it.

No, what makes more sense is that programmers simply should be expected to read the documentation related to the methods they are calling.

There was nothing that would clue me in in the method that appeared to be causing trouble, SwingWorker.execute().

Nothing? Well, not when you don't bother to debug your code, no. I suppose not.

So learn to use a debugger.

Now please drop this subject. Obviously we don't, and won't, agree on how much documentation should exist where. Continuing to belabor the issue won't accomplish anything, and your mudslinging certainly won't.
The original problem has been solved. I'm ready to move on.

Really? And yet, you saw the need to reply to my post? That doesn't seem like someone who's "ready to move on".

Are you?

Not if you aren't. I guess we'll see whether you really are or not.

Pete
.

Relevant Pages

  • Re: Wjf 5
    ... Luke Burrage effectively discredited ... illogical attacks on Garfield in Kaskade. ... I've had various meetings with Jason's private persona over the ... I don't hate Jason, ...
    (rec.juggling)
  • Re: Order of Elements in Hash
    ... >> Do you frequently use functions without reading their documentation? ... > Reading these sections points the user to perlsec (Algorithmic Complexity ... > Attacks), which states in bold print, that, ...
    (comp.lang.perl.misc)