DOC PREVIEW
Why we should not add readonly to Java

This preview shows page 1-2-3-4 out of 13 pages.

Save
View full document
View full document
Premium Document
Do you want full access? Go Premium and unlock all 13 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 13 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 13 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 13 pages.
Access to all documents
Download any document
Ad free experience
Premium Document
Do you want full access? Go Premium and unlock all 13 pages.
Access to all documents
Download any document
Ad free experience

Unformatted text preview:

Why we should not add readonly to Java (yet)∗John Boyland†June 30, 2005AbstractIn this paper, I examine some of reasons that “readonly” style qualifiers have been proposedfor Java, and also the principles behind the rules for these new qualifiers. I find that there isa mismatch between some of the motivating problems and the proposed solutions. Thus I urgeJava designers to proceed with caution when adopting a solution to these sets of problems.1 Proposals for “readonly” in JavaThe purpose in having qualifiers such as “readonly” on types in a programming language is so thatprogrammers can enlist the compiler (and loader) in enforcing rules about the proper use of data.One part of the program may be willing to grant access to data to another part of the program onlyif it can be guaranteed that the other part does not mutate the data. Several proposals have beenmade to add enforceable “readonly” qualifiers in Java programs:JAC [20] Kniesel and Theisen’s syste m “Java with Access Control”;Universes [23] M¨uller and Poetzsch-Heffter’s system for alias and dependency control.ModeJava [31] Skoglund and Wrigstad’s mode system for read-only references in Java.Javari [3] Birka and Ernst’s system for Java with “Reference Immutability.” (This work has beenupdated and will be presented at OOPSLA 2005, but no preprint is publicly available yet.)In this section, we compare these prop os als with emphasis on their broad similarities. We alsocompare with “const” in C++ [32] and with our earlier paper on capabilities [8].A motivating example is used in Section 2 which demonstrates short-comings of the “readonly”concept, in particular “observational exposure,” which is further explained and criticized in Section 3.1.1 Basic RulesThe basic idea in these systems is that a type may be given the “readonly” annotation. Formally,if T is some class, then readonly T represents a super-type of T . In other words, it is permitted toimplicit coerce a reference of type T to readonly T (widening conversion), but the reverse coercionrequires an explicit cast. This rule carries over in the obvious way to parameters, return values,local variables and fields. The receiver of a method may be typed as readonly, in which we call themethod a read-only method.The main restriction on a reference value of a “read-only” type is that the reference cannot beused to change a field. For a quick example, consider the artificial class in Fig. 1. Ignoring the∗Work supported in part by the NASA/Ames High Dependability Computing Program (NCC-2-1298)†University of Wisconsin–Milwaukee, USA, [email protected] B {A f1;readonly A f2;mutable A f3;mutable readonly A f4;readonly A method1() readonly {this.f1 = new A(); //! Writes field of readonly thisthis.f3 = null;if (...) return this.f1;else return this.f2;}A method2(A p1, readonly A p2) {this.f1 = p2; //! Field needs a read-write ref.this.f2 = p1;this.f3 = p1;return this.f4; //! Result needs a read-write ref.}}Figure 1: An artificial class illustrating read-only rules.mutable annotation for now, this example illustrates the rule. In method1, the receiver is readonly(indicated directly before the body) and thus this has type readonly B. Thus it is not legal to writefield f1 here. However, we are free to read these fields and since the return type is a “read-only”type, we can return the contents of either field f1 or f2 without error.The second m ethod method2 is declared normally (without readonly) and thus doesn’t havethis restriction, but must still follow the types of the fields, and thus the write to f1 fails because a“read-only” reference is an inappropriate value to store in the field; an explicit cast would be needed.However, the write to f2 succeeds because the “read-write” parameter p1 can be implicitly coercedinto a “read-only” reference to be stored in f2. The write of f3 does not require any coercion.This example shows the difference between readonly which applies to the reference stored in afield (protecting the fields of the object referred to), and Java’s existing final annotation whichrefers to the field itself, making it non-updatable in any method. This is the distinction that C++makes betwe en a p ointer to a “const” object (whose data members cannot be written) and a constdata member with a pointer in it (the pointer can be used for mutation). C++ can make do withone keyword (albeit somewhat confusingly) because pointers are explicitly typed.Java’s final annotation protects a field from b eing up dated regardless of whether the methodis read-only. JAC and Javari include a mutable annotation (borrowed from C++) that has theopposite effect: it makes a field updatable, again regardless of whether the method is read-only.Thus we see that method1 is permitted to update field f3 despite being “read-only.” Aside from thisbehavior, mutable has no effect, and thus we see that method2 cannot return the contents of fieldf4 since a “read-write” reference is needed. Indeed mutable would be the direct opposite of final,were it not for transitivity, as explained in the next section.1.2 TransitivityIn C++, some data members have pointer type, and others have object type. In a const object, anobject data member is also const. In other words, if I have a pointer to a “const” object and get areference to the object stored in this data member, this reference is also “const” (or rather it is alsoto a “const” objec t). This transitivity of “constness” is entirely reasonable since the second object is2stored within the first. On the other hand, if the first object has a pointer to a third object, then ifwe fetch this pointer, there are no restriction on mutating this object. Again, this lack of transitivityis reasonable if we consider the state of an object to consist solely of what is stored inside it.However, even in C++, som e object’s state notionally extends to other objects stored on theheap. For instance a “map” object includes pointers to nodes in a red-black tree. Changing anyof these nodes conceptually changes the map. And indeed a “map” will protect its nodes and“voluntarily” propagate “constness” to maintain desired invariants.In Java, there is no possibility of storing one object inside another (at the language level), andthus all subsidiary objects must be referred to through (implicit) pointers. The question is thenwhether transitivity


Why we should not add readonly to Java

Download Why we should not add readonly to Java
Our administrator received your request to download this document. We will send you the file to your email shortly.
Loading Unlocking...
Login

Join to view Why we should not add readonly to Java and access 3M+ class-specific study document.

or
We will never post anything without your permission.
Don't have an account?
Sign Up

Join to view Why we should not add readonly to Java 2 2 and access 3M+ class-specific study document.

or

By creating an account you agree to our Privacy Policy and Terms Of Use

Already a member?