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


87

Como sabes, java.util.Objectses

Esta clase consta de métodos de utilidad estáticos para operar con objetos.

Uno de esos métodos es Objects.isNull().

Tengo entendido que Objects.isNull()eliminaría la posibilidad de asignar accidentalmente un valor nulo al objeto omitiendo el segundo =.

Sin embargo, la nota de API dice:

Este método existe para ser utilizado como predicado, filtro (Objects :: isNull)

¿Habría alguna razón / circunstancia por la que debería usar object == nullover Objects.isNull()en una declaración if ?

¿Debería Objects.isNull()limitarse exclusivamente a los predicados?


3
Si todo lo que le preocupa es la asignación accidental, simplemente puede usarlo de manera if(null == variable)consistente ...
Holger

1
@Holder, ¿de qué asignación accidental hay que preocuparse? Esto es Java. Obtendrá un error de tipo.
Louis Wasserman

1
@LouisWasserman No si variablees un Boolean.
Alexis C.

2
@AlexisC, eso sería una preocupación en una pequeña cantidad de casos: su variable debe ser de un tipo muy específico, y debe realizar un error tipográfico muy específico, y no puede usar ningún IDE o análisis de compilador eso señalaría eso para usted (como lo harían casi todos los IDE). Me siento bastante cómodo sin preocuparme por ese caso.
Louis Wasserman

1
En el trabajo, he visto muchas instancias de null == object . Cuando pregunté, me dijeron que era para evitar asignaciones nulas accidentales. Con base en los comentarios y las respuestas que aquí se proporcionan, me inclinaría a creer que es una cuestión de gusto.
Lucas T

Respuestas:


79

¿Debería usar object == null sobre Objects.isNull () en una declaración if?

Si observa el código fuente del IsNullmétodo,

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

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

Es lo mismo. No hay diferencia. Para que puedas usarlo de forma segura.


14
Sí, se puede usar, pero puede interferir con el análisis de flujo local realizado por una herramienta. Es decir, con un simple "==", cualquier análisis de flujo puede ver que la desreferencia no es buena en la rama then, pero segura en otra rama. Obtendrá los errores / advertencias apropiados o nada. Con la indirección de llamar a isNull (), ese conocimiento puede perderse en la herramienta.
Stephan Herrmann

3
HAY una ligera diferencia de rendimiento. La comprobación de Java para una referencia nula de objeto frente a la llamada a un método estático tendrá una diferencia. Y se lee un poco menos claro que usar == al que estamos acostumbrados.
Kevin M

3
Es un uso más semántica == nullen if, pero isNull es de gran uso en las expresiones lambda.
Leonardo Ramos Duarte

1
seguramente es legítimo, pero no tiene ningún beneficio sobre los operadores. Entonces, si trabaja en equipo, use las cosas de acuerdo con su propósito previsto.
Alex Panchenko

74

Objects.isNull está diseñado para su uso dentro del filtrado lambda de Java 8.

Es mucho más fácil y claro escribir:

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

que escribir:

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

Dentro de una ifdeclaración, sin embargo, cualquiera funcionará. El uso de == nullprobablemente sea más fácil de leer, pero al final se reducirá a una preferencia de estilo.


12

Mira la fuente:

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

Para verificar los nullvalores, puede usar:

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

El hecho de que Objects.isNullesté destinado a Predicates no le impide usarlo como se indicó anteriormente.


1
¿A qué te refieres con riesgo de error tipográfico?
Ashish Lohia

2
@AshishLohia usando en =lugar de ==(no se compilaría a menos que sea un Booleancontenedor que acepte nulos , sea justo)
Mena

5
El riesgo de error tipográfico es el problema en C ++ no en Java si (myObject = null) dará como resultado el error de compilación. Siempre debe usar myObject == null sobre null == myObject.
Tomas Marik

1
@TomasMarik como se mencionó en mi comentario, el riesgo de error tipográfico se limita a los Booleancontenedores que aceptan valores NULL en Java. Esto es bastante raro de hecho (y dará advertencias al compilador cuando nullse verifique una asignación como si fuera una condición), pero no imposible.
Mena

7

¿Habría alguna razón / circunstancia por la que debería usar object == null sobre Objects.isNull () en una declaración if ?

Sí, una razón es mantener el código simple. Dentro de si la declaración object == null es clara y bien conocida. No puede dar lugar a ningún mal comportamiento si, por ejemplo, hay un error tipográfico.

Tengo entendido que Objects.isNull () eliminaría la posibilidad de asignar accidentalmente un valor nulo al objeto omitiendo el segundo =.

Si se omite un if (object = null) {}con , no se compilará o generará una advertencia en caso de objeto. En realidad, no hay razón para usar over dentro de la declaración if . Aquí están las dos variantes una al lado de la otra: =BooleanObjects.isNull(object)object == null

if (object == null) {
}

if (Objects.isNull(object)) {
}

¿Debería Objects.isNull () limitarse exclusivamente a predicados?

Se podría decir que sí, se limita exclusivamente a Predicados, aunque no hay ningún obstáculo técnico para utilizarlo en Objects.isNull()todas partes.

Desde el public static boolean isNull(Object obj)javadoc del método:

@apiNote Este método existe para ser utilizado como java.util.function.Predicate, filter (Objects :: isNull)

Entonces, si usa el método como no un predicado, en realidad está usando una expresión más compleja y engorrosa en comparación con la simple object == null.

Aquí hay un fragmento para comparar el beneficio de 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();

1

Semánticamente no hay diferencia, pero para la legibilidad prefiero lo siguiente whatever == null:

import static java.util.Objects.isNull;

// Other stuff...

if(isNull(whatever)) { 

}
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.