Are there scenarios in which "Down casting" Collection to Collection makes sense

Question

The stackoverflow question: Is List<Dog> a subclass of List<Animal>? Why aren't Java's generics implicitly polymorphic? has many correct answers that point out that you can add a Cat to List<Animal> but not to List<Dog>. This leads to the use of constructs like List<? extends Animal>. I have found that there are cases where this is just not convenient and therefore I have defined classes to "down cast" the collection. (See below for an example of DownCastCollection). My question is whether you can present some cases where the best approach is to downcast? If you think it is never the best approach then can you explain why? I realize this is a bit open ended but I think the answers may be very helpful since this situation is common. I do agree that in most cases we should use the `Collection, but I am pointing out that sometimes that is just not the best approach. Have you encountered examples where this is not the best approach and if so can you present them here?

Based on the answer in https://stackoverflow.com/a/27491199/4350148 i have changed DownCastCollection to be modifiable and so now it does not return an error. The question still is valid.

Here is the downcast collection class:

import java.util.AbstractCollection;
import java.util.Collection;
import java.util.Iterator;
import java.util.NoSuchElementException;

public class DownCastCollection<E> extends AbstractCollection<E> implements Collection<E> {
@SuppressWarnings("rawtypes")
private Collection delegate;

public DownCastCollection(Collection<? extends E> delegate) {
    if(delegate == null) throw new IllegalArgumentException();
    this.delegate = delegate;
}

@Override
public int size() {
    return delegate.size();
}

@Override
public boolean isEmpty() {
    return delegate.isEmpty();
}

@Override
public boolean contains(Object o) {
    return delegate.contains(o);
}
private class MyIterator implements Iterator<E>{
    @SuppressWarnings("rawtypes")
    Iterator delegateIterator;

    protected MyIterator() {
        super();
        this.delegateIterator = delegate.iterator();
    }

    @Override
    public boolean hasNext() {
        return delegateIterator.hasNext();
    }

    @SuppressWarnings("unchecked")
    @Override
    public  E next() {
            return (E)delegateIterator.next();
    }

    @Override
    public void remove() {
        delegateIterator.remove();

    }

}
@Override
public Iterator<E> iterator() {
    return new MyIterator();
}



@SuppressWarnings("unchecked")
@Override
public boolean add(E e) {
    return delegate.add(e);
}

@Override
public boolean remove(Object o) {
    return delegate.remove(o);
}

@SuppressWarnings("unchecked")
@Override
public boolean containsAll(Collection<?> c) {
        return delegate.containsAll(c);
}

@SuppressWarnings("unchecked")
@Override
public boolean addAll(Collection<? extends E> c) {
    return delegate.addAll(c);
}

@SuppressWarnings("unchecked")
@Override
public boolean removeAll(Collection<?> c) {
        return delegate.removeAll(c);
}

@SuppressWarnings("unchecked")
@Override
public boolean retainAll(Collection<?> c) {
        return delegate.retainAll(c);
}

@Override
public void clear() {
    if(delegate == null) return;
        delegate.clear();

}

Answer 1

Collections.unmodifiableCollection and its friends are built-in ways to view a Collection<? extends T> as a Collection<T>. They resolve exactly the issue you have correctly identified, that elements can be added to a Collection<T> that cannot be added to a Collection<? extends T>, by forbidding additions or any sort of modification.

Other solutions to this problem include not depending on the implementation details of the underlying objects, forbidding addition but not removal, or making copies.

Finally, for what it's worth, your solution is exactly as type-safe, but less efficient, than simply casting your collection (Collection<E>) (Collection) collection, which takes advantage of erasure to simply (and unsafely) cast the backing collection.

Answer 2

With a collection of a generic type ? extends E, it is not legal to add new elements as the compiler cannot verify the exact type of the collection that your variable points to. Instead, the compiler can only tell that the collection represents any collection of subtypes of E. Thus:

Collection<? extends Something> collection = ...
collection.add(new Something());

does not compile. With your version of a DownCastCollection, the example would compile but instead throw a runtime exception. You migrate a compile-time error to become a runtime error. This is not a good idea as it introduces potential errors to your application that your compiler could otherwise catch.

The only reason when casting a generic collection makes sense would be when you for some reason know the actual type of the collection but you were not able to express this by your program's types. Better that a cast is normally to create a new collection:

Collection<? extends Something> collection = ...
Collection<Something> other = new HashSet<>(collection);

Answer 3

I usually use List<? extends T> if I have a superclass or interface that should allow its subclasses or implementations to specify the return value of a method more precisely.

Given you have the following interface.

public interface Foo {
    public List<CharSequence> doSomething();
}

If you now want to create a class Bar implements Foo, the method signature of doSomething() will have to be List<CharSequence> doSomething() and nothing else.

However, if you define doSomething() like this...

public interface Foo {
    public List<? extends CharSequence> doSomething();
}

Bar's doSomething() might have a method signature that looks like this.

public class Bar implements Foo {
    public List<String> doSomething() {
        // ...
    }
}

Besides that, you should also pay attention to what @raphw said, you can't add elements to a List<?> or List<? extends T>.

Answer 4

Here is a scenario where the DownCastCollection class is useful. Suppose I have an interface (lets call it IFace) that has a method that returns Collection<Result>. Suppose that Impl is an implementation of IFace. In order to compute the Collection of Results for the method, Impl uses a particular implementation of the Result interface, called ResultImpl and maintains a list of Collection<ResultImpl>. ResultImpl has methods that are not part of the interface and hence maintaining Collection<Result> in that method does not work without casting up. My implementation of the method needs to return Collection<Result> from the Collection<ResultImpl> and this is where the DownCastCollection is useful. You might argue that the method can return Collection<? extends Result> however, that would alter the interface IFace. In other words the method wants the guarantee that Collection<Result> is returned. We may also want to allow the caller of the method to modify the final result by adding to it or removing from it. In that case we still need the returned result to be modifiable.