Matthew,
Sorry I didn't reply earlier. One of my customers is having enough
trouble with existing JVMs that thinking about future ones
had to go on the back burner for a while :-)
I agree with your assertion that immutability simplifies multi-threaded
programming, particularly if you can take advantage of structure
sharing while being confident that no other thread will mess with the
shared data you are using.
However I was a bit mystified as to the scenarios in which you
might wish to make a previously-immutable object mutable again.
> -----Original Message-----
> From: Evan Ireland [mailto:eireland@sybase.com]
> Sent: Monday, 20 October 2003 10:45 a.m.
> To: eireland@sybase.com
> Subject: [Matthew.Ford@forward.com.au: Re: JavaMemoryModel: Motivation
> and Semantics for Immutable objects]
>
>
> ------- Start of forwarded message -------
> Return-Path: <owner-javamemorymodel@cs.umd.edu>
> Date: Tue, 23 Sep 2003 10:22:14 +1000
> From: Matthew Ford <Matthew.Ford@forward.com.au>
> Subject: Re: JavaMemoryModel: Motivation and Semantics for
> Immutable objects
> To: javaMemoryModel@cs.umd.edu
> MIME-version: 1.0
> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
> X-Mailer: Microsoft Outlook Express 6.00.2800.1158
> Content-type: text/plain; charset=iso-8859-1
> Content-transfer-encoding: 7BIT
> X-Priority: 3
> X-MSMail-priority: Normal
> Sender: owner-javamemorymodel@cs.umd.edu
> Precedence: bulk
> X-BigFish: pcs-51(z17eNzdf9M122eHzz2cfRe5Rzz907ILz)v
> Content-Length: 3326
>
> 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
------- End of forwarded message -------
-------------------------------
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