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.
caches. The problem is even more confounding in that you might read an
object state on Thread B that was *never* a valid state.
final (I could be wrong about that though).