114

Does anyone have any idea, why removeRange method in AbstractList (and also in ArrayList) is protected? It looks like a quite well-defined and useful operation, but still, to use it, we're forced to subclass the List implementation.

Is there some hidden rationale? Seems quite inexplicable to me.

Joonas Pulakka
  • 36,252
  • 29
  • 106
  • 169

1 Answers1

182

Yes, because that's not how you remove a range from outside code. Instead, do this:

list.subList(start, end).clear();

This actually calls removeRange behind the scenes.


The OP asks why removeRange is not part of the List public API. The reason is described in Item 40 of Effective Java 2nd ed, and I quote it here:

There are three techniques for shortening overly long parameter lists. One is to break the method up into multiple methods, each of which requires only a subset of the parameters. If done carelessly, this can lead to too many methods, but it can also help reduce the method count by increasing orthogonality. For example, consider the java.util.List interface. It does not provide methods to find the first or last index of an element in a sublist, both of which would require three parameters. Instead it provides the subList method, which takes two parameters and returns a view of a sublist. This method can be combined with the indexOf or lastIndexOf methods, each of which has a single parameter, to yield the desired functionality. Moreover, the subList method can be combined with any method that operates on a List instance to perform arbitrary computations on sublists. The resulting API has a very high power-to-weight ratio.

One can argue that removeRange doesn't have that many parameters and is therefore probably not a candidate for this treatment, but given that there's a way to invoke removeRange through the subList, there is no reason to clutter up the List interface with a redundant method.


The AbstractList.removeRange documentation says:

This method is called by the clear operation on this list and its subLists. Overriding this method to take advantage of the internals of the list implementation can substantially improve the performance of the clear operation on this list and its subLists.

Also, see OpenJDK's implementation of AbstractList.clear and SubList.removeRange.

C. K. Young
  • 219,335
  • 46
  • 382
  • 435
  • 9
    Ok, it can done that way, but *why*? Seems awkward. Single elements can be removed from the list directly, why not multiple elements then? – Joonas Pulakka Feb 18 '10 at 14:22
  • 1
    @Joonas: Item 40 of Effective Java, 2nd ed describes the rationale for this. I'll paste in the relevant section in case you don't have the book. – C. K. Young Feb 18 '10 at 17:03
  • 1
    Thanks, exactly what I was looking for! Now it makes *some* sense :) – Joonas Pulakka Feb 18 '10 at 17:43
  • 22
    +1 (question answered). However, just because a rationale is given doesn't mean it makes sense. The process of shortening parameter lists hinders the ability of developers to understand operations available in an API, which works directly against the reason why the lists were shortened in the first place. – Sam Harwell Sep 21 '11 at 11:59
  • when using this method, how can i avoid "Cannot convert from List to ArrayList" – clankill3r Aug 31 '12 at 13:34
  • @clankill3r Do you have some example code? You should never need to convert to `ArrayList`. – C. K. Young Aug 31 '12 at 14:29
  • 6
    So typical for java. Let's make it most complicated and least effective. – Tomáš Zato Jun 17 '13 at 21:21
  • 1
    @vaxquis See [`AbstractList.clear`](http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/file/e2117e30fb39/src/share/classes/java/util/AbstractList.java#l233) and [`SubList.removeRange`](http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/file/e2117e30fb39/src/share/classes/java/util/AbstractList.java#l666). :-) – C. K. Young Feb 19 '16 at 14:18
  • 2
    as a side note, did you notice that `removeRange` calls `arraycopy` unnecessarily when the `ArrayList` version is used on a range spanning till the very end of the list? http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/file/e2117e30fb39/src/share/classes/java/util/ArrayList.java#l631 the `numMoved` is 0, so the entire arraycopy code could've been put into a single `if` (as done in `remove`); the difference is that a) arraycopy is a native call, incurring an overhead, b) arraycopy does *always* check params for correctness http://stackoverflow.com/questions/12594046/java-native-method-source-code –  Feb 19 '16 at 14:30
  • 1
    @vaxquis I've edited the post to add those links. Re `ArrayList.removeRange`, yeah, since the `numMoved > 0` check is already in `ArrayList.remove`, it should also be in `removeRange` for consistency. – C. K. Young Feb 19 '16 at 15:22