2.1.0.3 Java.

The Java designers have chosen to eliminate multiple inheritance of classes. Instead, the programmer is now expected to realize multiple inheritance by ``simulating'' it in the language. This decision is motivated by the problems sketched above and the additional desire for binary compatibility: Recall that in Java, the computation of numeric offsets for instance fields in memory is done by the run-time system. This permits updating a class with new instance variables or methods without affecting existing code. In other words, it is possible to run an existing bytecode file for a subclass after updating and recompiling the class, but without recompiling the subclass. This property would be lost if multiple inheritance were supported because multiple inheritance conflicts could suddenly arise during class loading.

Note also that, on older processors, single inheritance of classes had performance advantages over multiple inheritance because the former simplified the layout of instance fields and enabled generation of efficient code for dynamic dispatching of methods [1]. However, modern pipelined processors execute the additional offset adjustment instruction during the delay time required for branching to the method's code [7]. So, surprisingly, multiple inheritance overheads are negligible even in the presence of polymorphic variables.

We now explore the extent to which the reusability benefits of generics/templates and multiple inheritance can be reinstated in Java through specific patterns and idioms.