Java doesn't allow multiple inheritance, but it allows implementing multiple interfaces. Why?
-
1I edited the question title to make it more descriptive. – Bozho Mar 25 '10 at 12:45
-
4Interestingly, in the JDK 8, there will be [extension methods](http://cr.openjdk.java.net/~briangoetz/lambda/lambda-state-4.html) which will allow the definition of implementation of interface methods. Rules are been defined to govern multiple inheritance of behavior, but not of state (which I understand is more [problematic](http://mail.openjdk.java.net/pipermail/lambda-dev/2012-July/005197.html). – Edwin Dalorzo Jul 31 '12 at 12:48
-
1Before you guys waste time on answers which only tell you "How java acheives multiple inheritance "... I suggest you to go down to @Prabal Srivastava answer that logically gives you what must be happening internally, to not allow classes this right... and only allow interfaces the right to allow multiple inheritance. – Yo Apps Nov 27 '19 at 15:09
-
@YoApps That answer has it back to front. It was a design decision, and the compiler and JVM implementation followed. Most of the other answers here follow a similar cart-before-horse logic. All this is essentially tautologous. The real answer is that it was a design decision to avoid the diamond-inheritance issues, which are legion. – user207421 Jun 19 '22 at 04:30
21 Answers
Because interfaces specify only what the class is doing, not how it is doing it.
The problem with multiple inheritance is that two classes may define different ways of doing the same thing, and the subclass can't choose which one to pick.

- 588,226
- 146
- 1,060
- 1,140
-
8I used to do C++ and ran into that exact same issue quite a few times. I recently read about Scala having "traits" that to me seem like something in between the "C++" way and the "Java" way of doing things. – Niels Basjes Jul 29 '10 at 21:04
-
+1 , complete yet concise and last bot not the least easy to understand answer. – Geek Aug 06 '12 at 07:12
-
7This way, you are avoiding the "diamond problem": http://en.wikipedia.org/wiki/Diamond_problem#The_diamond_problem – Nick Louloudakis Feb 13 '14 at 15:32
-
7Since Java 8 you can define two identical default methods, one in each interface. If you will implement both interfaces in your class, you have to override this method in the class itself, see: http://docs.oracle.com/javase/tutorial/java/IandI/override.html#default – bobbel May 14 '14 at 12:29
-
-
12This answer is not accurate. The problem is not specifying the _how_ and Java 8 is there to prove. In Java 8, two _super interfaces_ can declare the same method with different implementations, but that's not a problem because interface methods are _virtual_, so you can just overwrite them and the problem is solved. The real problem is about **ambiguity** in the **attributes**, because you can't solve this ambiguity overwriting the attribute (attributes are not virtual). – Alex Oliveira Jul 13 '16 at 19:51
-
1
-
1@AlexOliveira is right here. A method can be overridden easily and the ambiguity would be solved; a field on the other hand is simply data storage without any virtual dispatch table. You would get either: duplicated fields with every class seeing only its own fields or unified fields with all classes stepping on each other's toes (and no ability to override that behavior). – marcus Oct 03 '18 at 16:42
-
@AlexOliveira is so right, and the chosen answer is so wrong. `Deadly Diamond of Death` has never been the problem when it comes to methods. It's the clash of variables that matters. Because with default methods in interfaces, you can still have your diamond constellation and get away with it, but you cannot have variables colliding. Java 8 proves this wrong. The answers to the question should be reset and answered with state-of-the-art-of-Java in mind. – JayC667 Mar 02 '20 at 22:57
-
@marcus Thanks for clearing on that state/fields create ambiguity. But why can't the same logic of implementing the default method used in Java 8 used for fields ... like when using multiple inheritances we also need to provide a default value to the fields which would solve the ambiguity problem for fields – Gautam Naik Jan 16 '21 at 05:55
-
@GautamNaik It's not only the default value that matters but will the space allocated to a field be merged with other fields with the same name? Would the JVM redirect all reads and writes to the merged fields? I think it would be *possible* but it would change mental model programmers have (fields are pieces of memory, methods are actions that can be called) and it would make some operations slower (accessing a field would involve a virtual dispatch). Not impossible, but if you look at what C++ and Scala did, you see that it does get more complex (virtual base classes, all fields are methods) – marcus Jan 16 '21 at 20:16
-
@marcus Thanks for that, I agree complexity would increase and Java's main motto is to be a simple, object-oriented language – Gautam Naik Jan 24 '21 at 07:30
One of my college instructors explained it to me this way:
Suppose I have one class, which is a Toaster, and another class, which is NuclearBomb. They both might have a "darkness" setting. They both have an on() method. (One has an off(), the other doesn't.) If I want to create a class that's a subclass of both of these...as you can see, this is a problem that could really blow up in my face here.
So one of the main issues is that if you have two parent classes, they might have different implementations of the same feature — or possibly two different features with the same name, as in my instructor's example. Then you have to deal with deciding which one your subclass is going to use. There are ways of handling this, certainly — C++ does so — but the designers of Java felt that this would make things too complicated.
With an interface, though, you're describing something the class is capable of doing, rather than borrowing another class's method of doing something. Multiple interfaces are much less likely to cause tricky conflicts that need to be resolved than are multiple parent classes.

- 10,721
- 3
- 25
- 25
-
6Thanks, NomeN. The source of the quote was a PhD student named Brendan Burns, who at the time was also the maintainer of the open-source Quake 2 source repository. Go figure. – Syntactic Mar 25 '10 at 13:22
-
4The problem with this analogy is that if you are creating a subclass of a nuclear bomb and a toaster, the "nuclear toaster" would reasonably blow up when used. – 101100 Mar 27 '13 at 17:55
-
31If someone decides to mix a nuclear bomb and a toaster, he deserves that the bomb blows up in his face. The quote is _fallacious reasoning_ – masoud May 19 '13 at 12:15
-
2The same programming language does allow multiple "interface" inheritance, so this "justification" does not apply. – curiousguy May 19 '13 at 16:13
-
1Lol only looking at this now, but big up vote vor @masoud. Every computer science student should be asking this question – Tomvkgames Dec 11 '20 at 02:45
-
Just like we have not gotten to getting multiline strings, and when we did, the implementation is completely useless, and due to its release will never be fixed. Now you have multiline string support but good luck embedding a value. I've literally implemented support for properties and fields in interfaces and it is possible using a static hashmap that keeps track of this to value. I will see if i get around to releasing it, but it comes with some caveats, like memory leaks if it is used incorrectly. Java should provide a similar or better such implementation but i guess we have to wait ... – mjs Apr 23 '21 at 09:54
Because inheritance is overused even when you can't say "hey, that method looks useful, I'll extend that class as well".
public class MyGodClass extends AppDomainObject, HttpServlet, MouseAdapter,
AbstractTableModel, AbstractListModel, AbstractList, AbstractMap, ...

- 342,105
- 78
- 482
- 720
-
Can you explain why you say inheritance is overused? Creating a god class is exactly what I want to do! I find so many people that work around single inheritance by creating "Tools" classes that have static methods. – Duncan Calvert Aug 12 '14 at 01:32
-
11@DuncanCalvert: No, you do not want to do that, not if that code will ever need maintenance. Lots of static methods misses the point of OO, but excessive multiple inheritance is *much* worse because you completely lose track of which code is used where, as well as what a class conceptually is. Both are trying to solve the problem of "how can I use this code where I need it", but that is a simple short-term problem. The much harder long-term problem solved by proper OO design is "how do I change this code without having the program break in 20 different places in unforeseeable ways? – Michael Borgwardt Aug 12 '14 at 13:03
-
3@DuncanCalvert: and you solve that by having classes with high cohesion and low coupling, which means they contain pieces of data and code that interact intensively with each other, but interact with the rest of the program only through a small, simple public API. Then you can think about them in terms of that API instead of the internal details, which is important because people can only keep a limited amount of details in mind at the same time. – Michael Borgwardt Aug 12 '14 at 13:06
-
-
Because we already have interfaces to do that. Simply adding properties / fields availability will not complicate anything, but rather make things simpler. Splitting implementations into interfaces with default methods for instance where each interface has one dependency say, SessionFactory sessionFactory(); and implement all logic pertaining to a SessionFactory, and say another interface implementing shit relating Session session(); will be way cleaner than having SessionFactory, and Session declared in one class. By splitting them each one handles their area and .... – mjs Apr 23 '21 at 20:09
-
For someone with 326K that is surprising. I am not from the Scala world, but there they have something called Traits. Have you heard of it? Imagine default interfaces with a state. There is no reason that this is not possible because it is possible to implement in the same manner. For all I care the state / property could be private but really they could be public and / or protected. When the Java world wakes up we might eventually get this feature, but I have little hopes. We waited til 2021 to get multiline strings and they screwed that part up majorily, and now there ... – mjs Apr 23 '21 at 20:16
-
They made default methods in interfaces possible to declare private which was welcome but completely missed the ball on protected. You might want to grant a subclass or subinterface access to implementation incase they decide to override your public method, but no. Only private. Fcuk. At least that one is redeemable. – mjs Apr 23 '21 at 20:20
-
Also caching is now not possible due to the interface limitation not being able to hold state. So if you have some computation that only needs to be done once, good luck. Do note that I have code that enables me state in interfaces but I would not use it for a large environment, but is fine to use for most other things. Since an interface will always hold a this, due to someone having an instance of the interface, a static WeakIdentityHashMap can be created to map this to a State. That means the interfae can call staticmap.get(this) and the state object. So even I can do it ... – mjs Apr 23 '21 at 20:24
-
To me default methods in interfaces is the best thing since sliced bread, and have lead to a reduction in overall complexity by a factor of 100 of my code. I can simply implement an interface to inject any behaviour i desire my new class, and /or interface to have. All i have to do is usually implement one method to supply what? Usually an instance. You can not beat that. The instance might still need to be supplied through an abstract method implementation, but the lack of ability to hold state in interfaces is the difference between interfaces and classes at this point and prevents ... – mjs Apr 23 '21 at 20:33
-
... for instance sub values being created based on another supplied value, and have that value be cached for instance. Caching is not possible. Other methods can not use your value. The thing is that an interface is always connected to a 'this', and so there is no real reason as to why it can not hold state relating to that interface alone. Conflicts in other interfaces? How is it solved with duplicate interface methods? The same way. Introduce some syntax and force the redeclaration in subinterfaces / subclasses and allow access through SuperInteface.super.myproperty; – mjs Apr 23 '21 at 20:35
The answer of this question is lies in the internal working of java compiler(constructor chaining). If we see the internal working of java compiler:
public class Bank {
public void printBankBalance(){
System.out.println("10k");
}
}
class SBI extends Bank{
public void printBankBalance(){
System.out.println("20k");
}
}
After compiling this look like:
public class Bank {
public Bank(){
super();
}
public void printBankBalance(){
System.out.println("10k");
}
}
class SBI extends Bank {
SBI(){
super();
}
public void printBankBalance(){
System.out.println("20k");
}
}
when we extends class and create an object of it, one constructor chain will run till Object
class.
Above code will run fine. but if we have another class called Car
which extends Bank
and one hybrid(multiple inheritance) class called SBICar
:
class Car extends Bank {
Car() {
super();
}
public void run(){
System.out.println("99Km/h");
}
}
class SBICar extends Bank, Car {
SBICar() {
super(); //NOTE: compile time ambiguity.
}
public void run() {
System.out.println("99Km/h");
}
public void printBankBalance(){
System.out.println("20k");
}
}
In this case(SBICar) will fail to create constructor chain(compile time ambiguity).
For interfaces this is allowed because we cannot create an object of it.
For new concept of default
and static
method kindly refer default in interface.
Hope this will solve your query. Thanks.

- 782
- 7
- 18
-
2This answer has it back to front. The compiler and interpreter were programmed to implement the language design decisions, not the other way round. – user207421 Jun 19 '22 at 04:24
You can find accurate answer for this query in oracle documentation page about multiple inheritance
- Multiple inheritance of state: Ability to inherit fields from multiple classes
In this case, When you create an object : It will inherit fields from all of the superclasses. It will cause two issues.
a. What if methods or constructors from different super classes instantiate the same field? b. Which method or constructor will take precedence?
- Multiple inheritance of implementation: Ability to inherit method definitions from multiple classes
This approach causes name conflicts and ambiguity. If a subclass and superclass contain same method name (and signature), compiler can't determine which version to invoke.
Java supports this type of multiple inheritance with default methods, since Java 8 release. The Java compiler provides some rules to determine which default method a particular class uses.
Refer to below SE post for more details on resolving diamond problem:
What are the differences between abstract classes and interfaces in Java 8?
- Multiple inheritance of type: Ability of a class to implement more than one interface.
Since interface does not contain mutable fields, you need not worry about problems that result from multiple inheritance of state here.

- 37,698
- 11
- 250
- 211
-
1At least you quoted an actual source giving an actual reason. Most of the other answers here are essentially tautologies. – user207421 Jun 19 '22 at 04:26
Java supports multiple inheritance through interfaces only. A class can implement any number of interfaces but can extend only one class.
Multiple inheritance is not supported because it leads to deadly diamond problem. However, it can be solved but it leads to complex system so multiple inheritance has been dropped by Java founders.
In a white paper titled “Java: an Overview” by James Gosling in February 1995(link - page 2) gives an idea on why multiple inheritance is not supported in Java.
According to Gosling:
"JAVA omits many rarely used, poorly understood, confusing features of C++ that in our experience bring more grief than benefit. This primarily consists of operator overloading (although it does have method overloading), multiple inheritance, and extensive automatic coercions."

- 326
- 3
- 8

- 528
- 7
- 15
Java does not support multiple inheritance because of two reasons:
- In java, every class is a child of
Object
class. When it inherits from more than one super class, sub class gets the ambiguity to acquire the property of Object class.. - In java every class has a constructor, if we write it explicitly or not at all. The first statement is calling
super()
to invoke the supper class constructor. If the class has more than one super class, it gets confused.
So when one class extends from more than one super class, we get compile time error.

- 18,379
- 16
- 47
- 61

- 79
- 1
- 1
-
For point 2: the need for `super()` is arbitrary ("just because"). The requirement could be removed or have a syntax that supports naming parent types. I would say the reverse: `super` exists **because** language does not support multiple class inheritance. – Xeverous Apr 18 '22 at 16:24
-
It works in C++. It could have been made to work in Java as well. Answer is inadequate to explain the phenomenon. – user207421 Jun 19 '22 at 04:25
Implementing multiple interfaces is very useful and doesn't cause much problems to language implementers nor programmers. So it is allowed. Multiple inheritance while also useful, can cause serious problems to users (dreaded diamond of death). And most things you do with multiple inheritance can be also done by composition or using inner classes. So multiple inheritance is forbidden as bringing more problems than gains.

- 12,283
- 6
- 56
- 83
-
-
2@curiousguy Containing more than one subobject of same base class, ambiguity (override from which base class use), complicated rules of resolving such ambiguity. – Tadeusz Kopec for Ukraine May 22 '13 at 07:54
-
@curiousguy: If a framework provides that casting an object reference to a base-type reference will be identity preserving, then every object instance must have exactly one implementation of any base-class method. If `ToyotaCar` and `HybridCar` both derived from `Car` and overrode `Car.Drive`, and if `PriusCar` inherited both *but didn't override `Drive`*, the system would have no way of identifying what the virtual `Car.Drive` should do. Interfaces avoid this problem by avoiding the italicized condition above. – supercat Jun 16 '13 at 19:36
-
@curiousguy: It's worthwhile to note that some frameworks avoid the issue by not allowing identity-preserving casts to the base type. If code couldn't use the `Drive` method, nor cast to `Car`, without first casting to either `HybridCar` or `ToyotaCar`, ambiguity would be avoided, but the result of the casting sequence `PriusCar`->`ToyotaCar`->`Car` would be different from that of `PriusCar`->`HybridCar`->`Car` (meaning the casts would not be identity-preserving). – supercat Jun 16 '13 at 19:39
-
1@supercat " the system would have no way of identifying what the virtual Car.Drive should do." <-- Or it could just give a compile error and make you choose one explicitly, like C++ does. – Chris Middleton Aug 13 '15 at 07:03
-
1@ChrisMiddleton: A method `void UseCar(Car &foo)`; cannot be expected to include disambiguation between `ToyotaCar::Drive` and `HybridCar::Drive` (since it should often neither know nor care that those other types even *exist*). A language could, as C++ does, require that code with `ToyotaCar &myCar` wishing to pass it to `UseCar` must first cast to either `HybridCar` or `ToyotaCar`, but since ((Car)(HybridCar)myCar).Drive` and `((Car)(ToyotaCar)myCar).Drive ` would do different things, that would imply that the upcasts were not identity-preserving. – supercat Aug 13 '15 at 15:57
It is said that objects state is referred with respect to the fields in it and it would become ambiguous if too many classes were inherited. Here is the link
http://docs.oracle.com/javase/tutorial/java/IandI/multipleinheritance.html

- 91
- 1
- 2
- 9
Since this topic is not close I'll post this answer, I hope this helps someone to understand why java does not allow multiple inheritance.
Consider the following class:
public class Abc{
public void doSomething(){
}
}
In this case the class Abc does not extends nothing right? Not so fast, this class implicit extends the class Object, base class that allow everything work in java. Everything is an object.
If you try to use the class above you'll see that your IDE allow you to use methods like: equals(Object o)
, toString()
, etc, but you didn't declare those methods, they came from the base class Object
You could try:
public class Abc extends String{
public void doSomething(){
}
}
This is fine, because your class will not implicit extends Object
but will extends String
because you said it. Consider the following change:
public class Abc{
public void doSomething(){
}
@Override
public String toString(){
return "hello";
}
}
Now your class will always return "hello" if you call toString().
Now imagine the following class:
public class Flyer{
public void makeFly(){
}
}
public class Bird extends Abc, Flyer{
public void doAnotherThing(){
}
}
Again class Flyer
implicit extends Object which has the method toString()
, any class will have this method since they all extends Object
indirectly, so, if you call toString()
from Bird
, which toString()
java would have to use? From Abc
or Flyer
? This will happen with any class that try to extends two or more classes, to avoid this kind of "method collision" they built the idea of interface, basically you could think them as an abstract class that does not extends Object indirectly. Since they are abstract they will have to be implemented by a class, which is an object (you cannot instanciate an interface alone, they must be implemented by a class), so everything will continue to work fine.
To differ classes from interfaces, the keyword implements was reserved just for interfaces.
You could implement any interface you like in the same class since they does not extends anything by default (but you could create a interface that extends another interface, but again, the "father" interface would not extends Object"), so an interface is just an interface and they will not suffer from "methods signature colissions", if they do the compiler will throw a warning to you and you will just have to change the method signature to fix it (signature = method name + params + return type).
public interface Flyer{
public void makeFly(); // <- method without implementation
}
public class Bird extends Abc implements Flyer{
public void doAnotherThing(){
}
@Override
public void makeFly(){ // <- implementation of Flyer interface
}
// Flyer does not have toString() method or any method from class Object,
// no method signature collision will happen here
}

- 1,423
- 1
- 16
- 31
For the same reason C# doesn't allow multiple inheritence but allows you to implement multiple interfaces.
The lesson learned from C++ w/ multiple inheritence was that it lead to more issues than it was worth.
An interface is a contract of things your class has to implement. You don't gain any functionality from the interface. Inheritence allows you to inherit the functionality of a parent class (and in multiple-inheritence, that can get extremely confusing).
Allowing multiple interfaces allows you to use Design Patterns (like Adapter) to solve the same types of issues you can solve using multiple inheritence, but in a much more reliable and predictable manner.

- 242,243
- 40
- 408
- 536
-
11C# does not have multiple inheritance precisely because Java does not allow it. It was designed much later than Java. The main problem with multiple inheritance I think was the way people were taught to use it left and right. The concept that delegation in most cases is a much better alternative just was not there in the early and mid-nineties. Hence I remember examples, in textbooks, when Car is a Wheel and a Door and a Windshield, vs. Car contains Wheels, Doors and Windshield. So the single inheritance in Java was a knee jerk reaction to that reality. – Alexander Pogrebnyak Mar 25 '10 at 12:55
-
2@AlexanderPogrebnyak: Pick two of the following three: (1) Allow identity-preserving casts from a subtype reference to a supertype reference; (2) Allow a class to add virtual public members without recompiling derived classes; (3) Allow a class to implicitly inherit virtual members from multiple base classes without having to explicitly specify them. I don't believe it's possible for any language to manage all three of the above. Java opted for #1 and #2, and C# followed suit. I believe C++ adopts #3 only. Personally, I think #1 and #2 are more useful than #3, but others may differ. – supercat Jun 16 '13 at 19:45
-
@supercat "I don't believe it's possible for any language to manage all three of the above" – if the offsets of data members are determined at runtime, rather than compilation time (as they are in Objective-C's "non-fragile ABI"), and or a per-class basis (i.e. each concrete class has its own member offset table), then I think all 3 goals can be achieved. – The Paramagnetic Croissant Sep 27 '15 at 18:46
-
@TheParamagneticCroissant: The major semantic problem is #1. If `D1` and `D2` both inherit from `B`, and each overrides a function `f`, and if `obj` is an instance of a type `S` which inherits from both `D1` and `D2` but does not override `f`, then casting a reference to `S` to `D1` should yield something whose `f` uses the `D1` override, and casting to `B` shouldn't change that. Likewise casting a reference `S` to `D2` should yield a something whose `f` uses the `D2` override, and casting to `B` shouldn't change that. If a language didn't need to allow virtual members to be added... – supercat Sep 27 '15 at 19:11
-
...without recompiling, it could allow multiple-inheritance in cases where there was no ambiguity and squawk if things became ambiguous, but if `D1` and `D2` can be changed and recompiled without recompiling `S`, then ambiguities could arise which no compiler would be able to see. – supercat Sep 27 '15 at 19:14
-
@supercat I would say that if both `D1` and `D2` (or even one of them) overrides `f`, then `S` should also override it, else it's a compiler error (since when calling `f` on an object of declared type `S`, how could one decide whether to call `D1::f` or `D2::f`?) – The Paramagnetic Croissant Sep 27 '15 at 19:38
-
@TheParamagneticCroissant: If `S` is compiled at a time when neither `D1` nor `D2` overrides `f`, but both classes will be be changed in future to override it, which compilation step should squawk? The compilation of `S` can't squawk because has no way of knowing that `D1` and `D2` will change. The compilations of `D1` and `D2` can't squawk since they know nothing of `S`. – supercat Sep 27 '15 at 19:42
-
@supercat That's right… couldn't this situation be checked for at runtime, though? – The Paramagnetic Croissant Sep 27 '15 at 19:52
-
1@TheParamagneticCroissant: It could, and my list of choices was somewhat over-simplified to fit in a comment, but deferring to run-time makes it impossible for the author of D1, D2, or S to know what changes they can make without breaking consumers of their class. – supercat Sep 27 '15 at 20:20
-
For example two class A,B having same method m1(). And class C extends both A, B.
class C extends A, B // for explaining purpose.
Now, class C will search the definition of m1. First, it will search in class if it didn't find then it will check to parents class. Both A, B having the definition So here ambiguity occur which definition should choose. So JAVA DOESN'T SUPPORT MULTIPLE INHERITANCE.

- 550
- 5
- 11
-
how about making the java compiler gives compiler if the same methods or variables defined in both parent class so that we can change the code... – Siluveru Kiran Kumar Aug 09 '19 at 06:06
in simple manner we all know, we can inherit(extends) one class but we can implements so many interfaces.. that is because in interfaces we don't give an implementation just say the functionality. suppose if java can extends so many classes and those have same methods.. in this point if we try to invoke super class method in the sub class what method suppose to run??, compiler get confused example:- try to multiple extends but in interfaces those methods don't have bodies we should implement those in sub class.. try to multiple implements so no worries..

- 119
- 4
Multiple inheritance is not supported by class because of ambiguity. (this point is explained clearly in above answers using super keyword)
Now for interfaces,
upto Java 7, interfaces could not define the implementation of methods. So if class implements from multiple interfaces having same method signature then implementation of that method is to be provided by that class.
from java 8 onwards, interfaces can also have implementation of methods. So if class implements two or more interfaces having same method signature with implementation, then it is mandated to implement the method in that class also.
From Java 9 onwards, interfaces can contain Static methods, Private methods, Private Static methods.
Modifications in features of Interfaces (over java version-7,8,9)

- 11
- 2
Because an interface is just a contract. And a class is actually a container for data.

- 7,928
- 7
- 46
- 71
-
The fundamental difficulty with multiple inheritance is the possibility that a class might inherit a member via multiple paths which implement it differently, without providing its own overriding implementation. Interface inheritance avoids this because the only place interface members can be implemented is in classes, whose descendants will be limited to single inheritance. – supercat Jun 16 '13 at 19:58
Consider a scenario where Test1, Test2 and Test3 are three classes. The Test3 class inherits Test2 and Test1 classes. If Test1 and Test2 classes have same method and you call it from child class object, there will be ambiguity to call method of Test1 or Test2 class but there is no such ambiguity for interface as in interface no implementation is there.

- 2,618
- 3
- 21
- 24
Java does not support multiple inheritance , multipath and hybrid inheritance because of the following ambiguity problem.
Scenario for multiple inheritance: Let us take class A , class B , class C. class A has alphabet(); method , class B has also alphabet(); method. Now class C extends A, B and we are creating object to the subclass i.e., class C , so C ob = new C(); Then if you want call those methods ob.alphabet(); which class method takes ? is class A method or class B method ? So in the JVM level ambiguity problem occurred. Thus Java does not support multiple inheritance.
Reference Link: https://plus.google.com/u/0/communities/102217496457095083679

- 305,947
- 44
- 307
- 483
Take for example the case where Class A has a getSomething method and class B has a getSomething method and class C extends A and B. What would happen if someone called C.getSomething? There is no way to determine which method to call.
Interfaces basically just specify what methods a implementing class needs to contain. A class that implements multiple interfaces just means that class has to implement the methods from all those interfaces. Whci would not lead to any issues as described above.

- 4,383
- 1
- 24
- 42
-
3"_What would happen if someone called C.getSomething._" It is an error in C++. Problem solved. – curiousguy May 19 '13 at 16:14
-
That was the point... that was a counter example that I thought was clear. I was pointing out that there is no way to determine which get something method should be called. Also as a side note, the question was related to java not c++ – John Kane May 20 '13 at 19:09
-
1I am sorry I do not get what your point is. Obviously, there are ambiguity in some cases with MI. How is that a counter example? Who claimed that MI never result in ambiguity? "_Also as a side note, the question was related to java not c++_" So? – curiousguy May 20 '13 at 23:20
-
I was just trying to show why that ambiguity exists and why it doesnt with interfaces. – John Kane May 20 '13 at 23:59
-
1Yes, MI can result in ambiguous calls. So can overloading. So Java should remove overloading? – curiousguy May 21 '13 at 00:19
-
...no. If a class extends multiple classes and both super classes extend the same method it will result in errors. There is no way to determine the correct method to be called. Overloading works because this is not allowed. Im not sure why overloading would result in an ambiguous call, what gets called is determined by scope. – John Kane May 21 '13 at 11:20
-
Overloading resolution sometimes results in an ambiguity, in C++ or in Java. – curiousguy May 21 '13 at 12:06
-
I was only referring to java (the language the question was asked about). Can you give an example of how overloading can be ambiguous in Java? I cannot think of any cases of hand. – John Kane May 21 '13 at 13:08
-
let us [continue this discussion in chat](http://chat.stackoverflow.com/rooms/30341/discussion-between-curiousguy-and-john-kane) – curiousguy May 21 '13 at 14:28
-
@curiousguy: Multiple inheritance may not be a problem if adding virtual public members to a base class will require recompiling all derived classes, and/or one doesn't need identity-preserving typecasts from a subtype to its base type. Both Java and .NET provide both those features, however; that in turn requires that classes must explicitly specify the implementation of all virtual members that may be imported via more than once source [which both frameworks do by requiring that such members be imported via interfaces]. – supercat Jun 16 '13 at 19:53
the image explaining the problem with multiple inheritances.
What is the inherited member of the derived class? it is still private or publically available in the derived class?
For not getting this type of problem in Java they removed multiple inheritance. This image is a simple example of an object-oriented programming problem.

- 305,947
- 44
- 307
- 483

- 19
- 2
-
There is no private inheritance in Java. Your answer and your image explain nothing. – user207421 Jun 20 '22 at 03:26
* This is a simple answer since I'm a beginner in Java *
Consider there are three classes X
,Y
and Z
.
So we are inheriting like X extends Y, Z
And both Y
and Z
is having a method alphabet()
with same return type and arguments. This method alphabet()
in Y
says to display first alphabet and method alphabet in Z
says display last alphabet.
So here comes ambiguity when alphabet()
is called by X
. Whether it says to display first or last alphabet???
So java is not supporting multiple inheritance.
In case of Interfaces, consider Y
and Z
as interfaces. So both will contain the declaration of method alphabet()
but not the definition. It won't tell whether to display first alphabet or last alphabet or anything but just will declare a method alphabet()
. So there is no reason to raise the ambiguity. We can define the method with anything we want inside class X
.
So in a word, in Interfaces definition is done after implementation so no confusion.

- 1,883
- 2
- 21
- 20
It is a decision to keep the complexity low. With hybrid inheritance, things would have been more complicated to implement, and anyways what is achievable by multiple inheritances is also with other ways.

- 1
- 2
-
1There are more concrete answers. I'm thinking specifically of C++'s "diamond problem" – ahoffer Jun 20 '21 at 01:50