Inheritance provides object-oriented programming with much of its great reusability power. When inheritance is single, its specifications are simple and everybody roughly agrees on them. In contrast, multiple inheritance yields ambiguities that have prompted long-standing debates, and no two languages agree on its specifications. In this paper, we present a semantics of multiple inheritance based on metamodeling. A metamodel is proposed which distinguishes the “identity” of properties from their “values” or “implementations”. It yields a clear separation between syntactic and semantic conflicts. The former can be solved in any language at the expense of a common syntactic construct, namely full name qualification. However, semantic conflicts require a programmer’s decision, and the programming language must help the programmer to some extent. This paper surveys the approach based on linearizations, which has been studied in depth, and proposes some extensions. As it turns out that only static typing takes full advantage of the metamodel, the interaction between multiple inheritance and static typing is also considered, especially in the context of virtual types. The solutions proposed by the various languages with multiple inheritance are compared with the metamodel results. Throughout the paper, difficulties encountered under the open-world assumption are stressed.

Achieving submillisecond response times in a managed language environment such as Java or C# requires overcoming significant challenges. In this article, we propose Reflexes, a programming model and runtime system infrastructure that lets developers seamlessly mix highly responsive tasks and timing-oblivious Java applications. Thus enabling gradual addition of real-time features, to a non-real-time application without having to resort to recoding the real-time parts in a different language such as C or Ada. Experiments with the Reflex prototype implementation show that it is possible to run a real-time task with a period of 45 ?s with an accuracy of 99.996 % (only 0.001% worse than the corresponding C implementation) in the presence of garbage collection and heavy load ordinary Java threads