Ndtyjky

What you are looking for is called covariant type parameters. This means that if one type of object can be substituted for another in a method (for instance, Animal can be replaced with Dog), the same applies to expressions using those objects (so List<Animal> could be replaced with List<Dog>). The problem is that covariance is not safe for mutable lists in general. Suppose you have a List<Dog>, and it is being used as a List<Animal>. What happens when you try to add a Cat to this List<Animal> which is really a List<Dog>? Automatically allowing type parameters to be covariant breaks the type system.

It would be useful to add syntax to allow type parameters to be specified as covariant, which avoids the ? extends Foo in method declarations, but that does add additional complexity.

The reason a List<Dog> is not a List<Animal>, is that, for example, you can insert a Cat into a List<Animal>, but not into a List<Dog>... you can use wildcards to make generics more extensible where possible; for example, reading from a List<Dog> is the similar to reading from a List<Animal> -- but not writing.

The Generics in the Java Language and the Section on Generics from the Java Tutorials have a very good, in-depth explanation as to why some things are or are not polymorphic or permitted with generics.

I would say the whole point of Generics is that it doesn't allow that. Consider the situation with arrays, which do allow that type of covariance:

  Object objects = new String[10];

  objects[0] = Boolean.FALSE;

That code compiles fine, but throws a runtime error (java.lang.ArrayStoreException: java.lang.Boolean in the second line). It is not typesafe. The point of Generics is to add the compile time type safety, otherwise you could just stick with a plain class without generics.

Now there are times where you need to be more flexible and that is what the ? super Class and ? extends Class are for. The former is when you need to insert into a type Collection (for example), and the latter is for when you need to read from it, in a type safe manner. But the only way to do both at the same time is to have a specific type.

A point I think should be added to what other answers mention is that while

List<Dog> isn't-a List<Animal> in Java

it is also true that

A list of dogs is-a list of animals in English (well, under a reasonable interpretation)

The way the OP's intuition works - which is completely valid of course - is the latter sentence. However, if we apply this intuition we get a language that is not Java-esque in its type system: Suppose our language does allow adding a cat to our list of dogs. What would that mean? It would mean that the list ceases to be a list of dogs, and remains merely a list of animals. And a list of mammals, and a list of quadrapeds.

To put it another way: A List<Dog> in Java does not mean "a list of dogs" in English, it means "a list which can have dogs, and nothing else".

More generally, OP's intuition lends itself towards a language in which operations on objects can change their type, or rather, an object's type(s) is a (dynamic) function of its value.

To understand the problem it's useful to make comparison to arrays.

List<Dog> is not subclass of List<Animal>.
But Dog is subclass of Animal.

Arrays are reifiable and covariant.
Reifiable means their type information is fully available at runtime.
Therefore arrays provide runtime type safety but not compile-time type safety.

    // All compiles but throws ArrayStoreException at runtime at last line

    Dog dogs = new Dog[10];

    Animal animals = dogs; // compiles

    animals[0] = new Cat(); // throws ArrayStoreException at runtime

It's vice versa for generics:
Generics are erased and invariant.
Therefore generics can't provide runtime type safety, but they provide compile-time type safety.
In the code below if generics were covariant it will be possible to make heap pollution at line 3.

    List<Dog> dogs = new ArrayList<>();

    List<Animal> animals = dogs; // compile-time error, otherwise heap pollution

    animals.add(new Cat());

The answers given here didn't fully convince me. So instead, I make another example.

public void passOn(Consumer<Animal> consumer, Supplier<Animal> supplier) {

    consumer.accept(supplier.get());

}

sounds fine, doesn't it? But you can only pass Consumers and Suppliers for Animals. If you have a Mammal consumer, but a Duck supplier, they should not fit although both are animals. In order to disallow this, additional restrictions have been added.

Instead of the above, we have to define relationships between the types we use.

E. g.,

public <A extends Animal> void passOn(Consumer<A> consumer, Supplier<? extends A> supplier) {

    consumer.accept(supplier.get());

}

makes sure that we can only use a supplier which provides us the right type of object for the consumer.

OTOH, we could as well do

public <A extends Animal> void passOn(Consumer<? super A> consumer, Supplier<A> supplier) {

    consumer.accept(supplier.get());

}

where we go the other way: we define the type of the Supplier and restrict that it can be put into the Consumer.

We even can do

public <A extends Animal> void passOn(Consumer<? super A> consumer, Supplier<? extends A> supplier) {

    consumer.accept(supplier.get());

}

