Por que as matrizes são covariantes, mas os genéricos são invariantes?

Do Effective Java de Joshua Bloch,

1. Matrizes diferem do tipo genérico de duas maneiras importantes. As primeiras matrizes são covariantes. Os genéricos são invariantes.

2. Covariante significa simplesmente se X é subtipo de Y, então X [] também será subtipo de Y []. Matrizes são covariantes Como string é o subtipo de Object So

   String[] is subtype of Object[]

   Invariante significa simplesmente, independentemente de X ser subtipo de Y ou não,

    List<X> will not be subType of List<Y>.

Minha pergunta é por que a decisão de fazer matrizes covariantes em Java? Existem outras postagens de SO, como Por que as matrizes são invariáveis, mas as listas são covariantes? , mas eles parecem estar focados em Scala e eu não consigo acompanhar.

Via wikipedia :

As versões anteriores do Java e C # não incluíam genéricos (também conhecido como polimorfismo paramétrico).

Nesse cenário, a criação de matrizes invariáveis ​​exclui programas polimórficos úteis. Por exemplo, considere escrever uma função para embaralhar uma matriz ou uma função que testa duas matrizes quanto à igualdade usando o Object.equalsmétodo nos elementos. A implementação não depende do tipo exato de elemento armazenado na matriz, portanto, deve ser possível escrever uma única função que funcione em todos os tipos de matrizes. É fácil implementar funções do tipo

boolean equalArrays (Object[] a1, Object[] a2);
void shuffleArray(Object[] a);

No entanto, se os tipos de matriz fossem tratados como invariantes, só seria possível chamar essas funções em uma matriz exatamente do tipo Object[]. Não se pode, por exemplo, embaralhar uma série de strings.

Portanto, Java e C # tratam os tipos de matriz de forma covariável. Por exemplo, em C # string[]é um subtipo de object[]e em Java String[]é um subtipo de Object[].

Isso responde à pergunta "Por que as matrizes são covariantes?" Ou, mais precisamente, "Por que as matrizes foram feitas covariantes na época ?"

Quando os genéricos foram introduzidos, eles não foram propositalmente tornados covariantes pelas razões apontadas nesta resposta por Jon Skeet :

Não, a List<Dog>não é a List<Animal>. Considere o que você pode fazer com um List<Animal>- você pode adicionar qualquer animal a ele ... incluindo um gato. Agora, você pode adicionar logicamente um gato a uma ninhada de filhotes? Absolutamente não.

// Illegal code - because otherwise life would be Bad
List<Dog> dogs = new List<Dog>();
List<Animal> animals = dogs; // Awooga awooga
animals.add(new Cat());
Dog dog = dogs.get(0); // This should be safe, right?

De repente você tem um gato muito confuso.

A motivação original para tornar as matrizes covariantes descritas no artigo da wikipedia não se aplicava aos genéricos, porque os curingas tornaram possível a expressão de covariância (e contravariância), por exemplo:

boolean equalLists(List<?> l1, List<?> l2);
void shuffleList(List<?> l);

O motivo é que toda matriz conhece seu tipo de elemento durante o tempo de execução, enquanto a coleta genérica não sabe por causa do apagamento do tipo.

Por exemplo:

String[] strings = new String[2];
Object[] objects = strings;  // valid, String[] is Object[]
objects[0] = 12; // error, would cause java.lang.ArrayStoreException: java.lang.Integer during runtime

Se isso foi permitido com coleções genéricas:

List<String> strings = new ArrayList<String>();
List<Object> objects = strings;  // let's say it is valid
objects.add(12);  // invalid, Integer should not be put into List<String> but there is no information during runtime to catch this

Mas isso causaria problemas mais tarde, quando alguém tentaria acessar a lista:

String first = strings.get(0); // would cause ClassCastException, trying to assign 12 to String

Pode ser esta ajuda: -

Os genéricos não são covariantes

Matrizes na linguagem Java são covariantes - o que significa que, se Inteiro estender Number (o que ele faz), além de um Inteiro também ser um Número, um Inteiro [] também será um Number[], e você poderá passar ou atribuir um número inteiro. Integer[]onde a Number[]é chamado. (Mais formalmente, se Number é um supertipo de Inteiro, então Number[]é um supertipo de Integer[].) Você também pode pensar o mesmo para tipos genéricos - que List<Number>é um supertipo List<Integer>e que você pode passar para List<Integer>onde List<Number>é esperado. Infelizmente, não funciona dessa maneira.

Acontece que há uma boa razão para que não funcione dessa maneira: quebraria o tipo que os genéricos de segurança deveriam fornecer. Imagine que você poderia atribuir a List<Integer>a a List<Number>. Em seguida, o código a seguir permitiria colocar algo que não era um número inteiro em um List<Integer>:

List<Integer> li = new ArrayList<Integer>();
List<Number> ln = li; // illegal
ln.add(new Float(3.1415));

