I'm wondering why class Collections
was created. Theoritically methods from this class could be put in class AbstractCollection
. So what was the reason seperate utils class was created?

- 1,986
- 1
- 20
- 46
-
possible duplicate of [Difference between Java Collection and Collections](http://stackoverflow.com/questions/1796275/difference-between-java-collection-and-collections) – Andrew Marshall Mar 03 '12 at 00:02
-
3Not quite a duplicate. This is `Collections` vs. `AbstractCollection`. The linked question is `Collection` vs `Collections`. – Pursuit Mar 03 '12 at 00:06
3 Answers
- Not every collection extends
AbstractCollection
, and those methods are still applicable there. - Having too many methods in the same class makes it harder to understand that class when you're working your way through the Javadoc.
- If you're receiving an
Collection
from an untrusted caller, being sure that you're always using the same implementation of e.g.unmodifiableCollection
can be helpful. - Most of the time, you don't keep track of the exact implementation type of collections: for example, you write
Set<E> set = new HashSet<>();
In this case, you won't be able to use any methods defined inAbstractCollection
that aren't inCollection
.

- 191,574
- 25
- 345
- 413
-
Could you give an example which `Collection` class does not extends `AbstractCollection`? – mmatloka Mar 03 '12 at 00:06
-
I'm not sure there are any examples in the JDK, but third-party projects like [Guava](http://guava-libraries.googlecode.com) do it all the time: for example, the `ImmutableCollection` hierarchy and the `ForwardingCollection` hierarchy don't extend `AbstractCollection`. – Louis Wasserman Mar 03 '12 at 00:09
-
@mich, you could implement your own Collection which doesn't extend AbstractCollection. That would be an example of a non-AbstractCollection Collection. – Steve Kuo Mar 03 '12 at 00:26
There may be a time you want to implement an independent Object which implements the one of the Collection
interface, without extending AbstractCollection.
For example: http://commons.apache.org/collections/api-release/org/apache/commons/collections/bag/HashBag.html

- 12,285
- 1
- 25
- 41
-
Well, let's be fair: that's because `Bag` deliberately violates the `Collection` contract. – Louis Wasserman Mar 03 '12 at 23:32
When the JDK folks decide that they want to add more methods to the Collections class they simply have to implement them. newSetFromMap was added in 1.6, for example. They cannot add more methods to the Collection interface and maintain backwards compatibility because, as Louis Wasserman said, not all collections extend AbstractCollection - specifically the third party ones that are part of Guava, Commons Collections, Hibernate, OpenJPA, etc.
This isn't nearly as big of a problem in languages that have mixins instead of interfaces. Scala, for instance, has a huge number of methods on its collections. So many, in fact, that you run into Louis Wasserman's number two issue of difficult to read javadoc (scaladoc in this case.)

- 739
- 6
- 10