Re: what the benefit is by using annotation, like "@Immutable" ?
Lew wrote:
The field in question is private, and does not change the externally
observable state. So the String instance acts like it's immutable, but
has mutable internal state.
So in a real sense String is mutable, and just as real, it's immutable.
To expound on this a bit, final fields in a constructor are treated
specially by the JVM and JLS. Even if an entire class is not strictly
immutable, the values and objects referred to by final fields will be
treated as immutable by the compiler & runtime.
Thus, if you have your own class which follows the rules for immutablity
for some of its fields, those fields will also be treated as immutable &
safe for publication with a data race.
public class Stooges {
private final List<String> stooges;
private int count;
public Stooges {
stooges = new ArrayList<String>();
stooges.add("Lary");
stooges.add("Curly");
stooges.add("Moe");
}
public boolean isStooge( String name ) {
return stooges.contains( name );
}
public int size() {
if( count == 0 ) {
count = stooges.size();
}
return count;
}
}
The field "stooges" is immutable and treated as such by the JVM. The
fact that "count" is kind of lazily-immutable (*) still is thread safe;
this whole class can be treated as immutable, not as effectively
immutable, with no repercussions or harm done.
(*) Is there an actually name for "lazily-immutable?" I seem to
remember it being talked about in JCIP but I can't find a reference now.
Hmmm, I wonder if a class can have no final fields, have at least one
mutable private field and still be immutable.