RFR [8014066] Mistake in documentation of ArrayList#removeRange

[David Holmes]

Hi Doug,

On 14/03/2014 9:42 PM, Doug Lea wrote:
> On 03/14/2014 02:38 AM, Martin Buchholz wrote:
>> On Thu, Mar 13, 2014 at 3:59 PM, Doug Lea <dl at cs.oswego.edu
>> <mailto:dl at cs.oswego.edu>> wrote:
>>     On 03/13/2014 12:34 PM, Martin Buchholz wrote:
>>         I notice there are zero jtreg tests for removeRange.  That
>> should be fixed.
>>
>>         I notice there is a removeRange in CopyOnWriteArrayList, but
>> it is
>>         package-private instead of "protected", which seems like an
>> oversight.
>>           Can Doug
>>         remember any history on that?
>>
>>
>>     CopyOnWriteArrayList does not extend AbstractList, but its
>>     sublist does. The sublist relies on COWAL.removeRange only for clear.
>>     So COWAL sublist clearing uses the same idea as
>>     AbstractList, and gives it the same name, but it is not the
>>     same AbstractList method, so need not be protected.
>>
>>
>> Ahh OK, I think the party line for *users* is if they want to remove a
>> range of
>> elements from a list, use list.subList(fromIndex, toIndex).clear (),
>> so there's
>> no advantage in making COWAL.removeRange a public interface.
>
> Right. This relates to the question of range checks for removeRange.
> Josh Block created removeRange as part of an incompletely documented
> recipe for AbstractList-based List implementations. It was intended that
> people creating new kinds of Lists implement this as a helper
> method to simplify sublist implementations. It is designed
> to be called only from other public methods that would either themselves
> perform range checks or skip them if statically unnecessary.
> So, there aren't any redundant checks in the default removeRange.
> Leaving this partially exposed as "protected" doesn't quite
> ensure that implementors follow this guidance, but in practice,
> I suspect that they all have. So it is not clear whether changing
> the spec or the implementation would be doing anyone a favor.

So what you are saying is that protected overrides of protected methods 
are not required to honor the specification of the super method?

That certainly gives some implementation flexibility, but I don't think 
I've ever seen it expressed as a rule.

David
-----

> -Doug
>
>
>