aspose file tools*
The moose likes Programmer Certification (SCJP/OCPJP) and the fly likes Arrays comparsion: int[].equals() vs Arrays.equals() Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Certification » Programmer Certification (SCJP/OCPJP)
Bookmark "Arrays comparsion: int[].equals() vs Arrays.equals()" Watch "Arrays comparsion: int[].equals() vs Arrays.equals()" New topic
Author

Arrays comparsion: int[].equals() vs Arrays.equals()

Robert O'Leary
Ranch Hand

Joined: Mar 24, 2009
Posts: 41
Hi,

Just to clarify a point in my head. When you declare two int arrays and use .equals() on them directly (see line 7 in code), are you actually calling .equals() of Object? So only when the two references point to the same object that they're equal in that scenario?

Then, with Arrays.equals(): two arrays are considered equal if both arrays contain the same number of elements, and all corresponding pairs of elements in the two arrays are equal.

Am I right with my thinking on the first point?



SCJP6
Ryan Beckett
Ranch Hand

Joined: Feb 22, 2009
Posts: 192


This is false because a and b have different hash codes and in order for objects to be equal their hash codes must be equal. Print them.



This is true because the two references refer to the same object. '==' will be true too.



"two arrays are equal if they contain the same elements in the same order" - Arrays - Maybe hash codes are ignored when trying to compare deep copies.
Robert O'Leary
Ranch Hand

Joined: Mar 24, 2009
Posts: 41
Ryan Beckett wrote:

This is false because a and b have different hash codes and in order for objects to be equal their hash codes must be equal. Print them.


Ryan, I think youre on the wrong track there. Hashcodes are not relevant here, they are used for collections such as HashSet and HashMap. A hashcode determines which bucket an object is stored in. It is used to retrieve objects quickly from large collections. What Im talking about here is equivalency of int arrays.

Can anyone else answer my question?
Ryan Beckett
Ranch Hand

Joined: Feb 22, 2009
Posts: 192
Sorry fellow, I'm going to have to slap you with a big fat Nooo.

If the hash codes of two object values are different, the object values are guaranteed to be different. However, if the hash codes of two object values are the same, the object values are not guaranteed to be the same. An additional call to Object.equals() must be made to confirm that the object values are the same. A good hash code algorithm will minimize the chance of two different values having the same hash code.


Read This

Like I said, print the hash codes.

Also, hash codes are always relevant when comparing objects, because you have to override Object.equals to make meaningful comparisons which means you have to override Object.hashCode correctly. As as far as Collections go, yes, sets (and don't forget maps) rely on Object.equals as well.
Robert O'Leary
Ranch Hand

Joined: Mar 24, 2009
Posts: 41
Ryan Beckett wrote:Sorry fellow, I'm going to have to slap you with a big fat Nooo.

If the hash codes of two object values are different, the object values are guaranteed to be different. However, if the hash codes of two object values are the same, the object values are not guaranteed to be the same. An additional call to Object.equals() must be made to confirm that the object values are the same. A good hash code algorithm will minimize the chance of two different values having the same hash code.


Read This

Like I said, print the hash codes.

Also, hash codes are always relevant when comparing objects, because you have to override Object.equals to make meaningful comparisons which means you have to override Object.hashCode correctly. As as far as Collections go, yes, sets (and don't forget maps) rely on Object.equals as well.


I saw that the hashcodes are different. Thanks for the link Ryan, it helped but Im not there yet.

For the case of a primitive array. It is not a collection of user-defined objects and I havent overidden equals() and hashCode(). I know as per hashcode contract if a.equals(b) == true, then a.hashCode() == b.hashCode(). BUT what is the reason that a.equals(b) is not true? What is the basis?

Ryan Beckett
Ranch Hand

Joined: Feb 22, 2009
Posts: 192
I really can't into much more detail, but I did find this:

As much as is reasonably practical, the hashCode method defined by class Object does return distinct integers for distinct objects. (This is typically implemented by converting the internal address of the object into an integer, but this implementation technique is not required by the JavaTM programming language.)


java.lang.Object

Now I'm official confused because this code prints "They're equal" and prints two different hash codes.

Ruben Soto
Ranch Hand

Joined: Dec 16, 2008
Posts: 1032
The hashCode() discussion is irrelevant. When you use equals() directly on an array, you are using Object.equals(Object), which simply checks to see if both references are the same (in other words, the only way that two references can be equal is if both references point to the same object in the heap.)

Now, there are several overloaded Arrays.equals() methods. You are using Arrays.equals(int[]) in your code, which works as expected. When you work with multidimensional arrays you end up having to work with Arrays.equals(Object), and then it's when surprises can take place, and when you need to look into deepEquals():



All code in my posts, unless a source is explicitly mentioned, is my own.
Robert O'Leary
Ranch Hand

Joined: Mar 24, 2009
Posts: 41
Ryan Beckett wrote:I really can't into much more detail, but I did find this:

As much as is reasonably practical, the hashCode method defined by class Object does return distinct integers for distinct objects. (This is typically implemented by converting the internal address of the object into an integer, but this implementation technique is not required by the JavaTM programming language.)


java.lang.Object


Ryan I appreciate the hustle!

What I think it is..is that basically a primitive array is considered an Object. So when you call equals() on a primitve array, you are calling equals() of Object. And in the API of Object, for equals() it states:

The equals method for class Object implements the most discriminating possible equivalence relation on objects; that is, for any non-null reference values x and y, this method returns true if and only if x and y refer to the same object (x == y has the value true).


So essentially for comparing primitive arrays: a.equals(b) is the same as saying a == b.

Does that make sense to you Ryan?

If anyone else can clarify this it would be great, but that what i think it is anyway
Ruben Soto
Ranch Hand

Joined: Dec 16, 2008
Posts: 1032
Robert, you got it. Look at my previous post for a little more detail, but what you said is exactly true.
Ryan Beckett
Ranch Hand

Joined: Feb 22, 2009
Posts: 192
Ahhh... very nice. I knew that arrays are objects, but I didn't Object.equals acts that way. So, I guess when you override, then it compares based on meaningful data instead of addresses.
Robert O'Leary
Ranch Hand

Joined: Mar 24, 2009
Posts: 41
Ruben Soto wrote:Robert, you got it. Look at my previous post for a little more detail, but what you said is exactly true.


Top man Rueben! I was looking at lots of questions today and my head was start to spin. Then it came to me when I took a break!
Ruben Soto
Ranch Hand

Joined: Dec 16, 2008
Posts: 1032
Ryan Beckett wrote:Ahhh... very nice. I knew that arrays are objects, but I didn't Object.equals acts that way. So, I guess when you override, then it compares based on meaningful data instead of addresses.

Ryan,

Here's the fun part: This is the exact implementation of equals(Object) in the Object class (you can look at the source code, which is provided by Sun):



Doesn't get any siimpler than that. I also thought it would be a little more complicated than that, but I looked in the source code and that's all there is to it.
Ruben Soto
Ranch Hand

Joined: Dec 16, 2008
Posts: 1032
Robert O'Leary wrote:
Ruben Soto wrote:Robert, you got it. Look at my previous post for a little more detail, but what you said is exactly true.


Top man Rueben! I was looking at lots of questions today and my head was start to spin. Then it came to me when I took a break!

It has happened to me to, brother. It pays to take breaks every once in a while. Also, I think your head was spinning too fast, 'cause you got my name wrong.
 
wood burning stoves
 
subject: Arrays comparsion: int[].equals() vs Arrays.equals()