The short answer is: because the language designers decided not to.

Basically, it seemed that both the .NET and Java designers did not allow multiple inheritance because they reasoned that adding MI added too much complexity to the languages while providing too little benefit. For a more fun and in-depth read, there are some articles available on the web with interviews of some of the language designers. For example, for .NET, Chris Brumme (who worked at MS on the CLR) has explained the reasons why they decided not to: 1. Different languages actually have different expectations for how MI works. For example, how conflicts are resolved and whether duplicate bases are merged or redundant. Before we can implement MI in the CLR, we have to do a survey of all the languages, figure out the common concepts, and decide how to express them in a language-neutral manner. We would also have to decide whether MI belongs in the CLS and what this would mean for languages that don't want this concept (presumably VB.NET, for example). Of course, that's the business we are in as a common language runtime, but we haven't got around to doing it for MI yet. 2. The number of places where MI is truly appropriate is actually quite small. In many cases, multiple interface inheritance can get the job done instead. In other cases, you may be able to use encapsulation and delegation. If we were to add a slightly different construct, like mixins, would that actually be more powerful? 3. Multiple implementation inheritance injects a lot of complexity into the implementation. This complexity impacts casting, layout, dispatch, field access, serialization, identity comparisons, verifiability, reflection, generics, and probably lots of other places. You can read the full article here. For Java, you can read this article: The reasons for omitting multiple inheritance from the Java language mostly stem from the "simple, object oriented, and familiar" goal. As a simple language, Java's creators wanted a language that most developers could grasp without extensive training. To

that end, they worked to make the language as similar to C++ as possible (familiar) without carrying over C++'s unnecessary complexity (simple). In the designers' opinion, multiple inheritance causes more problems and confusion than it solves. So they cut multiple inheritance from the language (just as they cut operator overloading). The designers' extensive C++ experience taught them that multiple inheritance just wasn't worth the headache.
share|improve this answer edited Jun 15 '09 at 10:48 answered Jun 15 '09 at 9:53

Razzie 13.5k63644

Nice comparison. Quite indicative of the thought-processes that under '09 at 10:47

5
add comment up vote

41down vote

Multiple inheritance of implementation is what is not allowed. The problem is that the compiler/runtime cannot figure out what to do if you have a Cowboy and an Artist class, both with implementations for the draw() method, and then you try to create a new CowboyArtist type. What happens when you call the draw() method? Is someone lying dead in the street, or do you have a lovely watercolor? I believe it's called the double diamond inheritance problem.
share|improve this answer

double diamond is the beer! ;) Mitch Wheat Jun 15 '09 at 9:54

39 You get a lovely watercolor of someone dead on the street :-) Dan F
Is this the only problem? I think, I'm not sure, that the C++ solves this I'm not good at C++ asattar Jun 15 '09 at 10:00

LOL @ "Is someone lying dead in the street, or do you have a lovely w

10:01

2
up

In C++ you can either specify which of the base class functions to call Dmitry Risenberg Jun 15 '09 at 10:09

show 6 more comments

