Why are TimerTasks Runnable?

[Warren Dew]

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 ]

[Ernest Friedman-Hill]

Runnable is here just being used as a convenient interface with a single no-argument, void-returning method. It's not used to start a new Thread; the timer machinery will call run() directly.

I'm pretty sure there are other instances of this in the API, although I can't think of one right now.

[Warren Dew]

Thanks much, Ernest.

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

[Henry Wong]

Originally posted by Warren Dew:

Seems superfluous to me since the TimerTask interface enforces an abstract run() method anyway, but maybe that's just me.

I agree... there is no need to specify that a timer task should implement Runnable, as the run method is abstract, forcing the developer to implement the method anyway.

On the other hand... there are quite a few cases, where I would just refactor a timer task to run in its own thread. And having it as runnable was very convenient.

Henry

[Ernest Friedman-Hill]

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.