MultiJava

Abstract

MultiJava is a conservative extension of the Java programming language that adds symmetric multiple dispatch and open classes. Among other benefits, multiple dispatch provides a solution to the binary method problem. Open classes provide a solution to the extensibility problem of object-oriented programming languages, allowing the modular addition of both new types and new operations to an existing type hierarchy. This article illustrates and motivates the design of MultiJava and describes its modular static typechecking and modular compilation strategies. Although MultiJava extends Java, the key ideas of the language design are applicable to other object-oriented languages, such as C# and C++, and even, with some modifications, to functional languages such as ML.This article also discusses the variety of application domains in which MultiJava has been successfully used by others, including pervasive computing, graphical user interfaces, and compilers. C. Clifton et al.MultiJava allows users to express desired programming idioms in a way that is declarative and supports static typechecking, in contrast to the tedious and type-unsafe workarounds required in Java. MultiJava also provides opportunities for new kinds of extensibility that are not easily available in Java.

Polymorphic symmetric multiple dispatch with variance

“…While FGFV does not support features like modularity, nominal exclusion, and closed types in their work, they can be added in an obvious way. As the related work section of Allen et al [2011] discusses in detail, most earlier systems like Dubious [Millstein andChambers 1999, 2002;Millstein 2003], MultiJava [Clifton et al 2006], and F(EML) [Lee and Chambers 2006] supported overloading with symmetric multiple dynamic dispatch with multiple inheritance, but without support for polymorphic methods or types. While ML ≤ [Bourdoncle and Merz 1997] integrates polymorphism and symmetric multiple dynamic dispatch, it lacks multiple inheritance.…”

A Fine-Grained, Customizable Debugger for Aspect-Oriented Programming

“…There is a many-to-many relationship between source language constructs and LIAM entities. For example, in listing 1, the pointcut designator target(b) is transformed to two LIAM entities, because it plays two roles: It specifies a dynamic condition under which the pointcut matches a join point (represented by the AtomicPredicate in lines 4-12, listing 2), as well as a value that is exposed to associated advices (represented by the Context in lines [13][14][15]. The pointcut designator, and thus also the atomic predicate, additionally depends on the declaration of the formal advice parameter Base b: The callee object must be an instance of type Base.…”

“…Shape Shape.intersect(Shape s) when s@Circle AOP languages (AspectJ and JBoss AOP [1]), and two predicate-dispatching languages (MultiJava [13] and JPred [24]). All statements specify the dispatch of a call to method Shape Shape.intersect (Shape) in which the first argument should be an instance of type Circle.…”

First-Class Compositions

“…The Visitor pattern emulates a functional composition style, which makes it easy to extend the operations, but in turn the data types cannot be easily extended. Different language-level solutions to this problem have been proposed that are all founded on combining multiple composition operators [16,26].…”

“…The middle ground that we believe should be pursued, is to have a language of a more declarative nature, which allows for static reasoning about the composition operators. In particular, such a language should allow the identification of the static elements in the operator specifications, so that these can be optimized for performance 16 . language integration: for practical application, an integration of this model with existing programming languages would be the most sensible.…”