Why is the java.lang.Thread class in Java not finally marked by designers?

Question

What is the essence of creating a thread by the user by extending the Thread class, when we can achieve the same functionality by implementing Runnable and passing it to the Thread constructor.

Answer 1

achieve the same functionality Runnable implementation and pass its constructor Thread

Using a continuation thread is not limited to runnable. For example, you can change the behavior of some methods or add your own local thread information (always available with Thread.currentThread() ).

Answer 2

From a historical perspective, you need to understand that the Thread API was developed in Java 1.0 before Java supports anonymous inner classes. And many of the earlier code examples show Thread subclasses. Only after that:

• they added support for anonymous inner classes (Java 1.1)
• they figured out that it's better to use inner classes (etc.) to provide Runnable instances
• they implemented standard classes for performing tasks, thread pools, etc. (Java 5.0).

Everyone says very well that "Thread class in .Net is marked as final", but you should understand that C # /. Net came in a few years ... and was able to learn from Java design. Java was / was stuck with the historical baggage of a number of solutions other than perfection ... due to the paramount need NOT to break old code.

Answer 3

Thread is unusual in that it can reference Runnable to run, but it is also Runnable . By default, Thread will use itself as an instance of Runnable to run, although of course you can specify it somewhere else.

I think there is no good reason to mark Thread final and require an external Runnable or make Thread extensible and have its own Runnable . Both approaches are perfectly fine, and none of them seem to be a much better choice than the other.

If I were to guess, the reason for creating Thread subclassable is that it allows you to write code as follows:

 Thread t = new Thread() { public void run() { /* ... your code here ... */ } }; 

This is a little cleaner than subclassing Runnable and then wrapping it in a stream. Similarly, you can subclass Thread to get Runnable , which clearly indicates that it should be used as a thread. Of course, this is mostly a matter of aesthetics, and if Java designers had gone a different way, I think it would be a great solution.

Answer 4

One noticeable difference is that if your class A needs to extend class B (other than Thread) and be a thread at the same time, it will have to implement Runnable.

Answer 5

If I add something by adding Thread , you can extend the functionality of the thread (which is not found in Runnable , because it contains only the run() method), for example, by allowing your thread to act as a daemon thread (just like a garbage collector daemon thread ) Other threads exist as one non-daemon thread that calls the main method of the class (when the JVM starts).

The Runnable interface allows your class to be activated as a thread (by implementing the run() method).

Answer 6

The thread class describes how the thread works; Runnable describes what is running. If you want to change what is running, you must implement Runnable. If you want to change the way the thread starts, you get from Thread. In the case when you want to change the way the thread is executed, you can get from Thread and implement a separate Runnable object.

Answer 7

The only thing I can think of is: if you extend the Thread class, it allows your run () method to be marked as protected. One drawback of the Runnable implementation is that your startup method MUST be marked as public.