Why does 'extends Thread' exist, when 'implements Runnable' is winner in all cases [duplicate]

Question

I know that implements Runnable is preferred over extends Thread in Java threads as it allows us to extend some other class if it is required. But if this is the case, does extends Thread also have its own advantages over implements Runnable and if so, what are these advantages?

Dehypnotize

@proudandhonour : Yes, I read the answer for that question, but all answers are explaining how 'implements runnable' is good. And actually those answers created this question in my mind. – Dehypnotize

@proudandhonour would you mind linking to the answer that answers this question? It doesn't seem in the first few. – Kittrell

consider scenario, when thread starts, you want to add the details of that particular thread to DB. This is different from business logic which you have in run() method, thus you want to keep it separate. Thus, you will override both start() and run() method – Liebermann

Answer 1

Because sometimes (almost never, but sometimes) you want to be able to change the basic behaviour of Thread.

That's when you'll need to extend it.

You can change it by overriding a method from the Thread class, you can't do it by implementing one from Runnable.

Apiarist

Example here - asker wanted to know which thread created/started this thread. Overrides constructor and start to do so. – Castoff

Answer 2

In the last 20+ years since Java 1.0 was released, what is a considered a good design pattern has changed. However, Java is committed to backward compatibility which means old code which might use poor design patterns will still work.

One of my pet hates is StringBuffer for which it was never a good idea to make it's method synchronized, was replaced more than tens years ago, but unfortunately developers are not prevented from using it today and even new developers use it, even though it was deprecated long before they started using Java.

Tarlatan

the choice between blocking runnables and threads has nothing to do with "design patterns", that does not make any sense. These are two different use-case scenarios – Collage

The design patterns are composition vs inheritance. What are the two different use cases you have in mind. Sub-classing Thread is very rarely about overriding anything but run() – Tarlatan

you seem to think that a Runnable is somehow related to a Thread. Well it isnt. At all. Runnables are blocking, executable algorithms and threads are asynchronous, independent ones which can still run long after the calling thread has ended. Please dont write answers about topics which are alien to you, thank you very much. This question could be reformulated to "Whats better : GM crops or the last season of breaking bad?" --- does not compute. – Collage

@Collage You must be taking about another language. I am talking about Java and in Java the first line of the code for Thread is class Thread implements Runnable This means that by inheritance you can pass an overridden Thread any where you use a Runnable, and you can pass a Runnable in the constructor of a Thread to be it's default implementation. If some one doesn't make sense to you, it probably just means you don't understand what they are talking about. The question does make sense as it is a common question see the "Possible duplicate" – Tarlatan

the fact that the class signatures are compatible does not change the senselessness of this question and all of the above answers - runnables still arent threads and they will never run asynchronously on their own – Collage

@Collage So you concede they are related, and it only doesn't make sense if you choose not to consider what the OP means when they ask this fairly common question. While your second statement is true, this is not what the OP is talking about. – Tarlatan

They arent related. At all. Signatures arent identities, thats basic logic - i could write a class which is signature-compatible to Integer yet change its entire behaviour so that it spits out a float value if i wanted to - id' run into precision problems inside of equals but thats about it, there are "good" approximations for that – Collage

@Collage IMHO There isn't a way to get a class written for Java 1.0 and an interface more related to one another. Your measure for what is related doesn't appear to be very useful. Methods have signatures, but classes and interfaces don't so you have lost me on that point. Only floatValue in Integer has a float value so I don't see what you are referring to. Instead of talking about something theoretical which might make sense to you, I suggest you consider how Java is actually used. – Tarlatan

@Collage where in the JLS does it mention the signature of a class? – Tarlatan

@Collage it's not just me but google has no idea what a class signature in Java means either google.co.uk/webhp?#safe=off&q=java+class+signature – Tarlatan

@Collage what baffles me is how some one has such a unique perspective on Java. – Tarlatan

well i guess you're new to programming so here goes nothing : signatures are sets of input/output declarations and types, in Java these are most commonly modifiers like "public" (visibility modifier) or "void" (input/output declaration). Classes also have these, they simply lack the input/output-part ... aaand thats about it. Now, i recommend doing a few programming exercies, you will quickly discover many things which arent even mentioned in some JLS - because they're absolutely basic, fundamental knowledge or even results of the application of pure logic, you have much to discover. – Collage

@Collage I see what you are trying to say in an informal manner however in Java these words have specific meanings and if you are going to argue with someone it is best to resort to the meaning they have been given in that language. Also if you are going to pick an argument with some one it is a good idea to know whom it is you are talking to when you have a lot to learn, because while it is true I have much yet to learn, you might appear to need to learn more basic things like the language you are arguing about. – Tarlatan