Language Design

Wednesday, 29 October – 15:30-17:00

HydroJ: Object-Oriented Pattern Matching for Evolvable Distributed Systems

Keunwoo Lee, University of Washington, klee@cs.washington.edu
Anthony LaMarca, Intel Research Seattle, lamarca@intel-research.net
Craig Chambers, University of Washington, chambers@cs.washington.edu

In an evolving software system, components must be able to change independently while remaining compatible with their peers. One obstacle to independent evolution is the brittle parameter problem}: the ability of two components to communicate can depend on a number of inessential details of the types, structure, and/or contents of the values communicated. If these details change, then the components can no longer communicate, even if the essential parts of the message remain unaffected.

We present HydroJ, an extension of Java that addresses this problem. In HydroJ, components communicate using self-describing, semi-structured messages, and programmers use pattern matching to define the handling of messages. This design stems from two central ideas: first, that self-describing messages reduce dependence on inessential message format details; and second, that object-oriented pattern matching naturally focuses on the essential information in a message and is insensitive to inessential information.

We have developed these ideas in the context of Rain, a distributed, heterogeneous messaging system for ubiquitous computing. To evaluate the design, we have constructed a prototype HydroJ compiler, implemented some Rain services in HydroJ, and formalized HydroJ's key features in a core language.

Relaxed MultiJava: Balancing Extensibility and Modular Typechecking

Todd Millstein, University of Washington, todd@cs.washington.edu
Mark Reay, University of Washington, mreay@cs.washington.edu
Craig Chambers, University of Washington, chambers@cs.washington.edu

We present the rationale, design, and implementation of Relaxed MultiJava (RMJ), a backward-compatible extension of Java that allows programmers to add new methods to existing classes and to write multimethods. Previous languages supporting these forms of extensibility either restrict their usage to a limited set of programming idioms that can be modularly typechecked (and modularly compiled) or simply forego modular typechecking altogether. In contrast, RMJ supports the new language features in a virtually unrestricted form while still providing modular static typechecking and compilation. In some cases, the RMJ compiler will warn that the potential for a type error exists, but it will still complete compilation. In that case, a custom class loader transparently performs load-time checking to verify that the potential error is never realized. RMJ's compiler and custom loader cooperate to keep load-time checking costs low. We report on our qualitative and quantitative experience with our implementation of RMJ.

ModJava: A Rational Module System for Java and Its Applications

John Corwin, IBM, jcorwin@us.ibm.com
David Bacon, IBM, bacon@us.ibm.com
David Grove, IBM, groved@us.ibm.com
Chet Murthy, IBM, chet@watson.ibm.com

While Java provides many software engineering benefits, it lacks a coherent module system and instead provides only packages (which are primarily a name space mechanism) and classloaders (which are very low-level). As a result, large Java applications suffer from unexpected interactions between independent components, require complex CLASSPATH definitions, and are often extremely complex to install and maintain.

We have implemented a module system for Java that is implemented with class loaders but provides a much higher-level interface. High-level properties can be specified in a module definition and are enforced by the module system as new modules are loaded.

To experimentally validate the ability of ModJava to properly handle the complex module inter-relationships found in large Java server systems, we replaced the classloader mechanisms of Apache Tomcat 4.1.18 with 30 ModJava modules. The modified Tomcat is functionally identical to the original, but requires no CLASSPATH definitions, and will operate correctly even if user code loads a different version of a module used by Tomcat, such as the Xerces XML parser. Furthermore, by making a small change to the Java core libraries enabled by ModJava, we obtained a 30% performance improvement in a servlet microbenchmark.