106 votes

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

Comme vous le savez, java.util.Objects es

Cette classe se compose de méthodes utilitaires statiques permettant d'opérer sur des objets.

L'une de ces méthodes est Objects.isNull() .

Je crois comprendre que Objects.isNull() éliminerait le risque d'attribuer accidentellement une valeur nulle à l'objet en omettant le deuxième élément = .

Cependant, la note de l'API précise que

Cette méthode existe pour être utilisée comme prédicat, filter(Objects::isNull)

Y a-t-il une raison ou une circonstance pour laquelle je devrais utiliser object == null plus Objects.isNull() dans un si déclaration ?

Doit Objects.isNull() se limite exclusivement aux prédicats ?

0 votes

Il y a aussi Objects.requireNonNull(T obj) ; btw

4 votes

Si tout ce qui vous préoccupe est une affectation accidentelle, vous pouvez simplement utiliser if(null == variable) de manière cohérente

1 votes

@Holder, quelle affectation accidentelle doit-on craindre ? Il s'agit de Java. Vous obtiendrez une erreur de type.

102voto

Faut-il utiliser object == null plutôt que Objects.isNull() dans une instruction if ?

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

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

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

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

14 votes

Oui, il peut être utilisé, mais il peut interférer avec l'analyse du flux local effectuée par un outil. Par exemple, avec un simple "==", n'importe quelle analyse de flux peut voir que le déréférencement n'est pas bon dans la branche then, mais qu'il est sûr dans une branche else. Vous obtiendrez les erreurs/avertissements appropriés ou rien du tout. Avec l'indirection de l'appel à isNull(), cette connaissance peut être perdue pour l'outil.

4 votes

Il y a une légère différence de performance. Le fait que Java vérifie la référence nulle d'un objet par rapport à l'appel d'une méthode statique aura une incidence. Et la lecture est un peu moins claire que l'utilisation de == à laquelle nous sommes tous habitués.

5 votes

Utilisation plus sémantique == null en if mais isNull est très utile pour les expressions lambda.

97voto

Craig Taylor Points 195

Objects.isNull est destiné à être utilisé dans le cadre du filtrage lambda de Java 8.

C'est beaucoup plus facile et plus clair à écrire :

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

que d'écrire :

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

Dans un délai de if Toutefois, l'une ou l'autre de ces déclarations peut être utilisée. L'utilisation de == null est probablement plus facile à lire, mais en fin de compte, il s'agit d'une préférence de style.

1 votes

Je ne suis pas d'accord avec l'affirmation selon laquelle il est "beaucoup plus facile/clair à écrire". 1. Il n'est pas plus concis. 2. Il est évidemment moins expressif, en particulier pour ceux qui ne sont pas familiarisés avec la syntaxe Java la plus récente. Pour moi qui n'écris pas Java tous les jours (j'écris Scala), il est hallucinant d'avoir une méthode statique qui ne fait rien d'autre que de vérifier la présence de null. Cette méthode n'est qu'un obstacle à la fluidité de la lecture du code sans aucun avantage.

14voto

Mena Points 12283

Regardez la source :

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

Pour vérifier null vous pouvez utiliser :

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

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

1 votes

Qu'entendez-vous par risque de faute de frappe ?

3 votes

@AshishLohia en utilisant = au lieu de == (ne compilerait pas à moins qu'il s'agisse d'un objet nullable) Boolean (pour être juste).

8 votes

Le risque de faute de frappe est un problème en C++ et non en Java. if (myObject = null) entraînera une erreur de compilation. Vous devez toujours utiliser myObject == null plutôt que null == myObject.

7voto

Vasil Points 113

Y a-t-il une raison ou une circonstance pour laquelle je devrais utiliser object == null plutôt que Objects.isNull() dans une application de type si déclaration ?

Oui, l'une des raisons est de garder le code simple. A l'intérieur de si déclaration object == null est claire et bien connue. Une faute de frappe, par exemple, ne peut donner lieu à aucun comportement erroné.

Si j'ai bien compris, Objects.isNull() éliminerait le risque d'attribuer accidentellement une valeur nulle à l'objet en omettant le deuxième =.

S'il y a un if (object = null) {} con omis = il ne compilera pas ou génèrera un avertissement en cas de Boolean objet ! En fait, il n'y a aucune raison d'utiliser Objects.isNull(object) plus object == null à l'intérieur si déclaration . Voici les deux variantes côte à côte :

if (object == null) {
}

if (Objects.isNull(object)) {
}

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

On pourrait dire que oui, il est limité aux prédicats exclusivement, bien qu'il n'y ait pas d'obstacle technique à l'utilisation de l'outil de gestion des prédicats. Objects.isNull() partout.

A partir de la public static boolean isNull(Object obj) de la méthode :

@apiNoteCette méthode existe pour être utilisée en tant que java.util.function.Predicate, filter(Objects::isNull)

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

Voici un extrait qui permet 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();

3voto

angry_snyder Points 79

D'un point de vue sémantique, il n'y a pas de différence, mais pour des raisons de lisibilité, je préfère l'option suivante à la suivante whatever == null :

import static java.util.Objects.isNull;

// Other stuff...

if(isNull(whatever)) { 

}

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X