Results 1 - 10
of
19
A Practical Type System and Language for Reference Immutability
- In OOPSLA
, 2004
"... This paper describes a type system that is capable of expressing and enforcing immutability constraints. The specific constraint expressed is that the abstract state of the object to which an immutable reference refers cannot be modified using that reference. The abstract state is (part of) the tran ..."
Abstract
-
Cited by 36 (10 self)
- Add to MetaCart
This paper describes a type system that is capable of expressing and enforcing immutability constraints. The specific constraint expressed is that the abstract state of the object to which an immutable reference refers cannot be modified using that reference. The abstract state is (part of) the transitively reachable state: that is, the state of the object and all state reachable from it by following references. The type system permits explicitly excluding fields or objects from the abstract state of an object. For a statically type-safe language, the type system guarantees reference immutability. If the language is extended with immutability downcasts, then run-time checks enforce the reference immutability constraints.
Object and reference immutability using Java generics
- In ESEC/FSE
, 2007
"... 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 a ..."
Abstract
-
Cited by 24 (11 self)
- Add to MetaCart
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.
Ownership and Immutability Inference for UML-based Object Access Control
- In ICSE
, 2007
"... We propose a mechanism for object access control which is based on the UML. Specifically, we propose use of ownership and immutability constraints on UML associations and verification of these constraints through reverse engineering. These constraints inherently support software design principles, a ..."
Abstract
-
Cited by 20 (6 self)
- Add to MetaCart
We propose a mechanism for object access control which is based on the UML. Specifically, we propose use of ownership and immutability constraints on UML associations and verification of these constraints through reverse engineering. These constraints inherently support software design principles, and impose requirements on the implementation that may help prevent serious program flaws. We propose implementation-level models for ownership and immutability that capture well the meaning of these concepts in design, and we develop novel static ownership and immutability inference analyses. We perform an empirical investigation on several small-to-large Java programs. The results indicate that the inference analyses are precise and practical. Therefore, the analyses can be integrated in reverse engineering tools and can help support effective reasoning about software quality and security. 1
Pluggable Verification Modules: An Extensible Protection Mechanism for the JVM
- IN PROCEEDINGS OF THE 19TH ANNUAL ACM SIGPLAN CONFERENCE ON OBJECT-ORIENTED PROGRAMMING, SYSTEMS, LANGUAGES, AND APPLICATIONS (OOPSLA’04
, 2003
"... ..."
Why we should not add readonly to Java (yet
- In FTfJP
, 2005
"... In this paper, I examine some of reasons that “readonly ” style qualifiers have been proposed for Java, and also the principles behind the rules for these new qualifiers. I find that there is a mismatch between some of the motivating problems and the proposed solutions. Thus I urge Java designers to ..."
Abstract
-
Cited by 13 (1 self)
- Add to MetaCart
In this paper, I examine some of reasons that “readonly ” style qualifiers have been proposed for Java, and also the principles behind the rules for these new qualifiers. I find that there is a mismatch between some of the motivating problems and the proposed solutions. Thus I urge Java designers to proceed with caution when adopting a solution to these sets of problems. 1 Proposals for “readonly ” in Java The purpose in having qualifiers such as “readonly ” on types in a programming language is so that programmers can enlist the compiler (and loader) in enforcing rules about the proper use of data.
Object-oriented encapsulation for dynamically typed languages
- In Proceedings of 18th International Conference on Object-Oriented Programming Systems, Languages and Applications (OOPSLA’04
, 2004
"... Encapsulation in object-oriented languages has traditionally been based on static type systems. As a consequence, dynamically-typed languages have only limited support for encapsulation. This is surprising, considering that encapsulation is one of the most fundamental and important concepts behind o ..."
Abstract
-
Cited by 13 (1 self)
- Add to MetaCart
Encapsulation in object-oriented languages has traditionally been based on static type systems. As a consequence, dynamically-typed languages have only limited support for encapsulation. This is surprising, considering that encapsulation is one of the most fundamental and important concepts behind object-oriented programming and that it is essential for writing programs that are maintainable and reliable, and that remain robust as they evolve. In this paper we describe the problems that are caused by insufficient encapsulation mechanisms and then present object-oriented encapsulation, a simple and uniform approach that solves these problems by bringing state of the art encapsulation features to dynamically typed languages. We provide a detailed discussion of our design rationales and compare them and their consequences to the encapsulation approaches used for statically typed languages. We also describe an implementation of object-oriented encapsulation in Smalltalk. Benchmarks show that extensive use of objectoriented encapsulation results in a slowdown of less than 15 per cent.
Ownership, uniqueness and immutability
- In TOOLS
, 2007
"... Programming in an object-oriented language demands a fine balance between high degrees of expressiveness and control. At one level, we need to permit objects to interact freely to achieve our implementation goals. At a higher level, we need to enforce architectural constraints so that the system can ..."
Abstract
-
Cited by 10 (3 self)
- Add to MetaCart
Programming in an object-oriented language demands a fine balance between high degrees of expressiveness and control. At one level, we need to permit objects to interact freely to achieve our implementation goals. At a higher level, we need to enforce architectural constraints so that the system can be understood by new developers and can evolve as requirements change. To resolve this tension, numerous explorers have ventured out into the vast landscape of type systems expressing ownership and behavioural restrictions such as immutability. (Many have never returned.) This work in progress reports on our consolidation of the resulting discoveries into a single programming language. Our language, Joe3, imposes little additional syntactic overhead, yet can encode powerful patterns such as fractional permissions, and the reference modes of Flexible Alias Protection. 1.
Proof Linking: A Modular Verification Architecture for Mobile Code Systems
-
, 2004
"... This dissertation presents a critical rethinking of the Java bytecode verification architecture from the perspective of a software engineer. In existing commercial implementations of the Java Virtual Machine, there is a tight coupling between the dynamic linking process and the bytecode verifier. Th ..."
Abstract
-
Cited by 9 (5 self)
- Add to MetaCart
This dissertation presents a critical rethinking of the Java bytecode verification architecture from the perspective of a software engineer. In existing commercial implementations of the Java Virtual Machine, there is a tight coupling between the dynamic linking process and the bytecode verifier. This leads to delocalized and interleaving program plans, making the verifier difficult to maintain and comprehend. A modular mobile code verification architecture, called Proof Linking, is proposed. By establishing explicit verification interfaces in the form of proof obligations and commitments, and by careful scheduling of linking events, Proof Linking supports the construction of bytecode verifier as a separate engineering component, fully decoupled from Java's dynamic linking process. This turns out to have two additional benefits: (1) Modularization enables distributed verification protocols, in which part of the verification burden can be safely offloaded to remote sites; (2) Alternative static analyses can now be integrated into Java's dynamic linking process with ease, thereby making it convenient to extend the protection mechanism of Java. These benefits make Proof Linking a competitive verification architecture for mobile code systems. A prototype of the Proof Linking Architecture has been implemented in an open source Java Virtual Machine, the Aegis VM (http://aegisvm.sourceforge.net). On the

