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 sin

Answer 1

There is [JDK-8154799] deprecate Timer and TimerTask in the JDK’s bug tracker and in mid-2016 JEP 277 stated that java.util.Timer (and TimerTask) would be deprecated in JDK 9.

Several Java SE APIs will have a @Deprecated annotation added, updated, or removed. Some examples of such changes are listed below.

[…]

• add @Deprecated to java.util.Timer and TimerTask

However, in the JDK 9 release, those classes are not deprecated (deprecated classes can be found in the Deprecated List).

Answer 2

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 3

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

Answer 4

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 5

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 not deprecated.

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 6

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.