Re: what the benefit is by using annotation, like "@Immutable" ?
Andreas Leitgeb wrote:
markspace <nospam@nowhere.com> wrote:
As stooges is private and has not even got a getter, your class would
still be immutable even without the "final" keyword.
This bit I don't think is true. I'm pretty sure the JLS only guarantees
visibility of these fields due to the presences of the final keyword.
See the Final Fields section of the JLS, section 17.5 iirc.
SomeClass: has a plain int-field initialized from its C'tors param.
some_shared_field: e.g. a non-final static field of a class known
to both threads.
Thread A doing:
some_shared_field = new SomeClass(42);
Thread B doing:
SomeClass sc=some_shared_field;
if (sc != null) { do_something_with(sc); }
Assuming that Thread B ever sees a non-null value in sc, I'd be very
surprised, if it then might ever see a *non-fully-initialized* instance,
even if SomeClass *doesn't* have final fields.
Not noticing changes in a plain field is one thing, but reading an old
value of something that wasn't so far seen by that thread... well,
that's beyond me. And, that adding a (dummy) final field to SomeClass
(e.g. one that's just "initialized to 0 in the c'tor) might solve that
problem is even further beyond me.
Remember that many systems allow threads to move from processor to
processor. Thread B, running on Processor 42, may see an old value of a
cache line it has never referenced because Thread A recently used a time
slice on Processor 42, and nothing has since happened to remove the line
from the Processor 42 cache. Thread A has since executed a store into
that cache line on Processor 5, but Processor 42 has not heard about
that yet.
It is up to the Java implementation to do whatever is needed, including
inserting memory barrier commands, to ensure that behavior conforms to
what the JLS says.
Patricia