Re: Re: 2.8 collections

For what it's worth, I think throwing UnsupportedOperationException on
hashCode would be a mistake, as would reverting back to identity
equality semantics for mutable collections.

Having a consistent equality and hashCode between mutable and
immutable collections makes it that much easier to use the
collection.* classes without having to worry about whether your
implementation is mutable or immutable (something which seems to be a
goal in the 2.8 redesign).

Further, having a working hashCode to go with the equality is both
required by the contract of hashCode and extremely useful. There are
many cases where it's perfectly safe to use a mutable collection as a
hash key (either because you know you're not mutating the keys or
because the hash is completely transient - e.g. for providing
efficient uniqueness filtering on a collection).

Sacrificing these use cases for conceptual purity (which I don't think
the UnsupportedOperationException approach achieves anyway) seems
undesirable.