permaculture playing cards*
The moose likes Beginning Java and the fly likes why java doesnot support Multiple Inheritance in classes? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Beginning Java
Bookmark "why java doesnot support Multiple Inheritance in classes?" Watch "why java doesnot support Multiple Inheritance in classes?" New topic
Author

why java doesnot support Multiple Inheritance in classes?

sriram sundararajan
Ranch Hand

Joined: Apr 08, 2003
Posts: 43
Hi
Java is not supporting Multiple Inheritance in classes. But it is actually supporting in Interface. Why?

class a{
}
class b{

}
class c extends a,b{//gives compilation exception

}

interface a{

}
interface b{

}

interface c extends a,b{//this works fine

}
Jeff Bosch
Ranch Hand

Joined: Jul 30, 2003
Posts: 804
Because that's how they designed it. Interfaces provide the flexibility of multiple inheritance without requiring the subclass to implement every method of its superclasses (assuming multiple inheritance would be an option, which it isn't).


Give a man a fish, he'll eat for one day. Teach a man to fish, he'll drink all your beer.
Cheers, Jeff (SCJP 1.4, SCJD in progress, if you can call that progress...)
Jayesh Lalwani
Ranch Hand

Joined: Nov 05, 2004
Posts: 502
because if you have multiple inheritance in classes, your inherited class will inherit differrent functions with the same name. Look at this




So, what will be printed on the screen
1. fooA
2. fooB

To solve this problem, Java did away with multiple inheritance for classes. Multiple Inheritance is allowed for interfaces because the interface doesnt implement the function. The function is always implemented by the class. So, in the above case, BaseA and BaseB will be interfaces, and MultiInh will implement foo. main knows which function to call because there's only one foo

Jayesh
Layne Lund
Ranch Hand

Joined: Dec 06, 2001
Posts: 3061
I think a major reason is that multiple inheritence is a bitch to implement in a compiler. The compiler writers wanted to avoid this hassle. Resolving function (or method) names, as mentioned above, is probably the least of the problems. There are some other issues involved, but I can't think of them off of the top of my head.

Layne


Java API Documentation
The Java Tutorial
Mike Gershman
Ranch Hand

Joined: Mar 13, 2004
Posts: 1272
Actually, most references I've seen say that the ambiguities inherent in "diamond inheritance" really are the main reason to restrict multiple inheritance. The compiler techniques for handling this are hardly more complex than those involved in resolving invocations of overloaded methods where the arguments would require different casts to match different method signatures.

Think about multiple inheritance involving three or four interlocking levels of parentage. The semantic analyzer in the compiler will work it out by navigating the parse tree and systematically applying precedence rules, but we humans may not be so fortunate.

Keeping program complexity within the ken of the working programmer, not just some genius at Bell Labs, was a principal goal when Gosling designed Java.
[ November 09, 2004: Message edited by: Mike Gershman ]

Mike Gershman
SCJP 1.4, SCWCD in process
David Harkness
Ranch Hand

Joined: Aug 07, 2003
Posts: 1646
Given all that, one feature I'd love to see is "default implementations" in interfaces: code that would merely be copied (by the compiler) into the implementing class if not overridden by the class itself.

True, this would take some solid analysis and defining, but how many times have you copied the same implementation from class to class?

To make it simpler and easily backwards compatible, Java could define a new type in addition to class and interface (implementor?). You'd write the interface and then a new class type that provides a default implementation for that interface. A class could implement the interface directly, providing its own implementation or "implement" the implementor to get a copy of that implementor's member fields and methods.
[ November 09, 2004: Message edited by: David Harkness ]
Mike Gershman
Ranch Hand

Joined: Mar 13, 2004
Posts: 1272
If the "implementor" is the only parent, it's just a superclass. If there is another parent, you have diamond inheritance of any methods contained in both parents.
Jason Fox
Ranch Hand

Joined: Jan 22, 2004
Posts: 114
Couldn't you just write an implementing class, and then point your methods there via a simple object? Something like:

