• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

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

 
Ranch Hand
Posts: 41
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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?

 
Ranch Hand
Posts: 194
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator


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
Posts: 41
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 194
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 41
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 194
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.

 
Ranch Hand
Posts: 1032
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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():

 
Robert O'Leary
Ranch Hand
Posts: 41
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 1032
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 194
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 41
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 1032
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 1032
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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.
 
Are we home yet? Wait, did we forget the tiny ad?
a bit of art, as a gift, that will fit in a stocking
https://gardener-gift.com
reply
    Bookmark Topic Watch Topic
  • New Topic