Java 8 collect vs reduce

Question

Come noto, quando si effettua l'accumulo, "reduce" restituisce sempre un nuovo oggetto immutabile mentre "collect" apporta le modifiche su un oggetto mutabile.

Tuttavia, quando accidentalmente assegno un riferimento al metodo per ridurre e raccogliere il metodo, esso viene compilato senza errori. Perché?

Date un'occhiata al codice seguente:

public class Test { 
    @Test 
    public void testReduce() { 

     BiFunction<MutableContainer,Long,MutableContainer> func = 
      MutableContainer::reduce; 

     // Why this can compile? 
     BiConsumer<MutableContainer,Long> consume = 
      MutableContainer::reduce; 

     // correct way: 
     //BiConsumer<MutableContainer,Long> consume = 
     // MutableContainer::collect; 


     long param=10; 

     MutableContainer container = new MutableContainer(0); 


     consume.accept(container, param); 
     // here prints "0",incorrect result, 
     // because here we expect a mutable change instead of returning a immutable value 
     System.out.println(container.getSum()); 

     MutableContainer newContainer = func.apply(container, param); 
     System.out.println(newContainer.getSum()); 
    } 
} 

class MutableContainer { 
    public MutableContainer(long sum) { 
     this.sum = sum; 
    } 

    public long getSum() { 
     return sum; 
    } 

    public void setSum(long sum) { 
     this.sum = sum; 
    } 

    private long sum; 

    public MutableContainer reduce(long param) { 
     return new MutableContainer(param); 
    } 

    public void collect(long param){ 
     this.setSum(param); 
    } 
} 

Answer 1

In sostanza, la questione si riduce a questo: BiConsumer è un'interfaccia funzionale la cui funzione è dichiarata in questo modo:

void accept(T t, U u) 

Hai dato è un riferimento al metodo con i parametri corretti, ma il tipo di ritorno errato:

public MutableContainer reduce(long param) { 
    return new MutableContainer(param); 
} 

[Il parametro T è in realtà l'oggetto this quando viene chiamato reduce, poiché reduce è un metodo di istanza e non un metodo statico. Ecco perché i parametri sono corretti.] Il tipo restituito è MutableContainer e non void, tuttavia. Quindi la domanda è: perché il compilatore lo accetta?

Intuitivamente, credo che questo è dovuto al fatto un riferimento metodo è, più o meno, equivalente ad una classe anonima che assomiglia a questo:

new BiConsumer<MutableContainer,Long>() { 
    @Override 
    public void accept(MutableContainer t, Long u) { 
     t.reduce(u); 
    } 
} 

noti che t.reduce(u) restituirà un risultato. Tuttavia, il risultato viene scartato. Poiché è corretto chiamare un metodo con un risultato e scartare il risultato, penso che, per estensione, è per questo che è OK utilizzare un riferimento al metodo in cui il metodo restituisce il risultato, per un'interfaccia funzionale il cui metodo restituisce void.

Legalisticamente, credo che il motivo sia JLS 15.12.2.5. Questa sezione è difficile e io non capiscono fino in fondo, ma da qualche parte in questa sezione si dice

Se e è un espressione esatta metodo di riferimento ... R è vuoto.

dove, se ho letto correttamente, R 2 è il tipo di risultato di un metodo di interfaccia funzionale. Penso che questa sia la clausola che consente di utilizzare un riferimento al metodo non void in cui è previsto un riferimento al metodo void.

(Edit: Come Ismail sottolineato nei commenti, JLS 15.13.2 può essere la clausola corretta qui; parla di un riferimento metodo congruente con un tipo di funzione, ed una delle condizioni per questo è che il risultato di il tipo di funzione è void.)

Ad ogni modo, si spera che spieghi perché è compila. Ovviamente, il compilatore non può sempre dire quando stai facendo qualcosa che produce risultati errati.