Perché non è possibile inferire tipi di diamante su classi interne anonime?

Question

Eventuali duplicati:
Double brace initialisation (anonymous inner class) with diamond operator

In Java 7 e versioni successive, il diamante può essere utilizzato per inferire i tipi avanti normalmente in questo modo, senza un problema:

List<String> list = new ArrayList<>(); 

Tuttavia, non può per classi interne anonime come questa:

List<String> st = new List<>() { //Doesn't compile 

    //Implementation here 

} 

Perché è questo? Logicamente in questo scenario, posso sicuramente dedurre il tipo come String. C'è una ragione logica per questa decisione in cui il tipo non può in realtà essere dedotto su classi interne anonime, o è stato omesso per altri motivi?

Answer 1

Nella JSR-334:

Utilizzando diamante con le classi interne anonime non è supportato dal farlo in generale richiederebbe estensioni file di classe attributo firma per rappresentare tipi non denotable, un de facto JVM cambiamento.

Ciò che immagino sia che, come tutti sanno, la classe anonima conduce a una generazione del proprio file di classe.

Immagino che il tipo generico non esista all'interno di questi file e piuttosto sostituito dal tipo effettivo (statico) (così dichiarato dal tipo esplicito come <String> all'ora dell'oggetto dichiarazione).

In effetti, il file corrispondente a una classe interna non viene mai condiviso tra più istanze diverse di esso, quindi perché preoccuparsi di generici? :).

Sarebbe più difficilmente realizzabile (e sicuramente inutile) per il compilatore forzare un'estensione (aggiungendo un attributo speciale per generici) a questi tipi di file di classe.

Answer 2

In breve, lo <> fa poco per dedurre i tipi, si spegne l'avviso che si otterrebbe senza di esso.

MODIFICA: come @Natix indica che esegue un controllo.

List<Integer> ints = new ArrayList<>(); 
List<String> copy = new ArrayList<>(ints); 

produce un errore di compilazione

Error:Error:line (42)error: incompatible types 
required: List<String> 
found: ArrayList<Integer> 

Come si può vedere la <> sta prendendo il tipo dell'argomento, non inferire il tipo dal tipo di copy

Answer 3

domande interessanti. La soluzione può essere trovata qui http://docs.oracle.com/javase/specs/jls/se7/html/jls-15.html#jls-15.9 o qui Double brace initialisation (anonymous inner class) with diamond operator

Almeno ho imparato qualcosa. Grazie per la domanda. ;)

Answer 4

google rendimenti, dopo aver saltato i messaggi da StackOverflow, http://mail.openjdk.java.net/pipermail/coin-dev/2011-June/003283.html

Sto indovinando è come questo, di solito una classe anonima è una sottoclasse concreta del tipo apparente

interface Foo<N extends Number> 
    { 
     void foo(N n); 
    } 

    Foo<Integer> foo = new Foo<Integer>(){ ... } 

è implementato da

class AnonFoo_1 implements Foo<Integer>{ ... } 

    Foo<Integer> foo = new AnonFoo_1(); 

Supponiamo di consentire l'inferenza del diamante su classi anonime, ci può essere un caso complicato come

Foo<? extends Runnable> foo = new Foo<>(){ ... } 

Le regole di inferenza producono N=Number&Runnable; dopo il trucco di implementazione precedente, è necessario

class AnonFoo_2 implements Foo<Number&Runnable>{ ... } 

Attualmente non consentito; il tipo arg a super type Foo deve essere di tipo "normale".

---

Tuttavia, la logica non è molto forte. Possiamo inventare altri trucchi di implementazione per farlo funzionare

class AnonFoo<N extends Number&Runnable> implements Foo<N> 
    { 
     @Override public void foo(N n) 
     { 
      n.intValue(); 
      n.run(); 
     } 
    } 

    Foo<? extends Runnable> foo = new AnonFoo<>(); 

il compilatore dovrebbe essere in grado di fare lo stesso trucco.

In ogni caso, almeno il compilatore dovrebbe consentire la maggior parte dei casi d'uso che non coinvolgono "tipi indistinguibili", come Foo<Integer> foo = new Foo<>(){...} È un peccato che questi casi comuni/semplici siano anch'essi inutilmente proibiti.