Como ln é a List<Number>, adicionar um float a ele parece perfeitamente legal. Mas se ln estivesse com um alias li, isso quebraria a promessa de segurança de tipo implícita na definição de li - que é uma lista de números inteiros, e é por isso que tipos genéricos não podem ser covariantes.

As matrizes são covariantes por pelo menos dois motivos:

• É útil para coleções que contêm informações que nunca serão alteradas para serem covariantes. Para que uma coleção de T seja covariante, sua loja de apoio também deve ser covariante. Embora se possa projetar uma Tcoleção imutável que não a use T[]como repositório (por exemplo, usando uma árvore ou uma lista vinculada), é improvável que essa coleção funcione tão bem quanto uma que é apoiada por uma matriz. Alguém poderia argumentar que uma maneira melhor de fornecer coleções imutáveis ​​covariantes seria definir um tipo de "matriz imutável covariante" que eles pudessem usar em uma loja de apoio, mas simplesmente permitir a covariância da matriz era provavelmente mais fácil.

• As matrizes serão frequentemente alteradas por código que não sabe que tipo de coisa haverá nelas, mas não colocará na matriz nada que não tenha sido lido nessa mesma matriz. Um excelente exemplo disso é o código de classificação. Conceitualmente, pode ter sido possível para os tipos de matriz incluir métodos para trocar ou permutar elementos (esses métodos podem ser igualmente aplicáveis ​​a qualquer tipo de matriz) ou definir um objeto "manipulador de matriz" que faça referência a uma matriz e uma ou mais coisas que foram lidas a partir dele e podem incluir métodos para armazenar itens lidos anteriormente na matriz da qual eles vieram. Se as matrizes não fossem covariantes, o código do usuário não seria capaz de definir esse tipo, mas o tempo de execução poderia ter incluído alguns métodos especializados.

O fato de que as matrizes são covariantes pode ser visto como um truque feio, mas na maioria dos casos, facilita a criação de código funcional.

Uma característica importante dos tipos paramétricos é a capacidade de escrever algoritmos polimórficos, ou seja, algoritmos que operam em uma estrutura de dados independentemente do seu valor de parâmetro, como Arrays.sort() .

Com genéricos, isso é feito com tipos curinga:

<E extends Comparable<E>> void sort(E[]);

Para ser realmente útil, os tipos de caracteres curinga requerem captura de caracteres curinga, e isso requer a noção de um parâmetro de tipo. Nada disso estava disponível no momento em que as matrizes foram adicionadas ao Java, e as matrizes de makes do tipo covariante de referência permitiram uma maneira muito mais simples de permitir algoritmos polimórficos:

void sort(Comparable[]);

No entanto, essa simplicidade abriu uma brecha no sistema de tipo estático:

String[] strings = {"hello"};
Object[] objects = strings;
objects[0] = 1; // throws ArrayStoreException

exigindo uma verificação de tempo de execução de todo acesso de gravação a uma matriz do tipo de referência.

Em poucas palavras, a abordagem mais recente incorporada pelos genéricos torna o sistema de tipos mais complexo, mas também mais estaticamente seguro, enquanto a abordagem mais antiga era mais simples e menos segura do tipo estaticamente. Os projetistas da linguagem optaram pela abordagem mais simples, tendo coisas mais importantes a fazer do que fechar uma pequena brecha no sistema de tipos que raramente causa problemas. Mais tarde, quando o Java foi estabelecido e as necessidades prementes foram atendidas, eles tinham os recursos necessários para fazer o correto para genéricos (mas alterá-lo para matrizes teria quebrado os programas Java existentes).

Os genéricos são invariantes : da JSL 4.10 :

... A subtipagem não se estende por tipos genéricos: T <: U não implica que C<T><: C<U>...

e algumas linhas adiante, a JLS também explica que as
matrizes são covariantes (primeiro marcador):

4.10.3 Subtipagem entre tipos de matriz

Eu acho que eles tomaram uma decisão errada em primeiro lugar que tornaram a matriz covariável. Ele quebra o tipo de segurança descrito aqui e eles ficaram presos por causa da compatibilidade com versões anteriores e depois tentaram não cometer o mesmo erro de genérico. E essa é uma das razões pelas quais Joshua Bloch prefere as listas ao item 25 do livro "Java eficaz (segunda edição)"

Minha opinião: quando o código está esperando uma matriz A [] e você fornece B [] onde B é uma subclasse de A, há apenas duas coisas com que se preocupar: o que acontece quando você lê um elemento da matriz e o que acontece se você escrever isto. Portanto, não é difícil escrever regras de linguagem para garantir que a segurança do tipo seja preservada em todos os casos (a regra principal é que um ArrayStoreExceptionpoderia ser lançado se você tentar inserir um A em um B []). Para um genérico, porém, quando você declara uma classe SomeClass<T>, pode haver várias maneiras de Tusá-lo no corpo da classe, e acho que é muito complicado elaborar todas as combinações possíveis para escrever regras sobre quando coisas são permitidas e quando não são.