RFR (M): JDK-6394757: rev1: AbstractSet.removeAll semantics are surprisingly dependent on relative sizes

[Stuart Marks]

On 5/16/19 10:06 PM, Alan Snyder wrote:
> Could you explain the inconsistency in the specification that affects removeAll()? I don’t see it.

It's the assumption that the operation can be reversed without changing its 
semantics. This isn't true, given the existence of SortedSet et. al. This is the 
point of this bug report. The inconsistency exists in the collections framework 
specifications taken as a whole, not removeAll() in isolation.

> I believe I already accepted the fact of ersatz Collections.

Of course I don't know your state of mind, but it it doesn't sound to me like 
you've accepted them. You're calling them "ersatz" collections, which sound to 
me like "fake" collections. You're carving them out of "real" collections and 
treating them like second-class citizens. I would have thought that was an 
overstatement, until I read this:

> Promoting ersatz Collections to first class citizens would be a significant incompatible change...

My goal here is to reconcile the various parts of the collections framework 
specifications so that they are more self-consistent as a whole. Treating 
certain pieces as second-class citizens makes the problem worse, not better.

> What I would most like to preserve is the performance advantages of using hash coding, which apparently was a goal of the original design:
> 
> "implementations of the various Collections Framework interfaces are free to take advantage of the specified behavior of underlying {@link Object} methods wherever the implementor deems it appropriate"
> 
> Promoting ersatz Collections to first class citizens would be a significant incompatible change to the specification because it invalidates this statement.

My changes don't affect the relationship of equals() and hashCode() in the 
slightest.

s'marks