So that A can extend what it wants, and you can reuse the same implementation code over and over again? Just curious.
Mike Gershman
Ranch Hand

Joined: Mar 13, 2004
Posts: 1272
I think David wants the "implementor" methods packaged with the interface so they automatically become members of the implementing class unless they are directly redefined in that class.
Jayesh Lalwani
Ranch Hand

Joined: Nov 05, 2004
Posts: 502
Originally posted by David Harkness:
Given all that, one feature I'd love to see is "default implementations" in interfaces: code that would merely be copied (by the compiler) into the implementing class if not overridden by the class itself.

True, this would take some solid analysis and defining, but how many times have you copied the same implementation from class to class?

To make it simpler and easily backwards compatible, Java could define a new type in addition to class and interface (implementor?). You'd write the interface and then a new class type that provides a default implementation for that interface. A class could implement the interface directly, providing its own implementation or "implement" the implementor to get a copy of that implementor's member fields and methods.

[ November 09, 2004: Message edited by: David Harkness ]



Aha!! but if 2 "implementor" classes had methods with the same name, and your class extends both the implementor classes, whose implementation will be copied over to your class? Implementor classes will cause multiple inheritance ambiguity problems
David Harkness
Ranch Hand

Joined: Aug 07, 2003
Posts: 1646
Originally posted by Jason Fox:
Couldn't you just write an implementing class, and then point your methods there via a simple object?
Yes, you could do that. The whole point, however, is to avoid copying code again and again. I end up doing this a lot as I tend to build framework code and refactor heavily.

Originally posted by Mike Gershman:
I think David wants the "implementor" methods packaged with the interface so they automatically become members of the implementing class unless they are directly redefined in that class.
Originally, yes, but that would mean changing the definition of an interface, possibly causing backward-compatibility problems. I'd settle for a new type of class/interface.

Originally posted by Mike Gershman:
If the "implementor" is the only parent, it's just a superclass. If there is another parent, you have diamond inheritance of any methods contained in both parents.
Yes, that's certainly the issue. Would it be too naive to have the rule "fields and methods get inherited with precedence ordering based on their ordering in the definition"?

I don't think this should happen very often, though. If this comes up, I think it points to a flaw in the design of the classes.

Here's an example from what I'm currently working on: domain objects. I created three basic interfaces:I trust we can all guess at the implementations of these interfaces. Now I have a case where one domain object is not Auditable (it's read-only). However, it has everything I need as a base for another domain object that is Auditable. I'm forced to copy the same code. If I find a bug in the original, I need to remember to copy the fix into all classes into which I copied the original code. This is a recipe for bugs.

Given my design, name clashes can only occur if I goof since they're all disjoint. I would think the JVM experts could come up with some middle ground for those that are experienced enough to handle multiple-inheritence.
sriram sundararajan
Ranch Hand

Joined: Apr 08, 2003
Posts: 43
Thanks for all your answers let me summarize why java doesnot support multiple inheritance in classes. Give me your responses
Since sub class doesnot know which super class to refer as java doesn't support pointer concept. If java is supporting the pointer concept then it will be easy to refer a particular reference from the heap using pointers. Is this answer sounds good? correct me if am wrong.
But here i got one more question why java doesnot support pointer concept?
I want to create a new thread for this topic.
Jayesh Lalwani
Ranch Hand

Joined: Nov 05, 2004
Posts: 502
Originally posted by sriram sundararajan:
Thanks for all your answers let me summarize why java doesnot support multiple inheritance in classes. Give me your responses
Since sub class doesnot know which super class to refer as java doesn't support pointer concept. If java is supporting the pointer concept then it will be easy to refer a particular reference from the heap using pointers. Is this answer sounds good? correct me if am wrong.
But here i got one more question why java doesnot support pointer concept?
I want to create a new thread for this topic.


Java references are pointers!!! The diamond inheritance problem doesnt have anything to do with pointers to objects

Or do you mean function pointers??
 
It is sorta covered in the JavaRanch Style Guide.
 
subject: why java doesnot support Multiple Inheritance in classes?