Language support for immutable objects is outside the scope of JSR-133
and the JMM. If such a language feature were to exist the JMM would
define it's behaviour of course.
While there might be merit in the idea, the problem in my opinion is
that immutability is often in the eye of the beholder. Consider C++
const and the need for the mutable modifier to un-const something.
Just because an object is logically immutable from an external
perspective, it may not be physically immutable from an internal
perspective. While transitive immutability might be desirable in some
contexts it may not be desirable in all contexts. Further, in your
scheme, how do you ensure that the same object is not manipulated via
both mutable and immutable references? You seem want to make an object
temporarily unmodifiable, or unmodifiable within a particular calling
context, and that to me is quite distinct from an object actually
being immutable. The advantage of immutability in a multi-threaded
context comes from knowing that something can never change.
If you can't trust the receiver of an object not to modify it then you
should provide either an unmodifiable object (a read-only view or have
modifying methods security checked in some way), or else provide an
object which you don't care is modified. That's not to suggest that
existing API's (like the event framework) can necessarily be
retrospectively adapted in this way.
Just my 2c.
David Holmes
-------------------------------
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:52 EDT