RFR: 8001647: In-place methods on Collection/List (original) (raw)

David Holmes david.holmes at oracle.com
Fri Apr 19 05:42:15 PDT 2013

On 19/04/2013 10:14 PM, Paul Sandoz wrote:

On Apr 19, 2013, at 1:15 PM, Alan Bateman <Alan.Bateman at oracle.com> wrote:

On 18/04/2013 19:49, Akhil Arora wrote: Looks like the stars are aligning on getting on this into TL... the refreshed webrev is -

http://cr.openjdk.java.net/~akhil/8001647.8/webrev/ A minor comment on Collection.removeIf is "that satisifies the given predicate" might be better than "which matches the provided predicate". Also for completeness, you could say "RuntimeExceptions and Errors thrown by the predicate are propagated ...". In List.replaceAll then @throws NullPointerException is listed twice, which is okay, but might be better to combine them. A typo in the second NPE description "if the an element". In the implementation then the only thing that puzzled me is checking the modification count in legacy Vector, that seems unnecessary. The function value could structurally modify the Vector instance.

So this came through while I was writing my similar comments ...

My reaction to this is simply "well don't do that". If the function/predicate/comparator is mutating the Vector then the user gets what they deserve in my opinion. Trying to account for that is somewhat futile. As per my other email the loop check for modCount==expectedModCount will get hoisted from the loop. Further in removeIf you need to be a lot more defensive during the first iteration as you haven't kept a reference to the original size and array. That aside the second part of removeIf (the actual removal) doesn't invoke any external code so no concurrent modification is possible then.

This seems like overkill to me.

Cheers, David

Paul.

More information about the lambda-dev mailing list