Ownership and Immutability in Generic

Yoav Zibin Alex Potanin Paley Li Mahmood Ali Michael D. Ernst Victoria University of Wellington Massachusetts Institute of Technology University of Washington Wellington, New Zealand Cambridge, MA, USA Seattle, WA, USA yoav|alex|[email protected] [email protected] [email protected]

Abstract 1. Introduction The Java language lacks the important notions of ownership This paper presents Ownership Immutability Generic Java (an object owns its representation to prevent unwanted alias- (OIGJ), a simple and practical language extension that ex- ing) and immutability (the division into mutable, immutable, presses both ownership and immutability information. OIGJ and readonly data and references). Programmers are prone is purely static, without any run-time representation. This to design errors, such as representation exposure or violation enables executing the resulting code on any JVM without of immutability contracts. This paper presents Ownership run-time penalty. Our ideas, though demonstrated using Java, Immutability Generic Java (OIGJ), a backward-compatible are applicable to any statically typed language with generics, purely-static language extension supporting ownership and such as C++, C#, Scala, and Eiffel. immutability. We formally defined a core calculus for OIGJ, OIGJ follows the owner-as-dominator discipline [1, 11, based on Featherweight Java, and proved it sound. We also 33] where an object cannot leak beyond its owner: outside implemented OIGJ and performed case studies on 33,000 objects cannot access it. If an object owns its representation, lines of code. then there are no aliases to its internal state. For example, Creation of immutable cyclic structures requires a “cook- a LinkedList should own all its Entry objects (but not its ing phase” in which the structure is mutated but the outside elements); entries should not be exposed to clients, and entries world cannot observe this mutation. OIGJ uses ownership from different lists must not be mixed. information to facilitate creation of immutable cyclic struc- The keyword private does not offer such strong protec- tures, by safely prolonging the cooking phase even after the tion as ownership, because a careless programmer might constructor finishes. write a public method that exposes a private object (a.k.a. rep- OIGJ is easy for a programmer to use, and it is easy to resentation exposure). Phrased differently, the name-based implement (flow-insensitive, adding only 14 rules to those of protection used in Java hides the variable but not the object, Java). Yet, OIGJ is more expressive than previous ownership as opposed to ownership that ensures proper encapsulation. languages, in the sense that it can type-check more good The key idea in ownership is that representation objects are code. OIGJ can express the factory and visitor patterns, and nested and encapsulated inside the objects to which they be- OIGJ can type-check Sun’s java.util collections (except long. Because this nesting is transitive, this kind of ownership for the clone method) without refactoring and with only a is also called deep ownership [12]. small number of annotations. Previous work required major OIGJ is based on our previous type systems for ownership refactoring of existing code in order to fit its ownership (OGJ [33]) and immutability (IGJ [40]). Although ownership restrictions. Forcing refactoring of well-designed code is and immutability may seem like two unrelated concepts, a undesirable because it costs programmer effort, degrades the design involving both enhances the expressiveness of each design, and hinders adoption in the mainstream community. individual concept. On the one hand, immutability previ- ously enhanced ownership by relaxing owner-as-dominator Categories and Subject Descriptors D.3.3 [Programming to owner-as-modifier [24]: it constrains modification instead Languages]: Language Constructs and Features; D.1.5 [Pro- of aliasing. On