Генералы второго порядка, похоже, ведут себя иначе, чем дженерики первого порядка

Я думал, что у меня разумное понимание дженериков. Например, я понимаю, почему

private void addString(List<? extends String> list, String s) {
    list.add(s); // does not compile
    list.add(list.get(0)); // doesn't compile either
}

Не компилируется. Я даже заработал некоторую интернет-карму со знаниями.

Но я бы подумал по тому же аргументу, что это не должно компилироваться:

private void addClassWildcard(List<Class<? extends String>> list, Class<? extends String> c) {
    list.add(c);
    list.add(list.get(0));
}

И это не должно:

private void addClass(List<Class<? extends String>> list, Class<String> c) {
    list.add(c);
    list.add(list.get(0));
}

Но оба компилируются. Зачем? Какая разница с примером сверху?

Я хотел бы получить объяснение на общем английском языке, а также указатель на соответствующие части спецификации Java или аналогичные.

Ответ 1

Второй случай безопасен, потому что все экземпляры Class<String> являются экземплярами Class<? extends String>.

Нет ничего опасного в добавлении экземпляра Class<? extends String> в List<Class<? extends String> - вы вернете экземпляр Class<? extends String> с помощью get(int), iterator() и т.д., чтобы он разрешался.

В некотором смысле подстановочный знак внутри Class рассматривается только тогда, когда экземпляр этого объекта действительно встречается. Рассмотрим следующие примеры (переход от String в Number, так как String является окончательным).

private void addClass(List<Class<? extends Number>> list, Class<Number> c) {
    list.add(c);
    list.add(list.get(0));
}

private void tryItSubclass() {
    List<Class<Integer>> ints = new ArrayList<>();

    addClass(ints, Number.class); // does not compile 
}

Здесь ints может содержать только экземпляры Class<Integer>, но Number.class также является Class<? extends Number> с ?, записанным как Number, поэтому два типа несовместимы.

private void tryItBound() {
    List<Class<Number>> ints = new ArrayList<>();

    addClass(ints, Number.class); // does not compile
}

Здесь ints может содержать только экземпляры Class<Number>, но Integer.class также является Class<? extends Number> с ?, записанным как Integer, поэтому два типа несовместимы.

private void tryItWildcard() {
    List<Class<? extends Number>> ints = new ArrayList<>();

    addClass(ints, Number.class); // does compile

    Class<? extends Number> aClass = ints.get(0);
}

Первый случай небезопасен, потому что - был ли гипотетический класс, который расширил String (которого нет, потому что String есть final, однако, дженерики игнорируют final), a List<? extends String> может a List<HypotheticalClass>. Таким образом, вы не можете добавить String в List<? extends String>, потому что вы ожидаете, что все в этом списке будет экземпляром HypotheticalClass:

List<HypotheticalClass> list = new ArrayList<>();
List<? extends String> list2 = list;
list2.add("");  // Not allowed, but pretend it is.
HypotheticalClass h = list.get(0);  // ClassCastException.

Ответ 2

Это связано с преобразованием захвата. Ответ Энди велик, но он не объясняет, как работает спецификация. Мой ответ здесь длинный, потому что, ну, это довольно плотная часть JLS, но я не вижу, чтобы это объяснялось много, и это не так сложно, если вы пройдете через него шаг за шагом.

Преобразование захвата - это процесс, при котором компилятор принимает тип с подстановочными знаками и заменяет (некоторые) подстановочные знаки типами, которые не являются подстановочными знаками.

Супертипы параметризованного типа с помощью подстановочных знаков являются супертипами этого типа после преобразования захвата:

4.10.2. Подтипирование между классами и типами интерфейсов

Учитывая объявление универсального типа C<F₁,...,F_n> (n > 0), прямые супертипы параметризованного типа C<R₁,...,R_n>, где по крайней мере один из R_i (1 ≤ я ≤ n) является аргументом типа подстановочных знаков, являются прямые супертипы параметризованного типа C<X₁,...,X_n>, который является результатом применения преобразования захвата в C<R₁,...,R_n>.

Типы членов (включая методы) параметризованного типа с помощью подстановочных знаков - это типы членов этого типа после преобразования захвата:

4.5.2. Члены и конструкторы параметризованных типов

Пусть C будет общим объявлением класса или интерфейса с параметрами типа A₁,...,A_n и пусть C<T₁,...,T_n> будет параметризацией C, где для 1 ≤ я ≤ n, T_i является типом (скорее чем подстановочный знак). Тогда:

[пропущен для неуместности]
Если какой-либо из аргументов типа в параметризации C являются подстановочными знаками, то:

