Pros and cons of using java.util.timer vs Quartz for scheduling? [closed]

偶尔善良 提交于 2019-11-30 02:26:01

Quartz

  • Additional dependency
  • API currently (late 2011) changing: 1.x on its way out, but the only one supported by Spring and possibly others
  • Jobs can be stored persistently; multiple Schedulers can be clustered for load balancing and failover
  • The differentiation between Job and Trigger takes a bit getting used to - but it is possible to
  • More powerful repeated scheduling expressions (e.g. CronTrigger for cron expressions)

Timer

  • Comes with JSE 1.3+ out of the box
  • For your functionality probably enough
  • Less flexible, but less complex as well

I am personally using Quartz + persistent storage for a Web application where triggers can be created interactively and should survive restarts, using Spring's scheduling abstraction. Both APIs IMHO lack an important concept: retrying failed tasks after a certain period of time. Adding this for myself was a pain for repeated tasks that should be retried as well.

For one, Quartz is more extendable. When you create a need for cron like jobs, quartz allready has the support for this. The threads that are used by your application are also managed by quartz, so you don't have to be starting your own thread. It is nice that this is handled by the Quartz Scheduler. It also integrates with the spring framework (don't know if that is applicable in your case). Quartz has reasonable documentation and is backed by a community.

Don't really know if the java.util.Timer is really used in Enterprise environments, but this depends on your application.

an update: now (in 2014) with the advent of inbuilt java schedulers in Java 1.6, 1.7,.... i think quartz is less of a choice.

易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!