It's a bit unusual, but I've seen it a few times. Bruce Eckel does it in all his Thread classes. My feeling is that if your classes will be used by any other developers, you should probably avoid unexpected behavior like this. Or alternately, make sure it's well-documented. Essentially, if I see a class that extends Thread, I assume that I should call start() to start it. If I see a class that implements Runnable without extending Thread, I assume it's my job to create a Thread object to start it. Those are the standard idioms as far as I'm concerned, and if a class doesn't follow them I'd expect to be warned about it. Note that for class A one option is to hide the Runnable aspect entirely by using a nested or inner class. E.g.
This may be a little more complex on the inside, but it has the advantage that someone looking at a javadoc-generated API for this class won't think "hey, it's a Runnable, therefore I should create a Thread for it." [ July 08, 2003: Message edited by: Jim Yingst ]
"I'm not back." - Bill Harding, Twister
posted 17 years ago
Thank you Jim for your ideas. Also, since your hidden Runnable is private, no one is going to invoke the run method except the Thread. Good idea. Here is a variation on your hidden Runnable, essentially the same thing.
If you settle for what they are giving you, you deserve what you get. Fight for this tiny ad!