I think this is a reasonable compromise (and will be what I use for the other cases).
Thanks! Mike On Sep 16 2013, at 01:13 , Paul Sandoz wrote: > Hi Mike, > > I suppose there could also be implementations of removeIf that always throw > UOE regardless of whether an element matched or not i.e. those that override > just to throw UOE. > > So perhaps: > > * @throws UnsupportedOperationException if elements cannot be removed > * from this collection. Implementations may throw this exception if a > * matching element cannot be removed or if, in general, removal is > not > * supported. > > Paul. > > On Sep 13, 2013, at 11:52 PM, Mike Duigou <mike.dui...@oracle.com> wrote: > >> Hello all; >> >> A very small patch that refines the declared conditions under which the >> Collection.removeIf() method will throw UOE. The intent of this patch is to >> allow the default implementation to be used for immutable collections. It's >> important that the default implementations provided and the specifications >> of the methods allow for the behaviour which results from using the default >> method implementation on any reasonable implementation including immutable >> implementations. In this case there was a bug originally written against >> j.u.Arrays.asList() The bug asserted that it's removeIf() implementation was >> "lazy" and only throws UOE when an element is to be removed. One possible >> solution was to add a non-default implementation of removeIf() to the >> Arrays.asList()-List. Since the default method definition must also satisfy >> other potential immutable implementations we decided to enhance the UOE >> conditions rather than paper over the problem by adding a default. >> >> (There are a couple of other similar issues which will have similar >> solutions) >> >> http://cr.openjdk.java.net/~mduigou/JDK-8023339/1/ >> >> Mike >> >
