On 18 May 2011 18:09, Stephen Colebourne <scolebou...@joda.org> wrote:
> See the EvilFoo example above. Any ability to subclass, even with safe
> methods, means its not completely thread-safe.
More info:
StringBuilder evilBuf = new StringBuilder();
EvilFoo evilFoo = new EvilFoo(evilBuf);
doStuff(evilFoo);
// evilFoo has now been passed to another thread/queued/somewhere else entirely
evilBuf.append("Shared object");
// this append is being done on an object that had been shared between
two threads
// that is a Bad Thing, although it only affects the caller here
I'm sure there are worse things that can be done here too. For
example, the end consumer of the evilFoo in another thread might
access the buffer (via a cast or reflection). Or the subclass might do
something during serialization/deserialization when it could change
the stored values, completely invalidating the original object.
So, making the supplied methods final helps (its a minimum), making
the class final really goes to avoid a whole slew of potential issues.
Safety by design.
Stephen
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
