Java Supports Multiple Inheritance without interfaces

Hi everyone !

My name is Akshay Sahu and I have a serious issue on my mind.

I say "Java supports multiple inheritance" and I came to this conclusion based on the following points:

1. Every class in java inherits itself and the java.lang.Object class. (Reference Kathy Sierra and Bert Bates OCJP 6). This statement alone is enough to prove it.

2. And if we extend another class, say java.lang.Thread, then clearly your class is said to be implementing Multiple Inheritance.

Then why does, Oracle (formerly SUN) say that, Java does not support Multiple Inheritance.

Please provide a solution to this at the earliest.

Thank You,
Akshay Sahu.

I was shocked to see the Subject of this post! Anyways I dont know how to explain. May be other Ranchers will be able to add relevant information.

The whole idea of not allowing multiple inheritance was to avoid the Deadly Diamond of death. But in the query raised by you I dont see any kind of such violation. And with overriding and Polymorphism, the JVM will know which method to call even if the particular Class extends Thread and it in turn Object (and Object contains fixed number of methods).

Howdy, Akshay!

Well champ, there is no multiple inheritance!

2. And if we extend another class, say java.lang.Thread, then clearly your class is said to be implementing Multiple Inheritance.

I think you are saying this because you have the feeling that you are extending Thread and Object, right? Well, the thing is, you are only extending Thread, and Thread extends Object. So it is indeed possible to only extend one class, and thus no multiple inheritance.

Exactly this topic has been already discussed here. Your question is answered in that thread.

Ah how easy was that answer. Never struck to my thoughts

Hi everyone !!!

I have got my answers after I discussed the above issue with my colleague.

The explanation is as follows:

1. A class extending itself is called as Cyclic Inheritance. And no OO programming language in this world supports Cyclic Inheritance.
2. In Kathy's book, it was written as "Other than objects of class Object, all java objects are polymorphic as they pass the IS-A test for their own type and for the Object class".
3. And when you extend, say java.lang.Thread class, then your class does not extend Object, they extend Thread which in turn extends Object. This becomes Multi-level inheritance instead of multiple inheritance.



Thank You,
Akshay Sahu.

Hi Akshay,

If your class is extending Thread Class then the Object class automatically comes in the hierarchy,so it won't be multiple inheritance but multi-level inheritance.
Your class extending Thread which in turn extending Object.

Hope it clears your doubt

So we can conclude by saying Java supports multilevel inheritance but not multiple inheritance.

public class Something extends AnotherThing implements AnInterface
the following is an illegal syntax

public class Something extends AnotherThing, ThirdThing implements AnInterface

That is why it is not permitted to extend from multiple classes but you can implement multiple interfaces

java doesn't support multiple inheritence...
because when you extends a class,the super class will extends object class by default,and when you extends a class, the super class contains object class properties and the base class will get the properties of object through multilevel inheritance....

Welcome to the Ranch

That is correct, but it doesn't explain why Java® doesn't support multiple inheritance. Multiple inheritance means that a class has more than one direct superclass. If you write class Foo extends Bar, then Bar is the direct superclass and Object is an indirect superclass of Foo. What you might call a multilevel superclass.

I've just always understood multiple inheritance to be combining object A with Object B to create Object C which would inherit an amalgam of the methods and properties of both A and B!

That is to say that multiple inheritance would mean each object having more than one 'direct' parent!

That sounds like what I have always understood multiple inheritance to mean.

To avoid ambiguity error java does not support multiple inheritance through class. But through the interface, multiple inheritance is possible in java. No java doesn't support multiple inheritance directly because it leads to overiding of methods when both extended class have a same method name.

meenal deshpande wrote:. . . multiple inheritance is possible in java. No java doesn't support multiple inheritance directly . . . .

Why are you contradicting yourself? Multiple interfaces don't constitute inheritance, so Java® doesn't support multiple inheritance full stop.

Before there was a Java, I was one of the first would-be implementors of a C++ compiler. C++, of course, does implement true multiple inheritance.

To understand why the Java language definition doesn't do multiple inheritance, you have to understand the essential difference between a Java Class and a Java Interface.

Essentially, a Java Class defines the characteristics of a concrete object. While an Abstract class cannot itself be instantiated as a concrete object, it is assumed that abstract classes will serve as superclasses for concretely-instantiable objects. If there's any way to use an abstract class that doesn't at some point involve a concrete subclass, it doesn't occur to me at the moment.

Interfaces, on the other hand, are never instantiated. An Interface isn't so much a definition as it is a contract. When a class says that it implements an Interface, then what it's really promising is that for each method defined in the interface, there will be a corresponding method implementation in the class. Since an interface definition is a promise, rather than a model, having a class implement two or more interfaces which contain methods whose signatures are identical is not a problem, since all that has been done is a repetition of the promise of that method.

On the other hand, in a true multiple inheritance system, where class C inherits from both class A and class B, a reference to public method "foo" is ambiguous if both classes implement a member names foo. And in C++, the deductive mechanisms (at least originally) would have been able to determine which "foo" you meant even if they were of non-intersecting types (for example an "int foo" and a "class *foo"). And it's even messier when methods/functions are involved. You no longer have a simple and abstract way of referencing class methods if the same method signature is published for 2 different classes, you have to explicitly disambiguate them. Which loses you not only abstraction itself, but the primary benefits of abstraction, such as "black box" operation and relative immunity in the class-using code to changes in the class definitions.

And speaking from experience, multiple inheritance of classes is a right royal pain. Between that and the fact that C++ started with a pretty fuzzy disambiguation mechanism to begin with, I ended up abandoning my hopes of implementing a C++ compiler of my own.