Object-oriented programming languages allow inter-object aliasing. Although necessary to construct linked data structures and networks of interacting objects, aliasing is problematic in that an aggregate object's state can change via an alias to one of its components, without the aggregate being aware of any aliasing. Ownership types form a static type system that indicates object ownership. This provides a flexible mechanism to limit the visibility of object references and restrict access paths to objects, thus controlling a system's dynamic topology. The type system is shown to be sound, and the specific aliasing properties that a system's object graph satisfies are formulated and proven invariant for well-typed programs. Keywords Alias protection, sharing, containment, ownership, representation exposure, programming language design 1

Aliasing is endemic in object oriented programming. Because an object can be modified via any alias, object oriented programs are hard to understand, maintain, and analyse. Flexible alias protection is a conceptual model of inter-object relationships which limits the visibility of changes via aliases, allowing objects to be aliased but mitigating the undesirable effects of aliasing. Flexible alias protection can be checked statically using programmer supplied aliasing modes and imposes no runtime overhead. Using flexible alias protection, programs can incorporate mutable objects, immutable values, and updatable collections of shared objects, in a natural object oriented programming style, while avoiding the problems caused by aliasing.

Containment of objects is a natural concept that has been poorly supported in object-oriented programming languages. For a predefined set of ownership contexts, this paper presents a type system that enforces certain containment relationships for run-time objects. A fixed ordering relationship is presumed between the owners. The formalisation of ownership types has developed from our work with flexible alias protection together with an investigation of structural properties of object graphs based on dominator trees. Our general ownership type system permits fresh ownership contexts to be created at run-time. Here we present a simplified system in which the ownership contexts are predefined. This is powerful enough to express and enforce constraints about a system's high-level structure. Our formal system is presented in an imperative variant of the object calculus. We present type preservation and soundness results. Furthermore we highlight how these type theoretic results establish a containment invariant for objects, in which access to contained objects is only permitted via their owners. In effect, the predefined ownership ordering restricts the permissible inter-object reference structure.

A central methodological problem in programming with multiple levels of abstractions is the loosely defined problem of rep exposure. This paper traces the problem of rep exposure to the precisely defined notion of abstract aliasing. The paper also outlines a statically-enforceable discipline for avoiding abstract aliasing, but the outline is incomplete.

Existing approaches to adding unique references to object-oriented programming languages suffer from two problems, which we identify in this paper: the abstraction problem and the orthogonality problem. To counter these problems, we propose an alternative: external uniqueness. The idea is that an externally unique reference is the only reference into an aggregate object from outside the aggregate. An externally unique reference is the only active reference to an object, and is thus effectively unique. We present a formal account of external uniqueness which relies essentially on deep ownership types, and, by demonstrating that it does not suffer from the two problems, argue that it is better suited to object-oriented programming than conventional uniqueness. We also discuss a third problem, the definitional problem, which we cannot yet address satisfactorily.

kind, express or implied, including, but not limited to, the implied warranties of merchantability, fitness for a particular purpose, or non-infringement. This publication could include technical inaccuracies or typographical errors. Furthermore, the Compaq Extended Static Checker for Java (ESC/Java) is currently under development. Compaq therefore expects that changes will occur in the ESC/Java software and documentation, from time to time. Compaq reserves the right to adopt such changes, or to cause or recommend that ESC/Java users adopt such changes, upon such notice as is practicable under the circumstances or without any notice, in its discretion. The Compaq Extended Static Checker for Java (ESC/Java) is not a product of Sun Microsystems, Inc. Compaq is a registered trademark of Compaq Computer Corporation. Java is a trademark or registered trademark of Sun Microsystems, Inc. UNIX is a registered trademark in the United States and other countries, exclusively licensed through X/Open Company, Ltd. Windows is a registered trademark of Microsoft Corporation. PostScript is a registered trademark of Adobe Systems, Inc. All other trademarks or registered trademarks mentioned herein are the property of their respective holders. 1 of 95

Abstract. A good object-oriented effects system gives the ability to define abstract regions (or “data groups”) of state within objects that can be extended in subclasses. Then one can specify (for instance) read and write effects on these abstract regions. Additionally, effects on “wholly owned subsidiary ” objects should be seen as effects on regions of the owning object. For instance, an assignment within a bucket of a hash table should be seen as an effect on the hash table alone. Correctness of this transfer of effects depends on the bucket being accessible only through the hash table; it must be unique. Uniqueness can be guaranteed using destructive reads (in which a unique variable can be used at most once). Destructive reads are inconvenient, so most uniqueness systems permit borrowing reads as well, in which a temporary alias of a unique variable is permitted. But if the unique variable is read during the lifetime of this alias, the uniqueness invariant fails. So we wish to ensure that this read effect does not happen. For modularity reasons, we use effects annotations on methods to check for such read effects. Thus we see that effects and uniqueness depend on each other. Our position is that the use of annotations breaks the cyclic dependence as long as the annotations are given semantics independent of the analyses. As a semantics of uniqueness annotations is already available, we then sketch a semantics of effects annotations independent of uniqueness. Thus decoupled, one can prove the correctness of a uniqueness analysis and an effects analysis without regard for the other. 1

Object-oriented programming languages allow inter-object aliasing to represent linked data structures and networks of interacting objects. Aliasing complicates formal reasoning about programs, as it can occur anywhere in a program. In our mode system programs are annotated with modes that indicate object ownership and control the extent of object aliases. By localising aliases, our mode system provides a context for formal reasoning about object systems. Being statically checkable our system offers a practical target for the formal refinement of object-based specifications. 1