Porque é que List <Number> não um sub-tipo de List <Ob

Considere se fosse ...

List<Integer> nums = new ArrayList<Integer>();
List<Object> objs = nums
objs.add("Oh no!");
int x = nums.get(0); //throws ClassCastException

Você seria capaz de adicionar qualquer coisa do tipo pai para a lista, que pode não ser o que foi anteriormente declarado como, que, como o exemplo acima demonstra, faz com que todos os tipos de problemas. Assim, não é permitido.

Não são subtipos do outro devido como genéricos trabalho. O que você quer é declarar a sua função como esta:

public void wahey(List<?> list) {}

Em seguida, ele vai aceitar uma lista de tudo que se estende objeto. Você também pode fazer:

public void wahey(List<? extends Number> list) {}

Isso permitirá que você tomar em Listas de algo que é uma subclasse de Number.

Eu recomendo que você pegar uma cópia de "Java Generics e Coleções", de Maurice Naftalin & Philip Wadler.

Existem essencialmente duas dimensões de abstração aqui, a lista de abstração e a abstração de seus conteúdos. É perfeitamente possível variar ao longo da lista de abstração - para dizer, por exemplo, que é um LinkedList ou um ArrayList - mas não é bom para restringir ainda mais o conteúdo, a dizer: Este (lista que contém objetos) é um (lista encadeada que detém apenas números). Porque qualquer referência que sabe como (lista que contém objetos) compreende, pelo contrato de seu tipo, que pode conter qualquer objeto.

Este é bastante diferente do que você tem feito no exemplo de código não-genéricos, onde você disse: tratar esta String como se fosse um duplo. Você está em vez tentando dizer: tratar este assunto (lista que contém apenas números) como um (lista que detém nada). E isso não acontecer, eo compilador pode detectá-lo, para que ele não deixá-lo fugir com ele.

"O que estamos fazendo aqui é essencialmente a mesma coisa, exceto que isso vai passar verificações de tempo de compilação e só não a tempo de execução. A versão com listas não compilar. "

O que você está observando faz todo o sentido quando se considera que o principal objetivo dos genéricos Java é fazer com que tipo incompatibilidades a falhar em tempo de compilação em vez de tempo de execução.

A partir java.sun.com

Os genéricos fornece uma maneira para você comunicar o tipo de uma coleção para o compilador, de modo que possa ser verificado. Uma vez que o compilador sabe o tipo de elemento de recolha, o compilador pode verificar que você tenha usado a coleta de forma consistente e lata inserir os moldes correctas sobre valores sendo retirado da coleção.

Em Java, List<S> não é um subtipo de List<T> quando S é um subtipo de T. Essa regra fornece segurança de tipos.

Vamos dizer que permitir que um List<String> ser um subtipo de List<Object>. Considere o seguinte exemplo:

public void foo(List<Object> objects) {
    objects.add(new Integer(42));
}

List<String> strings = new ArrayList<String>();
strings.add("my string");
foo(strings); // this is not allow in java
// now strings has a string and an integer!
// what would happen if we do the following...??
String myString = strings.get(1);

Assim, forçando este fornece segurança de tipos, mas também tem uma desvantagem, é menos flexível. Considere o seguinte exemplo:

class MyCollection<T> {
    public void addAll(Collection<T> otherCollection) {
        ...
    }
}

Aqui você tem uma coleção de T de, você quer adicionar todos os itens de outra coleção. Você não pode chamar esse método com um Collection<S> para um subtipo S de T. Idealmente, isso é ok, porque você só está adicionando elementos em sua coleção, você não está modificando a coleção de parâmetros.

Para corrigir isso, Java fornece o que eles chamam de "wildcards". Wildcards são uma forma de prestação de covariância / contravariance. Agora, considere o seguinte usando wildcards:

class MyCollection<T> {
     // Now we allow all types S that are a subtype of T
     public void addAll(Collection<? extends T> otherCollection) {
         ...

         otherCollection.add(new S()); // ERROR! not allowed (Here S is a subtype of T)
     }
}

Agora, com wildcards nós permitimos covariância no tipo T e nós bloquear operações que não são do tipo seguro (por exemplo, adicionar um item na coleção). Desta forma, temos flexibilidade e tipo de segurança.