Why Does <equals()> Method on Arrays Always Return False?

[kvnsmnsn]

I spent August 2004 to December 2005 as a teaching assistant to the
Intro to Computer Science class here at BYU, that used Java. One
thing we've been very careful to tell the students is that if you want
to check for equality of two objects in Java, you use the <equals()>
method, not the "==" operator. The <equals()> method is inherited by
every object from the <Object> class, so you can pretty much call it
on everything.

But I just found out that if you create an array of <int>s and popu-
late it with the very same values as you have in another array of
<int>s, and then call the <equals()> method on the two arrays, it re-
turns <false>, even though the two arrays are identical. Anyone know
why this is doing this? What use is the <equals()> method defined for
each array if I can't use it to tell whether two arrays are equal?

---Kevin Simonson

"You'll never get to heaven, or even to LA,
if you don't believe there's a way."
from _Why Not_

public class EqualsCheck
{
public static void main ( String[] arguments)
{
int[] original = new int[ 1];
int[] copy = new int[ 1];

original[ 0] = 55;
copy[ 0] = 55;
if (original.equals( copy))
{ System.out.println( "Original equals copy.");
}
else
{ System.out.println( "Original doesn't equal copy.");
}
}
}

 

[Roedy Green]

But I just found out that if you create an array of <int>s and popu-
late it with the very same values as you have in another array of
<int>s, and then call the <equals()> method on the two arrays, it re-
turns <false>, even though the two arrays are identical. Anyone know
why this is doing this? What use is the <equals()> method defined for
each array if I can't use it to tell whether two arrays are equal?

Object.equals just acts like == and that is what array uses. You'd
think it makes so sense to have .equals defined as == for an array,
since if that is what you wanted you could always use ==.

However, your desired equals definition is much slower than ==. ==
style equals would normally suffice for HashMap work. That is why they
probably defined array equals that way.

 

[Adam Maass]

I spent August 2004 to December 2005 as a teaching assistant to the
Intro to Computer Science class here at BYU, that used Java. One
thing we've been very careful to tell the students is that if you want
to check for equality of two objects in Java, you use the <equals()>
method, not the "==" operator. The <equals()> method is inherited by
every object from the <Object> class, so you can pretty much call it
on everything.

But I just found out that if you create an array of <int>s and popu-
late it with the very same values as you have in another array of
<int>s, and then call the <equals()> method on the two arrays, it re-
turns <false>, even though the two arrays are identical. Anyone know
why this is doing this? What use is the <equals()> method defined for
each array if I can't use it to tell whether two arrays are equal?

Short answer: because the classes for arrays don't override the equals()
methods to do this.

Longer answer: probably because Sun didn't think about this. Furthermore,
today, java.util.Arrays.equals provides this functionality.

 

[Oliver Wong]

I just found out that if you create an array of <int>s and popu-
late it with the very same values as you have in another array of
<int>s, and then call the <equals()> method on the two arrays, it re-
turns <false>, even though the two arrays are identical. Anyone know
why this is doing this? What use is the <equals()> method defined for
each array if I can't use it to tell whether two arrays are equal?

[...]

Longer answer: probably because Sun didn't think about this.

To be fair, the semantics of "equality" is somewhat context dependent,
in that in some cases, for two arrays to be "equal", all that needs to be
true is that each of its elements are also "equal". In other cases, for two
arrays to be "equal", all that needs to be true is for its elements to be
identical (as in ==). In yet other cases, other semantics might apply.

This is one reason why I wish there was something like the Comparator
interface for equality, so that you could use a different EqualityChecker
object for different semantics.

It's somewhat "dirty" to use Comparator as an EuqualityChecker, and just
check about whether the compareTo() method returns == 0 or != 0, because
Comparator implies a total ordering over the instances of types, which might
not make sense for the data you're working with.

- Oliver

 

[Adam Maass]

To be fair, the semantics of "equality" is somewhat context dependent,
in that in some cases, for two arrays to be "equal", all that needs to be
true is that each of its elements are also "equal". In other cases, for
two arrays to be "equal", all that needs to be true is for its elements to
be identical (as in ==). In yet other cases, other semantics might apply.

This is one reason why I wish there was something like the Comparator
interface for equality, so that you could use a different EqualityChecker
object for different semantics.

It's somewhat "dirty" to use Comparator as an EuqualityChecker, and
just check about whether the compareTo() method returns == 0 or != 0,
because Comparator implies a total ordering over the instances of types,
which might not make sense for the data you're working with.

Long ago and far away, I did a significant amount of programming in Lisp.
Lisp has at least four different notions of equality:

eq
eql
equal
=


If I remember aright, eq tested that the two operands were bound to the same
object; eql evaluted to t if its operands were eq or if its operands were
lists whose elements were pairwise eq; equal evaluated to t if its operands
were eql or if its operands were lists that were pairwise eql.

Essentially, the longer the funtion name, the deeper the compare.

And = was for use with numeric quantities.

 

[Tony Morris]

This is one reason why I wish there was something like the Comparator

interface for equality, so that you could use a different EqualityChecker
object for different semantics.

There is. http://contractualj.com/api/net/tmorris/adt/Equalable.html

What you are eluding to, even if you don't know it, is that the OO paradigm
as we know it, is implicitly in contradiction to a formally stated
requirement specification. Think about it some more.