java.util.Objects.isNull vs object == null

Come sai, lo java.util.Objectsè

Questa classe è costituita da metodi di utilità statici per operare sugli oggetti.

Uno di questi metodi è Objects.isNull() .

La mia comprensione è questo Objects.isNull() eliminerebbe la possibilità di assegnare accidentalmente un valore nullo all'oggetto omettendo il secondo =.

Tuttavia, la nota API afferma:

Questo metodo esiste per essere utilizzato come predicato, filtro (Oggetti :: isNull)

Ci sarebbe una ragione / circostanza per cui dovrei usare object == nullpiù Objects.isNull()di un file if ?

Dovrebbe Objects.isNull()essere limitato esclusivamente ai predicati?

dovrebbe usare object == null su Objects.isNull () in un'istruzione if?

Se guardi il codice sorgente del IsNullmetodo,

 /* Returns true if the provided reference is null otherwise returns false.*/

 public static boolean isNull(Object obj) {
     return obj == null;
 }

È lo stesso. Non c'è differenza. Quindi puoi usarlo in sicurezza.

Objects.isNull è inteso per l'uso all'interno del filtro lambda Java 8.

È molto più facile e chiaro scrivere:

.stream().filter(Objects::isNull) 

che scrivere:

.stream().filter(x -> x == null).  

All'interno di una ifdichiarazione, tuttavia, funzioneranno entrambi. L'uso di == nullè probabilmente più facile da leggere ma alla fine si riduce a una preferenza di stile.

Guarda la fonte:

public static boolean isNull(Object obj) {
    return obj == null;
}

Per verificare i nullvalori, puoi utilizzare:

• Objects.isNull(myObject)
• null == myObject // avoids assigning by typo
• myObject == null // risk of typo

Il fatto che Objects.isNullsia pensato per Predicates non ti impedisce di usarlo come sopra.

Ci sarebbe una ragione / circostanza per cui dovrei usare object == null su Objects.isNull () in un'istruzione if ?

Sì, uno dei motivi è mantenere il codice semplice. Entro if object == null è chiara e ben nota. Non può portare a comportamenti scorretti se ad esempio c'è un errore di battitura.

La mia comprensione è che Objects.isNull () eliminerebbe la possibilità di assegnare accidentalmente un valore nullo all'oggetto omettendo il secondo =.

Se è presente un if (object = null) {}con omesso = non verrà compilato o genererà un avviso in caso di Booleanoggetto! In realtà non v'è alcun motivo per utilizzare Objects.isNull(object)nel corso object == nullall'interno di if . Ecco le due varianti affiancate:

if (object == null) {
}

if (Objects.isNull(object)) {
}

Objects.isNull () dovrebbe essere limitato esclusivamente a Predicates?

Si potrebbe dire di sì, è limitato esclusivamente ai Predicati, sebbene non ci siano ostacoli tecnici per utilizzare il Objects.isNull() ovunque.

Dal public static boolean isNull(Object obj)javadoc del metodo:

@apiNote Questo metodo esiste per essere utilizzato come java.util.function.Predicate, filter (Objects :: isNull)

Quindi, se usi il metodo come non predicato, stai effettivamente usando un'espressione più complessa e ingombrante rispetto al sempliceobject == null .

Ecco uno snippet per confrontare i vantaggi di Objects.isNull(object)

List<String> list = Arrays.asList("a", "b", null, "c", null);

// As ready-made predicate
long countNullsWithPredicate = list.stream().filter(Objects::isNull).count();

// Lambda
long countNullsWithLambda = list.stream().filter(object -> object == null).count();

// Reimplement the Objects::isNull predicate
long countNullsWithAnonymous = list.stream().filter(new Predicate<Object>() {
    @Override
    public boolean test(Object obj) {
        return obj == null;
    }
}).count();

Semanticamente non c'è differenza ma per leggibilità preferisco quanto segue rispetto a whatever == null:

import static java.util.Objects.isNull;

// Other stuff...

if(isNull(whatever)) { 

}