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

Jak wiesz, java.util.Objectsjest

Ta klasa składa się ze statycznych metod narzędziowych do wykonywania operacji na obiektach.

Jedną z takich metod jest Objects.isNull().

Rozumiem, Objects.isNull()że wyeliminowałoby to możliwość przypadkowego przypisania wartości zerowej do obiektu poprzez pominięcie drugiej =.

Jednak uwaga API stwierdza:

Ta metoda istnieje do użycia jako predykat, filtr (Objects :: isNull)

Czy istnieje jakikolwiek powód / okoliczność, dla których warto korzystać z object == nullponad Objects.isNull()w if ?

Czy powinno Objects.isNull()się ograniczyć wyłącznie do orzeczeń?

należy używać object == null nad Objects.isNull () w instrukcji if?

Jeśli spojrzeć na kod źródłowy w IsNullmetodzie

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

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

To jest to samo. Nie ma różnicy. Więc możesz go bezpiecznie używać.

Objects.isNull jest przeznaczony do użycia z filtrowaniem lambda Java 8.

O wiele łatwiej i jaśniej jest pisać:

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

niż pisać:

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

ifJednak w ramach oświadczenia oba będą działać. Użycie języka == nulljest prawdopodobnie łatwiejsze do odczytania, ale ostatecznie sprowadzi się do preferencji stylu.

Spójrz na źródło:

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

Aby sprawdzić nullwartości, możesz użyć:

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

Fakt, że Objects.isNulljest przeznaczony dla Predicates, nie przeszkadza w używaniu go jak powyżej.

Czy byłby jakiś powód / okoliczność, dla której powinienem używać object == null nad Objects.isNull () w instrukcji if ?

Tak, jednym z powodów jest prostota kodu. Wewnątrz, jeśli stwierdzenie object == null jest jasne i dobrze znane. Nie może to prowadzić do niewłaściwego zachowania, jeśli na przykład pojawi się literówka.

Rozumiem, że Objects.isNull () wyeliminowałoby możliwość przypadkowego przypisania wartości null do obiektu poprzez pominięcie second =.

Jeśli zostanie pominiętyif (object = null) {} z, nie będzie się kompilował lub wygeneruje ostrzeżenie w przypadku obiektu! W rzeczywistości nie ma powodu, aby używać instrukcji over within if . Oto dwa warianty obok siebie: =BooleanObjects.isNull(object)object == null

if (object == null) {
}

if (Objects.isNull(object)) {
}

Czy Objects.isNull () powinno być ograniczone wyłącznie do predykatów?

Można powiedzieć, że tak, ogranicza się to wyłącznie do orzeczeń, chociaż nie ma technicznych przeszkód w używaniu Objects.isNull()wszędzie.

Z public static boolean isNull(Object obj)javadoc metody:

@apiNote Ta metoda istnieje do wykorzystania jako java.util.function.Predicate, filter (Objects :: isNull)

Więc jeśli używasz metody jak nie orzecznika jesteś rzeczywiście przy bardziej złożonych i uciążliwych ekspresji w porównaniu do prostych object == null.

Oto fragment, z którego można porównać korzyści 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();

Pod względem semantycznym nie ma różnicy, ale ze względu na czytelność wolę następujące rzeczy whatever == null:

import static java.util.Objects.isNull;

// Other stuff...

if(isNull(whatever)) { 

}