where, having the intuitive relations Life -> Animal -> Mammal -> Dog, Cat etc., we could even put a Mammal into a Life consumer, but not a String into a Life consumer.

The basis logic for such behavior is that Generics follow a mechanism of type erasure. So at run time you have no way if identifying the type of collection unlike arrays where there is no such erasure process. So coming back to your question...

So suppose there is a method as given below:

add(List<Animal>){

    //You can add List<Dog or List<Cat> and this will compile as per rules of polymorphism

}

Now if java allows caller to add List of type Animal to this method then you might add wrong thing into collection and at run time too it will run due to type erasure. While in case of arrays you will get a run time exception for such scenarios...

Thus in essence this behavior is implemented so that one cannot add wrong thing into collection. Now I believe type erasure exists so as to give compatibility with legacy java without generics....

Actually you can use an interface to achieve what you want.

public interface Animal {

    String getName();

    String getVoice();

}

public class Dog implements Animal{

    @Override 

    String getName(){return "Dog";}

    @Override

    String getVoice(){return "woof!";}

}

you can then use the collections using

List <Animal> animalGroup = new ArrayList<Animal>();

animalGroup.add(new Dog());

If you are sure that the list items are subclasses of that given super type you can cast the list using this approach:

(List<Animal>) (List<?>) dogs

This is usefull when you want to pass the list in a constructor or iterate over it

The answer as well as other answers are correct. I am going to add to those answers with a solution that I think will be helpful. I think this comes up often in programming. One thing to note is that for Collections (Lists, Sets, etc.) the main issue is adding to the Collection. That is where things break down. Even removing is OK.

