On Fri, 20 Apr 2001, Waldhoff, Rodney wrote:
> I was adding/refactoring the Collections test framework, and I notice that:
>
> (new FastArrayList()).equals(new FastArrayList())
>
> returns false.
>
> I also notice Craig's javadoc comment that equals is not overridden, so
> that's no surprise.
>
> But why is that? Have we just not gotten around to defining equals, or is
> there some design reason I'm missing for not supporting it? I guess it's a
> little tricky when we want to avoid synchronization? Same for hashCode? Is
> there an appropriate way of defining these in keeping with the
> java.util.List contract?
>
To be honest, I hadn't ever really thought about equals() or hashCode()
calls on these classes. Looks like that comment in the docs should have
said TODO instead of NOTE.
It seems that we could implement these methods as described for
java.util.List, assuming the need for synchronization (or not) based on
the "fast" property -- just as is done for all other accesses. Anyone see
any problem with that thinking? If not, I will implement them over the
weekend.
Same issues apply to FastHashMap/FastTreeMap versus the contracts for
java.util.Map.
> - Rod
>
Craig
