In Java I am told that when doing a null check one should use == instead of .equals(). What are the reasons for this?
-
15The easiest thing is to try null checking with `equals()` and see. When you try it will instantly be obvious – Goran Jovic Dec 21 '10 at 15:50
-
By the way, a google search with keywords "java null check" (without quotes) gave me as one of the top hits [this thread](http://www.velocityreviews.com/forums/t151631-stringobj-null-vs-stringobj-equals-null-for-null-check.html), which has the same info as the answers here. – Mitch Schwartz Dec 21 '10 at 15:53
16 Answers
They're two completely different things. ==
compares the object reference, if any, contained by a variable. .equals()
checks to see if two objects are equal according to their contract for what equality means. It's entirely possible for two distinct object instances to be "equal" according to their contract. And then there's the minor detail that since equals
is a method, if you try to invoke it on a null
reference, you'll get a NullPointerException
.
For instance:
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

- 1,031,962
- 187
- 1,923
- 1,875
-
-
@Xepoch: No, I don't generally create public fields (although it doesn't really matter for this example either way). Why? – T.J. Crowder Dec 22 '10 at 16:11
-
@T.J. Crowder "They're two completely different things.." in general yes. However, the default implementation of both is the same, if my understanding is correct. Looking at the source code, .equals() basically does an == check. http://hg.openjdk.java.net/jdk7/jdk7/jdk/file/tip/src/share/classes/java/lang/Object.java – Ayush Jun 19 '20 at 09:25
-
1@Ayush - That's the default in `Object`, yes. It's overridden by a large number of the JDK classes, though. But the point about isn't about implementation, it's about semantics. (Side note: JDK7 is very out of date.) – T.J. Crowder Jun 19 '20 at 09:57
-
-
Wouldn't writing `null` create a new null value with a different reference? Why would the equality ever return `true`? – Roger Wang Oct 12 '20 at 05:53
-
2@RogerWang - Good question! The answer is that `null` isn't an object, it's an object *reference* (a blank one). It's the only object reference we can write literally in code. So `Object a = null; Object b = null;` means that `a == b` is true, because both variables contain the same object reference (the single universal blank one). – T.J. Crowder Oct 12 '20 at 06:41
In addition to the accepted answer (https://stackoverflow.com/a/4501084/6276704):
Since Java 1.7, if you want to compare two Objects which might be null, I recommend this function:
Objects.equals(onePossibleNull, twoPossibleNull)
java.util.Objects
This class consists of static utility methods for operating on objects. These utilities include null-safe or null-tolerant methods for computing the hash code of an object, returning a string for an object, and comparing two objects.
Since: 1.7

- 3,196
- 2
- 23
- 39
-
4Just to make it more visible for others (see chin90's answer or the [JavaDoc](https://docs.oracle.com/en/java/javase/13/docs/api/java.base/java/util/Objects.html#equals(java.lang.Object,java.lang.Object))): `Objects.equals(null, null)` will return `true` - keep that in mind. – Thomas Oct 08 '19 at 16:31
-
Intellij always suggests to use `Object.equals()` instead, when I use `==` in my code. – kaushalpranav Nov 04 '21 at 10:18
if you invoke .equals()
on null
you will get NullPointerException
So it is always advisble to check nullity before invoking method where ever it applies
if(str!=null && str.equals("hi")){
//str contains hi
}
Also See
-
49
-
4@user368186: the point isn't whether the equals method includes a null check. If your object reference is null, then the call `someObject.equals(null)` will raise a `NullPointerException` without ever entering the equals method. – Dave Costa Dec 21 '10 at 15:51
-
3
-
2It's always advisable to avoid nulls at all cost, so you don't need null checks at all ;). – cthulhu Dec 28 '10 at 15:44
-
4You can always use `Objects.equals(a, b)` It won't raise NullPointerException, but it still depends on the "equal" method of the "a" and "b" – Dominik Minc Sep 12 '16 at 07:36
In Java 0 or null are simple types and not objects.
The method equals() is not built for simple types. Simple types can be matched with ==.

- 339
- 2
- 8
-
6upvote for the actual answer that is most useful as opposed to the obvious "NullPointerException will be returned" herp derp answer. – volk Aug 20 '12 at 03:50
-
For “simple types” hope it’s understood that null is not a primitive type, rather it’s default value for object, and have some interesting facts: https://www.geeksforgeeks.org/interesting-facts-about-null-in-java/amp/ – Treefish Zhang Feb 05 '22 at 16:18
-
For the record, you can't have a primitive with a null value, so yes, OP wanted to check null safety of objects and not primitives. – Guilherme Taffarel Bergamin Feb 07 '22 at 20:06
Object.equals is null safe, however be aware that if two objects are null, object.equals will return true so be sure to check that the objects you are comparing aren't null (or hold null values) before using object.equals for comparison.
String firstname = null;
String lastname = null;
if(Objects.equals(firstname, lastname)){
System.out.println("equal!");
} else {
System.out.println("not equal!");
}
Example snippet above will return equal!

- 101
- 1
- 3
-
As stated by the [JavaDoc](https://docs.oracle.com/en/java/javase/13/docs/api/java.base/java/util/Objects.html#equals(java.lang.Object,java.lang.Object)) (it's always wise to read those): `Consequently, if both arguments are null, true is returned. ...` :) – Thomas Oct 08 '19 at 16:27
-
I mean... if both are null, they are indeed equal... I think that should be obvious to anybody using `Objects.equals()` – Guilherme Taffarel Bergamin Feb 07 '22 at 20:09
foo.equals(null)
What happens if foo is null?
You get a NullPointerException.

- 3,563
- 2
- 21
- 28
If an Object variable is null, one cannot call an equals() method upon it, thus an object reference check of null is proper.

- 10,359
- 13
- 53
- 61
If we use=> .equals method
if(obj.equals(null))
// Which mean null.equals(null) when obj will be null.
When your obj will be null it will throw Null Point Exception.
so we should use ==
if(obj == null)
it will compare the references.

- 4,873
- 1
- 24
- 38

- 182
- 1
- 8
here is an example where str != null
but str.equals(null)
when using org.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:
here is the org.json.JSONObject$Null class:
/**
* 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;
}
}

- 4,039
- 6
- 39
- 67
-
The issue here is that `field.equals(null)` returns true. This breaks usual Java behaviour and is therefore confusing. It should only work for `field.equals("null")`, at least in my point of view. I don't know why the library developers thought, that this would be good to support. – Tom Dec 10 '16 at 20:55
-
Btw, your first sentence has a grammar issue and it is unclear what you mean with it. Do you mean "Here is an example where `str != null` and `str.equals(null)` return `true` when using *org.json*."? – Tom Dec 10 '16 at 20:56
-
I think that's because the `jsonObject` contains the "field" key that's why `field` isn't null, it has a reference which contains the `json.org.JSONObject$Null` object – dina Dec 10 '16 at 21:23
-
Yes, but I wouldn't treat `Null` like `null` and would use `"null"` instead. But I guess they did that to avoid requiring Strings. But even with that lib, `field.equals(null)` is still *almost* always an issue :P. – Tom Dec 10 '16 at 21:53
If you try calling equals on a null object reference, then you'll get a null pointer exception thrown.

- 7,693
- 6
- 33
- 37
According to sources it doesn't matter what to use for default method implementation:
public boolean equals(Object object) {
return this == object;
}
But you can't be sure about equals
in custom class.

- 6,557
- 5
- 31
- 52
-
It matters, since `equals` can only return `false` or cause a `NullPointerException` (or something different if the overriden `equals` method is nonsense). – Tom Dec 26 '15 at 18:04
Because equal is a function derived from Object class, this function compares items of the class. if you use it with null it will return false cause cause class content is not null. In addition == compares reference to an object.

- 18,479
- 29
- 135
- 200
-
Well, the result can only be `false` or `NullPointerException` (if `equals` is not overriden to something bad). – Tom Dec 26 '15 at 18:14
So I never get confused and avoid problems with this solution:
if(str.trim().length() <=0 ) {
// is null !
}

- 41
- 2
-
6
-
Additionally an _empty_ string (`""` having length 0) is something entirely different than a `null` reference (i.e. _no_ string). – Thomas Oct 08 '19 at 16:24
I have encountered this case last night.
I determine that simply that:
Don't exist equals() method for null
So, you can not invoke an inexistent method if you don't have
-->>> That is reason for why we use == to check null

- 107
- 1
- 4
You code breaks Demeter's law. That's why it's better to refactor the design itself. As a workaround, you can use Optional
obj = Optional.ofNullable(object1)
.map(o -> o.getIdObject11())
.map(o -> o.getIdObject111())
.map(o -> o.getDescription())
.orElse("")
above is to check to hierarchy of a object so simply use
Optional.ofNullable(object1)
if you have only one object to check
Hope this helps !!!!

- 3,882
- 25
- 20
You could always do
if (str == null || str.equals(null))
This will first check the object reference and then check the object itself providing the reference isnt null.

- 1,012
- 3
- 11
- 24
-
-
i used your answer and added a check for an empty string! if im not mistaken, null and "" are not the same thing. – Lou Morda Sep 21 '12 at 17:21
-
4
-
2@JustinRowe It is not only redundant, it is also _very_ wrong. Please, never do something like `x.equals(null)`. – Tom Dec 26 '15 at 12:04
-
@Tom, JustinRowe please see my answer above why this isn't redundant nor complete garbage http://stackoverflow.com/questions/4501061/java-null-check-why-use-instead-of-equals/41079420#41079420 – dina Dec 10 '16 at 19:34
-
@dina: Your post refers to Object compare, not String compare. It is not applicable to this post (assuming that str is a String which seems to be a safe assumption...) – Justin Rowe Jun 21 '18 at 09:58