RFR [8014066] Mistake in documentation of ArrayList#removeRange (original) (raw)

Doug Lea dl at cs.oswego.edu
Fri Mar 14 11:42:07 UTC 2014

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.

-Doug

More information about the core-libs-dev mailing list