<Swing Dev> JDK-4290274 (timer) java.util.Timer.scheduleAtFixedRate() fails if the system time is changed

[Martin Buchholz]

I added a comment to that bug

"""
There's some serious confusion about the various timer implementations in
the JDK.
The summary and component refer to java.util.Timer, but the test program is
all about javax.swing.Timer! And of course there's
ScheduledThreadPoolExecutor, which inspired fixes to javax.swing.Timer but
java.util.Timer has been left unchanged, still using
System.currentTimeMillis for everything.

Realistically, it's too late to fix java.util.Timer, and javax.swing.Timer
has already been fixed, but Josh's comments from 2004 are still food for
thought, which keeps me from closing this ancient bug.
"""

We cannot have an automated jtreg test so intrusive that the system clock
is changed.
A manual test is barely possible, but it's still pretty weird.



On Mon, Sep 21, 2015 at 12:21 PM, Sebastian Sickelmann <
sebastian.sickelmann at gmx.de> wrote:

> Hi,
>
> while looking through some bugs in JBS I found this[1] one.
>
> It seems to be that it is already solved. I tried the submitted example
> with jdk6,7,8 and
> it seems that it works since jdk7.
>
> So maybe the bug can be closed, like the one it relates to
>         JDK-5056544 javax.swing.timer stops after changing actual system
> time
>
> I created a headless swing based jtreg-test for JDK-4290274 but actually
> it would run
> only on linux(which can be changed) and must be started by a user that
> can change the time.
>
> Is it possible to integrate such a test in openjdk?
>
> -- Sebastian
>
> [0] https://bugs.openjdk.java.net/browse/JDK-4290274
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20150921/2bc1bf38/attachment.html>