Object and Reference Immutability using Java Generics

A compiler-checked immutability guarantee provides useful documentation, facilitates reasoning, and enables optimizations. This paper presents Immutability Generic Java (IGJ), a novel language extension that expresses immutability without changing Javas syntax by building upon Javas generics and annotation mechanisms. In IGJ, each class has one additional generic parameter that is Immutable, Mutable, or ReadOnly. IGJ guarantees both reference immutability (only mutable references can mutate an object) and object immutability (an immutable reference points to an immutable object). IGJ is the first proposal for enforcing object immutability, and its reference immutability is more expressive than previous work. IGJ also permits covariant changes of generic arguments in a type-safe manner, e.g., a readonly list of integers is a subtype of a readonly list of numbers. IGJ extends Javas type system with a few simple rules. We formalize this type system and prove it sound. Our IGJ compiler works by type-erasure and generates byte-code that can be executed on any JVM without runtime penalty

A Syntactic Model of Mutation and Aliasing

Traditionally, semantic models of imperative languages use an auxiliary structure which mimics memory. In this way, ownership and other encapsulation properties need to be reconstructed from the graph structure of such global memory. We present an alternative "syntactic" model where memory is encoded as part of the program rather than as a separate resource. This means that execution can be modelled by just rewriting source code terms, as in semantic models for functional programs. Formally, this is achieved by the block construct, introducing local variable declarations, which play the role of memory when their initializing expressions have been evaluated. In this way, we obtain a language semantics which directly represents at the syntactic level constraints on aliasing, allowing simpler reasoning about related properties. To illustrate this advantage, we consider the issue, widely studied in the literature, of characterizing an isolated portion of memory, which cannot be reached through external references. In the syntactic model, closed block values, called "capsules", provide a simple representation of isolated portions of memory, and capsules can be safely moved to another location in the memory, without introducing sharing, by means of "affine' variables. We prove that the syntactic model can be encoded in the conventional one, hence efficiently implemented.Comment: In Proceedings DCM 2018 and ITRS 2018 , arXiv:1904.0956

Declarative Immutability in Java

A pervasive mechanism is proposed to declare that variables and object instances are mutable or immutable, and whether methods mutate instances. These declarations are integral to the type structure of the language and allow the developer to declare, and the reader (and compiler) to determine, if a variable or instance is immutable (even if other instances of the Class are mutable) or that an instance is immutable throughout the application (a Pure instance). The concept of the owner or outsiders of variables and instances is combined with a series of tags to declare mutability, and can be enforced during compilation. This provides a more informative definition of the interface for a Class, requires fewer lines of code for implementation, and reduces the runtime overhead of defensive coding (creating clones). In a multi-threaded application, flagging a Pure instance to the JVM can provide significant performance improvements by eliminating unnecessary synchronizations. Many of the benefits recognized for Functional Programming are introduced to Java as an optional enhancement

Definite Reference Mutability (Artifact)

Related paper "Definite Reference Mutability" presents ReM (Re[ference] M[utability]), a type system that separates mutable references into (1) definitely mutable, and (2) maybe mutable, i.e., references whose mutability is due to inherent approximation. We have implemented ReM and applied it on a large benchmark suite. Results show that ~ 86% of mutable references are definitely mutable. This article describes the tool artifact from the related paper. The purpose of the article and artifact is to allow researchers to reproduce our results, as well as build new type systems upon our code

Encoding Featherweight Java with Assignment and Immutability using The Coq Proof Assistant

We develop a mechanized proof of Featherweight Java with Assignment and Immutability in the Coq proof assistant. This is a step towards more machine-checked proofs of a non-trivial type system. We used object immutability close to that of IGJ [8]. We describe the challenges of the mechanization and the encoding we used inside of Coq. prover. Our Coq sources are publically available 1. Example. We define a parametrized class Cell, where the mutable instantiation can get and set the interned object, whereas the immutable instantiation can only get the interned object, provided initially in the constructor. We chose to use transitive mutability in this example. 1

Definite Reference Mutability

Reference immutability type systems such as Javari and ReIm ensure that a given reference cannot be used to mutate the referenced object. These systems are conservative in the sense that a mutable reference may be mutable due to approximation. In this paper, we present ReM (for definite Re[ference] M[utability]). It separates mutable references into (1) definitely mutable, and (2) maybe mutable, i.e., references whose mutability is due to inherent approximation. In addition, we propose a CFL-reachability system for reference immutability, and prove that it is equivalent to ReIm/ReM, thus building a novel framework for reasoning about correctness of reference immutability type systems. We have implemented ReM and applied it on a large benchmark suite. Our results show that approximately 86.5% of all mutable references are definitely mutable

Designing with Static Capabilities and Effects: Use, Mention, and Invariants (Pearl)

Capabilities (whether object or reference capabilities) are fundamentally tools to restrict effects. Thus static capabilities (object or reference) and effect systems take different technical machinery to the same core problem of statically restricting or reasoning about effects in programs. Any time two approaches can in principle address the same sets of problems, it becomes important to understand the trade-offs between the approaches, how these trade-offs might interact with the problem at hand. Experts who have worked in these areas tend to find the trade-offs somewhat obvious, having considered them in context before. However, this kind of design discussion is often written down only implicitly as comparison between two approaches for a specific program reasoning problem, rather than as a discussion of general trade-offs between general classes of techniques. As a result, it is not uncommon to set out to solve a problem with one technique, only to find the other better-suited. We discuss the trade-offs between static capabilities (specifically reference capabilities) and effect systems, articulating the challenges each approach tends to have in isolation, and how these are sometimes mitigated. We also put our discussion in context, by appealing to examples of how these trade-offs were considered in the course of developing prior systems in the area. Along the way, we highlight how seemingly-minor aspects of type systems - weakening/framing and the mere existence of type contexts - play a subtle role in the efficacy of these systems

Simple Reference Immutability for System F-sub

Reference immutability is a type based technique for taming mutation that has long been studied in the context of object-oriented languages, like Java. Recently, though, languages like Scala have blurred the lines between functional programming languages and object oriented programming languages. We explore how reference immutability interacts with features commonly found in these hybrid languages, in particular with higher-order functions -- polymorphism -- and subtyping. We construct a calculus System F-sub-M which encodes a reference immutability system as a simple extension of F-sub and prove that it satisfies the standard soundness and immutability safety properties.Comment: 25 page