Ownership and immutability in generic Java
Submitted by mernst on Wed, 2011-11-30 14:35
| Title | Ownership and immutability in generic Java |
| Publication Type | Conference Paper |
| Year of Publication | 2010 |
| Authors | Zibin Y, Potanin A, Li P, Ali M, Ernst MD |
| Conference Name | Object-Oriented Programming Systems, Languages, and Applications (OOPSLA 2010) |
| Date or Month Published | October 19–21 |
| Conference Location | Revo, NV, USA |
| Abstract | <p>The Java language lacks the important notions of <em>ownership</em> (an object owns its representation to prevent unwanted aliasing) and <em>immutability</em> (the division into mutable, immutable, and readonly data and references). Programmers are prone to design errors, such as representation exposure or violation of immutability contracts. This paper presents <em>Ownership Immutability Generic Java</em> (OIGJ), a backward-compatible purely-static language extension supporting ownership and immutability. We formally defined a core calculus for OIGJ, based on Featherweight Java, and proved it sound. We also implemented OIGJ and performed case studies on 33,000 lines of code. </p> <p> Creation of immutable cyclic structures requires a ``<em>cooking phase</em>'' in which the structure is mutated but the outside world cannot observe this mutation. OIGJ uses <em>ownership</em> information to facilitate creation of <em>immutable</em> cyclic structures, by safely prolonging the cooking phase even after the constructor finishes. </p> <p> OIGJ is easy for a programmer to use, and it is easy to implement (flow-insensitive, adding only 14 rules to those of Java). Yet, OIGJ is more expressive than previous ownership languages, in the sense that it can type-check more good code. OIGJ can express the factory and visitor patterns, and OIGJ can type-check Sun's <tt>java.util</tt> collections (except for the <tt>clone</tt> method) without refactoring and with only a small number of annotations. Previous work required major refactoring of existing code in order to fit its ownership restrictions. Forcing refactoring of well-designed code is undesirable because it costs programmer effort, degrades the design, and hinders adoption in the mainstream community.</p> |
| Downloads | TR with proofs PDF |
| Citation Key | ZibinPLAE2010 |
Last changed Mon, 2013-06-03 10:27

cs.