The documentation on the Timer class implies that all TimerTasks queued to the timer are run in the Timer's thread, sequentially. (That's why Timer does not make real time guarantees.)
Why, then, does TimerTask implement Runnable? They don't need to be Runnable if they are just executing in the Timer's thread. Or am I reading the Timer documentation wrong, and do the TimerTasks actually run in their own threads? [ April 26, 2005: Message edited by: Warren Dew ]
Seems superfluous to me since the TimerTask interface enforces an abstract run() method anyway, but maybe that's just me.
Actually, it bothers me more than that, since it seems to me that implementing Runnable promises that the object can be safely run in its own thread, which is more than a TimerTask should have to promise. That's probably just me being anal.
And why can't I get rid of a nagging doubt about whether I should rely on this, after being burned by relying on seemingly similar interface contracts regarding the Swing dispatch thread? Maybe I should reask that question in this forum, rather than the Swing forum....
Probably an example of evolutionary design. I bet they started out using Runnable, and then defined the abstract class when somebody wanted a cancel() method, and then they forgot to remove the interface before releasing the new API.