Bug ID: JDK-6451578 A mouse listener method happens to process mouse events whose time is in the future.

Versions (Unresolved/Resolved/Fixed)

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 6	JDK 7
6u10Fixed	7 b17Fixed

J2SE Version (please include all output from java -version flag):
  java version "1.6.0-rc"
  Java(TM) SE Runtime Environment (build 1.6.0-rc-b91)
  Java HotSpot(TM) Client VM (build 1.6.0-rc-b91, mixed mode, sharing)

Does this problem occur on J2SE 1.4.x or 5.0.x ?  Yes / No (pick one)
  not known

Operating System Configuration Information (be specific):
 Windows XP Professional SP2

Hardware Configuration Information (be specific):
 Intel Pentium III, 730 Mhz, 384 Mb RAM

Bug Description:
A mouse listener method happens to process mouse events whose time
is in the future.

Steps to Reproduce (be specific):

Compile and run the attached program. A window is displayed.
Move the mouse in it. On the command prompt window mouse events
are traced. Some of them report "delay = -1". This is the
difference between the current time and the time of the event.
A negative number means that the event has in it a time in the
future. However coarse might the system clock be, it should never
go back. Therefore, if the system clock is consistently used
all over JRE, an event occurring before another can never have
a timestamp greater that that of the other.

EVALUATION The problem could be uncovered by looking on awt_Component.updateBootTimeUTC() function which tries to calculate the number of millis that have elapsed since system was started. For that purpose it gets currentTime(millis since 1601) and getTickCount()(millis since boot) and calculates a number of millis since 1970 till system start. The trick is, boot_time_1601 variable changes rather often in the range +-1 if we use that updateBootTimeUTC() function(now it's under if statement and called rarely). Sometimes the value changes by +-10 millis. So far if we use updateBootTimeUTC() for every message then the defect goes away. That happens because of that +-1 millis correction. We probably do not use this update yet because of performance issues(is this still an issue though?).
31-05-2007
SUGGESTED FIX http://sa.sfbay.sun.com/projects/awt_data/7/6451578/
18-05-2007
EVALUATION I verified that the time obtained by JVM_CurrentTimeMillis() method (native method for System.currentTimeMillis()) and nowMillisUTC() may differ. In my environment I haven't seen more the one ms shift. The best approach that comes in mind is to use the same way as JVM when obtaining system time.
18-05-2007
EVALUATION Seem there is a inaccurancy when we calcalating a time when native message happen. awt_Component.nowMillisUTC(DWORD event_offset) takes a message_offset (relative to sys epoch) and is trying to convert it into UTC. But it uses GetTickCount() and GetSystemTime() for further calculations. I verified that
16-08-2006
EVALUATION This bug can be easily reproduced at least with 1.5, so this is not a regression. AWT event's field 'when' is calculated in nowMillisUTC() function defined in awt_Component.cpp. It seems that this function uses another native API (or uses it in another way) than System.currentTimeMillis().
25-07-2006

Relates :	JDK-6626492 - Event time in future part 2, now on X
Relates :	JDK-8046495 - KeyEvent can not be accepted in quick mouse clicking
Relates :	JDK-6461933 - To adjust system boot time in nowMillisUTC() frequently
Relates :	JDK-4511903 - At times getWhen()in ActionEvent returns higher value than the CurrentSystemTime
Relates :	JDK-6207371 - InputEvent.getWhen() (and similar) does not specify timebase of timestamp