web-dev-qa-db-fra.com

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

Comme vous le savez, Java.util.Objects est

Cette classe comprend des méthodes utilitaires statiques permettant d’exploiter des objets.

Une de ces méthodes est Objects.isNull().

Si j'ai bien compris, Objects.isNull() éliminerait le risque d'attribuer accidentellement une valeur nulle à object en omettant le second =.

Cependant, la note API indique:

Cette méthode existe pour être utilisée en tant que prédicat, filtre (Objects :: isNull)

Y aurait-il une raison/circonstance pour laquelle je devrais utiliser object == null Sur Objects.isNull() dans une instruction if ?

Est-ce que Objects.isNull() devrait être limité aux prédicats exclusivement?

javajava-8compare
50
Lucas T

devrait utiliser object == null sur Objects.isNull () dans une instruction if?

Si vous regardez la méthode code source de IsNull,

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

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

C'est le même. Il n'y a pas de différence. Vous pouvez donc l'utiliser en toute sécurité.

53
Suresh Atta

Objects.isNull est destiné à être utilisé avec le filtrage lambda Java 8).

C'est beaucoup plus facile et plus clair d'écrire

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

que d'écrire

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

Au sein d'un si, cependant, l'un ou l'autre fonctionnera, l'utilisation de == null est probablement plus facile à lire, mais elle se résumera finalement à une préférence de style.

37
Craig Taylor

Regardez la source:

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

Pour vérifier les valeurs null, vous pouvez utiliser:

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

Le fait que Objects.isNull Soit destiné à Predicates ne vous empêche pas de l'utiliser comme ci-dessus.

10
Mena

Y aurait-il une raison/circonstance pour laquelle je devrais utiliser object == null sur Objects.isNull () dans un if statement?

Oui, une des raisons est de garder le code simple. Dans si déclarationobject == null Est clair et bien connu. Cela ne peut conduire à aucune mauvaise conduite si, par exemple, il y a une faute de frappe.

Si j'ai bien compris, Objects.isNull () supprimerait le risque d'attribuer accidentellement une valeur null à object en omettant le second =.

S'il y a un if (object = null) {} avec omis=, Il ne sera pas compilé ou il générera un avertissement dans le cas d'un objet Boolean! En fait, il n'y a aucune raison d'utiliser Objects.isNull(object) sur object == null Dans si instruction. Voici les deux variantes côte à côte:

if (object == null) {
}

if (Objects.isNull(object)) {
}

Objects.isNull () doit-il être limité aux prédicats exclusivement?

On pourrait dire que oui, il est limité aux prédicats exclusivement, bien qu'il n'y ait pas d'obstacle technique à utiliser la Objects.isNull() partout.

Depuis la javadoc de la méthode public static boolean isNull(Object obj):

La méthode @apiNoteThis existe pour être utilisée en tant que filtre Java.util.function.Predicate (Objects :: isNull)

Donc, si vous utilisez la méthode comme pas un prédicat, vous utilisez en réalité une expression plus complexe et plus lourde que le simple object == null.

Voici un extrait permettant de comparer les avantages 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();
3
Vasil