Jesper de Jong wrote:What does your class SlidingState look like; especially the hashCode() and equals() methods of that class?
Jesper de Jong wrote:What does your class SlidingState look like; especially the hashCode() and equals() methods of that class?
Henry Wong wrote:
Jesper de Jong wrote:What does your class SlidingState look like; especially the hashCode() and equals() methods of that class?
Also the compareTo() method -- since TreeSet uses the Comparable (or optionally, Comparator) interface, instead of the hashCode() and equals() methods.
Henry
Yogesh Gandhi wrote:
Ideally you need not look, how hashCode/equals is implemented... as long as the output is correct....
When the System out statements are making sure, that hashCode of both the objects are different...
The most interesting thing here to note is,..............I am able to add the same two States to HashSet..........but not to TreeSet
Yogesh Gandhi wrote:Ideally you need not look, how hashCode/equals is implemented... as long as the output is correct....
"Leadership is nature's way of removing morons from the productive flow" - Dogbert
Articles by Winston can be found here
Henry Wong wrote:
Yogesh Gandhi wrote:
Ideally you need not look, how hashCode/equals is implemented... as long as the output is correct....
When the System out statements are making sure, that hashCode of both the objects are different...
The most interesting thing here to note is,..............I am able to add the same two States to HashSet..........but not to TreeSet
Unfortunately, it is not ideal... TreeSet doesn't use hashCode/equals, so it doesn't matter if the output is correct. How about running the two objects via compareTo() and see if the output is also correct. That method should return zero of the two objects are equal.
[EDIT: It looks like you figure it out ... great]
Henry
Winston Gutkowski wrote:
Yogesh Gandhi wrote:Ideally you need not look, how hashCode/equals is implemented... as long as the output is correct....
Erm...but clearly it ISN'T.
Also, your statement: "Both the objects have different hashCode... That means, definitely the objects are different."
is absolutely WRONG.
Different objects CAN have the same hashCode() (indeed, it's impossible to prevent). The only (I'll say again: ONLY) requirement is that equal objects have the same hashcode.
The only thing that a GOOD hashcode will do is allow you to assume that objects with different hashcode are probably not equal().
Does that help?
Winston
Yogesh Gandhi wrote:There is a equal-hashcode contract...
1) Equal objets will have equal Hashcode...
So, you can read it like this also...
If hashcodes are not equal, that means objects are not equal.....
"Leadership is nature's way of removing morons from the productive flow" - Dogbert
Articles by Winston can be found here
Winston Gutkowski wrote:
Yogesh Gandhi wrote:There is a equal-hashcode contract...
1) Equal objets will have equal Hashcode...
So, you can read it like this also...
If hashcodes are not equal, that means objects are not equal.....
No you CAN'T.
I suspect you'll need to think about it, but those two statements are not universal negatives.
It's akin (but not quite; but I'm not an expert in semiotics) to saying "All daffodils are yellow, therefore all things that are yellow are daffoldils."
Winston
Yogesh Gandhi wrote:A and B are two objects having different hashcodes....
Now, as the hashcodes are different, we can say objects are different...
"Leadership is nature's way of removing morons from the productive flow" - Dogbert
Articles by Winston can be found here
A hashcode does NOT tell you if two objects are the same; it tells you if they're different.
Yogesh Gandhi wrote:If hashcodes are different, that means objects are different.
"Leadership is nature's way of removing morons from the productive flow" - Dogbert
Articles by Winston can be found here
Winston Gutkowski wrote:
Yogesh Gandhi wrote:If hashcodes are different, that means objects are different.
But that's NOT the same as saying that if they are the same, then the two objects are equal. Like I say, you have to think about it. Hashcodes are designed for a very specific purpose - to store objects in hashed collections - and they rely on difference, not similarity.
Winston
Henry Wong wrote:
you can't use the hashcode to confirm that two objects are definitely different -- it will sometimes fail to work.
Yogesh Gandhi wrote:
Henry Wong wrote:
you can't use the hashcode to confirm that two objects are definitely different -- it will sometimes fail to work.
I disagree.. Please prove with example. (I am assuming contract is adhered).
Equal objects cannot produce distinct hashcodes.... (so if hashcodes are different, that means objects are different...........NO EXCEPTIONS......it will always hold true)...
As you said, it may sometime fail........can you help us with an example?
Henry Wong wrote:
Yogesh Gandhi wrote:
Henry Wong wrote:
you can't use the hashcode to confirm that two objects are definitely different -- it will sometimes fail to work.
I disagree.. Please prove with example. (I am assuming contract is adhered).
Equal objects cannot produce distinct hashcodes.... (so if hashcodes are different, that means objects are different...........NO EXCEPTIONS......it will always hold true)...
As you said, it may sometime fail........can you help us with an example?
Check my wording -- I was very exact about it (because this is a subtle discussion). Or perhaps I should add "just" to make it clearer. You can't just use the hashcode to confirm that two objects are different.
Simple example. I have two different objects with the exact same hashcode. This is valid according to the contract. In this case, just using the hashcode test will fail -- you will need to follow up with the equals() method to confirm that they are different.
Henry
Heena Agarwal wrote:
We all know what the output would be.
Heena Agarwal wrote:Yes Jesper, I get what you are saying. His compareTo method isn't consistent with his equals and hashCode methods, which, like you said is the root cause of the problem. :-)
The OP needs to fix that.
Yogesh Gandhi wrote:Guys !!! is there still any confusion left to anyone?
"Leadership is nature's way of removing morons from the productive flow" - Dogbert
Articles by Winston can be found here
There are three kinds of actuaries: those who can count, and those who can't.
Heena Agarwal wrote:
We all know what the output would be.
Obviously an object has one hashCode. So we can't test why different hashCodes may not imply different objects by just invoking the hashCode method. Let us not know in advance that we have one object only. Let us put this object in a collection and then use hashCode to see if the hashCode alone can tell us if two objects are different.
true
41
true
51
2
Heena Agarwal wrote:Yes Jesper, I get what you are saying. His compareTo method isn't consistent with his equals and hashCode methods, which, like you said is the root cause of the problem. :-)
The OP needs to fix that.
Winston Gutkowski wrote:No. And my apology if I was the cause
Yogesh Gandhi wrote:So the bottom line is.........
Be cautious when you override, compareTo.............it must stick with the contract of equals and hashcode..........Would that be a right conclusion?
"Leadership is nature's way of removing morons from the productive flow" - Dogbert
Articles by Winston can be found here