View Full Document

Why we should not add readonly to Java



View the full content.
View Full Document
View Full Document

15 views

Unformatted text preview:

Why we should not add readonly to Java yet John Boyland June 30 2005 Abstract 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 One part of the program may be willing to grant access to data to another part of the program only if it can be guaranteed that the other part does not mutate the data Several proposals have been made to add enforceable readonly qualifiers in Java programs JAC 20 Kniesel and Theisen s system Java with Access Control Universes 23 Mu ller 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 been updated and will be presented at OOPSLA 2005 but no preprint is publicly available yet In this section we compare these proposals with emphasis on their broad similarities We also compare 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 Rules The 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 to implicit coerce a reference of type T to readonly T widening conversion but the reverse coercion requires 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 the method a read only method The main restriction on a reference value of a read only type is that the reference cannot be used 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 of Wisconsin Milwaukee USA boyland cs uwm edu University class 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 this this 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 write field 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 method method2 is declared normally without readonly and thus doesn t have this 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 coerced into 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 a field protecting the fields of the object referred to and Java s existing final annotation which refers to the field itself making it non updatable in any method This is the distinction that C makes between a pointer to a const object whose data members cannot be written and a const data member with a pointer in it the pointer can be used for mutation C can make do with one keyword albeit somewhat confusingly because pointers are explicitly typed Java s final annotation protects a field from being updated regardless of whether the method is read only JAC and Javari include a mutable annotation borrowed from C that has the opposite 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 this behavior mutable has no effect and thus we see that method2 cannot return the contents of field f4 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 Transitivity In C some data members have pointer type and others have object type In a const object an object data member is also const In other words if I have a pointer to a const object and get a reference to the object stored in this data member this reference is also const or rather it is also to a const object This transitivity of constness is entirely reasonable since the second object is 2 stored within the first On the other hand if the first object has a pointer to a third object then if we fetch this pointer there are no restriction on mutating this object Again this lack of transitivity is reasonable if we consider the state of an object to consist solely of what is stored inside it However even in C some object s state notionally extends to other objects stored on the heap For instance a map object includes pointers to nodes in a red black tree Changing any of 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 and thus all subsidiary objects must be referred to through implicit pointers The question is then whether transitivity should apply or not The right answer should depend on whether the referred to object is part of first object or not If it is conceptually part of that object s representation then transitivity applies otherwise it does not This is the rule used in flexible alias protection 24 Unfortunately of the four proposals


Access the best Study Guides, Lecture Notes and Practice Exams

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 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?