Re: JavaMemoryModel: Motivation and Semantics for Immutable objects

From: Matthew Ford (Matthew.Ford@forward.com.au)
Date: Mon Sep 22 2003 - 20:22:14 EDT


The need for Immutable object references

I came to this list because of the mention of immutable objects. However
none of the
the proposals seem to satisfy my requirement for an immutable object
reference.

Why I need immutable object references?
For listeners' event objects. There is no guarantee in what order listeners
are called so
for consistent results it is imperative that event objects are not changed
by any listener.

An immutable object reference and any object references it contains should
be immune from change after it is
created. So in an immutable array of objects
Objects[] objArray.
all the elements need to be immutable also, and all the elements' elements
and so on down.

This kind of immutability does not seem to be part of this JSR but I believe
it is necessary
as it also simplifies multi-threaded programming.

One possibility would be a wrapper class
public Object Immutable(Object obj);
Note the Collections methods do not enforce immutability on internal fields.

This would return all objects referenced via this Immutable class as (deep)
clones.
Hence maintain the original object as immutable.

This class may be writeable in Java source but would result in large
overheads for non-trivial objects.
A better approach would be to add an immutable flag to Object references to
prevent assignment once the flag is set.
This is like a delayed final but applied to object references rather than to
the objects themselves.

The flag should be recursive. That is if an object reference has the
immutable flag set then all objects referenced
by it will also have their immutable flag set.

Actually the enclosing object acts like a filter with sets the immutable
flag on references accessed via it.

The algorithm is a follows
i) set immutable flag on an object. (fields of this object now cannot be
assigned to)
ii) Any object reference returned by this immutable object reference also
has its immutable flag set.
That is all return statements need to do a final check before returning a
reference and all
   reference = obj.field;
statements need to set the immutable flag on reference if the immutable flag
is set on the obj being accessed.

The user should be able to unset the flag on any object reference

In the Java language I propose two additions
a) an immutable keyword
b) immutable and mutable methods in the Object class.

The immutable keyword would have the semantics of final i.e.
        immutable Object immutableObj = obj1; // immutableObj is an
immutable reference to obj1;
and in listeners could be defined like
        public void actionPerformed(immutable ActionEvent e)
        // e is an immutable reference in this method

The immutable() method in the Object class returns an immutable reference
for that object i.e.
     Object immutableObj = oldObj.immutable(); // immutableObject is an
immutable reference to oldObj
The mutable() method in the Object class returns an mutable reference for
that object i.e.
     Object mutableObj = oldObj.mutable(); // mutableObject is an mutable
reference to oldObj

Any comments?

----------------------------------------------------
Dr. Matthew.Ford
Forward Computing & Control Pty. Ltd.
www.forward.com.au

-------------------------------
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel



This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:51 EDT