Details
-
Type:
Bug
-
Status:
Closed
-
Priority:
Trivial
-
Resolution: Fixed
-
Affects Version/s: 1.5.4
-
Fix Version/s: 1.6-beta-1
-
Component/s: Swing
-
Labels:None
-
Environment:Linux/Windows XP
JDK 1.5 / 1.6
Groovy 1.5.4
-
Number of attachments :
Description
Open Groovy Console and run the following script:
assert ('a'..'c').contains('b')
It may be necessary to run it multiple times until you get the Executing window "frozen" on screen. Hitting the Interrupt button won't do anything, but if you run the script again, the window disappears at the end of the execution.
Activity
Your comment in the fixed code indicates you think this is due to an AWT bug. I'm pretty sure that is not the case.
Because showRunWaitDialog is done on the EDT, this behavior is very probably because you're executing the code and calling hide before the dialog is shown. So the hide does nothing and then the event finally fires and displays the "wait" dialog (a bit tooo late 
.
Your thread fix is OK, although this could also be handled without one with suitable checks.
@Jim White .
Hide was /also/ being called in the EDT. Both were added to the EDT thread via SwingUtilities.invokeLater. My comment indicates I would assume that calling show in one runnable added to the EDT would result in the dialig being fully shown and stable, and that if I call hide the first thing in the next runnable, it will hide. however, that is not the case. either the second runnable added is being executed before the first runnable being added is resolved, or something is going strange in the AWT in that the dialog isn't done 'showing', perhaps placing it's own invokeLater to do some processing, and my hide gets called before the further processing gets called,
@Paul King
I doubt that my change could cause it, all the stack is in the EDT. It seems like you are running out of system resources (I got 4GB, I ran out of heap first). Besides, that script is not interruptable. Try this one
while (true) synchronized (this) {wait(100); println "Hi"}
It's more likely bad UI to imply to the user that runaway threads can easily be stopped 
What exact versions of java are you using? I tried invoking the script above a few hundred times and didn't observe the behavior you describe. If I give it an infinite loop, there are times when I then can't interrupt but not with the script you gave. I am trying to work out how to replicate your issue.