Because Java has a greatly different design philosophy from C++. (I'm not going to discuss C# vote do here.)

wn vote

In designing C++, Stroustrup wanted to include useful features, regardless of how they could be misused. It's possible to screw up big-time with multiple inheritance, operator overloading, templates, and various other features, but it's also possible to do some very good things with them. The Java design philosophy is to emphasize safety in language constructs. The result is that there are things that are a lot more awkward to do, but you can be a lot more confident that the code you're looking at means what you think it does. Further, Java was to a large extent a reaction from C++ and Smalltalk, the best known OO languages. There are plenty of other OO languages (Common Lisp was actually the first one to be standardized), with different OO systems that handle MI better. Not to mention that it's entirely possible to do MI in Java, using interfaces, composition, and delegation. It's more explicit than in C++, and therefore is clumsier to use but will get you something you're more likely to understand at first glance. There is no right answer here. There are different answers, and which one is better for a given situation depends on applications and individual preference.
share|improve this answer

answered Jun 15 '09 at 18:01

David Thornley 37.6k652115 add comment

The main (although by no means the only) reason people steer away from MI is the so called vote do "diamond problem" leading to ambiguity in your imlpementation. This wikipedia wn vote article discusses it and explains better than I could. MI can also lead to more complex code, and a lot of OO designers claim that you do't need MI, and if you do use it your model is probably wrong. I'm not sure I agree with this last point, but keeping things simple is always a good plan.

up

share|improve this answer

answered Jun 15 '09 at 9:52

Steve Haigh 6,1211324 add comment

In C++ multiple inheritance was a major headache when used improperly. To avoid those popular vote do design issues multiple interfaces "inheritance" was forced instead in modern languages (java, wn vote C#).

up

share|improve this answer

answered Jun 15 '09 at 9:56

inazaruk 33.2k693100 add comment

Another reason is that single-inheritance makes casting trivial, emitting no assembler instructions vote do (other than checking for the compatibility of the types where required). If you had multiplewn vote inheritance, you'd need to figure out where in the child class a certain parent starts. So performance is certainly a perk (although not the only one).

up

share|improve this answer

answered Jun 15 '09 at 10:02

Blindy 25.1k32863 add comment up

Multiple Inheritance is hard to understand hard to debug (for example, if you mix classes from multiple frameworks that have identically-named methods deep down, quite unexpected synergies can occur) easy to mis-use not really that useful hard to implement, especially if you want it done correctly and efficiently Therefore, it can be considered a wise choice to not include Multiple Inheritance into the Java language.
share|improve this answer

vote do wn vote

answered Jun 15 '09 at 11:14

mfx 4,2811019 I disagree with all the above, having worked with the Common Lisp Object System. David Thornley Jun 15 '09 at

1 17:51

Dynamic languages don't count ;-) In any Lisp-like system, you have a REPL that makes debugging rather easy. Also CLOS (as i understand it, i have never really used it, only read about it) is a meta-object-system, with a lot of flexibility and a roll-your-own attitude. But consider a statically compiled language like C++, where the compiler generates some fiendishly complex method lookup using multiple (possibly overlapping) vtables: in such an implementation, finding out what implementation of a method was invoked might be a not-so-trivial task. mfx Jun 1 16 '09 at 7:28 add comment up

I take the statement that "Multiple inheritance is not allowed in Java" with a pinch of salt.

vote do wn vote Multiple Inheritance is defined when a "Type" inherits from more than one "Types". And

interfaces are also classified as types as they have behavior. So Java does have multiple inheritance. Just that it is safer.

share|improve this answer

edited Jun 15 '09 at 17:27

answered Jun 15 '09 at 10:56

Rig Veda 216129

3 But you don't inherit from an interface, you implement it. Interfaces aren't classes. Blorgbeard Jun 15 '09 at 11:14

Yes, but inheritance was never so narrowly defined, except in some prelim books. And I think we should look beyond the grammar of it. They both do the same thing,and interfaces were "invented" only for that reason. Rig Veda Jun 2 15 '09 at 17:22 Upvoting to remove the -1. You've got a good point. David Thornley Jun 15 '09 at 18:02 add comment

Java has concept, i.e. polymorphism. There are 2 types of polymorphism in java. There are vote do method overloading and method overriding. Among them, method overriding happens with wn vote super- and subclass relationship. If we are creating an object of a subclass and invoking the method of superclass, and if subclass extends more than one class, which super class method should be called?

up

Or , while calling superclass constructor by super(), which super class constructor will get called? This decisions are impossible by current java API features. so multiple inheritance is not allowed in java.
share|improve this answer edited Oct 30 '12 at 18:04

answered Oct 30 '12 at 17:38

jrouquie 2,6603824

Abhay Kokate 291

Fundamentally, Java's type system assumes that every object instance has one type, casting an object to a supertype wil always work and be reference-preserving, and casting a reference to a subtype will be reference-preserving if the instance is of that subtype or a subtype thereof. Such assumptions are useful, and I don't think it's possible to allow generalized multiple inheritance in a way consistent with them. supercat Oct 31 '12 at 17:50 add comment

Back in the old days ('70s) when Computer Science was more Science and less mass production vote do the programmers had time to think about good design and good implementation and as a result wn vote the products (programms) had high quality ( eg. TCP/IP design and implementation ). Nowadays, when everybody is programming, and the managers are changing the specs before deadlines, subtle issues like the one descriped in the wikipedia link from Steve Haigh post are difficult to track; therefore, the "multiple inheritance" is limited by compiler design. If you like it, you can still use C++ .... and have all the freedom you want :)

up

share|improve this answer

answered Jun 15 '09 at 10:31 Cata Lin

2 ... including the freedom to shoot yourself in the foot, multiple times ;) Mario Ortegn Jun 15 '09 at 10:46
add comment up

Dynamic loading of classes makes the implementation of multiple inheritance difficult.

vote do inheritance and interface. Complexity of multiple inheritance is very high in a situation like wn vote

In java actually they avoided the complexity of multiple inheritance instead by using single below explained

diamond problem of multiple inheritance. We have two classes B and C inheriting from A. Assume that B and C are overriding an inherited method and they provide their own implementation. Now D inherits from both B and C doing multiple inheritance. D should inherit that overridden method, jvm can't able to decide which overridden method will be used? In c++ virtual functions are used to handle and we have to do explicitly. This can be avoided by using interfaces, there are no method bodies. Interfaces cannot be instantiatedthey can only be implemented by classes or extended by other interfaces.
share|improve this answer

answered Jan 12 '13 at 11:44

sujith s 111 add comment

Reason: Java is very popular and easy to code, because of its simplicity. vote do So what ever java developers feel difficult and complicated to understand for wn vote programmers, they tried to avoid it. One such kind of property is multiple inheritance.

up

1. They avoided pointers 2. They avoided multiple inheritance. Problem with multiple inheritance: Diamond problem. Example: 1. Assume that class A is having a method fun(). class B and class C derives from class A. 2. And both the classes B and C, overrides method fun(). 3. Now assume that class D inherits both class B, and C. (just Assumption) 4. Create object for class D. 5. D d = new D(); 6. and try to access d.fun(); => will it call class B's fun() or class C's fun()? This is the ambiguity existing in diamond problem. It is not impossible to solve this problem, but it creates more confusion and complexities to the programmer while reading it. It causes more problem than it tries to solve. Note: But any way you can always implement multiple inheritance indirectly by using interfaces.

Ippili, Padmapriya (Cognizant) ; Gorantla, Anantha Rama Krishna (Cognizant) ; Varre, Raja Sekhar (Cognizant) ;Vadlamudi, Rakesh Sharma (Cognizant) ; Anumala, Nandakishore(Cognizant) ; Malapaka, Sampath (Cognizant) ;Channamadhavuni, Naveen Kumar (Cognizant) ; Bolloju, Niranjan(Cognizant) ;Korrapati, Siddhendra (Cognizant) ; Dhulipudi, Ashok (Cognizant) ;Pinnamaneni, Seetarama Nagendra Babu (Cognizant) ; Bhooman, Sowjanya (Cognizant) ;K.V.L, Siva Kumar (Cognizant) ; D, Jaya Krishna (Cognizant) ; Thukkisetty, KiranMayi (Cognizant) ;Sarvey, DineshKumar (Cognizant) ; Alwarusetty, Ushakiran(Cognizant) ; Tokala, Tulasi (Cognizant) ;Pagadala, Madhavi (Cognizant) ; Jayaraman, Lavanya(Cognizant) ; Chichadi, Dilip (Cognizant) ;Vora, Julie (Cognizant) ; Kodidela, Subhan (Cognizant) ; Tulabandula, Prathap (Cognizant) ;Kakumanu, Kalpana (Cognizant) ; Banothu, Jhansi (Cognizant) ; Kokala, Sridhar (Cognizant) ;Reddy, Bomma (Cognizant) ; Murthy Bolisetty, Satyanarayana (Cognizant) ; Yalla, Sanjeevamma (Cognizant) ;Adavelli, Archana (Cognizant) ; Kasamasetty, Srinivas (Cognizant) ; Pedavalli, Sunil Kumar (Cognizant) ;Kothapalli, Vijay Kumar (Cognizant) ; M, Umamaheswari (Cognizant) ; BuKKa, Sandhya (Cognizant) ;Chirlla, Shirisha (Cognizant) ; Jainapally, Deepika (Cognizant) ; Sarda, Niketa (Cognizant) ;Subramani, Sasikala (Cognizant) ; Mathew, Jocy (Cognizant) ; Sadhu, Venugopal (Cognizant) ;Y, Sreenivasulu (Cognizant) ; Roy, Sujan (Cognizant) ; PURUSHAVAKAM, RAJESWARI (Cognizant) ;Ayyadevara, Prakash (Cognizant) ; Thatikonda, Venu Babu (Cognizant) ; Mandadapu, Suresh (Cognizant) ;Melukota, Sridevi (Cognizant) ; Boreda, Raghavender (Cognizant) ; Vemuri, Srivally (Cognizant) ;Kodamasimham, Ramu (Cognizant) ; Bhanu, Chitra (Cognizant) ; Basetti, Kiran Kumar (Cognizant) ;Tammineedi, Aparna (Cognizant) ; Nallani, Chaya Annapurna (Cognizant) ; Tirumareddy, Sudhir (Cognizant) ;Balasubramanyam, Anushka (Cognizant) ; M, Vijay (Cognizant) ; Karnati, Harshavardhan Reddy (Cognizant) ;Madiraju, Madhuri (Cognizant) ; Bhattiprolu, Raajitha (Cognizant) ; Lam, Samyuktha (Cognizant) ;Bonthu, Rajesh (Cognizant) ; Vijjeswarapu, Praveen (Cognizant) ; Shaik, Ruksana (Cognizant) ;Shaik, Asha (Cognizant) ; G, Pavani (Cognizant) ; Shaik, Babina (Cognizant) ; Devisetty, Sridhar (Cognizant) ;Lakshmi Narayana, Battigiri(Cognizant) ; Shivannagari, Mahender (Cognizant) ;Kotagiri, Aruna Kumari (Cognizant) ; Lachyan, Reshma (Cognizant) ; Tadikonda, Vishnu Tejaswi (Cognizant) ;Gangisetty, Sravan (Cognizant) ; Sivalanka, Usha Kiran (Cognizant) ; Saranya B, Shanti (Cognizant) ;Gudapati, Sandhya (Cognizant) ; Vegunta, Ravi Kumar (Cognizant) ; Gundapuneni, Dheeraj (Cognizant) ;Ayyadevara, Lakshmi Sowjanya (Cognizant) ; Telagamchetty, Sailesh (Cognizant) ; Das, Sreelabdha (Cognizant) ;Mahanthi, Manasa (Cognizant) ; Kondam, Deepa (Cognizant) ; Kallu, Manisha (Cognizant) ;Garlapati, Suchita (Cognizant) ; Amrutham, ChandraSheker (Cognizant) ; Pasupuleti, Naga Ramya (Cognizant) ;Vemula, Venugopal (Cognizant) ; Panjala, Deepthi (Cognizant) ; Potharaboina, Sri Lakshmi (Cognizant) ;K, Dileep (Cognizant) ; K, Abhishek Reddy (Cognizant) ; Daripally, Anusha (Cognizant) ;S, Deepthy Kaivalya (Cognizant) ; Gangadhara Batla, Swetha (Cognizant) ; Kalimela, Niharika (Cognizant) ;Ramavath, Mahesh (Cognizant) ; Sheik, Asmath (Cognizant) ; Chilka, Mahesh ; K, Srikanth (Cognizant) ;Yaswanth, Makham (Cognizant) ; D, Anil Varma (Cognizant) ; Gillela, Damodhar Reddy (Cognizant) ;Halder, Susamay (Cognizant) ; Kunda, Murali Krishna (Cognizant) ; Dasari, Balakrishna (Cognizant) ;N, Ravindranath (Cognizant) ; Niharika, Komma (Cognizant) ; Goel, Rajesh (Cognizant) ;Bhanushali, Leena (Cognizant) ; J, Geethanjali (Cognizant) ; Garnepudi, Keerthi (Cognizant) ;Samula, Swathi Reddy (Cognizant) ; Gadapaka, Vishal Kumar (Cognizant) ; Cyclewala, Batul (Cognizant) ;Beemarthi, Mohan Shiva Krishan (Cognizant) ; K K, Priyadarsini (Cognizant) ; M V, Pavan Kumar (Cognizant) ;Varada, Venkata Raghu Pavan (Cognizant) ; MBV, Subba (Cognizant) ; Panda, Sagarika (Cognizant) ;Sripada, Rajitha (Cognizant) ; Gollamudi, Narasimharao (Cognizant) ; adavala, santhoshi (Cognizant) ;M, Sai Sharan (Cognizant) ; neeli, karthik (Cognizant) ; JITHENDER REDDY, CHALLA (Cognizant) ;POCHARAM, NITHIN (Cognizant) ; NIKHILESH, B R (Cognizant) ; Telugu, Monika (Cognizant) ;DAKA, RAJAVARDHAN (Cognizant) ; Bandi, Thirumalesh (Cognizant) ; Kethireddy, Manjeera (Cognizant) ;Nune, Venkata Suhasini (Cognizant) ; Lanka, Rajasekhar (Cognizant) ; Aluru, Hareesha (Cognizant) ;Sanapala, Kishankumar (Cognizant) ; Bengeri, Krishna Teja (Cognizant) ;STAFF MGMT SRV TST HYD(Cognizant)