Jaka jest różnica między <? rozszerza bazę> i <T rozszerza bazę>?

W tym przykładzie:

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() nie można skompilować z:

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>>());
                      ^

podczas gdy compiles()jest akceptowany przez kompilator.

Ta odpowiedź wyjaśnia, że ​​jedyną różnicą jest to, że w przeciwieństwie do <? ...>, <T ...>pozwala odwoływać się do typu później, co nie wydaje się być prawdą.

Jaka jest różnica między <? extends Number>iw <T extends Number>tym przypadku i dlaczego pierwsza kompilacja nie jest wykonywana?

Definiując metodę z następującym podpisem:

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

i wywoływanie go w następujący sposób:

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

W jls §8.1.2 stwierdzamy, że (interesująca część pogrubiona przeze mnie):

Ogólna deklaracja klasy definiuje zestaw sparametryzowanych typów (§ 4.5), po jednym dla każdego możliwego wywołania sekcji parametru typu według argumentów typu . Wszystkie te sparametryzowane typy dzielą tę samą klasę w czasie wykonywania.

Innymi słowy, typ Tjest dopasowywany do typu wejściowego i przypisywany Integer. Podpis stanie się skutecznie static void compiles(Map<Integer, List<Integer>> map).

Jeśli chodzi o doesntCompilemetodę, jls określa zasady subtypowania ( pogrubione przeze mnie p. 4.5.1 ):

Mówi się, że argument typu T1 zawiera inny argument typu T2, zapisany T2 <= T1, jeśli zbiór typów oznaczonych przez T2 jest możliwym podzbiorem zbioru typów oznaczonych przez T1 pod zwrotnym i przechodnim zamknięciem następujących reguł ( gdzie <: oznacza podtyp (§4.10)):

• ? rozszerza T <=? rozszerza S, jeśli T <: S

• ? rozszerza T <=?

• ? super T <=? super S, jeśli S <: T

• ? super T <=?

• ? super T <=? rozszerza Object

• T <= T

• T <=? rozszerza T

• T <=? super T.

Oznacza to, że ? extends Numberrzeczywiście zawiera Integerlub nawet List<? extends Number>zawiera List<Integer>, ale nie jest tak w przypadku Map<Integer, List<? extends Number>>i Map<Integer, List<Integer>>. Więcej na ten temat można znaleźć w tym wątku SO . Nadal możesz sprawić, by wersja ze ?znakiem wieloznacznym działała, deklarując, że spodziewasz się podtypu 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>>());
    }
}

W rozmowie:

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

T jest dopasowane do liczby całkowitej, więc typ argumentu to Map<Integer,List<Integer>>. W przypadku tej metody tak nie jest doesntCompile: typ argumentu pozostajeMap<Integer, List<? extends Number>> bez względu na faktyczny argument w wywołaniu; i nie można tego przypisać HashMap<Integer, List<Integer>>.

AKTUALIZACJA

W doesntCompilemetodzie nic nie stoi na przeszkodzie, aby zrobić coś takiego:

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

Oczywiście nie może przyjąć HashMap<Integer, List<Integer>>argumentu.

Uproszczony przykład demonstracji. Ten sam przykład można wizualizować jak poniżej.

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>>jest wielopoziomowym typem symboli wieloznacznych, podczas gdy List<? extends Number>jest standardowym typem symboli wieloznacznych.

Prawidłowe konkretne instancje typu dzikiej karty List<? extends Number>obejmują Numberi wszelkie podtypy, Numberpodczas gdy w przypadku List<Pair<? extends Number>>których jest argumentem typu argument typu i sam ma konkretną instancję typu ogólnego.

Generyczne są niezmienne, więc Pair<? extends Number>typ wieloznaczny może tylko zaakceptować Pair<? extends Number>>. Typ wewnętrzny ? extends Numberjest już kowariantny. Musisz ustawić typ zamykający jako kowariant, aby umożliwić kowariancję.

Polecam zajrzeć do dokumentacji ogólnych symboli wieloznacznych, a zwłaszcza wskazówek dotyczących używania symboli wieloznacznych

Szczerze mówiąc, twoja metoda #doesntCompile

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

i zadzwoń jak

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

Jest zasadniczo niepoprawny

Dodajmy prawne wdrożenie:

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

Jest naprawdę w porządku, ponieważ Double rozszerza liczbę, więc ułożenie List<Double>jest absolutnie w porządku List<Integer>, prawda?

Czy jednak nadal uważasz, że legalne jest przekazywanie tutaj new HashMap<Integer, List<Integer>>()ze swojego przykładu?

Kompilator tak nie uważa i robi wszystko, aby uniknąć takich sytuacji.

Spróbuj wykonać tę samą implementację za pomocą metody #compile, a kompilator oczywiście nie pozwoli Ci umieścić listy podwójnych na mapie.

    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
    }

Zasadniczo nic nie możesz umieścić, ale List<T>dlatego bezpiecznie jest wywoływać tę metodę za pomocą new HashMap<Integer, List<Integer>>()lub new HashMap<Integer, List<Double>>()lub new HashMap<Integer, List<Long>>()lub new HashMap<Integer, List<Number>>().

Krótko mówiąc, próbujesz oszukiwać za pomocą kompilatora, który dość dobrze broni się przed takim oszustwem.

Uwaga: odpowiedź wysłana przez Maurice'a Perry'ego jest całkowicie poprawna. Po prostu nie jestem pewien, czy to wystarczająco jasne, więc próbowałem (naprawdę mam nadzieję, że udało mi się) dodać bardziej obszerny post.