Why does the Collections class contain standalone (static) methods, instead of them being added to the List interface?

Question

For all the methods in Collections that take a List as their first argument, why aren't those methods simply part of the List interface?

My intuition is: given a List object, that object itself should "know" how to perform on itself operations such as rotate(), shuffle(), or reverse(). But instead, as a Java programmer, I have to review both the methods in the List interface, as well as the static methods "over there" in the Collections class, to ensure I'm using a canonical solution.

Why were some methods placed as static standalone methods in the Collections class, instead of being added to the List interface (and presumably thus implemented by some existing or would-be base class)?

I'm trying to better understand the design decisions behind the Java collections framework.

Is there some compelling OO design principle here that I'm overlooking? Or was this distinction done simply for some practical, performance reason?

Answer 1

The point is that given suitable primitive operations (remove, set etc) a bunch of more high level operations (sort, shuffle, binary search) can be implemented once rather than being implemented by every single list implementation.

Effectively, java.util.Collections is like .NET's Enumerable class - full of general purpose methods which can work on any collection, so that they can share a single implementation and avoid duplication.