In most cases, we can use Collection<? extends T> rather then Collection<T> and that should be the first choice. However, I am finding cases where it is not easy to do that. It is up for debate as to whether that is always the best thing to do. I am presenting here a class DownCastCollection that can take convert a Collection<? extends T> to a Collection<T> (we can define similar classes for List, Set, NavigableSet,..) to be used when using the standard approach is very inconvenient. Below is an example of how to use it (we could also use Collection<? extends Object> in this case, but I am keeping it simple to illustrate using DownCastCollection.

/**Could use Collection<? extends Object> and that is the better choice. 

* But I am doing this to illustrate how to use DownCastCollection. **/



public static void print(Collection<Object> col){  

    for(Object obj : col){

    System.out.println(obj);

    }

}

public static void main(String args){

  ArrayList<String> list = new ArrayList<>();

  list.addAll(Arrays.asList("a","b","c"));

  print(new DownCastCollection<Object>(list));

}

Now the 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> {

private Collection<? extends E> delegate;



public DownCastCollection(Collection<? extends E> delegate) {

    super();

    this.delegate = delegate;

}



@Override

public int size() {

    return delegate ==null ? 0 : delegate.size();

}



@Override

public boolean isEmpty() {

    return delegate==null || delegate.isEmpty();

}



@Override

public boolean contains(Object o) {

    if(isEmpty()) return false;

    return delegate.contains(o);

}

private class MyIterator implements Iterator<E>{

    Iterator<? extends E> delegateIterator;



    protected MyIterator() {

        super();

        this.delegateIterator = delegate == null ? null :delegate.iterator();

    }



    @Override

    public boolean hasNext() {

        return delegateIterator != null && delegateIterator.hasNext();

    }



    @Override

    public  E next() {

        if(!hasNext()) throw new NoSuchElementException("The iterator is empty");

        return delegateIterator.next();

    }



    @Override

    public void remove() {

        delegateIterator.remove();



    }



}

@Override

public Iterator<E> iterator() {

    return new MyIterator();

}







@Override

public boolean add(E e) {

    throw new UnsupportedOperationException();

}



@Override

public boolean remove(Object o) {

    if(delegate == null) return false;

    return delegate.remove(o);

}



@Override

public boolean containsAll(Collection<?> c) {

    if(delegate==null) return false;

    return delegate.containsAll(c);

}



@Override

public boolean addAll(Collection<? extends E> c) {

    throw new UnsupportedOperationException();

}



@Override

public boolean removeAll(Collection<?> c) {

    if(delegate == null) return false;

    return delegate.removeAll(c);

}



@Override

public boolean retainAll(Collection<?> c) {

    if(delegate == null) return false;

    return delegate.retainAll(c);

}



@Override

public void clear() {

    if(delegate == null) return;

        delegate.clear();



}

}

Subtyping is invariant for parameterized types. Even tough the class Dog is a subtype of Animal, the parameterized type List<Dog> is not a subtype of List<Animal>. In contrast, covariant subtyping is used by arrays, so the array
type Dog is a subtype of Animal.

Invariant subtyping ensures that the type constraints enforced by Java are not violated. Consider the following code given by @Jon Skeet:

List<Dog> dogs = new ArrayList<Dog>(1);

List<Animal> animals = dogs;

animals.add(new Cat()); // compile-time error

Dog dog = dogs.get(0);

As stated by @Jon Skeet, this code is illegal, because otherwise it would violate the type constraints by returning a cat when a dog expected.

It is instructive to compare the above to analogous code for arrays.

Dog dogs = new Dog[1];

Object animals = dogs;

animals[0] = new Cat(); // run-time error

Dog dog = dogs[0];

The code is legal. However, throws an array store exception.
An array carries its type at run-time this way JVM can enforce
type safety of covariant subtyping.

To understand this further let's look at the bytecode generated by javap of the class below:

import java.util.ArrayList;

import java.util.List;



public class Demonstration {

    public void normal() {

        List normal = new ArrayList(1);

        normal.add("lorem ipsum");

    }



    public void parameterized() {

        List<String> parameterized = new ArrayList<>(1);

        parameterized.add("lorem ipsum");

    }

}

Using the command javap -c Demonstration, this shows the following Java bytecode:

Compiled from "Demonstration.java"

public class Demonstration {

  public Demonstration();

    Code:

       0: aload_0

       1: invokespecial #1                  // Method java/lang/Object."<init>":()V

       4: return



  public void normal();

    Code:

       0: new           #2                  // class java/util/ArrayList

       3: dup

       4: iconst_1

       5: invokespecial #3                  // Method java/util/ArrayList."<init>":(I)V

       8: astore_1

       9: aload_1

      10: ldc           #4                  // String lorem ipsum

      12: invokeinterface #5,  2            // InterfaceMethod java/util/List.add:(Ljava/lang/Object;)Z

      17: pop

      18: return



  public void parameterized();

    Code:

       0: new           #2                  // class java/util/ArrayList

       3: dup

       4: iconst_1

       5: invokespecial #3                  // Method java/util/ArrayList."<init>":(I)V

       8: astore_1

       9: aload_1

      10: ldc           #4                  // String lorem ipsum

      12: invokeinterface #5,  2            // InterfaceMethod java/util/List.add:(Ljava/lang/Object;)Z

      17: pop

      18: return

}

Observe that the translated code of method bodies are identical. Compiler replaced each parameterized type by its erasure. This property is crucial meaning that it did not break backwards compatibility.

In conclusion, run-time safety is not possible for parameterized types, since compiler replaces each parameterized type by its erasure. This makes parameterized types are nothing more than syntactic sugar.

Lets take the example from JavaSE tutorial

public abstract class Shape {

    public abstract void draw(Canvas c);

}



public class Circle extends Shape {

    private int x, y, radius;

    public void draw(Canvas c) {

        ...

    }

}



public class Rectangle extends Shape {

    private int x, y, width, height;

    public void draw(Canvas c) {

        ...

    }

}

So why a list of dogs (circles) should not be considered implicitly a list of animals (shapes) is because of this situation:

// drawAll method call

drawAll(circleList);





public void drawAll(List<Shape> shapes) {

   shapes.add(new Rectangle());    

}

So Java "architects" had 2 options which address this problem:

1. do not consider that a subtype is implicitly it's supertype, and give a compile error, like it happens now




2. consider the subtype to be it's supertype and restrict at compile the "add" method (so in the drawAll method, if a list of circles, subtype of shape, would be passed, the compiler should detected that and restrict you with compile error into doing that).

For obvious reasons, that chose the first way.

We should also take in consideration how the compiler threats the generic classes: in "instantiates" a different type whenever we fill the generic arguments.

Thus we have ListOfAnimal, ListOfDog, ListOfCat, etc, which are distinct classes that end up being "created" by the compiler when we specify the generic arguments. And this is a flat hierarchy (actually regarding to List is not a hierarchy at all).

Another argument why covariance doesn't make sense in case of generic classes is the fact that at base all classes are the same - are List instances. Specialising a List by filling the generic argument doesn't extend the class, it just makes it work for that particular generic argument.

The problem has been well-identified. But there's a solution; make doSomething generic:

<T extends Animal> void doSomething<List<T> animals) {

}

now you can call doSomething with either List<Dog> or List<Cat> or List<Animal>.

another solution is to build a new list

List<Dog> dogs = new ArrayList<Dog>(); 

List<Animal> animals = new ArrayList<Animal>(dogs);

animals.add(new Cat());