why java doesnot support Multiple Inheritance in classes?

[sriram sundararajan]

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]

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).

[Jayesh Lalwani]

because if you have multiple inheritance in classes, your inherited class will inherit differrent functions with the same name. Look at this

  
class BaseA
{
   public int foo()
   {
      System.out.println("fooA");
   }
}
class BaseB
{
   public int foo()
   {
      System.out.println("fooB");
   }
}
class MultiInh extends BaseA, BaseB
{
}
 
public void main()
{
    MultiInh mi = new MultiInh();
    mi.foo();
}

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]

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

[Mike Gershman]

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 ]

[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 ]

[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.

[Jason Fox]

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

 
interface B {
   void printName();
}
 
class Implementor {
   void printName() {
      System.out.println("Jason\n");
   }
}
class A implements B {
   Implementor i = new Implementor();
 
   void printName() {
      i.printName();
   }
}
 

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

[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.

[Jayesh Lalwani]

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]

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:

public interface Identifiable {
    public void setId(Integer id);
    public Integer getId();
    public String getIdAsString();
}
 
public interface Auditable {
    public void setModifiedDate(Date date);
    public Date getModifiedDate();
    public void setCreatedDate(Date date);
    public Date getCreatedDate();
    public void setVersionNumber(int versionNumber);
    public int getVersionNumber();
}
 
public interface Validatable {
    public void validate();
}

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]

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]

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??