"Joseph Bowbeer" <jozart@csi.com> writes:
> If I understand correctly, some of the proposed fixes to JMM are
> designed so that immutable objects can be accessed without
> synchronization once they are constructed.
Yes. But we must be very clear on one thing (and then the answers to
your questions, no and no, are obvious):
* Any class with SETTER methods (or init methods, or any other method
which visibly changes object state) is clearly not "immutable".
* State changes are going to require either locking or volatility.
I really do think there needs to be a solid set of patterns for
immutability, and it needs to be clear that using immutable objects
rules out other usages. There should also be nice patterns for setter
and initialization methods for mutable objects. But I don't think
there should be patterns for "immutable initialization" or any such
thing---if you want an immutable object, you create it, you don't
mutate it.
It is clear that coming up with a good set of design patterns will be
key to making JMM-compliant code widespread, whatever the JMM ends up
being. And it's clear that some of the existing patterns are broken
in this regard (such as the one for beans which _requires_
argument-less constructors).
It feels like we run into these sorts of questions/problems on a
fairly regular basis. I'm wondering therefore if any of the patterns
gurus out there have systematically taken a look at some of the more
pedestrian design patterns and seen how they are affected by JMM
issues (Doug Lea, you're an obvious candidate in this regard). Step 1
is to ignore any kind of multiprocessor cleverness and focus on the
basics. I'd love to see answers in this regard.
-Jan-Willem Maessen
PS - coming from a Functional Programming background, any use of
setter methods to perform initialization just looks wrong, wrong,
wrong. So I have some pretty clear biases.
-------------------------------
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:27 EDT