I want to ask why java doesn't support multiple inheritance.

[vibha Gupta]

I read if we have two methods with same name in two different super classes and theses 2 classes was inherited by one child class .In this case child class will confuse whom method should call.

[Carey Brown]

The scenario you present is impossible because Java does not support multiple inheritance, and a child class can't have two parent classes.

[Campbell Ritchie]

Welcome to the Ranch

I know lots of people say child class, but that isn't an accurate analogy. Maybe the best terms I have seen are what the C# people say: base class and derived class.
As Carey said, that scenario cannot happen because Gosling etc. decided that multiple inheritance was more trouble than it was worth. It is possible to have two override‑equivalent methods inherited from non‑default interfaces methods, in which case they must have compatible intent (as per documentation comments) and return type. In case you inherit two non‑abstract methods, the rules are in the Java® Language Specification (=JLS). In most cases, the code won't compile. I can't remember the full rules; it is sometimes possible to
get code to compile by overriding the conflicting methods.

[Tim Moores]

You present a good reason for why having multiple inheritance was maybe not such a good idea :-)

[salvin francis]

Here's my two cents :

class SuperVillian {
	public void doSomething() {
		System.out.println("Destroy the world");
	}
}

class SuperHero {
	public void doSomething() {
		System.out.println("Save the world");
	}
}

class Me extends SuperVillian, SuperHero{ //-- Let's assume this works
	...
}

...
	public static void main(String[] args) {
		Me mondayMorningMe = new Me();
		mondayMorningMe.doSomething(); //-- What will I do ? Stay tuned !!!
	}

[salvin francis]

On the other hand, a class can implement multiple interfaces:

interface SuperVillian {
	public void doSomething(); // -- abstract
}

interface SuperHero {
	public void doSomething();// -- abstract
}

class Me implements SuperVillian, SuperHero {
	@Override
	public void doSomething() {
		System.out.println("Breaks the alarm clock");
	}
}
...
	public static void main(String[] args) {
		Me mondayMe = new Me();
		mondayMe.doSomething(); //-- Will break an alarm clock only.
	}

There is a behavior that will surprise you when it comes to default methods for Java8. I'll let you work that out.

[Tim Holloway]

Salvin is on point.

I worked with C++ from very early days. C++ does support multiple inheritance, and I did use it on occasion.

The results were not pleasant.

The Java Interface is overall a much saner way to achieve the effects of multiple  inheritance while avoiding the potential conflicts such as Salvin illustrated.

[Todor Kolev]

Slavin, in your second example, why did you @Override?

[Campbell Ritchie]

People had years of complaining about this sort of thing:-

public String tostring()
{
   return ...;
}

That method won't be called as expected and toString() won't work as desired. When annotations were introduced in 2004, Override was one of the first to be published. It is to prevent the problem I have just shown. Read more about it in the Java™ Tutorials (look for “Predefined Annotation Types”).

[Todor Kolev]

I thought you don't need to @Override a method implementing a body-less interface method?

[Campbell Ritchie]

No, in that instance it isn't essential, but it has been permissible since 2006 (Java6).

[salvin francis]

It's not essential, but it does help. If you wrote another method say:

class Me implements SuperVillian {
	@Override
	public void doSomething() {
	}

	// -- Bunch of other methods...

	@Override
	public void doSomething(String text) {
		// -- Wont compile.
	}

}

The Override ensures that method follows the right method declaration. However, it does sound confusing for interfaces since we're implementing and not actually overriding. Seeing that annotation puts you at ease that it's the right method you're looking at  

[Royale Summers]

Because of the 'inherited" diamond problem -- pun intended.

Please see the following link:

Multiple Inheritance in Java
https://www.journaldev.com/1775/multiple-inheritance-in-java

[Tim Holloway]

At certain times and in certain conditions, compilers and/or IDEs have been known to whine when you override a method in a subclass that had been defined in a base class and not added the @Override annotation to indicate having done so. It's a warning (usually).

Using @Override on an Interface is pretty pointless, however, since an Interface merely defines method signatures and having 2 interfaces define the same signature is precisely how we avoid the woes that you get when you define 2 method implementations in a multiple-inheritance subclass.

But failure to implement a method when actually defining a concrete class is a compile-time fatal error.

[Campbell Ritchie]

It is failure correctly to override concrete methods that causes the trouble; without @Override, it slips past the compiler with no word of warning.

[Kristina Hansen]

vibha Gupta wrote:I read if we have two methods with same name in two different super classes and theses 2 classes was inherited by one child class .In this case child class will confuse whom method should call.

Well, in just four words: because someone decided so
That's my favourite style of beginner questions (for some reasons I won't point out cause mods don't like to read it). Basically: When ever you come up with a Why? question it's most likely been asked and answered multiple times - a search often gets you your answer without asking again. In addition to that always turn it around Why not? Or in your case as you have a Why not? question ask Why (should it)?
A technical side note: Many limitations are only apply to source code - bytecode allows way more complicated stuff. Obfuscators for example can produce bytecode where multiple methods have the same name, same srguments and may even same return type - wich is impossible in source but is in bytecode - as bytecode works like assembly - it's just jumps and calls - method names are just meta data and can be ignored. So this means on bytecodelevel multiple inheritance is possible as the bytecode already knows wich method to call by it's address.

[Paul Clapham]

Kristina Hansen wrote:Well, in just four words: because someone decided so.

That's not wrong in this case. Why doesn't Java support multiple inheritance? Because the designers of the language decided not to do that.

