Immutability specification and its applications

Pechtchanski, Igor; Sarkar, Vivek

doi:10.1002/cpe.853

Cited by 26 publications

(26 citation statements)

References 8 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Immutability information is useful in many software engineering tasks, such as modeling [7], verification [30], compile-and runtime optimizations [9,25,28], refactoring [17], test input generation [1], regression oracle creation [24,32], invariant detection [15], specification mining [10], and program comprehension [13]. Three varieties of immutability guarantee are: Class immutability No instance of an immutable class may be changed; examples in Java include String and most subclasses of Number such as Integer and BigDecimal.…”

Section: Introductionmentioning

confidence: 99%

Object and reference immutability using Java generics

Zibin

Potanin

Ali

et al. 2007

Proceedings of the the 6th Joint Meeting of the European Software Engineering Conference and the ACM SIGSOFT Symposium on the F

View full text Add to dashboard Cite

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 Java's syntax by building upon Java's generics and annotation mechanisms. In IGJ, each class has one additional type parameter that is Mutable, Immutable, 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 within Java's syntax and type system, and its reference immutability is more expressive than previous work. IGJ also permits covariant changes of type parameters in a type-safe manner, e.g., a readonly list of integers is a subtype of a readonly list of numbers. IGJ extends Java's type system with a few simple rules. We formalize this type system and prove it sound. Our IGJ compiler works by typeerasure and generates byte-code that can be executed on any JVM without runtime penalty.

show abstract

Section: Introductionmentioning

confidence: 99%

Object and reference immutability using Java generics

Zibin

Potanin

Ali

et al. 2007

Proceedings of the the 6th Joint Meeting of the European Software Engineering Conference and the ACM SIGSOFT Symposium on the F

View full text Add to dashboard Cite

show abstract

“…public, protected, private) had any bearing on the likelihood of a field being declared or undeclared final. It would also be interesting to extend our analysis to detect deep stationary behaviour, similar to the smaller analysis of Pechtchanski and Sarkar [20].…”

Section: Resultsmentioning

confidence: 84%

“…Pechtchanski and Sarkar present an interesting study of field immutability [20]. Their work includes a framework for specifying and verifying both shallow and deep field immutability, as well as a runtime study that found that at least 61% of field accesses were immutable, a similar property to stationary fields.…”

Section: Threats To Validitymentioning

confidence: 99%

Profiling Field Initialisation in Java

Nelson

Pearce

Noble

2013

Runtime Verification

View full text Add to dashboard Cite

Abstract. Java encourages programmers to use constructor methods to initialise objects, supports final modifiers for documenting fields which are never modified and employs static checking to ensure such fields are only ever initialised inside constructors. Unkel and Lam observed that relatively few fields are actually declared final and showed using static analysis that many more fields have final behaviour, and even more fields are stationary (i.e. all writes occur before all reads). We present results from a runtime analysis of 14 real-world Java programs which not only replicates Unkel and Lam's results, but suggests their analysis may have under-approximated the true figure. Our results indicate a remarkable 72-82% of fields are stationary, that final is poorly utilised by Java programmers, and that initialisation of immutable fields frequently occurs after constructor return. This suggests that the final modifier for fields does a poor job of supporting common programming practices.

show abstract

“…This leads to the definition of immutability of an object [8], in relationship to the semantics of the program: an object is immutable if it is never modified by the code of the program. Our approach is to detect all immutable objects and to place them in ROM.…”

Section: Placing Data In Rommentioning

confidence: 99%