Java Collections API Quirks

So we tend to think we’ve seen it all, when it comes to the Java Collections API. We know our ways around Lists, Sets, Maps, Iterables, Iterators. We’re ready for Java 8?s Collections API enhancements.

But then, every once in a while, we stumble upon one of these weird quirks that originate from the depths of the JDK and its long history of backwards-compatibility. Let’s have a look at unmodifiable collections

Unmodifiable Collections

Whether a collection is modifiable or not is not reflected by the Collections API. There
 
is no immutable List, Set or Collection base type, which mutable subtypes could extend. So, the following API doesn’t exist in the JDK:

// Immutable part of the Collection APIpublic interface Collection {  boolean  contains(Object o);  boolean  containsAll(Collection<?> c);  boolean  isEmpty();  int      size();  Object[] toArray();  <T> T[]  toArray(T[] array);}// Mutable part of the Collection APIpublic interface MutableCollection extends Collection {  boolean  add(E e);  boolean  addAll(Collection<? extends E> c);  void     clear();  boolean  remove(Object o);  boolean  removeAll(Collection<?> c);  boolean  retainAll(Collection<?> c);}

Now, there are probably reasons, why things hadn’t been implemented this way in the early days of Java. Most likely, mutability wasn’t seen as a feature worthy of occupying its own type in the type hierarchy. So, along came the Collections helper class, with useful methods such as unmodifiableList(), unmodifiableSet(), unmodifiableCollection(), and others. But beware when using unmodifiable collections! There is a very strange thing mentioned in the Javadoc: The returned collection does not pass the hashCode and equals operations through to the backing collection, but relies on Object’s equals and hashCode methods. This is necessary to preserve the contracts of these operations in the case that the backing collection is a set or a list. “To preserve the contracts of these operations”. That’s quite vague. What’s the reasoning behind it? A nice explanation is given in this Stack Overflow answer here:

An UnmodifiableList is an UnmodifiableCollection, but the same is not true in reverse — an UnmodifiableCollection that wraps a List is not an UnmodifiableList. So if you compare an UnmodifiableCollection that wraps a List a with an UnmodifiableList that wraps the same List a, the two wrappers should not be equal. If you just passed through to the wrapped list, they would be equal. While this reasoning is correct, the implications may be rather unexpected.

The bottom line

The bottom line is that you cannot rely on Collection.equals(). While List.equals() and Set.equals() are well-defined, don’t trust Collection.equals(). It may not behave meaningfully. Keep this in mind, when accepting a Collection in a method signature:

public class MyClass {  public void doStuff(Collection<?> collection) {    // Don't rely on collection.equals() here!  }}

Reference: Java Collections API Quirks from our JCG partner Lukas Eder at the JAVA, SQL, AND JOOQ blog.

Source : feedproxy[dot]google[dot]com