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

[Stuart Marks]

On 5/7/19 4:33 PM, Brent Christian wrote:
> Collection.java:
> 
>   110  * that use different membership semantics. For operations that involve 
> more than
>   111  * one collection, it is specified which collection's membership semantics 
> are
>   112  * used by the operation.
> 
> addAll() and copyOf() involve more than one collection, though I agree that they 
> do not need to be updated to specify membership semantics.

Yeah. Maybe I can be more specific here... operations that involve membership in 
both collections, or something.

> AbstractCollection.java:
> 
> 
> 404 * obtaining an iterator from the {@code iterator} method. Each element
> 405 * is passed to the {@code contains} method of the specified collection.
> 406 * If this call returns {@code false}, the element is removed from
>           ^^^^^^^^^
> 
> Is "this call" a little ambiguous?  Maybe:
> 
> "If contains() returns false..."
> or
> "If false is returned..."
> 
> ?

Yeah I agree it's a bit clumsy. I'll tweak it to be better.

> List.java:
> 
> Should containsAll(), removeAll(), retainAll() have the @implNote about 
> contains() performance?

Good question.

I started to go and add them, but then I thought that it didn't make sense. 
List.contains() is almost unavoidably linear in performance -- at least our 
built-in List implementations are -- so the note on containsAll() is mostly 
pointless.

However, the bulk removals (removeAll and retainAll) on ArrayList are optimized 
to make a single pass over the list elements (i.e., they don't do repeated 
copying) so the performance of contains() on the specified collection is indeed 
relevant. I'll add the notes to those methods.

s'marks