Limite superiore del tipo restituito generico - interfaccia vs. classe - codice sorprendentemente valido

Questo è un esempio reale di un'API di librerie di terze parti, ma semplificato.

Compilato con Oracle JDK 8u72

Considera questi due metodi:

<X extends CharSequence> X getCharSequence() {
    return (X) "hello";
}

<X extends String> X getString() {
    return (X) "hello";
}

Entrambi riportano un avviso "non controllato" - capisco perché. La cosa che mi sconcerta è perché posso chiamare

Integer x = getCharSequence();

e si compila? Il compilatore dovrebbe sapere che Integernon implementa CharSequence. La chiamata a

Integer y = getString();

dà un errore (come previsto)

incompatible types: inference variable X has incompatible upper bounds java.lang.Integer,java.lang.String

Qualcuno può spiegare perché questo comportamento dovrebbe essere considerato valido? Come sarebbe utile?

Il client non sa che questa chiamata non è sicura: il codice del client viene compilato senza preavviso. Perché la compilazione non dovrebbe avvisare di ciò / emettere un errore?

Inoltre, in cosa differisce da questo esempio:

<X extends CharSequence> void doCharSequence(List<X> l) {
}

List<CharSequence> chsL = new ArrayList<>();
doCharSequence(chsL); // compiles

List<Integer> intL = new ArrayList<>();
doCharSequence(intL); // error

Tentare di passare List<Integer>genera un errore, come previsto:

method doCharSequence in class generic.GenericTest cannot be applied to given types;
  required: java.util.List<X>
  found: java.util.List<java.lang.Integer>
  reason: inference variable X has incompatible bounds
    equality constraints: java.lang.Integer
    upper bounds: java.lang.CharSequence

Se questo viene segnalato come errore, perché Integer x = getCharSequence();non lo è?

CharSequenceè un interface. Pertanto, anche se SomeClassnon implementato CharSequence, sarebbe perfettamente possibile creare una classe

class SubClass extends SomeClass implements CharSequence

Quindi puoi scrivere

SomeClass c = getCharSequence();

perché il tipo inferito Xè il tipo di intersezione SomeClass & CharSequence.

Questo è un po 'strano nel caso di Integerperché Integerè definitivo, ma finalnon gioca alcun ruolo in queste regole. Ad esempio puoi scrivere

<T extends Integer & CharSequence>

D'altra parte, Stringnon è un interface, quindi sarebbe impossibile estenderlo SomeClassper ottenere un sottotipo di String, perché java non supporta l'ereditarietà multipla per le classi.

Con l' Listesempio, è necessario ricordare che i generici non sono né covarianti né contraddittori. Ciò significa che se Xè un sottotipo di Y, List<X>non è né un sottotipo né un supertipo di List<Y>. Poiché Integernon implementa CharSequence, non è possibile utilizzare List<Integer>nel doCharSequencemetodo.

Tuttavia, puoi farlo compilare

<T extends Integer & CharSequence> void foo(List<T> list) {
    doCharSequence(list);
}  

Se hai un metodo che restituisce un List<T>simile a questo:

static <T extends CharSequence> List<T> foo() 

tu puoi fare

List<? extends Integer> list = foo();

Ancora una volta, questo è perché il tipo inferito è Integer & CharSequencee questo è un sottotipo di Integer.

I tipi di intersezione si verificano implicitamente quando si specificano più limiti (ad es <T extends SomeClass & CharSequence>.).

Per ulteriori informazioni, ecco la parte di JLS in cui spiega come funzionano i limiti di tipo. È possibile includere più interfacce, ad es

<T extends String & CharSequence & List & Comparator>

ma solo il primo limite può essere una non interfaccia.

Il tipo inferito dal compilatore prima dell'assegnazione per Xè Integer & CharSequence. Questo tipo sembra strano, perché Integerè definitivo, ma è un tipo perfettamente valido in Java. Viene quindi lanciato Integer, il che è perfettamente OK.

V'è esattamente un possibile valore per il Integer & CharSequencetipo: null. Con la seguente implementazione:

<X extends CharSequence> X getCharSequence() {
    return null;
}

Il seguente incarico funzionerà:

Integer x = getCharSequence();

A causa di questo possibile valore, non c'è motivo per cui l'assegnazione debba essere sbagliata, anche se ovviamente è inutile. Un avvertimento sarebbe utile.

Il vero problema è l'API, non il sito di chiamata

In effetti, ho recentemente scritto un blog su questo anti pattern di progettazione API . Non dovresti (quasi) mai progettare un metodo generico per restituire tipi arbitrari perché non puoi (quasi) mai garantire che il tipo inferito verrà consegnato. Un'eccezione sono metodi come Collections.emptyList(), nel caso in cui il vuoto dell'elenco (e la cancellazione di tipo generico) sia il motivo per cui qualsiasi inferenza <T>funzionerà:

public static final <T> List<T> emptyList() {
    return (List<T>) EMPTY_LIST;
}