Nie można rozwiązać metodą przeładowany generycznego lambda

Question

ten kod:

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])); 
} 

kompiluje sukces z jdk8u45 ale jdk8u60 drukuje się następujący błąd:

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 

nie wynika z JSL, dlaczego kompilator nie może rozwiązać przeciążone metody? Czy był to naprawiony błąd w jdk8u45?

Answer 1

To wygląda jak błąd wprowadzony ostatnio w javac.

Argument w wywołaniu f(..) jest wyraźnie typu String[]. Można, na przykład, być przedstawiony przez rozwiązanie tego samego wyrażenia w postaci samodzielnej ekspresji:

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

Te są akceptowane przez wszystkie wersje kompilatorów.

Oczywiście, f(Integer[]) nie ma zastosowania z argumentem typu String[]. Nie widzę powodu, dla którego zewnętrzne wnioskowanie zmusiłoby wewnętrzną rozdzielczość do gorszego wyniku (np. Object[]) niż rozdzielczość jako samodzielne wyrażenie.

Dodatkowy dowód: poniższe zestawienie jest poprawnie odrzucony nawet przez tych wersjach javac dotkniętych przez ten błąd:

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

Stąd f(Integer[]) jest wyraźnie z rachunku.

Answer 2

Dostaniesz ból od znanego błędu w JVM http://bugs.java.com/bugdatabase/view_bug.do?bug_id=8029718 Nie wiesz, jak odnosić się do „stałe wersji” do buduje dostępny na stronie internetowej Oracle. Ale mimo to powinieneś pracować w najnowszej wersji i zgłosić swoje odkrycia w tym błędzie. Może to naprawili i teraz jest regresja.