On Wed, May 18, 2011 at 12:20 PM, Stephen Colebourne
<scolebou...@joda.org> wrote:
> 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.
>
I'm having a hard time caring about the mutability of a hypothetical
EvilPair beyond its Pair "aspect." At the same time I'm good and
ready to settle the issue in just about any way on which we can all
compromise. :/
Matt
> Stephen
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
