• Post Reply Bookmark Topic Watch Topic
  • New Topic

Regarding Hashcode  RSS feed

 
Ranch Hand
Posts: 165
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
hi,

If two objects are equals then its hash-code are equals


is the reverse...that is if two objects hash-code are equals then they are equal


And when exactly are two objects equals can one please let me know..
 
Bartender
Posts: 6109
6
Android IntelliJ IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
deepak carter wrote:hi,

If two objects are equals then its hash-code are equals


That's the rule, yes, but it only works if you write equals() and hashCode() correctly. If you do it wrong, you may end up breaking the rule and then your class won't work in a hash-based data structure.

is the reverse...that is if two objects hash-code are equals then they are equal


No. Unequal objects can have equal hashCodes. A proper hashing function yielding a good distribution will make this unlikely for any two random objects, however.

And when exactly are two objects equals can one please let me know..


Whenever the designer of the class decides they are, as expressed by how he implements the equals() method.

 
deepak carter
Ranch Hand
Posts: 165
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
suppose there is a instance variable age in a class person.i create two object o1 and o2 of that class person.the objects o1 and o2 are considered equal when there
age matches ??? and equality is checked by equals operator?
 
Java Cowboy
Sheriff
Posts: 16060
88
Android IntelliJ IDE Java Scala Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
What do you mean with "equals operator"? Do you mean ==?

The equals() method of a class is what defines what it means for two objects of that class to be equal.

The hashCode() method of the class must be implemented in such a way that if a.equals(b) is true, then a.hashCode() must be the same as b.hashCode().

But the other way around does not need to be true. So if a.equals(b) is false, then it doesn't matter if a.hashCode() and b.hashCode() are the same or not.
 
deepak carter
Ranch Hand
Posts: 165
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
i am talking about equals operator.
 
Sheriff
Posts: 21136
87
Chrome Eclipse IDE Java Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
deepak carter wrote:suppose there is a instance variable age in a class person.i create two object o1 and o2 of that class person.the objects o1 and o2 are considered equal when there
age matches ???

Only if you the person class overrides equals to return true if the passed object is a person with the same age.

and equality is checked by equals operator?

Yes.

About equal hash codes not necessarily meaning equal objects, there is a very good reason for this. hashCode() returns an int. That means that there are only 2^32 possible return values. If equal hash codes would mean equal objects, that would mean that you could have no more than 2^32 different objects inside your application. That may seem like a lot, but in larger, long-running applications it is not uncommon to have a multitude of this number.
 
Jeff Verdegan
Bartender
Posts: 6109
6
Android IntelliJ IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
deepak carter wrote:suppose there is a instance variable age in a class person.i create two object o1 and o2 of that class person.the objects o1 and o2 are considered equal when there
age matches ???


If that's how you choose to write it.

and equality is checked by equals operator?


The X.equals(Y) is used to test whether the state ("contents") of object X is equal to the state of object Y, by whatever rules the designer of X's class thought would be appropriate. In the implementation of equals(), there may be uses of ==, or equals(), or both.
 
Jeff Verdegan
Bartender
Posts: 6109
6
Android IntelliJ IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
deepak carter wrote:i am talking about equals operator.


== is an operator.
equals() is a method.
 
deepak carter
Ranch Hand
Posts: 165
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
i am bit confused about this equals method.in the previous post you mentioned that it all happens on the desugn...can you give any example as what i am think is that
when when we think abt equality of object we are thinking the contents which two objects holds are equal or not.
 
Bartender
Posts: 4568
9
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I'll have a go.

The == operator will only ever check whether the two arguments are actually referencing the same object. It doesn't care about the contents of the object.

By default, the equals() method (the version of equals() in the Object class) does the same thing. It only considers two objects to be the same if they are the same object. However, this method can be overridden.

So it is up to the designer of a class to decide what it means for two objects of that class to be equal. They should then override equals() to implement that decision. There are lots of examples in the core Java libraries: e.g. String overrides equals() to check the value of the characters. HashMap overrides equals() to make two sets with the same contents equal. But there are plenty that don't. E.g. JPanel doesn't - why would you want to consider two different JPanels to be equal?

So when you write a class, you should decide what "equals" means. And then you should implement equals() accordingly. The compiler doesn't know what the class is for, so it can't make this decision for you. If you want to consider two of your objects to be the same if they have the same age value, fine, implement equals() to check that. If you want equality to depend on name, check that. If you want it to depend on name and age, check them both. If you decide that two different objects should never be considered equal regardless of their contents, do nothing - the default implementation does what you want.

And then, if you have overridden equals(), that's when you have to override hashCode() as well to make sure it's consistent.

Is that any clearer?
 
Jeff Verdegan
Bartender
Posts: 6109
6
Android IntelliJ IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
deepak carter wrote:i am bit confused about this equals method.in the previous post you mentioned that it all happens on the desugn...can you give any example as what i am think is that
when when we think abt equality of object we are thinking the contents which two objects holds are equal or not.


The most common approach is probably that you just compare all the fields. Another approach might be that there's a single identity field and you just compare that one. Or you might compare fields that make up the "state" of the object and ignore "bookkeeping" fields. Or you might compare using some aspect of the public interface according to higher level semantics, without caring about specific field values at all.

It really depends on what kind of class you're designing and what makes sense in the context of your design for that class.

A couple of quick examples:

A String is equal to another object if and only if that object is also a String, and if it has the same sequence of characters in the same order. So String's equals must check the class of the object, probably checks if the lengths are equal, and then compares the char array char-by-char.

A java.util.List is equal to another object iff and only if that object is also a java.util.List, and only if it has the same elements in the same sequence. This is an example of the last kind of equality test I mentioned above. An ArrayList can be equal to a LinkedList or to any List that you might write. So a list implementation can't use getClass() like String might do. It has to check for instanceof List, and then it has to iterate over the other list and over itself and compare elements. It can't compare fields directly, since it can't know ahead of time what class the other object will be.

You can find the source code for these in src.zip that came with your JDK download. And you can google for something like java equals examples or java equals tutorial for more. (And really, you should have done that before posting here.)
 
Greenhorn
Posts: 24
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
If two objects are equals then its hash-code are equals?
is the reverse...that is if two objects hash-code are equals then they are equal

[ If two objects hash-code are equal its equals may or may not be equal. ]


And when exactly are two objects equals?

[The objects are equals when the equals method return true in the comparison for the objects ]
 
Jeff Verdegan
Bartender
Posts: 6109
6
Android IntelliJ IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
suraj aryan wrote:If two objects are equals then its hash-code are equals?
is the reverse...that is if two objects hash-code are equals then they are equal


No, that's incorrect. You can read hashCode()'s javadocs to verify this. We can also prove it with a simple thought experiment: There are 2^32 possible values for hashCode(). There are 2^64 possible values for Long. By the pigeonhole principle, many Long values will have the same hashCode, but clearly those Longs are not all equal.

The rule is: Equal objects must have equal hashCodes, but unequal objects can have equal or uneqal hashCodes.

[ If two objects hash-code are equal its equals may or may not be equal. ]


Yes, that is correct, and it contradicts what you just said above.


And when exactly are two objects equals?

[The objects are equals when the equals method return true in the comparison for the objects ]


Yes, as already stated: They're equal whenever the designer of the class decides they are, as expressed by the equals() method.
 
Don't get me started about those stupid light bulbs.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!