В чем разница между <? расширяет базу> и <T расширяет базу>?

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

import java.util.*;

public class Example {
    static void doesntCompile(Map<Integer, List<? extends Number>> map) {}
    static <T extends Number> void compiles(Map<Integer, List<T>> map) {}

    static void function(List<? extends Number> outer)
    {
        doesntCompile(new HashMap<Integer, List<Integer>>());
        compiles(new HashMap<Integer, List<Integer>>());
    }
}

doesntCompile() не может скомпилировать с:

Example.java:9: error: incompatible types: HashMap<Integer,List<Integer>> cannot be converted to Map<Integer,List<? extends Number>>
        doesntCompile(new HashMap<Integer, List<Integer>>());
                      ^

пока compiles()принимается компилятором.

Этот ответ объясняет, что единственное отличие состоит в том <? ...>, что в отличие от этого , <T ...>вы можете ссылаться на тип позже, что, похоже, не так.

В чем разница между <? extends Number>и <T extends Number>в этом случае, и почему первая компиляция не выполняется?

Определив метод со следующей подписью:

static <T extends Number> void compiles(Map<Integer, List<T>> map) {}

и вызывая его так:

compiles(new HashMap<Integer, List<Integer>>());

В jls §8.1.2 мы находим, что (интересная часть выделена мной):

Объявление универсального класса определяет набор параметризованных типов (§4.5), по одному для каждого возможного вызова раздела параметров типа аргументами типа . Все эти параметризованные типы совместно используют один и тот же класс во время выполнения.

Другими словами, тип Tсопоставляется с типом ввода и назначается Integer. Подпись эффективно станет static void compiles(Map<Integer, List<Integer>> map).

Когда дело доходит до doesntCompileметода, jls определяет правила подтипирования ( §4.5.1 , выделенный мной):

Говорят, что аргумент типа T1 содержит другой аргумент типа T2, записанный как T2 <= T1, если набор типов, обозначаемых через T2, является доказуемо подмножеством набора типов, обозначаемых через T1 при рефлексивном и транзитивном замыкании следующих правил ( где <: обозначает подтип (§4.10)):

• ? расширяет T <=? расширяет S, если T <: S

• ? расширяет T <=?

• ? супер T <=? супер S если S <: T

• ? супер T <=?

• ? супер T <=? расширяет объект

• Т <= Т

• Т <=? расширяет T

• Т <=? супер т

Это означает, что ? extends Numberдействительно содержит Integerили даже List<? extends Number>содержит List<Integer>, но это не относится к Map<Integer, List<? extends Number>>и Map<Integer, List<Integer>>. Больше на эту тему можно найти в этой теме . Вы все еще можете заставить ?работать версию с подстановочными знаками, объявив, что вы ожидаете подтип List<? extends Number>:

public class Example {
    // now it compiles
    static void doesntCompile(Map<Integer, ? extends List<? extends Number>> map) {}
    static <T extends Number> void compiles(Map<Integer, List<T>> map) {}

    public static void main(String[] args) {
        doesntCompile(new HashMap<Integer, List<Integer>>());
        compiles(new HashMap<Integer, List<Integer>>());
    }
}

В звонилке:

compiles(new HashMap<Integer, List<Integer>>());

T соответствует Integer, поэтому тип аргумента a Map<Integer,List<Integer>>. Это не относится к методу doesntCompile: тип аргумента остается Map<Integer, List<? extends Number>>тем же фактическим аргументом в вызове; и это не присваивается из HashMap<Integer, List<Integer>>.

ОБНОВИТЬ

В doesntCompileметоде ничто не мешает вам сделать что-то вроде этого:

static void doesntCompile(Map<Integer, List<? extends Number>> map) {
    map.put(1, new ArrayList<Double>());
}

Очевидно, что он не может принять HashMap<Integer, List<Integer>>аргумент в качестве аргумента.

Упрощенный пример демонстрации. Тот же пример можно визуализировать как ниже.

static void demo(List<Pair<? extends Number>> lst) {} // doesn't work
static void demo(List<? extends Pair<? extends Number>> lst) {} // works
demo(new ArrayList<Pair<Integer>()); // works
demo(new ArrayList<SubPair<Integer>()); // works for subtype too

public static class Pair<T> {}
public static class SubPair<T> extends Pair<T> {}

List<Pair<? extends Number>>является многоуровневым типом подстановочных знаков, тогда как List<? extends Number>является стандартным типом подстановочных знаков.

Допустимые конкретные экземпляры подстановочного типа List<? extends Number>включают в себя Numberи любые подтипы, Numberтогда как в случае, List<Pair<? extends Number>>когда это аргумент типа аргумента типа, а сам по себе имеет конкретный экземпляр универсального типа.

Дженерики являются инвариантами, поэтому Pair<? extends Number>можно использовать только групповые символы Pair<? extends Number>>. Внутренний тип ? extends Numberуже ковариантен. Вы должны сделать включающий тип ковариантным, чтобы разрешить ковариацию.

Я бы порекомендовал вам ознакомиться с документацией об универсальных подстановочных знаках, особенно с инструкциями по их использованию.

Откровенно говоря ваш метод #doesntCompile

static void doesntCompile(Map<Integer, List<? extends Number>> map) {}

и звоните как

doesntCompile(new HashMap<Integer, List<Integer>>());

В корне неверно

Добавим юридическую реализацию:

    static void doesntCompile(Map<Integer, List<? extends Number>> map) {
        List<Double> list = new ArrayList<>();
        list.add(0.);
        map.put(0, list);
    }

Это действительно хорошо, потому что Double расширяет Number, так что put List<Double>тоже отлично List<Integer>, верно?

Тем не менее, вы все еще думаете, что это законно, чтобы перейти new HashMap<Integer, List<Integer>>()от вашего примера?

Компилятор так не считает, и делает все возможное, чтобы избежать подобных ситуаций.

Попробуйте сделать ту же реализацию с методом #compile, и компилятор, очевидно, не позволит вам поместить список двойников в карту.

    static <T extends Number> void compiles(Map<Integer, List<T>> map) {
        List<Double> list = new ArrayList<>();
        list.add(10.);
        map.put(10, list); // does not compile
    }

По сути, вы ничего не можете поместить, но List<T>поэтому безопасно вызывать этот метод с помощью new HashMap<Integer, List<Integer>>()или new HashMap<Integer, List<Double>>()или new HashMap<Integer, List<Long>>()или new HashMap<Integer, List<Number>>().

Итак, в двух словах, вы пытаетесь обмануть с помощью компилятора, и он справедливо защищает от такого обмана.

NB: ответ Мориса Перри абсолютно верный. Я просто не уверен, что это достаточно ясно, поэтому постарался (очень надеюсь, что мне удалось) добавить более обширный пост.