Типы полей, методов и конструкторов в C<T₁,...,T_n> - это типы полей, методов и конструкторов в преобразовании захвата C<T₁,...,T_n>.

Итак, как работает преобразование захвата?

Предположим, что нам дано следующее объявление класса (более полно проиллюстрировано некоторые части процесса):

class C<V, W extends List<V>> {

    void m(V v, W w) {
    }
}

И следующее использование этого типа:

C<Number, ?> c = new C<>();

Double       tArg = 1.0;
List<Number> uArg = new ArrayList<>();
c.m(tArg, uArg);

Как определить тип c.m с целью определения если типы аргументов могут быть назначены типам параметров?

Ну, для начала, как указано выше, типы параметров c.m являются типами параметров m в преобразовании захвата C<Number, ?>:

5.1.10. Преобразование захвата

Пусть G укажите объявление общего типа с параметрами n типа A₁,...,A_n с соответствующими границами U₁,...,U_n.

В этом примере:

G C.
A₁ имеет V с привязкой U₁, которая Object.
A₂ имеет W с привязкой U₂, которая List<V>.

Существует преобразование захвата из параметризованного типа G<T₁,...,T_n> в параметризованный тип G<S₁,...,S_n>...

В этом примере G<T₁,...,T_n> есть C<Number, ?>:

T₁ - Number.
T₂ - ?.

..., где для 1 ≤ я ≤ n:

Если T_i является аргументом типа подстановки формы ?, то S_i является переменной нового типа, верхняя граница которой U_i[A₁:=S₁,...,A_n:=S_n] и нижняя граница которой - тип null.

Если T_i является аргументом типа подстановки формы ? extends B_i, то S_i является переменной нового типа, верхняя граница которой glb(B_i, U_i[A₁:=S₁,...,A_n:=S_n]) и нижняя граница которой - тип null.

glb(V₁,...,V_m) определяется как V₁ & ... & V_m.

U_i[A₁:=S₁,...,A_n:=S_n] является границей A_i (параметр типа) с подстановкой каждого аргумента типа для каждого соответствующего параметра типа. (Вот почему я объявил C параметром типа, связанный с которым ссылается на другой параметр типа: потому что он иллюстрирует, что делает эта часть.)

В нашем примере для T₂ (который есть ?), S₂ является переменной нового типа, верхняя граница которой U₂ (которая есть List<V>) с заменой Number для V.

S₂, следовательно, является новой переменной типа, верхняя граница которой List<Number>.

Для простоты я проигнорирую случай, когда у нас ограниченный подстановочный знак, но ограниченный подстановочный знак - это, по сути, просто захват, преобразованный в новую переменную типа, граница которой BoundOfWildcard & BoundOfTypeParameter. Кроме того, если подстановочный знак имеет нижнюю границу (super), то новая переменная типа также имеет нижнюю границу.

Если T_i не является подстановочным знаком, то:

В противном случае S_i = T_i.

Итак, в нашем примере S₁ является просто T₁, который является Number.

И что:

Преобразование захвата не применяется рекурсивно.

который мы получим позже.

Теперь мы знаем, что:

S₁ - Number.
S₂ - это некоторая переменная типа FRESH extends List<Number>, которую только что создал компилятор.

Следовательно, преобразование захвата C<Number, ?> составляет C<Number, FRESH>.

Теперь мы можем ответить на вопрос: есть ли Double и List<Number>, назначаемые Number и FRESH extends List<Number>, соответственно? В первом случае да. В последнем случае нет.

Это по тем же причинам, что выражение не будет компилироваться, если мы сами объявили переменную типа:

static <FRESH extends List<Number>> void n() {
    C<Number, FRESH> c = new C<>();

    Double       tArg = 1.0;
    List<Number> uArg = new ArrayList<>();
    c.m(tArg, uArg);
}

Супертипы переменной типа::

Прямыми супертипами переменной типа являются типы, перечисленные в ее привязке.

Следовательно, List<Number> не может быть присвоен FRESH, потому что List<Number> является супертипом FRESH.

По аналогии, мы могли бы также объявить класс следующим образом:

class Fresh extends List<Number> {}
C<Number, Fresh> c = new C<>();

Double       tArg = 1.0;
List<Number> uArg = new ArrayList<>();
c.m(tArg, uArg);

Это может быть более знакомым, и на самом деле это не так уж и отличается в отношении того, как отношения между типами работают в этом случае.

Другими словами, в нашем первоначальном примере:

C<Number, ?> c = new C<>();

Double       tArg = 1.0;
List<Number> uArg = new ArrayList<>();
c.m(tArg, uArg);
//        ^^^^ this

- это более сложная версия:

Object o = ...;
String s = o; // Error: attempting to assign a supertype to its subtype.

