Operatore ternario Java vs if / else nella compatibilità <JDK8

Recentemente sto leggendo il codice sorgente di Spring Framework. Qualcosa che non riesco a capire va qui:

public Member getMember() {
    // NOTE: no ternary expression to retain JDK <8 compatibility even when using
    // the JDK 8 compiler (potentially selecting java.lang.reflect.Executable
    // as common type, with that new base class not available on older JDKs)
    if (this.method != null) {
        return this.method;
    }
    else {
        return this.constructor;
    }
}

Questo metodo è un membro della classe org.springframework.core.MethodParameter. Il codice è facile da capire mentre i commenti sono difficili.

NOTA: nessuna espressione ternaria per mantenere la compatibilità JDK <8 anche quando si utilizza il compilatore JDK 8 (potenzialmente selezionando java.lang.reflect.Executablecome tipo comune, con quella nuova classe base non disponibile su JDK precedenti)

Qual è la differenza tra l'uso di espressioni ternarie e l'uso di if...else...costrutti in questo contesto?

Quando si pensa al tipo di operandi, il problema diventa più evidente:

this.method != null ? this.method : this.constructor

ha come tipo il tipo comune più specializzato di entrambi gli operandi, cioè il tipo più specializzato comune a entrambi this.methode this.constructor.

In Java 7 questo è java.lang.reflect.Member, tuttavia la libreria di classi Java 8 introduce un nuovo tipo java.lang.reflect.Executableche è più specializzato del generico Member. Quindi con una libreria di classi Java 8 il tipo di risultato dell'espressione ternaria è Executablepiuttosto che Member.

Alcune versioni (pre-release) del compilatore Java 8 sembrano aver prodotto un riferimento esplicito al Executablecodice generato all'interno durante la compilazione dell'operatore ternario. Ciò attiverebbe un caricamento di classe, e quindi a sua volta ClassNotFoundExceptionin fase di esecuzione quando viene eseguito con una libreria di classi <JDK 8, perché Executableesiste solo per JDK ≥ 8.

Come notato da Tagir Valeev in questa risposta , questo è in realtà un bug nelle versioni pre-rilascio di JDK 8 e da allora è stato risolto, quindi sia la if-elsesoluzione alternativa che il commento esplicativo sono ora obsoleti.

Nota aggiuntiva: si potrebbe giungere alla conclusione che questo bug del compilatore fosse presente prima di Java 8. Tuttavia, il byte code generato per il ternario da OpenJDK 7 è lo stesso del byte code generato da OpenJDK 8. Infatti, il tipo di L'espressione non viene menzionata completamente in fase di esecuzione, il codice è in realtà solo test, branch, load, return senza ulteriori controlli in corso. Quindi stai certo che questo non è un problema (più) e anzi sembra essere stato un problema temporaneo durante lo sviluppo di Java 8.

Questo è stato introdotto in un commit piuttosto vecchio il 3 maggio 2013, quasi un anno prima del rilascio ufficiale di JDK-8. Il compilatore era in forte sviluppo a quei tempi, quindi potrebbero verificarsi problemi di compatibilità. Immagino che il team di Spring abbia appena testato la build JDK-8 e abbia cercato di risolvere i problemi, anche se in realtà sono problemi del compilatore. Con il rilascio ufficiale di JDK-8 questo è diventato irrilevante. Ora l'operatore ternario in questo codice funziona correttamente come previsto (non Executableè presente alcun riferimento alla classe nel file .class compilato).

Attualmente cose simili appaiono in JDK-9: un po 'di codice che può essere ben compilato in JDK-8 fallisce con JDK-9 javac. Immagino che la maggior parte di questi problemi verrà risolta fino al rilascio.

La differenza principale è che un if elseblocco è un'istruzione mentre il ternario (più spesso noto come operatore condizionale in Java) è un'espressione .

Una dichiarazione può fare cose come returnal chiamante su alcuni dei percorsi di controllo. Un'espressione può essere utilizzata in un incarico:

int n = condition ? 3 : 2;

Quindi le due espressioni nel ternario dopo la condizione devono essere coercibili allo stesso tipo. Ciò può causare alcuni effetti strani in Java, in particolare con l'auto-boxing e il casting automatico dei riferimenti: questo è ciò a cui si riferisce il commento nel codice pubblicato. La coercizione delle espressioni nel tuo caso sarebbe un java.lang.reflect.Executabletipo (poiché è il tipo più specializzato ) e che non esiste nelle versioni precedenti di Java.

Stilisticamente dovresti usare un if elseblocco se il codice è simile a un'istruzione e un ternario se è simile a un'espressione.

Ovviamente, puoi fare in modo che un if elseblocco si comporti come un'espressione se usi una funzione lambda.

Il tipo di valore restituito in un'espressione ternaria è influenzato dalle classi padre, che sono cambiate come descritto in Java 8.

Difficile capire perché non sia stato possibile scrivere un cast.