JDK-8210231 : Robot.delay() catches InterruptedException and prints stacktrace to stderr
  • Type: Bug
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: 8,9,10,11,12
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: windows_10
  • CPU: x86_64
  • Submitted: 2018-08-18
  • Updated: 2020-01-27
  • Resolved: 2019-12-25
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 15
15 b07Fixed
Related Reports
CSR :  
Relates :  
Sub Tasks
JDK-8236543 :  
Description
ADDITIONAL SYSTEM INFORMATION :
x64-based PC
Microsoft Windows 10 Pro (10.0.17134 build 17134)
java version "1.8.0_181"
Java(TM) SE Runtime Environment (build 1.8.0_181-b13)
Java HotSpot(TM) 64-Bit Server VM (build 25.181-b13, mixed mode)

A DESCRIPTION OF THE PROBLEM :
The java.awt.Robot.delay() method calls Thread.sleep(), which has the potential of throwing an InterruptedException.  If that exception occurs, Robot.delay() catches it and outputs the exception's stacktrace to the standard error stream.  The JavaDoc does not mention anything about the stderr writes.

REGRESSION : Last worked in version 8u181

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
This problem occurs at random times.  But it is possible to induce it by calling Robot.delay() and then having another thread interrupt the sleeping thread.

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Since the JavaDoc does not mention stderr writes, I suggest that Robot.delay() capture and bury the exception.  This is preferable to modifying Robot.delay() to throw the exception since that method redefinition would break existing code.
ACTUAL -
Robot.delay() outputs the InterruptedException stacktrace to the standard error stream.

---------- BEGIN SOURCE ----------
Robot robot = new Robot();
robot.delay(10000);

or

robot.mouseWheel(5); // see Workaround for explanation
---------- END SOURCE ----------

CUSTOMER SUBMITTED WORKAROUND :
Note that Robot.delay() is used internally by other Robot methods.  For instance, mouseWheel() -> afterEvent() -> autoDelay() -> delay().  This means that a programmer cannot alleviate this problem by simply using  Thread.sleep() in place of Robot.delay().

However, the standard error stream can be redirected to prevent the user from seeing a sporadic exception message in the output console.

FREQUENCY : rarely



Comments
URL: https://hg.openjdk.java.net/jdk/jdk/rev/6dbd8a434f44 User: psadhukhan Date: 2020-01-22 08:47:51 +0000
22-01-2020

URL: https://hg.openjdk.java.net/jdk/client/rev/6dbd8a434f44 User: serb Date: 2019-12-25 18:00:15 +0000
25-12-2019

https://mail.openjdk.java.net/pipermail/awt-dev/2019-December/015630.html
17-12-2019

http://mail.openjdk.java.net/pipermail/awt-dev/2018-October/014536.html
15-02-2019

According to submitter, ========================================================= The java.awt.Robot.delay() method calls Thread.sleep(), which has the potential of throwing an InterruptedException. In the below example, the ite.printStackTrace() line in the Robot.java source is considered as the issue: public synchronized void delay(int ms) { checkDelayArgument(ms); try { Thread.sleep(ms); } catch(InterruptedException ite) { ite.printStackTrace(); } } Historically, in the prior versions of Robot.java, System.err.out("...") was called to send an error message to stderr. It's poor API design to write out to stdout or stderr instead of throwing an exception or returning an error code. As is, it is impossible for outer code to handle the error. And the programmer must make extra effort to suppress the stderr stream if he doesn't want the user to see the error message. However, since modifying the method signature could potentially break existing code, the only feasible solution is to stop writing anything to stderr. The Javadoc does not suggest that delay()--or any of the methods that call delay()--writes to stderr. So, commenting out that bold line is consistent with the behavior described there. ========================================================
30-08-2018