Qual è la differenza tra <? estende Base> e <T estende Base>?

In questo esempio:

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() non riesce a compilare con:

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

mentre compiles()è accettato dal compilatore.

Questa risposta spiega che l'unica differenza è che a differenza <? ...>,<T ...> consente di fare riferimento al tipo in un secondo momento, il che non sembra essere il caso.

Qual è la differenza tra <? extends Number>e <T extends Number>in questo caso e perché la prima compilazione?

Definendo il metodo con la seguente firma:

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

e invocandolo come:

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

Nel jls §8.1.2 troviamo che (parte interessante in grassetto da me):

Una dichiarazione di classe generica definisce un insieme di tipi parametrizzati (§4.5), uno per ogni possibile invocazione della sezione dei parametri di tipo mediante argomenti di tipo . Tutti questi tipi con parametri condividono la stessa classe in fase di esecuzione.

In altre parole, il tipo Tviene confrontato con il tipo di input e assegnato Integer. La firma diventerà effettivamentestatic void compiles(Map<Integer, List<Integer>> map) .

Quando si tratta di doesntCompilemetodo, jls definisce le regole del sottotipo ( §4.5.1 , in grassetto da me):

Si dice che un argomento di tipo T1 contenga un altro argomento di tipo T2, scritto T2 <= T1, se l'insieme di tipi indicato da T2 è di fatto un sottoinsieme dell'insieme di tipi indicato da T1 sotto la chiusura riflessiva e transitiva delle seguenti regole ( dove <: indica il sottotipo (§4.10)):

• ? estende T <=? estende S se T <: S

• ? estende T <=?

• ? super T <=? super S se S <: T

• ? super T <=?

• ? super T <=? estende l'oggetto

• T <= T

• T <=? estende T

• T <=? super T

Ciò significa che ? extends Numbereffettivamente contiene Integero addirittura List<? extends Number>contiene List<Integer>, ma non è il caso di Map<Integer, List<? extends Number>>e Map<Integer, List<Integer>>. Ulteriori informazioni su questo argomento sono disponibili in questo thread SO . Puoi comunque far funzionare la versione con ?caratteri jolly dichiarando che ti aspetti un sottotipo di 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>>());
    }
}

Nella chiamata:

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

T è abbinato a Integer, quindi il tipo di argomento è a Map<Integer,List<Integer>>. Non è il caso del metodo doesntCompile: il tipo di argomento rimane Map<Integer, List<? extends Number>>qualunque sia l'argomento effettivo nella chiamata; e che non è assegnabile da HashMap<Integer, List<Integer>>.

AGGIORNARE

Nel doesntCompilemetodo, nulla ti impedisce di fare qualcosa del genere:

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

Quindi, ovviamente, non può accettare a HashMap<Integer, List<Integer>>come argomento.

Esempio semplificato di dimostrazione. Lo stesso esempio può essere visualizzato come di seguito.

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>> è un tipo di carattere jolly a più livelli mentre List<? extends Number> è un tipo di carattere jolly standard.

Sono List<? extends Number>incluse le istanze concrete del tipo di jolly Numbere tutti i sottotipi di Numbermentre in caso diList<Pair<? extends Number>> cui si tratti di un argomento di tipo di argomento di tipo e esso stesso abbia un'istanza concreta di tipo generico.

I generici sono invarianti, quindi Pair<? extends Number>il tipo di carattere jolly può solo accettare Pair<? extends Number>>. Il tipo interno ? extends Numberè già covariante. Devi rendere il tipo allegato come covariante per consentire la covarianza.

Ti consiglierei di consultare la documentazione dei caratteri jolly generici, in particolare le linee guida per l'uso dei caratteri jolly

Francamente parlando del tuo metodo #doesntCompile

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

e chiama come

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

È fondamentalmente errato

Aggiungiamo l' implementazione legale :

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

Va davvero bene, perché Double estende il numero, quindi put List<Double>è assolutamente perfettoList<Integer> , giusto?

Tuttavia, pensi ancora che sia legale passare qui new HashMap<Integer, List<Integer>>()dal tuo esempio?

Il compilatore non la pensa così e sta facendo del suo meglio per evitare tali situazioni.

Prova a fare la stessa implementazione con il metodo #compile e il compilatore ovviamente non ti permetterà di mettere un elenco di doppi nella mappa.

    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
    }

Fondamentalmente non puoi mettere nulla, ma List<T>è per questo che è sicuro chiamare quel metodo con new HashMap<Integer, List<Integer>>()o new HashMap<Integer, List<Double>>()o new HashMap<Integer, List<Long>>()o new HashMap<Integer, List<Number>>().

Quindi, in poche parole, stai cercando di imbrogliare con il compilatore e si difende abbastanza da tale imbroglio.

NB: la risposta inviata da Maurice Perry è assolutamente corretta. Non sono sicuro che sia abbastanza chiaro, quindi ho provato (spero davvero di esserci riuscito) di aggiungere post più ampi.