18

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?

Community
  • 1
  • 1
Dan Rosenstark
  • 68,471
  • 58
  • 283
  • 421
  • 1
    `java.util.Timer` is far from brilliantly written. It's inflexible and difficult to write testable code around. `ScheduledExecutorService` is better in every measurable way. – skaffman Feb 06 '10 at 13:16
  • @skaffman, that may be correct. My only question is whether `ScheduledExecutorService` is as lightweight as `Timer`. It's just a thin wrapper on `Object.wait(long)`... what about Scheduled...? – Dan Rosenstark Feb 06 '10 at 14:09
  • 1
    The source code is there, have a look for yourself. What I can say is that the `java.util.concurrent` stuff (including `ScheduledExecutorService`) has been designed for extremely high throughput, which `Timer` never was. – skaffman Feb 06 '10 at 14:17
  • Thank you @skaffman, I will check out he source. – Dan Rosenstark Feb 06 '10 at 14:52

6 Answers6

17

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.
Adamski
  • 54,009
  • 15
  • 113
  • 152
  • The last benefit might be interesting to me. But aside from that, I'm worried that ScheduledEx... might be "heavier". Thoughts? – Dan Rosenstark Feb 06 '10 at 13:01
  • 3
    Assuming you create a ScheduledExecutorService with a single thread it is highly unlikely you'll see any difference in performance (despite Timer containing its own priority queue implementation). – Adamski Feb 06 '10 at 13:08
8

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.

Simon Forsberg
  • 13,086
  • 10
  • 64
  • 108
Andreas Dolk
  • 113,398
  • 19
  • 180
  • 268
  • Thanks for that. So do you think, in terms of weight of implementation -- speed, memory-use, CPU-use -- Timer is the lightest option? – Dan Rosenstark Feb 06 '10 at 12:58
  • Timer is 'lightweight' in that is only has a single background thread. Be aware that both Timer and ScheduledExecutorService use an array internally to hold scheduled tasks. Hence, scheduling 10,000,000 tasks and then cancelling them will leave the array size at 10,000,000. In reality this would rarely be an issue. – Adamski Feb 06 '10 at 13:04
  • Honestly, I don't know and don't care about performance in most cases. If I had a performance issue, than exchanging Timer.sleep() by ScheduledThreadPoolExecuter would be on of the last things I looked at... – Andreas Dolk Feb 06 '10 at 13:08
  • Sorry @Andreas_D I don't normally care abut performance either, but I'm using Timer -- successfully -- to create MIDI-note loopers. So if there might easily be 1K scheduled tasks per second... on the other hand, maybe I've gone in an absolutely crazy direction by using Timers. – Dan Rosenstark Feb 06 '10 at 14:13
6

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.

Brian Agnew
  • 268,207
  • 37
  • 334
  • 440
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.

Bill the Lizard
  • 398,270
  • 210
  • 566
  • 880
4

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).

Martin
  • 2,573
  • 28
  • 22
  • Thanks. Readers should see the previously accepted answer here: http://stackoverflow.com/a/2213146/8047 – Dan Rosenstark Aug 03 '16 at 20:09
  • @Martin: I didn't see any reference to Timer or TimerTask being deprecated, as of today (6/26/2017). Maybe they were removed from the list. – FractalBob Jun 27 '17 at 01:28
  • @FractalBob Indeed these classes do not appear in the [JDK9 Deprecated List](http://download.java.net/java/jdk9/docs/api/deprecated-list.html#class). I found [this bug report](https://bugs.openjdk.java.net/browse/JDK-8154799)—looks like it’s not yet decided if they will be deprecated (see the change at 2016-10-04 21:40 under Activity → All). – Martin Jun 27 '17 at 15:04
2

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

stacker
  • 68,052
  • 28
  • 140
  • 210