Java sacrifice Multiple Implementation Inheritance for its Dynamic Object Model & efficient Garbage collector, although it can achieve it via Interface.
can any one please give me a little explanation for this, i got the idea for Dynamic Object Model but unclear about how it could effect Garbage Collector if Multiple Implementation Inheritance was there.
I was under the impression that the designers of Java rejected multiple inheritance of implementation because it was too much trouble and of too little benefit.
I don't know what this "dynamic object model" is which you mention... could you describe what you mean by that? As for garbage collection, I doubt that it would be affected at all by multiple inheritance, but perhaps you know something which proves me wrong? Or perhaps you read a link with something about that? (It's hard to provide an explanation for false statements, if you know what I mean. At least a good explanation; people are very good at confabulating explanations for falsehoods.)
Himanshu V Singh
Joined: May 06, 2011
Yes, Multiple Inheritance was way too much for Java, but the biggest advantage of Multiple Inheritance i.e Loose Coupling cant be avoided in OOP..
My Java professor told us about the story behind why Java could not afford Multiple Implementation Inheritance though the they bring the Interface in picture.
C++ has static object model - all classes are combined and copied in single source code at compile time
Java has Dynamic Object Model - only the required class is loaded by JVM's system class loader at runtime by decided by Hot Spot Engine in java
1. Dynamic Object Model Vs Multiple Inheritance
Two multiple base classes having same method when called on derived class's object may lead to ambiguity in Java since Java loads classes at runtime(Dynamic Object Model), while C++ do that with its static object model i.e all classes loads and copied at compile time and the static or dynamic casting can provide the way to choose the appropriate method from required class.
So to avoid that Java preferred Dynamic Object Model ahead of Multiple Inheritance
As far about Garbage collection and Multiple Inheritance, i think i have to re-ask my professor as iam confused.
Ok, so with "dynamic object model" you mean that Java loads classes at runtime, using a classloader.
Multiple inheritance leads to problems like the diamond problem. In C++ this was solved by introducing a new feature to the language, virtual inheritance. In Java, it was solved by simply disallowing multiple inheritance. One of the goals of the designers of the Java programming language was to make it easier than C++. In practice, you rarely really need multiple inheritance while it can lead to complicated situations, so they decided to leave it out of Java.
I don't agree with your professor that Java has no multiple inheritance solely because it would be impossible because of Java's dynamic class loading. I think it would be possible in principle to have multiple inheritance and dynamic class loading, but he's right in that it would make the system a lot more complicated than it is now.
One purpose for which multiple inheritance is useful is for mixins. A mixin is a little bit like an abstract class that you can add to an existing class via inheritance, to add the functionality of the mixin to the existing class. You need some form of multiple inheritance to be able to add multiple mixins to a class. Because Java lacks this, there's no good way to work with mixins in Java.
Hello Jesper, thanks for throwing some light. Actually i meant that Multiple Implementation Inheritance (proper word) is not there in Java, but multiple inheritance is possible in Java via Interface. And one of most important practice utility of Multiple inheritance is loose coupling that is very important in industrial Java's application so that your existing framework of classes (previous logic) don't have to be changed. Java designer cant deny with the importance of Loose Coupling in OOP.
The upcoming version of C++0x allows Garbage collection in C++ plus Multiple Inheritance. But they decided to choose from one, either Garbage collection or multiple inheritance. If you declared a class with "gc" keyword than that class's objects are eligible for Garbage Collection but will loose the functionality of Multiple Inheritance and if you don't declare it with "gc" than old C++ model that have Multiple Inheritance without Garbage Collection will be applicable.
That prove the fact the two biggest problems due to which Java couldn't implement the Multiple Implementation inheritance was Java's Dynamic Model and Garbage Collection.
I'm not convinced that you can necessarily deduce anything about the motivations for Java's design from decisions made about designing a C++ compiler.
I agree with Jesper. I believe the main reason Java's designers didn't use it is because life is simpler without it. And while I agree that loose coupling is an important design principle in OO systems, Java's interface approach provides that just as well (if not better).
Matthew Brown wrote:I'm not convinced that you can necessarily deduce anything about the motivations for Java's design...
I don't even believe you can necessarily deduce anything about the motivations for Java's design beyond what the designers actually said at the time. It's easy to make up stuff like "Java didn't include multiple inheritance of implementation because that would have made garbage collection more difficult" but if the designers didn't say that, then that's just speculation.
It's certainly possible to look at the effects of various design decisions and comment on their pros and cons, but going back and translating "This was a good decision because of (positive result X)" into "The designers made this decision because of (positive result X)" just isn't justified.
I don't agree with the basic premise that multiple inheritance is useful at all. There are tons of problems in using it with C++, and I'm not convinced that the few good use cases for it justify the problems.
But it really doesn't matter. Java is what it has been for the past decade. Its not going to change significantly. If there is to be a new cool language with different features, it will *not* be Java