Sure, it wasn't just the result of a coin toss. (Or maybe it was!) There are good reasons for not supporting multiple inheritance and we can speculate why they found those reasons better than the reasons for supporting multiple inheritance. And we could discuss those reasons (both sets) but in the end we won't ever know what the designers were thinking that day.

[Tim Holloway]

Paul Clapham wrote:
Sure, it wasn't just the result of a coin toss. (Or maybe it was!) There are good reasons for not supporting multiple inheritance and we can speculate why they found those reasons better than the reasons for supporting multiple inheritance. And we could discuss those reasons (both sets) but in the end we won't ever know what the designers were thinking that day.

Actually, I believe Gosling himself said why. It was because they, like myself, had seen what a mess it had made of C++.

I've always been partial to the description of Java as "C++ without the mace and knives". I was one of the very earliest adopters of C++ outside of Bell Labs. I ported it to the Commodore Amiga OS and it was sold by the SAS Institute as Lattice/SAS C++ for the Amiga. They were also looking to get it ported to the IBM PC - preferably OS/2, but the AT&T translator was a fairly large program and it processed in a way that was ill-suited to the IBM segmented model - at the time, only the Amiga had a 32-bit flat memory space, MacOS was still operating on 16-bit design, even though it had the same processor (Motorola MC68000) as the Amiga.

I was given the intermediate codes so that I could write a native C++ frontend to feed the Lattice C compiler backend, but I ran into problems with the disambiguating rules for function/operator overloading, as at the time there didn't seem to be an absolute way of picking which of several equally-scored overload candidates should be chosen as the call target. Java's overload rules are much more precise and don't allow ambiguity.

In sum, sometimes we do learn from our mistakes. Gosling, et. al. were well aware of the problems with C++ and took steps to avoid them when they designed Java, even if it meant omitting features and the result really is more civilized.

The one thing that they didn't carry from C++ to Java that I regret was operator overloading. It makes a lot of things tidier, and as far as I can recall, was not a major problem to use or implement. I suppose they were just trying to keep things simple, though.

[Campbell Ritchie]

Tim Holloway wrote:. . . . Java's overload rules are much more precise and don't allow ambiguity.

Lots of Java®'s rules are so much stricter and the loss of ambiguity is a really good thing. Even when you get unexpected results like that in this recent threa‍d.

. . . operator overloading. . . . .

I don't think I am a fan of operator overloading, but I can see how nice it would have been to write,

BigDecimal x = ...;
BigDecimal y = ...;
System.out.println(x * y);

But (a proper red rag to a bull for some people) what about unsigned integers?

I remember reading that Gosling looked at several older languages including Eiffel before designing Java®. Bertrand Meyer used to think multiple inheritance was absolutely essential for OO programming. It caused me no slight amusement to find he had collaborated with somebody to create a language E#, but that only supports single inheritance

[Tim Holloway]

Operator overloading with unsigned integers is no different than a method call in that regard. And, yes, the ability to define your own mathematical notations is really appealing to me.

One of the scarier things was overloading the "[]" (array element access) operator. It can change standard addressing rules, not only on sources, but targets and it's really applied to the "array" class, not the target class, despite C++ not having a formal class for arrays, even as meta-data. Then there's the really frightening one, where you overload "." and "->" with different meanings! One of the things I love most about Java is no "->" operator!

One of the real nuisances about C++ overloading was when automatic up-casts kicked in. Consider:

foo(int x, float y);
foo(float x, int y);

bar = foo(123, 456);

Java will have no truck with that. In C++ you have a scoring system, but both of those would have an equal overload score and - at least back when I was dealing with that - there was no universal tie-breaking system. I just spent a really frustrating day trying to overload a method involving object references in C++ and finally gave it up as too much time for too little benefit - and, as I have mentioned, my C++ experience goes back to 1986. May the Flying Spaghetti Monster help those less experienced!

I think that the existence of the Java Interface indicates that there is a definite case to be made for multiple inheritance. But that "multiple inheritance" needs to support intersecting method sets. Not only because outlawing such things limits future flexibility, but also because sometimes there are primitive methods (toString()) for example, that many classes would want to implement. Just not always in the same way.

[Campbell Ritchie]

I actually meant that maybe Java® should support unsigned integers (as C, C++ and C# do) when I said “unsigned”. I know that mentioning unsigned is very much, “dem's fighting words.”

[Tim Holloway]

Java is not a universal language. For all its warts, for example, it does not have a native number format that's precise to 2, 3, or 4 decimal places like COBOL does, despite the fact that BCD arithmetic has been in the Intel and Motorola instruction sets since their earliest processor models. One of the reasons I wish it actually did have operator overloading - so classes could be defined to rectify that.

Unsigned numbers have 2 purposes. One is the realm of pure mathematics, where they are of interest to problems involving only positive integers. The other purpose is for the benefit of low-level machine programming where what you're dealing with isn't necessarily an integer considered abstractly, but you want to push around bits and bytes. The mathematical case is not one that's a major area in the sort of work Java was designed for. The low-level case flies in the face of Java being a high-level abstract language. Plus, it complicates the overloading and up-casting process. Might as well ask for bitfields while you're at it. Not bit arrays, not arrays of booleans, actual C-style bitfields.

[Campbell Ritchie]

Thank you

Tim Holloway wrote:. . . native number format that's precise to 2, 3, or 4 decimal places like COBOL . . .

That would allow for precise calculations for money. But, as you say, we have to deal with what we have been given.