The ACE Project

"Take encapsulation seriously!"
Andrew Black,
ECOOP'98 Conference Banquet speech ,
Brussles, 24th July 1998

The ACE project is dedicated to a better notion of encapsulation in object-oriented languages.

The traditional notion of encapsulation is purely visibility-based: it tries to protect parts of an object's state from unauthorised access by making them invisible to other objects. For instance, Java distinguishes between public, protected, package and private visibility of methods and fields. However, the "state of an object is not fully specified by just its variables, but also upon the states of the objects to which these variables refer" (see [1]). The latter transitive state of an object is not protected by visibility-based encapsulation, which protects variables and methods from being accessed but does not protect their values. When being passed as parameters or results, copies of private references are handed out to other objects, thus creating aliases to the transitive state of an object. Problems can arise when such an alias is used to change the transitive state in a way not anticipated by the creator of the alias.
In a nutshell, the limitation of traditional, visibility-based encapsulation is that

• it does neither prevent the creation of aliases to the transitive state of an object,
• nor does it protect against undesired manipulation of the transitive state via aliases.

Many authors have opted for the first solution, proposing techniques for alias prevention to address the problems caused by aliasing. However, aliasing itself is not the problem. It is traditionally and successfully applied as a means to express object sharing. Without aliasing, programmers have to recurse to inefficient deep copying and ensure the consistency and conceptual common identity of duplicate data.
Therefore we consider alias prevention to be a too strong restriction and address the second problem: How is it possible to control what can be done to an object via an alias?

ACE is an acronym for "AccessControl-based Encapsulation", which describes our approach. ACE is a general model for object-oriented languages in which access control information is tied to every reference. Access rights can specify different kinds of access permissions, different durations of access permissions and different transfer modes of access permissions.

For instance, a Person instance could hand out a reference to its address specifing that the receiver object may read it and may also pass these rights to others:

// returned address is at most readable and transferable:
Address getAddress() {    
     return (readable transferable) address
} 

Reference-specific transitive access rights combine transitive protection of the full state of an object with maximum flexibility. An object may have full access to objects that it references and still

• explicitly protect its mutable state by restricting the access rights of references handed out to other objects
• rely on the implicit protection of its state that results from transitivity: when the object is accessed via a reference with restricted access rights ar, only its methods that respect these access rights will be called and all references to its state handed out within such methods will have at most the access rights ar.

See our papers for details on ACE.

JAC is an extension of Java and GJ . It partly follows and partly extends ACE.
JAC introduces the keyword readonly, which can be attached to methods and type declarations. The JAC compiler verifies that no mutating operations are performed on the (local and transitive) state of objects returned by expressions of readonly type. In particular, the implicit this parameter of methods declared as readonly is considered to be an expression of readonly type. So the compiler ensures that readonly methods do not perform any mutating operations, neither on the local, nor on the transitive state of this.

Entities that should not be protected (e.g. instance variables that are not part of an object's conceptual state, like caches and other implementation details) can be annotated as mutable.

In a nutshell, readonly is a clean, transitive version of the "const pointers" of C++. Unlike in C++, there is no unsafe means to cast away "readonlyness".

See our papers for details on JAC.

Because of his work on making static and dynamic delegation type-safe (see Darwin project) Günter was concerned about the claim of Patrick Steyaert and Wolfgang de Meuter in their ECOOP 95 paper that "delegation breaches encapsulation". Reading that paper he realized that the "breach of encapsulation" that it describes was indeed an aliasing problem unrelated to delegation and that no notion of encapsulation existed that could capture the essence of the problem. So he started investigating how access rights can complement purely visibility-based notions of encapsulation.

Dirk Theisen found ACE too general and aimed at a streamlined version that could be used easily by professional Java programmers. He kept only the most essential access rights, invented an elegant mapping of access right transitivity to the type system and integrated both into Java / GJ.

@Article{HLW+91,
        Author="Hogg, J. and Lea, D. and Wills, A. and de Champeaux, D. and Holt, Richard",
        Title="Report on {ECOOP}'91 Workshop {W}3:
               The {G}eneva convention on the treatment of object aliasing",
        Journal="OOPS Messenger",
        Volume=3,
        Number=2,
        Pages="11-16",
        Year=1992
}