Ownership and immutability in generic Java
The Java language lacks the important notions of ownership (an object owns its representation to prevent unwanted aliasing) and immutability (the division into mutable, immutable, and readonly data and references). Programmers are prone to design errors, such as representation exposure or violation...
Gespeichert in:
Veröffentlicht in: | SIGPLAN notices 2010-10, Vol.45 (10), p.598-617 |
---|---|
Hauptverfasser: | , , , , |
Format: | Artikel |
Sprache: | eng |
Online-Zugang: | Volltext |
Tags: |
Tag hinzufügen
Keine Tags, Fügen Sie den ersten Tag hinzu!
|
Zusammenfassung: | The Java language lacks the important notions of
ownership
(an object owns its representation to prevent unwanted aliasing) and
immutability
(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
Ownership Immutability Generic Java
(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.
Creation of immutable cyclic structures requires a
"cooking phase"
in which the structure is mutated but the outside world cannot observe this mutation. OIGJ uses
ownership
information to facilitate creation of
immutable
cyclic structures, by safely prolonging the cooking phase even after the constructor finishes.
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 java.util collections (except for the clone 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. |
---|---|
ISSN: | 0362-1340 1558-1160 |
DOI: | 10.1145/1932682.1869509 |