LambdaConversionException quando si mescolano metodi di riferimento e generici

Question

Il codice seguente compila bene ma genera un'eccezione in fase di runtime. È questo il comportamento previsto e perché?

Codice:

public static void main(String[] args) { 
    A<Integer> a = new A<>(); 
    System.out.println(a.min()); //prints null as expected 
    System.out.println(a.max()); //throws exception 
} 

static class A<T extends Number & Comparable<? super T>> { 
    Stream<T> s = Stream.empty(); 
    public T min() { return s.min((t1, t2) -> t1.compareTo(t2)).orElse(null); } 
    public T max() { return s.max(T::compareTo).orElse(null); } 
} 

uscita:

null 
Exception in thread "main" java.lang.BootstrapMethodError: call site initialization exception 
    at java.lang.invoke.CallSite.makeSite(CallSite.java:341) 
    at java.lang.invoke.MethodHandleNatives.linkCallSiteImpl(MethodHandleNatives.java:307) 
    at java.lang.invoke.MethodHandleNatives.linkCallSite(MethodHandleNatives.java:297) 
    at abc$A.max(abc.java:19) 
    at abc.main(abc.java:8) 
Caused by: java.lang.invoke.LambdaConversionException: Invalid receiver type class java.lang.Number; not a subtype of implementation type interface java.lang.Comparable 
    at java.lang.invoke.AbstractValidatingLambdaMetafactory.validateMetafactoryArgs(AbstractValidatingLambdaMetafactory.java:233) 
    at java.lang.invoke.LambdaMetafactory.metafactory(LambdaMetafactory.java:303) 
    at java.lang.invoke.CallSite.makeSite(CallSite.java:302) 
    ... 4 more 

Answer 1

Sembra essere un problema di Netbeans e non riesco a riprodurre il problema quando si utilizza javac dalla riga di comando. Ho registrato uno bug report.

Answer 2

Il tuo codice non avrebbe funzionato anche se si utilizza lambda invece di metodo riferimenti perché il flusso è già esaurita

System.out.println(a.min()); 
System.out.println(a.max()); // exhausted 

I flussi sono uno fuori. Ma lasciamo questo a parte. Quando si utilizza la versione di riferimento del metodo, acquisisce Number come parametro di tipo e non Comparable dove Number non ha compareToforse perché Number è più specifico qui. Se si basta usare Comparable che funzionerà bene

static class A<T extends Comparable<? super T>> { 
    Stream<T> s = Stream.empty(); 
    public T min() { return s.min((t1, t2) -> t1.compareTo(t2)).orElse(null); } 
    public T max() { 
     T t = s.max(T::compareTo).orElse(null); 
     return t; } 
} 

System.out.println(a.max()); //null 

IMO (tanto per essere prudenti): Credo che sia un bug.

Quello che effettivamente credo: è sicuramente un bug.

Modifica: Si scopre che questo era in realtà un bug ed è stato risolto come confermato da Brian Goetz. https://bugs.openjdk.java.net/browse/JDK-8058112. Secondo il database dei bug, questo è stato risolto in 8u40

Answer 3

La chiamata problema sito di inizializzazione viene risolto mediante una JDK-8058112 disponibile in JDK 8u40 B17 o poi.

Answer 4

Per coloro che stanno affrontando questo problema nel 2017 con java8 1.8.0_141, c'è un altro rapporto di bug archiviato JDK-8142476 e la versione di correzione è solo java9.