java.util.Timer: Is it deprecated?

Question

I read in a comment to this answer and in many other questions about scheduling (sorry, no references) that java.util.Timer is deprecated. I really hope not since I'm using it as the light way to schedule things in Java (and it works nicely). But if it's deprecated, I'll look elsewhere. However, a quick look at the API docs for 1.6 doesn't say anything about it being deprecated. It's not even mentioned in Sun's Deprecated List.

Is it officially deprecated^* and if so, what should I use instead?

---

^* On the other hand, if it's not deprecated, could people stop badmouthing this innocent and brilliantly-implemented set-o-classes?

Answer 1

In jdk1.6_10 it's not deprecated, so there is no need for an alternative.

Answer 2

No. Not all. You may want to use other mechanisms like Quartz for more complex timer requirements, but Timer works perfectly well and is not going anywhere.

Answer 3

I think this is a misunderstanding. The Timer class's JavaDoc mentions ScheduledThreadPoolExecutor and notes, that this class is effectively a more versatile replacement for the Timer/TimerTask combination. Nothing else. Timer is no deprecated.

EDIT

another quote from JavaDoc, ScheduledThreadPoolExecutor this time:

A ThreadPoolExecutor that can additionally schedule commands to run after a given delay, or to execute periodically. This class is preferable to Timer when multiple worker threads are needed, or when the additional flexibility or capabilities of ThreadPoolExecutor (which this class extends) are required.

Answer 4

No, it's not deprecated. In addition to Sun's Deprecated List, you'll also see a note in the JavaDoc for a class that has been deprecated. For example, the note for StringBufferInputStream says:

Deprecated. This class does not properly convert characters into bytes. As of JDK 1.1, the preferred way to create a stream from a string is via the StringReader class.

Answer 5

As others have mentioned, no it is not deprecated but I personally always use ScheduledExecutorService instead as it offers a richer API and more flexibility:

• ScheduledExecutorService allows you to specify the number of threads whereas Timer always uses a single thread.
• ScheduledExecutorService can be constructed with a ThreadFactory allowing control over thread aspects other than the name / daemon status (e.g. priority, ThreadGroup, UncaughtExceptionHandler).
• ScheduledExecutorService allows tasks to be scheduled with fixed delay as well as at a fixed rate.
• ScheduledExecutorService accepts Callable / Runnable as it's unit of work, meaning that you don't need to subclass TimerTask specifically to use it; i.e. you could submit the same Callable implementation to a regular ExecutorService or a ScheduledExecutorService.