Quartz is a job scheduling library that can be integrated with, or used along side virtually any other software system. The term "job scheduler" seems to conjure different ideas for different people. The Quartz Scheduler documentation should give you a firm idea of what we mean by this term, but in short, a job scheduler is a service component that is responsible for executing (or notifying) other software components when a pre-determined (scheduled) time arrives.

Quartz is quite flexible, and contains multiple usage paradigms that can be used separately or together, in order to achieve your desired behavior, and enable you to write your code in the manner that seems most natural to your project.

Quartz is very light-weight, and requires very little setup/configuration. You can actually use it "out-of-the-box" if your needs are relatively basic.

Quartz is fault-tolerant, and can persist ("remember" your scheduled jobs between system restarts.

Although Quartz is extremely useful for running certain system processes on given schedules, the full potential of Quartz can be realized when you learn how to use it to drive the flow of your application's business processes.

Quartz is not a job queue, although it is often used as one, and can do a reasonable job of such at a small scale.

Quartz is not a grid computation engine, however simple, small scale usage as such can be achieved with effort.

Quartz is not a job execution service for use by business personnel. It is a code library that can be easily embedded into applications that need the capability to schedule application-related tasks to occur in the future or on a recurring basis.

Quartz is distributed as a small Java library (.jar file) that contains all of the core Quartz functionality. The main interface (API) to this functionality is the Scheduler interface. It provides simple operations such as scheduling/unscheduling jobs, starting/stopping/pausing the scheduler.

If you want to schedule your own software components for execution, they must implement the simple Job interface, which contains the method execute(). If you want to have components notified when a scheduled fire-time arrives, then the components should implement either the TriggerListener or JobListener interface.

The main Quartz process can be started and executed within your own application, as a stand-alone application (with an RMI interface), or within a J2EE application server to be used as a resource by your J2EE components.

Since JDK 1.3, Java has "built-in" timer capabilities through the java.util.Timer and java.util.TimerTask classes, why would someone use Quartz rather than these standard features?

There are many reasons. Here are a few:

Of course, for certain simple applications these features may not be important, in which case it might then be the right decision not to use Quartz.

Terracotta acquired the rights to the Quartz Scheduler project in November, 2009. Terracotta and the original Quartz team together can provide improved features and services for Quartz. Quartz is still (and always will be) an open-source project with contributors from around the world. Terracotta brings additional expertise for improving some of the advanced features of Quartz, and offers commercial support services to Quartz users.

Yes, Terracotta offers great commercial support services to Quartz users.

There are no known competing open source projects (there are a few other open source schedulers, but they are basically just Cron replacements written in Java).

Commercially, you will want to look at the well-regarded Flux scheduler.

Although Quartz ships "pre-built," many people like to make their own alterations and/or build the latest 'non-released' version of Quartz from CVS. To do this, follow the instructions in the README.TXT file that ships with Quartz.

Quartz contains an "update check" feature that connects to a server to check if there is a new version of Quartz available for download. This check runs asynchronously and does not affect startup/initialization time of Quartz, and it fails gracefully if the connection cannot be made. If the check runs, and an update is found, it will be reported as available in the Quartz logs.

You can disable the update check with the Quartz config property org.quartz.scheduler.skipUpdateCheck: true or the system property org.terracotta.quartz.skipUpdateCheck=true (which you can set in your system environment or as a -D on the java command line). It is recommended that you disable the update check for production deployments.