Re: Mutable Objects and Thread Boundaries
Peter Duniho wrote:
markspace wrote:
Joshua Cranmer wrote:
Immutability is the easiest way to guarantee safe publication: final
fields guarantee that they can be used by any thread safely.
Note quite. Final fields by themselves don't guarantee immutability
or safe publication. An immutable object must:
* All fields are final.
* It is properly constructed. (No "this escapes." That bit is
important.)
* Its state cannot be modified after construction.
Those three things must hold for an object to be treated as immutable
by the JVM. Mess up any one, and poof, no more immutability.
I would be interested in seeing an example where your third point is
violated but the first point is not.
class Mutable {
private final List<String> names;
public Mutable() {
names = new List<String>();
names.add("Joe");
names.add("Jim");
}
public List<String> getNames() {
return names;
}
}
This class would be immutable except for the fact that the private final
variable "names" escapes and could be modified. If the getNames()
method is removed, then the class is immutable and can be published even
in a data race.
And I know what's coming next, but it really is immutable if the getter
is removed. The JLS was designed to work this way because String has to
be immutable, and String initializes itself the same way, so the JLS was
constructed to make this kind of initialization safe and immutable.