RFR: 8023339: (xs) Refine UOE conditions for removeIf()

[Mike Duigou]

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.duigou at 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
>> 
>