Why weren't the methods from Collections placed in AbstractCollection?

Question

I am wondering why the Collections class was created. Theoretically, the methods from this class can be placed in the AbstractCollection class. So what is the reason for creating a separate utils class?

Answer 1

• Not every collection extends AbstractCollection , and these methods are still applicable there.
• Too many methods in one class make it difficult to understand when you work your way through Javadoc.
• If you get a Collection from an untrusted caller, make sure you always use the same implementation, for example, unmodifiableCollection can be useful.
• In most cases, you do not track the exact type of collection implementation: for example, you write Set<E> set = new HashSet<>(); In this case, you cannot use any methods defined in AbstractCollection that are not in Collection .

Answer 2

You might want to implement an independent object that implements one of the Collection interfaces without the AbstractCollection extension.

For example: http://commons.apache.org/collections/api-release/org/apache/commons/collections/bag/HashBag.html

Answer 3

When JDK people decide that they want to add more methods to the Collections class, they just need to implement them. For example, newSetFromMap was added in 1.6. They cannot add more methods to the Collection interface and maintain backward compatibility, because, as Louis Wasserman said, not all collections extend AbstractCollection - in particular third-party ones, which are part of Guava, Commons Collections, Hibernate, OpenJPA, etc.

These are not many problems in languages ​​that have mixins instead of interfaces. Scala, for example, has a huge number of methods in its collections. So much, in fact, that you are faced with the problem of Louis Wasserman, the number two of which is hard to read javadoc (in this case, scaladoc.)