eiffel和c++都提供了多继承的机制。但java却没有，因为它认为多继承会导致许多问题的出现。不过java提供了接口(interface)作为一种替换机制，它类似于objective c中的协议(protocol)。sun宣称接口可以提供多继承所能提供的所有特性。
sun所宣称的“多继承会带来许多的问题”这个观点是对的，尤其是在c++中用以实现多继承的方法更能说明这一点。那些看起来似乎使用多继承会比单继承更简单的理由，现在都以被证明是毫无意义。例如，如何制订对于从两个类之上继承得到的具有相同名字的数据项之间的策略？它们之间是否兼容？如果是的话，那他们是否应该被合并成为一个实体？如果不兼容，那应该如何区分它们？……这样的列表可以列出很长很长。
java的接口机制也可以用以实现多继承，但它也有一个很重要的不同之处（与c++相比）：继承中的接口必须是抽象的。由于使用接口并没有任何的实作，这就消除了需要从不同实作之间选择的可能。java允许在接口中声明具有常数字段。当需要多继承时，他们就合并成为一个实体，这样也就不会导致歧义的产生。但是，当这些常数具有不同的值时，又有什么会发生呢？
由于java不支持多继承，我们就不可以像在c++和eiffel中那样使用混合(mixin)了。混合是一种特性，它可以把从不同的类中得到的不同的非抽象的函数放到一起形成一个新的复杂的类。例如，我们可能希望从不同的源代码中导入一些utility函数。然而，我们也可以通过使用组合而不是继承来达到同样的效果，因此，这也就不会对java构成一个重要的攻击了。
eiffel在解决多继承问题时并没有导入一个单独的接口机制。
有些人可能认为，相对于多继承来说，单继承更优雅一些。这是一个很特别的观点。
beta [madsen 93]就属于认为“多继承不优雅”的那一种：“beta中没有多继承，这主要是因为（对于多继承）缺乏一个深刻的理论上的理解，并且当前的（对于多继承的）建议在技术上看来也非常复杂”。他们引用了flavors（一种可以将类混合在一起的语言）为证据。与madsen相比，flavors中的多继承与其顺序有关，也就是说，继承自(a,b)和继承自(b,a)是不一样的。
ada95是另一种不支持多继承的语言。ada95支持单继承，并把它叫做标记类型扩展（tagged type extension）。
另外一些人认为，对于某些特殊模型下的问题，多继承可以提供优雅的解法，因此为之付出的努力也是值得的。虽然上面所列出的关于多继承的问题列表并不完善，它仍然显示：与多继承相关的问题是可以被系统地辨识出来的，而一旦问题被确认，它们也就可以被优雅地解决。当[sakkinen 92]对于多继承研究到达一个很深的程度后，它就得出了上述定义。