On 30/10/2018 15:52, Philip Race wrote:
But Robot.delay() is inherently a long lived operation, so interrupts are
more likely there. And you *are* changing behaviour. So I am still
unconvinced this is right. When might this matter in practice in writing tests ?
This might matter for example if the next sequence of code is interrupted by
the test harness:
Robot.delay(10);
EventQueue.invokeAndWait(...); or any other code which may throw
"InterruptedException".
Depending on when the interrupt will happen the test will continue or will
stop, the fix will removed this dependency.
-phil.
On 10/30/18, 3:17 PM, Sergey Bylokhov wrote:
On 30/10/2018 14:03, Phil Race wrote:
But the docs for Robot.delay() state :
> To catch any |InterruptedException|s that occur, |Thread.sleep()| may be
used instead.
So to my reading it is telling you "this call will completely swallow thread
interrupts".
This is what I have tried to follow, if the user need to catch the
InterruptedException then Thread.sleep() should be used. Otherwise the
Robot.delay() may be used, which will be transparent to the Thread.interrupt().
I mean behavior will not be depend on the moment when interrupt was called,
before Robot.delay(), inside Robot.delay() or right after the Robot.delay().
And you are changing that and I don't think you should.
It has nothing to do with removing the printStackTrace which is the only
change requested by the submitter.
-phil.
On 10/30/18 11:04 AM, Sergey Bylokhov wrote:
Hi, Phil.
On 30/10/2018 10:34, Phil Race wrote:
Can you explain why you are doing this ?
Thread.sleep() clears the IE so why do you need to restore it ?
It just looks like an un-specified and un-needed change of behaviour to me.
It is done to "notify" other code which follows Robot.delay() that the thread
was interrupted.
So for example before the fix the code below depended on when the
thread.interrupt() was called:
Robot.delay(10);
EventQueue.invokeAndWait(...);
If the method "interrupt()" was called by the application, when invokeAndWait
() was called, then the thread will be stopped as expected.
But if the method "interrupt()" is called during Robot.delay(10), the
application will miss the fact that the flow was interrupted.
-phil.
On 10/7/18 9:56 PM, Sergey Bylokhov wrote:
Hello.
Please review the fix for jdk12.
Bug: https://bugs.openjdk.java.net/browse/JDK-8210231
Webrev: http://cr.openjdk.java.net/~serb/8210231/webrev.00
The Robot.delay() is a simple wrapper on top of Thread.sleep(), which ignores
the InterruptedException. But in case of InterruptedException it prints the
stack trace, which is unspecified behavior.
In the fix the "printStackTrace()" was removed, and the interrupted state of
the thread is restored.
--
Best regards, Sergey.
