2015-08-26 16 views
7

Questo codice:non può risolvere metodo di overload con lambda generico

public static void f(String[] args) {} 
public static void f(Integer[] args) {} 

public static void main(String[] args) 
{ 
    f(Stream.of("xxx").toArray(i -> new String[i])); 
} 

compila il successo con jdk8u45 ma jdk8u60 stampa il seguente errore:

Error:(17, 9) java: reference to f is ambiguous 
    both method f(java.lang.String[]) in type_infer.Test and method f(java.lang.Integer[]) in type_infer.Test match 

Ne segue la JSL, perché compilatore non può risolvere i metodi sovraccarichi? Era un bug fisso in jdk8u45?

+2

Ulteriori informazioni: compila bene in javac 1.8.0_25, 1.8.0_40, ecj 3.10.2; fallisce con lo stesso messaggio in javac 1.9.0-ea-b72. Più interessante è che la sostituzione di 'i -> new String [i]' con 'String [] :: new' risolve il problema in javac 1.9.0-ea-b72. –

+2

credo sia corretto, l'ho provato in ideone, e sta usando sun jdk 8u51 qui è link http://ideone.com/wvCXyO – user902383

+0

E con jdk1.8.0_60 sostituendo i -> new String [i] con String [] :: new non risolve il problema. – And390

risposta

1

Questo sembra un bug recentemente introdotto in javac.

L'argomento nella chiamata a f(..) è chiaramente di tipo String[]. Questo può, per esempio, essere mostrato risolvendo la stessa espressione come espressione autonoma:

String s1 = Stream.of("xxx").toArray(i -> new String[i])[0]; 
String[] s2 = Stream.of("xxx").toArray(i -> new String[i]).clone(); 

Questi sono accettato da tutte le versioni di compilatori.

Chiaramente, f(Integer[]) non è applicabile con un argomento di tipo String[]. Non vedo alcuna ragione per cui l'inferenza del tipo esterno costringa la risoluzione interiore a un risultato peggiore (ad es., Object[]) della risoluzione come espressione autonoma.

Ulteriori prove: la seguente dichiarazione sia correttamente respinto anche da quelle versioni di javac interessate da questo bug:

Integer[] s3 = Stream.of("xxx").toArray(i -> new String[i]); 

Quindi f(Integer[]) è chiaramente fuori dalla resa dei conti.

1

che stai ricevendo il dolore da un bug noto nella JVM http://bugs.java.com/bugdatabase/view_bug.do?bug_id=8029718 Non sei sicuro di come mettere in relazione la "versione fissa" per le generazioni disponibile sul sito di Oracle. Ma comunque dovresti lavorare nell'ultima versione e riportare le tue scoperte in quel bug. Forse l'hanno riparato e ora c'è una regressione.

+0

Un bug jvm non spiega l'errore di compilazione, ma il bug che citi viene effettivamente assegnato a javac. OTOH, quel bug è stato corretto per 8u20 quindi la correzione * è * disponibile in tutte le versioni menzionate nella domanda più commenti. –

Problemi correlati