Was ist der Unterschied zwischen <? erweitert Base> und <T erweitert Base>?

In diesem Beispiel:

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() Kompiliert nicht mit:

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

while compiles()wird vom Compiler akzeptiert.

Diese Antwort erklärt , dass der einzige Unterschied ist , dass im Gegensatz zu <? ...>, <T ...>können Sie die Art Referenz später, das scheint nicht der Fall zu sein.

Was ist der Unterschied zwischen <? extends Number>und <T extends Number>in diesem Fall und warum wird die erste Kompilierung nicht durchgeführt?

Durch Definieren der Methode mit der folgenden Signatur:

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

und aufrufen wie:

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

In jls §8.1.2 finden wir, dass (interessanter Teil von mir fett gedruckt):

Eine generische Klassendeklaration definiert eine Reihe parametrisierter Typen (§4.5), einen für jeden möglichen Aufruf des Typparameterabschnitts durch Typargumente . Alle diese parametrisierten Typen haben zur Laufzeit dieselbe Klasse.

Mit anderen Worten, der Typ Twird mit dem Eingabetyp abgeglichen und zugewiesen Integer. Die Signatur wird effektiv static void compiles(Map<Integer, List<Integer>> map).

Wenn es um doesntCompileMethoden geht, definiert jls Regeln für die Untertypisierung ( §4.5.1 , von mir fett gedruckt):

Ein Typargument T1 soll ein anderes Typargument T2 enthalten, geschrieben T2 <= T1, wenn die mit T2 bezeichnete Menge von Typen nachweislich eine Teilmenge der mit T1 bezeichneten Typmenge unter dem reflexiven und transitiven Abschluss der folgenden Regeln ist ( wobei <: die Untertypisierung bezeichnet (§4.10)):

• ? erweitert T <=? erweitert S, wenn T <: S.

• ? erweitert T <=?

• ? Super T <=? super S wenn S <: T.

• ? Super T <=?

• ? Super T <=? erweitert Objekt

• T <= T.

• T <=? verlängert T.

• T <=? Super T.

Dies bedeutet, dass ? extends Numbertatsächlich enthält Integeroder sogar List<? extends Number>enthält List<Integer>, aber es ist nicht der Fall für Map<Integer, List<? extends Number>>und Map<Integer, List<Integer>>. Mehr zu diesem Thema finden Sie in diesem SO-Thread . Sie können die Version mit ?Platzhalter weiterhin zum Laufen bringen, indem Sie deklarieren, dass Sie einen Subtyp von 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>>());
    }
}

Im Anruf:

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

T ist mit Integer abgeglichen, daher ist der Typ des Arguments a Map<Integer,List<Integer>>. Dies ist bei der Methode nicht der Fall doesntCompile: Der Typ des Arguments bleibt Map<Integer, List<? extends Number>>unabhängig vom tatsächlichen Argument im Aufruf. und das ist nicht abtretbar von HashMap<Integer, List<Integer>>.

AKTUALISIEREN

In der doesntCompileMethode hindert Sie nichts daran, Folgendes zu tun:

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

Es kann also offensichtlich kein HashMap<Integer, List<Integer>>als Argument akzeptieren .

Vereinfachtes Demonstrationsbeispiel. Das gleiche Beispiel kann wie unten dargestellt werden.

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>>ist ein mehrstufiger Platzhaltertyp, während List<? extends Number>es sich um einen Standard-Platzhaltertyp handelt.

Gültige konkrete Instanziierungen des Platzhaltertyps List<? extends Number>umfassen Numberund alle Untertypen von, Numberwährend in diesem Fall List<Pair<? extends Number>>ein Typargument vom Typargument ist und selbst eine konkrete Instanziierung des generischen Typs aufweist.

Generika sind unveränderlich, sodass Pair<? extends Number>Wildcard-Typen nur akzeptiert werden können Pair<? extends Number>>. Der innere Typ ? extends Numberist bereits kovariant. Sie müssen den umschließenden Typ als Kovariante festlegen, um die Kovarianz zuzulassen.

Ich würde Ihnen empfehlen, in der Dokumentation allgemeiner Platzhalter nachzuschlagen, insbesondere in Richtlinien für die Verwendung von Platzhaltern

Ehrlich gesagt Ihre Methode #doesntCompile

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

und wie anrufen

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

Ist grundsätzlich falsch

Fügen wir die rechtliche Umsetzung hinzu:

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

Es ist wirklich in Ordnung, weil Double Number erweitert, also ist Put List<Double>absolut in Ordnung List<Integer>, oder?

Nehmen Sie jedoch immer noch an, dass es legal ist , hier new HashMap<Integer, List<Integer>>()von Ihrem Beispiel abzuweichen?

Der Compiler glaubt das nicht und tut sein Bestes, um solche Situationen zu vermeiden.

Versuchen Sie, die gleiche Implementierung mit der Methode #compile durchzuführen, und der Compiler erlaubt Ihnen offensichtlich nicht, eine Liste von Doubles in die Map einzufügen.

    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
    }

Grundsätzlich können Sie nichts setzen, aber List<T>deshalb ist es sicher, diese Methode mit new HashMap<Integer, List<Integer>>()oder new HashMap<Integer, List<Double>>()oder new HashMap<Integer, List<Long>>()oder aufzurufen new HashMap<Integer, List<Number>>().

Kurz gesagt, Sie versuchen, mit dem Compiler zu schummeln, und dieser verteidigt sich ziemlich gegen solchen Schummel.

NB: Die Antwort von Maurice Perry ist absolut richtig. Ich bin mir nur nicht sicher, ob es klar genug ist, also habe ich versucht (ich hoffe wirklich, dass ich es geschafft habe), einen umfangreicheren Beitrag hinzuzufügen.