и (в конце дня) не компилируется по той же причине.

В резюме

Преобразование захвата принимает подстановочные знаки и включает их для ввода переменных (временно). После этого это просто обычные правила подтипирования, которые вызывают эти ошибки.

Так, например, учитывая код в вопросе:

private void addString(List<? extends String> list, String s) {
    list.add(s); // does not compile
    list.add(list.get(0)); // doesn't compile either
}

При просмотре выражения list.add(s) компилятор видит что-то вроде этого:

private <CAP#1 extends String>
void addString(List<? extends String> list, String s) {
    ((List<CAP#1>) list).add( s );
    list.add(list.get(0));
}

Полученная ошибка выглядит следующим образом:

error: no suitable method found for add(String)
        list.add(s); // does not compile
            ^
    method Collection.add(CAP#1) is not applicable
      (argument mismatch; String cannot be converted to CAP#1)
    method List.add(CAP#1) is not applicable
      (argument mismatch; String cannot be converted to CAP#1)
  where CAP#1 is a fresh type-variable:
    CAP#1 extends String from capture of ? extends String

Другими словами, обнаруженные компилятором методы add(CAP#1) и String не поддаются изменению переменной типа CAP#1.

При просмотре выражения list.add(list.get(0)) компилятор видит что-то вроде этого:

private <CAP#1 extends String, CAP#2 extends String>
void addString(List<? extends String> list, String s) {
    list.add(s);
    ((List<CAP#2>) list).add( ((List<CAP#1>) list).get(0) );
}

Полученная ошибка выглядит следующим образом:

error: no suitable method found for add(CAP#1)
        list.add(list.get(0)); // doesn't compile either
            ^
    method Collection.add(CAP#2) is not applicable
      (argument mismatch; String cannot be converted to CAP#2)
    method List.add(CAP#2) is not applicable
      (argument mismatch; String cannot be converted to CAP#2)
  where CAP#1,CAP#2 are fresh type-variables:
    CAP#1 extends String from capture of ? extends String
    CAP#2 extends String from capture of ? extends String

Другими словами, компилятор обнаружил, что list.get(0) возвращает CAP#1 и нашел методы add(CAP#2), но CAP#1 не может быть преобразован в CAP#2.

(Источник ошибок.)

Итак, почему работает `List<Class<?>>` и другие подобные типы?

Напомним, что:

В противном случае, если T_i не является подстановочным шрифтом], S_i = T_i.

И что:

Преобразование захвата не применяется рекурсивно.

Итак, если T_i является параметризованным типом типа Class<?>, то S_i является просто Class<?>. Кроме того, поскольку преобразование захвата не применяется рекурсивно, алгоритм просто останавливается после преобразования T₁,...,T_n в S₁,...,S_n. Новый тип не конвертируется с захватом, а границы переменных нового типа не преобразуются в захват.

Мы также можем убедиться, что это действительно то, что делает компилятор, вызывая некоторые интересные ошибки:

Map<?, List<?>> m = new HashMap<>();

List<?> list = new ArrayList<>();
list.add(m);

Это приводит к следующей ошибке:

error: no suitable method found for add(Map<CAP#1,List<?>>)
        list.add(m);
            ^
    […]

(Источник.

Обратите внимание, что аргумент типа List<?> в захвате типа Map преобразует в себя.

И еще:

Map<?, ? extends List<?>> m = new HashMap<>();

List<?> list = new ArrayList<>();
list.add(m);

Это приводит к следующей ошибке:

error: no suitable method found for add(Map<CAP#1,CAP#2>)
        list.add(m);
            ^
    […]
  where CAP#1,CAP#2,CAP#3 are fresh type-variables:
    CAP#1 extends Object from capture of ?
    CAP#2 extends List<?> from capture of ? extends List<?>
    CAP#3 extends Object from capture of ?

(Источник.

Обратите внимание, что на этот раз, когда ? extends List<?> преобразуется с захватом, граница List<?> не является.

Наконец

Ответ на поставленный вопрос заключается в том, что подстановочный знак в List<? extends String> преобразуется с захватом в новую переменную типа, но подстановочный знак в List<Class<? extends String>> не является.

Ответ 3

Ваш пример пропускает факт (по крайней мере, я так думаю), что (переход к Integer и Number для существующих примеров) List<Class<Integer>> не является допустимым экземпляром List<Class<? extends Number>>.

Итак, это не скомпилируется:

public static void main(String[] args) {
    List<Class<Integer>> intClasses = new LinkedList<>();
    addClass(intClasses, Number.class); // compiler error
}

private static void addClass(List<Class<? extends Number>> list, Class<Number> c) {
    list.add(c);
    list.add(list.get(0));
}