Win a copy of Machine Learning for Business: Using Amazon SageMaker and JupyterE this week in the Jython/Python forum
or Object Design Style Guide in the Object-Oriented programming forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Bear Bibeault
  • Paul Clapham
  • Jeanne Boyarsky
  • Knute Snortum
Sheriffs:
  • Liutauras Vilda
  • Tim Cooke
  • Junilu Lacar
Saloon Keepers:
  • Ron McLeod
  • Stephan van Hulst
  • Tim Moores
  • Tim Holloway
  • Carey Brown
Bartenders:
  • Joe Ess
  • salvin francis
  • fred rosenberger

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

 
Greenhorn
Posts: 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Saloon Keeper
Posts: 6772
64
Eclipse IDE Firefox Browser MySQL Database VI Editor Java Windows
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The scenario you present is impossible because Java does not support multiple inheritance, and a child class can't have two parent classes.
 
Marshal
Posts: 67464
257
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Saloon Keeper
Posts: 6066
154
Android Mac OS X Firefox Browser VI Editor Tomcat Server Safari
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You present a good reason for why having multiple inheritance was maybe not such a good idea :-)
 
Bartender
Posts: 2472
108
Google Web Toolkit Eclipse IDE Java
  • Likes 3
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Here's my two cents :
 
salvin francis
Bartender
Posts: 2472
108
Google Web Toolkit Eclipse IDE Java
  • Likes 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
On the other hand, a class can implement multiple interfaces:
There is a behavior that will surprise you when it comes to default methods for Java8. I'll let you work that out.
 
Saloon Keeper
Posts: 21603
147
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Ranch Hand
Posts: 69
1
Python Java Linux Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Slavin, in your second example, why did you @Override?
 
Campbell Ritchie
Marshal
Posts: 67464
257
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
People had years of complaining about this sort of thing:-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
Ranch Hand
Posts: 69
1
Python Java Linux Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I thought you don't need to @Override a method implementing a body-less interface method?
 
Campbell Ritchie
Marshal
Posts: 67464
257
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
No, in that instance it isn't essential, but it has been permissible since 2006 (Java6).
 
salvin francis
Bartender
Posts: 2472
108
Google Web Toolkit Eclipse IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
It's not essential, but it does help. If you wrote another method say:
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  
 
Ranch Hand
Posts: 89
1
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Saloon Keeper
Posts: 21603
147
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Marshal
Posts: 67464
257
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
It is failure correctly to override concrete methods that causes the trouble; without @Override, it slips past the compiler with no word of warning.
 
Ranch Hand
Posts: 118
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

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.
 
Marshal
Posts: 24950
61
Eclipse IDE Firefox Browser MySQL Database
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

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
Saloon Keeper
Posts: 21603
147
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

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
Marshal
Posts: 67464
257
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

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,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
Saloon Keeper
Posts: 21603
147
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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:


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
Marshal
Posts: 67464
257
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Saloon Keeper
Posts: 21603
147
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Marshal
Posts: 67464
257
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
The airline is called "Virgin"? Don't you want a plane to go all the way? This tiny ad will go all the way:
Sauce Labs - World's Largest Continuous Testing Cloud for Websites and Mobile Apps
https://coderanch.com/t/722574/Sauce-Labs-World-Largest-Continuous
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!