Perché list.sort non utilizza l'API opzionale

Question

Java 8 introduce un nuovo metodo predefinito nell'interfaccia List per ordinarlo. E 'firma è:

void sort(Comparator<? super E> c) 

La documentazione dice:

Se il comparatore specificato è nullo, allora tutti gli elementi in questo elenco devono implementare l'interfaccia Comparable e naturale ordinamento degli elementi dovrebbe essere usato.

Quindi, se si desidera ordinare l'elenco da esso è ordine naturale (e che gli elementi sono confrontabili) si hanno a che fare list.sort(null); che è un po 'strano del mio parere.

Se hanno utilizzato un Optional, il documento dichiarerebbe che è possibile fornire facoltativamente un comparatore e che se non viene fornito presupporrà che gli elementi siano già comparabili.

Una chiamata list.sort(null); si trasforma in list.sort(Optional.empty());.

Poiché è un metodo che è esposto al mondo esterno, lo troverei più preciso.

Perché non hanno usato la nuova API Opzionale invece?

Answer 1

Opzionale è destinato all'uso come tipo di reso. Questo è sempre stato il mantra degli sviluppatori JDK-8. Quindi non infrangeranno la loro regola usandola come argomento.

Detto questo, avrei fatto l'argomento obbligatorio, e quindi costringere lo sviluppatore di utilizzare

list.sort(Comparator.<Foo>naturalOrder()); 

Anche se posso passare nulla, trovo quanto sopra più leggibile, e non molto più dettagliato. Quindi è quello che uso nel mio codice.

Answer 2

Il metodo predefinito è la delega a Arrays#sort, che è has existed since at least Java 1.7.

Ecco il frammento di rilevante per il metodo predefinito:

@SuppressWarnings({"unchecked", "rawtypes"}) 
default void sort(Comparator<? super E> c) { 
    Object[] a = this.toArray(); 
    Arrays.sort(a, (Comparator) c); 
    ListIterator<E> i = this.listIterator(); 
    for (Object e : a) { 
     i.next(); 
     i.set((E) e); 
    } 
} 

Osservare che sta convertendo l'elenco in un array e lasciando Arrays#sort gestirlo da lì. Il comportamento predefinito per questo poi ricadrà su ciò che è supportato per quel metodo.

Ci sono due ragioni per cui vedo questo essere preferibile l'aggiunta di un Optional:

• Se non hanno un Comparator da usare, o vogliono solo il comportamento di "default", si può fornire un null ad esso. In questo contesto, null e Optional.isPresent() hanno lo stesso scopo e non guadagnano punti di usabilità.

  È un fastidio dover fornirenull a una funzione per il suo comportamento predefinito; un design migliore potrebbe essere stato quello di sovraccaricare il metodo o consentire invece di passare un'istanza predefinita naturalOrder.

• Il modello Optional è più destinata ad evitare la manipolazione inavvertitamente un riferimento null, invece di essere utilizzato per un controllo null. Il sovraccarico nell'aggiunta di Optional dove un semplice controllo null sarebbe di gran lunga superiore ai suoi benefici, soprattutto considerando che non vi è alcuna differenza semantica.