Why does Thread implement Runnable?

The reason is “backwards compatibility”.

The Thread class originated in Java 1.0 … or earlier. In those days, Java didn’t have inner classes, and so there wasn’t a light-weight way to implement a Runnable instance. If you look at old threading examples and tutorials from that era, it is common to see classes that extend Thread and override the run() method.

Over time, it was realized that extending Thread is not a good idea (for various reasons). However, the Thread design could not be changed because that would have made old Java code incompatible with newer JVMs.

Is there a legitimate use for Thread implementing Runnable that I’m not seeing?

It depends what you mean by “legitimate”.

• Old code that was written in the early days is not “illegitimate” by virtue of doing things the old way. There is nothing “broken” about it.

• There are potentially scenarios where it does make sense to extend Thread and override the run() method. For example, you might want run() to implement some special mechanism for passing info in or out of the supplied Runnable, or implement some special exception handling, or … make the thread “restartable”.

• There might even be scenarios where you’d want to call run() directly on a thread object. For instance if you were handed some “dogs breakfast” code that extended Thread and you had to convert it to run in a thread pool without modifying the original code. You might consider instantiating the crufty thread class and passing the instances as runnables to the threadpool to run. (Yes … horrible!)