JDK-5056533 : javax.swing.timer stops after changing actual system time
  • Type: Bug
  • Component: client-libs
  • Sub-Component: javax.swing
  • Affected Version: 1.4.0,1.4.2,5.0
  • Priority: P4
  • Status: Closed
  • Resolution: Duplicate
  • OS: generic,windows_2000,windows_xp
  • CPU: generic,x86
  • Submitted: 2004-06-02
  • Updated: 2006-09-25
  • Resolved: 2006-09-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 7
7Resolved
Related Reports
Duplicate :  
Relates :  
Description
Name: gm110360			Date: 06/02/2004


FULL PRODUCT VERSION :
java version "1.5.0-beta2"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0-beta2-b51)
Java HotSpot(TM) Client VM (build 1.5.0-beta2-b51, mixed mode, sharing)

ADDITIONAL OS VERSION INFORMATION :
Windows XP Pro 32 bit +Service Pack 1

A DESCRIPTION OF THE PROBLEM :
I used javax.swing.timer and added ActionListener. After that I started timer and counted "ticks" of this timer. Everything goes well untill I change the system time (for example it's 5:00 and I set 4:23). After increasing time nothing happens but after decreasing it - timer stops - it just doesn't notify the action listener - actionPerformed method isn't called.

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Define javax.swing.timer, add ActionListener, start timer, change time for the lower one and that's it.

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
actionPerformed method is still called
ACTUAL -
actionPerformed method isn't called any longer

REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
import java.awt.event.ActionListener;
import java.awt.event.ActionEvent;
import javax.swing.Timer;
import java.awt.Frame;

public class TimerTest
{
	public static void main(String[] args)
	{
		Tester tester = new Tester();
		
	}
}

class Tester extends Frame
{
	public Tester()
	{
		super();
		Timer t = new Timer(100, new
			ActionListener(){
				int i = 0;
				public void actionPerformed(ActionEvent e)
				{
					System.out.println("i=: " + i++);
				}
				
			});
		t.start();    //this te beggining and the end
		show();
		
		
	}
}
---------- END SOURCE ----------

CUSTOMER SUBMITTED WORKAROUND :
Using own timer constructed with Thread but it's not very good solution.
(Incident Review ID: 275579) 
======================================================================

Comments
EVALUATION This bug was fixed as part of the fix for 5053997 [Swing Timer cannot handle multiple timers effectively]. Closing as duplicate.
25-09-2006

EVALUATION FYI: The same problem with java.util.Timer is being addressed under 4290274.
06-09-2006

EVALUATION swing.Timer uses System.currentTimeMillis() for time measurement. System.currentTimeMillis returns the current time on the system. Changing the current time breaks the timer. We need to use something independent of the system current time. I suggest to use System.nanoTime() <skip> * Returns the current value of the most precise available system * timer, in nanoseconds. * * <p>This method can only be used to measure elapsed time and is * not related to any other notion of system or wall-clock time. * The value returned represents nanoseconds since some fixed but * arbitrary time (perhaps in the future, so values may be * negative). <skip> System.nanoTime() This should fix 6452147 [increase granularity of javax.swing.Timer] too.
31-08-2006

EVALUATION The bug is reported against a stand alone application. Re-assigning to Swing team ###@###.### 2004-06-02 A very interesting case that wasn't considered. Due to the importance of Swing Timers, I wonder if they should be made robust enough to be independent of changes to System time. Also, I wonder if they CAN be. More investigation is needed. I've contacted the author of java.util.Timer, which exhibits similar behavior, to see if we can discuss the possibility. ###@###.### 2004-06-03
03-06-2004