Из того, что еще не было упомянуто: по-разному устроены способы реализации ко- и контра- вариантности в generics-ах.
Как оно работает в C#
В шарпах, как известно, например, ковариантный интерфейс можно объявить вот так (пример нагло сворован с MSDN):
interface ICovariant<out R>
{
R GetSomething();
}
Тогда, если у нас есть класс по типу:
class Implementation<T> : ICovariant<T> where T : new()
{
public T GetSomething()
{
return new T();
}
}
И два наследующих друг от друга класса:
class A {}
class B : A {}
Мы можем сделать так:
Implementation<B> b = new Implementation<B>();
ICovariant<A> a = b;
Т.е. получается, что ICovariant<B> как будто наследует от ICovariant<A>. Аналогично с контравариантностью, только там у type paramet-ра модификатор in вместо out, и все ровно наоборот - созданный от базового класса (A) экземпляр как бы "наследует" от производного (B). (на самом деле, это не наследование, а отношение is-a, т.е. если B есть A, то ICovariant<B> есть ICovariant<A>, но это уже семантические дебри).
Как оно работает в Java
А в Джаве по те же цели запилили другой механизм, который иногда ругают за ограниченность и меньшую безопасность, однако работает же!
Если я ничего не путаю, это называется call-site co/contra- variance. Фокус тут в том, что в шарпах вариантность (ко-, контра-, ин-) задается в декларации интерфейсов и делегатов, а у Джавы - в декларации самих объектов.
Это пашет через Джавины wildcard-ы (когда вместо T в "клювиках" стоит ?). Аналогичный данному для шарпов пример тут будет выглядеть так:
class GenericClass<T> {
public T field;
}
class A {}
class B extends A {}
GenericClass<B> b = new GenericClass<B>();
GenericClass<? extends A> a = b;
? (Wildcard) в качетсве type-paramet-ра обозначает, что черт его, собственно, знает, что это за тип такой, так что расслабиться с проверкой типов чуток можно.
Они бывают unbounded (просто один ? в клювиках), upper-bounded (<? extends A>, т.е. об этом типе есть информация, что он наследует от какого-то другого типа - A. По сути, <? extends Object> аналогично unbounded wildcard), и lower-bounded (<? super B>, т.е. этот тип должен быть одним из предков другого типа - B).
Upper-bounded wildcards используются, как я продемонстрировал выше, для ковариантности, а lower-bounded wildcards, как ясно, для контравариантности.
Вообще и wildcard-ы, и механизмы ко- и контра- вариантности в шарпах - тема большая и довольно интересная, рекомендую почитать по ним поподробнее (особенно про обход безопасности типов при помощи wildcard-ов, пример тут).