The contract of <code>equals</code> with regards to <code>null</code>, is as follows: <blockquote> For any non-null reference value <code>x</code>, <code>x.equals(null)</code> should <code>return false</code>. </blockquote> This is rather peculiar, because if <code>o1 != null</code> and <code>o2 == null</code>, then we have: <pre class="prettyprint"><code>o1.equals(o2) // returns false o2.equals(o1) // throws NullPointerException </code></pre> The fact that <code>o2.equals(o1) throws NullPointerException</code> is a good thing, because it alerts us of programmer error. And yet, that error would not be catched if for various reasons we just switched it around to <code>o1.equals(o2)</code>, which would just "silently fail" instead. So the questions are: <ul> <li>Why is it a good idea that <code>o1.equals(o2)</code> should <code>return false</code> instead of throwing <code>NullPointerException</code>?</li> <li>Would it be a bad idea if wherever possible we rewrite the contract so that <code>anyObject.equals(null)</code> always throw <code>NullPointerException</code> instead?</li> </ul> <hr> <h3>On comparison with <code>Comparable</code> </h3> In contrast, this is what the <code>Comparable</code> contract says: <blockquote> Note that <code>null</code> is not an instance of any class, and <code>e.compareTo(null)</code> should throw a <code>NullPointerException</code> even though <code>e.equals(null)</code> returns <code>false</code>. </blockquote> If <code>NullPointerException</code> is appropriate for <code>compareTo</code>, why isn't it for <code>equals</code>? <h3>Related questions</h3> <ul> <li>Comparable and Comparator contract with regards to null</li> </ul> <hr> <h3>A purely semantical argument</h3> These are the actual words in the <code>Object.equals(Object obj)</code> documentation: <blockquote> Indicates whether some other object is "equal to" this one. </blockquote> And what is an object? <h3>JLS 4.3.1 Objects</h3> <blockquote> An object is a class instance or an array. The reference values (often just references) are pointers to these objects, and a special <code>null</code> reference, which refers to no object. </blockquote> My argument from this angle is really simple. <ul> <li> <code>equals</code> tests whether some other object is "equal to" <code>this</code> </li> <li> <code>null</code> reference gives no other object for the test</li> <li>Therefore, <code>equals(null)</code> should throw <code>NullPointerException</code> </li> </ul>

To the question of whether this asymmetry is inconsistent, I think not, and I refer you to this ancient Zen kōan: <ul> <li>Ask any man if he's as good as the next man and each will say yes. </li> <li>Ask any man if he's as good as nobody and each will say no.</li> <li>Ask nobody if it's as good as any man and you'll never get a reply.</li> </ul> At that moment, the compiler reached enlightenment.

Is it a bad idea if equals(null) throws NullPointerException instead?

The contract of equals with regards to null, is as follows:

For any non-null reference value x, x.equals(null) should return false.

This is rather peculiar, because if o1 != null and o2 == null, then we have:

o1.equals(o2) // returns false o2.equals(o1) // throws NullPointerException

The fact that o2.equals(o1) throws NullPointerException is a good thing, because it alerts us of programmer error. And yet, that error would not be catched if for various reasons we just switched it around to o1.equals(o2), which would just "silently fail" instead.

So the questions are:

Why is it a good idea that o1.equals(o2) should return false instead of throwing NullPointerException?
Would it be a bad idea if wherever possible we rewrite the contract so that anyObject.equals(null) always throw NullPointerException instead?

On comparison with `Comparable`

In contrast, this is what the Comparable contract says:

Note that null is not an instance of any class, and e.compareTo(null) should throw a NullPointerException even though e.equals(null) returns false.

If NullPointerException is appropriate for compareTo, why isn't it for equals?

A purely semantical argument

These are the actual words in the Object.equals(Object obj) documentation:

Indicates whether some other object is "equal to" this one.

And what is an object?

JLS 4.3.1 Objects

An object is a class instance or an array.

The reference values (often just references) are pointers to these objects, and a special null reference, which refers to no object.

My argument from this angle is really simple.

equals tests whether some other object is "equal to" this
null reference gives no other object for the test
Therefore, equals(null) should throw NullPointerException

Is it good to throw NullPointerException?

Applications should throw instances of this class to indicate other illegal uses of the null object. Read the last sentence again: "Applications should throw instances of this class to indicate other illegal uses of the null object".

What happens if you compare an object to null using equals ()?

Code Correctness: null Argument to equals()equals(null) will always be false. The program uses the equals() method to compare an object with null . This comparison will always return false, since the object is not null . (If the object is null , the program will throw a NullPointerException ).

Can we use equals with null?

The equals() method is a static method of the Objects class that accepts two objects and checks if the objects are equal. If both the objects point to null , then equals() returns true .

Does equals null safe Java?

Bonus: Using Apache CommonsThe equals() method of StringUtils class is a null-safe version of the equals() method of String class, which also handles null values.

To the question of whether this asymmetry is inconsistent, I think not, and I refer you to this ancient Zen kōan:

Ask any man if he's as good as the next man and each will say yes.
Ask any man if he's as good as nobody and each will say no.
Ask nobody if it's as good as any man and you'll never get a reply.

At that moment, the compiler reached enlightenment.

Is it a bad idea if equals(null) throws NullPointerException instead?