Hi Alan,
Whether you call them "ersatz" collections, "non-standard" collections, or
collections with different membership semantics, they have been around in the
collections framework from day one. This is perhaps unfortunate, and it may be
considered to be bad design, but it is a fact.
The issue is not with undefined or implementation-specific behavior. The issue
is that the specification as it stands is self-contradictory. In particular, it
assumes that certain operations are symmetric that in fact are not, if you read
other parts of the spec and derive logical conclusions from them. This is what
I'm trying to fix. This is not a mere a matter of intellectual consistency. This
state of affairs has real consequences. There is a whole family of bugs linked
to this one which complain both about the performance issue and the semantic
issue. All of these bugs are directly related to the self-contradictory nature
of the current specification. With my changes, the spec is self-contradictory in
fewer places. (There is, however, more work to be done; see JDK-8190545.)
Your lead point, though, is about performance. The performance optimization of
AbstractSet.removeAll is one of those that assumes that the operation is
symmetric, when in fact it isn't. As a rule, optimizations mustn't change
semantics. Therefore, it has to go.
s'marks
