United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-6451578 A mouse listener method happens to process mouse events whose time is in the future.
JDK-6451578 : A mouse listener method happens to process mouse events whose time is in the future.

Details
Type:
Bug
Submit Date:
2006-07-21
Status:
Closed
Updated Date:
2011-05-18
Project Name:
JDK
Resolved Date:
2011-05-18
Component:
client-libs
OS:
windows_xp
Sub-Component:
java.awt
CPU:
x86
Priority:
P3
Resolution:
Fixed
Affected Versions:
6
Fixed Versions:

Related Reports
Backport:
Relates:
Relates:
Relates:
Relates:

Sub Tasks

Description
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.

                                    

Comments
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().
                                     
2006-07-25
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
                                     
2006-08-16
SUGGESTED FIX

http://sa.sfbay.sun.com/projects/awt_data/7/6451578/
                                     
2007-05-18
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.
                                     
2007-05-18
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?).
                                     
2007-05-31



Hardware and Software, Engineered to Work Together