Java library class to handle scheduled execution of "callbacks"?

My program has a component - dubbed the Scheduler - that lets other components register points in time at which they want to be called back. This should work much like the Unix cron service, i. e. you tell the Scheduler "notify me at ten minutes past every full hour".

I realize there are no real callbacks in Java.

Here's my approach, is there a library which already does this stuff? Feel free to suggest improvements, too.

Register call to Scheduler passes:

• a time specification containing hour, minute, second, year month, dom, dow, where each item may be unspecified, meaning "execute it every hour / minute etc." (just like crontabs)
• an object containing data that will tell the calling object what to do when it is notified by the Scheduler. The Scheduler does not process this data, just stores it and passes it back upon notification.
• a reference to the calling object

Upon startup, or after a new registration request, the Scheduler starts with a Calendar object of the current system time and checks if there are any entries in the database that match this point in time. If there are, they are executed and the process starts over. If there aren't, the time in the Calendar object is incremented by one second and the entreis are rechecked. This repeats until there is one entry or more that match(es). (Discrete Event Simulation)

The Scheduler will then remember that timestamp, sleep and wake every second to check if it is already there. If it happens to wake up and the time has already passed, it starts over, likewise if the time has come and the jobs have been executed.

---

Edit: Thanks for pointing me to Quartz. I'm looking for something much smaller, however.

From stackoverflow

• Lookup Quartz

• Quartz scheduler is usually recommended.

• Quartz is the big and obvious powerhouse in this area, but there are some alternatives to explore.

  Cron4j is a decent enough library, that is a little more lightweight than Quartz. It provides good documentation and will do what you want.

  Probably more interesting is if you want to use a library that fits better with Java's concurrency libraries (particularly Executors and ScheduledExecutors) then HA-JDBC has a CronExecutorService interface, implemented by its CronThreadPoolExecutor. Now, interestingly, it has a dependency on Quartz (to provide the CronExpression class), but I find that the two together work better than just Quartz alone. If you don't want large dependencies, its easy to extract the handful of classes from Quartz and HA-JDBC that make this happen.

  Since you want something much smaller (just noticed your edit), grab CronExpression from Quartz, and the two HA-JDBC classes I mentioned above. That'll do it.

• If your objects know exactly the individual points in time which they wish to be executed, then you could use a java.util.concurrent.ScheduledExecutorService. Then they simple call:

  ScheduledExecutorService scheduler = Executors.newScheduledThreadPool(2);
  long timeToExecute = ... //read from DB? use CronTrigger?
  long delayToExecution = timeToExecute - System.currentTimeMillis();
  scheduler.schedule(aRunnable, delayToExecution, TimeUnit.MILLISECONDS);
  

  You'd only need to use Quartz if you want the scheduler itself to handle functionality like "execute every 5 seconds", or if you want complex behaviour around missed executions, or the persistence of the execution audit trail.

  You can actually trivially re-use Quartz's CronTrigger class to get a "next execution time". The class is completely standalone and does not depend on being invoked from within the Quartz "context". Once you have the next execution time as a Date or long, you can just use the Java ScheduledExecutorService as above

• If your needs are simple, consider using java.util.Timer:

  public class TimerDemo {
  
    public static void main(String[] args) {
      // non-daemon threads prevent termination of VM
      final boolean isDaemon = false;
      Timer timer = new Timer(isDaemon);
  
      final long threeSeconds = 3 * 1000;
      final long delay = 0;
      timer.schedule(new HelloTask(), delay, threeSeconds);
  
      Calendar calendar = Calendar.getInstance();
      calendar.add(Calendar.MINUTE, 1);
      Date oneMinuteFromNow = calendar.getTime();
  
      timer.schedule(new KillTask(timer), oneMinuteFromNow);
    }
  
    static class HelloTask extends TimerTask {
      @Override
      public void run() {
        System.out.println("Hello");
      }
    }
  
    static class KillTask extends TimerTask {
  
      private final Timer timer;
  
      public KillTask(Timer timer) {
        this.timer = timer;
      }
  
      @Override
      public void run() {
        System.out.println("Cancelling timer");
        timer.cancel();
      }
    }
  
  }
  

  As has been noted, the ExecutorService of java.util.concurrent offers a richer API if you need it.

• Can't believe java.util.Timer was voted as the answer. Quartz is really a much better choice.

  A big advantage of quartz over java.util.Timer is that with quartz the jobs can be stored in the db. As a result one jvm can schedule and another can execute. Also (obviously) the request survives across jvm restarts.

  Hanno Fietz : Yeah, but I needed something really simple, without additional dependencies. I've got persistence handled in my app anyway, the scheduler doesn't need it itself. I've got Quartz on my list though, should I need more power later on.

  Alex Miller : In the most recent release, you can now cluster Quartz jobs with Terracotta in addition to a database.

  StaxMan : It's funny that Quartz persistence features are touted as a big advantage: in many/most cases they are just a big PITA.

  Pat : Depends if you are scheduling a one-shot job or a repeated job. For repeated jobs, I agree db persistence is a PITA.

• Probably more interesting is if you want to use a library that fits better with Java's concurrency libraries (particularly Executors and ScheduledExecutors) then HA-JDBC has a CronExecutorService interface, implemented by its CronThreadPoolExecutor. Now, interestingly, it has a dependency on Quartz (to provide the CronExpression class), but I find that the two together work better than just Quartz alone. If you don't want large dependencies, its easy to extract the handful of classes from Quartz and HA-JDBC that make this happen.

  I just wanted to say that I tried extracting these classes, and it worked! I needed these three classes:

  • CronExpression (quartz)
  • CronThreadPoolExecutor (ha-jdbc)
  • DaemonThreadFactory (ha-jdbc)

  And I only had to do these minor tweaks:

  • Removing the logger from CronThreadPoolExecutor (it was created but never used)
  • Moved the constant YEAR_TO_GIVEUP_SCHEDULING_AT from CronTrigger to CronExpression

  I was thrilled that I didn't get stuck pull in a tangle of dependencies. Congrats to the class authors!

  And it's been working like a champ.

• I would strongly recommend cron4j (already mentioned) over Quartz, unless you absolutely need some of more advanced and complex features of Quartz. Cron4j focuses nicely on what it is supposed to do, has decent documentation, and is not a kitchen-sink solution.