[concurrency-interest] java.util.Timer is good for wall time scheduling?

Roman Leventov leventov.ru at gmail.com
Sun Jan 5 14:22:43 EST 2020


There is an interesting question on StackOverflow with an evidence of
rather extreme time drift when a task is scheduled periodically using
ScheduledThreadPoolExecutor:
https://stackoverflow.com/questions/56571647/why-does-the-java-scheduler-exhibit-significant-time-drift-on-windows.
java.util.Timer appears to be a workaround for that problem. It looks to me
that java.util.Timer is an only tool offered by JDK suitable for wall-clock
time (cron-style) scheduling.

In this context, I would like to recall the discussion of hibernation and
ScheduledThreadPoolExecutor behavior (
https://bugs.openjdk.java.net/browse/JDK-8146527; the discussion thread in
this list:
http://cs.oswego.edu/pipermail/concurrency-interest/2016-January/014817.html).
It seems actually that the desired case of "sending an e-mail each hour"
could be pretty easily coded with Timer:

new Timer().scheduleAtFixedRate(new TimerTask() {
  long minutes = 0;
  @Override public void run() {
      if (minutes % 60 == 0 &&
          System.currentTimeMillis() - scheduledExecutionTime() <
MINUTES.toMillis(1)) {
       sendEmail();
     }
     minutes++;
   }
}, nextRoundMinuteDate(), MINUTES.toMillis(1));

With this, I have a few questions:

 1) Should the Javadoc for Timer, which currently says:

"Java 5.0 introduced the java.util.concurrent package and one of the
concurrency utilities therein is the ScheduledThreadPoolExecutor which is a
thread pool for repeatedly executing tasks at a given rate or delay. It is
effectively a more versatile replacement for the Timer/TimerTask
combination, as it allows multiple service threads, accepts various time
units, and doesn't require subclassing TimerTask (just implement Runnable).
Configuring ScheduledThreadPoolExecutor with one thread makes it equivalent
to Timer."

be amended, perhaps, with the following passage: ", except that Timer may
be more appropriate for scheduling recurring activities that are sensitive
to absolute time because Timer is more robust to the clock drift
than ScheduledThreadPoolExecutor."

 2) In https://bugs.openjdk.java.net/browse/JDK-8146527, David wrote

"Also note that we (JSR166 expert group) explicitly killed the
absolute-time schedule methods due to their problematic nature (as
evidenced by bugs reports on java.util.Timer functionality) - and that
wasn't even considering PC sleep/suspend/hibernate issues."

Could somebody please kindly point to these bugs on Timer functionality in
JDK issue tracker, or note whether they were fixed?

3) Quite unrelated to the previous, but since Timer is discussed rarely:
would it make sense to replace Timer's threadReaper field which is
currently an Object with a finalize() method overridden with a Cleaner?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20200105/c7bd41c3/attachment.html>


More information about the Concurrency-interest mailing list