Re: java.util.Timer is good for wall time scheduling?

Hi Roman,

 

Regarding:

 

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

 

See for example

 

https://bugs.openjdk.java.net/browse/JDK-4290274

 

and linked bugs.

 

Cheers,

David

 

From: Roman Leventov 
Sent: Monday, January 6, 2020 5:23 AM
To: concurrency-interest <[email protected]>; [email protected]; [email protected]
Subject: java.util.Timer is good for wall time scheduling?

 

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?

_______________________________________________
Concurrency-interest mailing list
[email protected]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest