En Java, on me dit que lors d'un contrôle nul, il faut utiliser == au lieu de .equals (). Quelles en sont les raisons?
En Java, on me dit que lors d'un contrôle nul, il faut utiliser == au lieu de .equals (). Quelles en sont les raisons?
Réponses:
Ce sont deux choses complètement différentes. ==
compare la référence d'objet, le cas échéant, contenue dans une variable. .equals()
vérifie si deux objets sont égaux selon leur contrat pour ce que signifie l'égalité. Il est tout à fait possible que deux instances d'objets distinctes soient «égales» selon leur contrat. Et puis il y a le détail mineur qui equals
est une méthode, si vous essayez de l'invoquer sur une null
référence, vous obtiendrez un NullPointerException
.
Par exemple:
class Foo {
private int data;
Foo(int d) {
this.data = d;
}
@Override
public boolean equals(Object other) {
if (other == null || other.getClass() != this.getClass()) {
return false;
}
return ((Foo)other).data == this.data;
}
/* In a real class, you'd override `hashCode` here as well */
}
Foo f1 = new Foo(5);
Foo f2 = new Foo(5);
System.out.println(f1 == f2);
// outputs false, they're distinct object instances
System.out.println(f1.equals(f2));
// outputs true, they're "equal" according to their definition
Foo f3 = null;
System.out.println(f3 == null);
// outputs true, `f3` doesn't have any object reference assigned to it
System.out.println(f3.equals(null));
// Throws a NullPointerException, you can't dereference `f3`, it doesn't refer to anything
System.out.println(f1.equals(f3));
// Outputs false, since `f1` is a valid instance but `f3` is null,
// so one of the first checks inside the `Foo#equals` method will
// disallow the equality because it sees that `other` == null
public int data
?
Object
, oui. Il est cependant remplacé par un grand nombre de classes JDK. Mais ce n'est pas une question d'implémentation, mais de sémantique. (Note latérale: JDK7 est très obsolète.)
si vous invoquez .equals()
, null
vous obtiendrezNullPointerException
Il est donc toujours conseillé de vérifier la nullité avant d'appeler la méthode où qu'elle s'applique
if(str!=null && str.equals("hi")){
//str contains hi
}
Regarde aussi
if ("hi".equals(str))
.
someObject.equals(null)
lèvera a NullPointerException
sans jamais entrer la méthode equals.
Objects.equals(a, b)
Cela ne lèvera pas NullPointerException, mais cela dépend toujours de la méthode "égale" du "a" et du "b"
En plus de la réponse acceptée ( https://stackoverflow.com/a/4501084/6276704 ):
Depuis Java 1.7, si vous souhaitez comparer deux objets qui peuvent être nuls, je recommande cette fonction:
Objects.equals(onePossibleNull, twoPossibleNull)
java.util.Objects
Cette classe se compose de méthodes utilitaires statiques permettant d'opérer sur des objets. Ces utilitaires incluent des méthodes de sécurité nulle ou tolérantes à zéro pour calculer le code de hachage d'un objet, renvoyer une chaîne pour un objet et comparer deux objets.
Depuis: 1.7
En Java, 0 ou null sont des types simples et non des objets.
La méthode equals () n'est pas conçue pour les types simples. Les types simples peuvent être mis en correspondance avec ==.
foo.equals(null)
Que se passe-t-il si foo est nul?
Vous obtenez une NullPointerException.
Si une variable Object est nulle, on ne peut pas appeler une méthode equals () dessus, donc une vérification de référence d'objet de null est appropriée.
Selon les sources , peu importe ce qu'il faut utiliser pour l'implémentation de la méthode par défaut:
public boolean equals(Object object) {
return this == object;
}
Mais vous ne pouvez pas en être sûr equals
dans la classe personnalisée.
equals
ne peut retourner false
ou provoquer un NullPointerException
(ou quelque chose de différent si la equals
méthode surchargée est absurde).
Object.equals est null safe, mais sachez que si deux objets sont null, object.equals retournera true donc assurez-vous de vérifier que les objets que vous comparez ne sont pas null (ou contiennent des valeurs nulles) avant d'utiliser object.equals pour Comparaison.
String firstname = null;
String lastname = null;
if(Objects.equals(firstname, lastname)){
System.out.println("equal!");
} else {
System.out.println("not equal!");
}
L'exemple d'extrait ci-dessus renverra égal!
Étant donné qu'égal est une fonction dérivée de la classe Object, cette fonction compare les éléments de la classe. si vous l'utilisez avec null, il retournera false car le contenu de la classe n'est pas nul. De plus == compare la référence à un objet.
false
ou NullPointerException
(s'il equals
n'est pas remplacé par quelque chose de mauvais).
voici un exemple où str != null
mais str.equals(null)
lors de l'utilisationorg.json
JSONObject jsonObj = new JSONObject("{field :null}");
Object field = jsonObj.get("field");
System.out.println(field != null); // => true
System.out.println( field.equals(null)); //=> true
System.out.println( field.getClass()); // => org.json.JSONObject$Null
EDIT:
voici la classe org.json.JSONObject $ Null :
/**
* JSONObject.NULL is equivalent to the value that JavaScript calls null,
* whilst Java's null is equivalent to the value that JavaScript calls
* undefined.
*/
private static final class Null {
/**
* A Null object is equal to the null value and to itself.
*
* @param object
* An object to test for nullness.
* @return true if the object parameter is the JSONObject.NULL object or
* null.
*/
@Override
public boolean equals(Object object) {
return object == null || object == this;
}
}
field.equals(null)
renvoie vrai. Cela rompt le comportement habituel de Java et prête donc à confusion. Cela ne devrait fonctionner que pour field.equals("null")
, du moins à mon avis. Je ne sais pas pourquoi les développeurs de la bibliothèque ont pensé que ce serait bon à supporter.
str != null
et de str.equals(null)
retour true
lors de l'utilisation de org.json ."?
jsonObject
contient la clé "field", c'est pourquoi il field
n'est pas nul, il a une référence qui contient l' json.org.JSONObject$Null
objet
Null
comme null
et utiliserais à la "null"
place. Mais je suppose qu'ils ont fait cela pour éviter d'avoir besoin de cordes. Mais même avec cette bibliothèque, field.equals(null)
c'est toujours presque toujours un problème: P.
Donc, je ne me trompe jamais et évite les problèmes avec cette solution:
if(str.trim().length() <=0 ) {
// is null !
}
""
longueur 0) est quelque chose de complètement différent d'une null
référence (c'est-à-dire pas de chaîne).
Votre code enfreint la loi de Demeter. C'est pourquoi il est préférable de refactoriser le design lui-même. Pour contourner ce problème, vous pouvez utiliser facultatif
obj = Optional.ofNullable(object1)
.map(o -> o.getIdObject11())
.map(o -> o.getIdObject111())
.map(o -> o.getDescription())
.orElse("")
ci-dessus est de vérifier la hiérarchie d'un objet donc utilisez simplement
Optional.ofNullable(object1)
si vous n'avez qu'un seul objet à vérifier
J'espère que cela t'aides !!!!
Tu pourrais toujours faire
if (str == null || str.equals(null))
Cela vérifiera d'abord la référence de l'objet, puis vérifiera l'objet lui-même en fournissant que la référence n'est pas nulle.
x.equals(null)
.
equals()
et de voir. Lorsque vous essayez, il sera instantanément évident