What difference exactly will come for this case if I override hashcode and equals?

[Campbell Ritchie]

Yesterday, I wrote:And do you understand those implementations? Tell us what differences you may see if . . . .

...and got no reply. I hope that means you think my questions are so easy that it would be beneath your dignity to answer them. I hope it doesn't mean that you prefer us to give you the answers like some sort of sp‍oon‑feeding. Remember that this forum, programming, and the whole of life have this in common: the more you put into it, the more you will get out.

[Monica Shiralkar]

Campbell Ritchie wrote:[..and got no reply. I hope that means you think my questions are so easy that it would be beneath your dignity to answer them.

Not at all. If something is simple and direct for me to answer immediately, I do that. Else , I analyze and answer. Specially when the post thread goes longer, then the depth of the level of things discussed increases and requires some analysis for me intead of simply answering. Sorry if it appeared otherwise.

[Monica Shiralkar]

Campbell Ritchie wrote: Remember that this forum, programming, and the whole of life have this in common: the more you put into it, the more you will get out.

True. Thanks.

[Monica Shiralkar]

Campbell Ritchie wrote:And do you understand those implementations

For hashcode, it creates a unique number to return.

For equals method it lets us specify that in what case should the objects be considered equal.

Campbell Ritchie wrote:And do you understand those implementations? Tell us what differences you may see if you use... getClass() != obj.getClass() ...as opposed to... !getClass().equals(obj.getClass()) ...or... !(obj instanceof Foo) ... // Foo=name of current class

First one will will check for the object reference to be same. The second should be used in case of checking if Strings are having the same content. The third one checks if it belongs to that type in the hierarchy.

but you can reduce the multiple returns to one like this

Yes and how about simply using as below:

public boolean equals(Object obj) {
        return (this.name.equals(((Person) obj).name) && this.age == ((Person) obj).age);
    }

Does it matter which order the subexpressions are evaluated in?

Left to right inside the braces.

[Campbell Ritchie]

Monica Shiralkar wrote:. . . For hashcode, it creates a unique number to return.

Disagree.

System.out.printf("%h %h%n", "Monica", "NNnica");

For equals method it lets us specify that in what case should the objects be considered equal.

Agree

Campbell Ritchie wrote:. . . Tell us what differences you may see if you use... getClass() != obj.getClass() ...as opposed to... !getClass().equals(obj.getClass()) ...or... !(obj instanceof Foo) ... // Foo=name of current class

First one will will check for the object reference to be same. The second should be used in case of checking if Strings are having the same content. The third one checks if it belongs to that type in the hierarchy.

You have the checks right, but the order wrong. If you test String equality before type equality, what will happen?
You misunderstood which question I was actually asking. I wanted to know the difference between the three lines numbered 16, 16, and 14 in the code above. Assume you are in a class called Foo.

. . . Yes and how about simply using as below: . . .

Tell me which of the five bullet points in the general contract of equals() you are going to violate.

Does it matter which order the subexpressions are evaluated in?

Left to right inside the braces.

What would happen if you wrote the subexpressions in a different order?

[Campbell Ritchie]

Earlier, I wrote:

System.out.printf("%h %h%n", "Monica", "NNnica");

The following works better:-

System.out.printf("%h %h%n", "Monica", "NPnica");

[Monica Shiralkar]

Disagree

Hashcode has to return an integer which would be same for elements inserted in the same hash buckets. But I am not sure how the above code generated by Eclipse does that.


I am not sure how both game the same results. What is the reason why both gave same hashcode?

	System.out.printf("%h %h%n", "Monica", "NNnica");
		System.out.printf("%h %h%n", "Monica", "NPnica");

You have the checks right, but the order wrong. If you test String equality before type equality, what will happen?

Are you talking about the below code which I had written?

public boolean equals(Object obj) {
        return (this.name.equals(((Person) obj).name) && this.age == ((Person) obj).age);
    }

I think in this braces are missing after && and it should be instead like below:

public boolean equals(Object obj) {
        return (this.name.equals(((Person) obj).name) && (this.age == ((Person) obj).age));
    }

You have the checks right, but the order wrong

Not sure about how order matters in this case as it is AND condition.

I wanted to know the difference between the three lines numbered 16, 16, and 14 in the code above.

As per my understanding:
First 16: will check for the object reference to be same.
Second 16:   will check if Strings are having the same content.
14: will check if it belongs to that type in the hierarchy.



Not sure about which one of the below would my code be voilating:

It is reflexive: for any non-null reference value x, x.equals(x) should return true.
It is symmetric: for any non-null reference values x and y, x.equals(y) should return true if and only if y.equals(x) returns true.
It is transitive: for any non-null reference values x, y, and z, if x.equals(y) returns true and y.equals(z) returns true, then x.equals(z) should return true.
It is consistent: for any non-null reference values x and y, multiple invocations of x.equals(y) consistently return true or consistently return false, provided no information used in equals comparisons on the objects is modified.
For any non-null reference value x, x.equals(null) should return false.

What would happen if you wrote the subexpressions in a different order?

As per my understanding that matters in case of OR not AND.

[Campbell Ritchie]

Monica Shiralkar wrote:. . . same for elements inserted in the same hash buckets. . . . .

No, it is the other way round. The hash code is calculated according to its formula and the Map decides where to locate the corresponding Entry.

What is the reason why both gave same hashcode? . . .

Because such a question has come up here before. Because I can remember how a String calculates its hash code.

Are you talking about the below code which I had written?

No.

. . . I think in this braces are missing after && and it should be instead like below:. . . .

They aren't called braces; they are round brackets or parentheses. Only say “round brackets” in Britain. The extra () are not essential

. . .
As per my understanding:
First 16: will check for the object reference to be same.
Second 16:   will check if Strings are having the same content.
14: will check if it belongs to that type in the hierarchy.

I meant the lines in the following code.... getClass() != obj.getClass() ...... !getClass().equals(obj.getClass()) ...... !(obj instanceof Foo) ... // Foo=name of current classIf you were thinking of that code, you are completely wrong.

Not sure about which one of the below would my code be voilating:

It is reflexive: for any non-null reference value x, x.equals(x) should return true.

Correct.

It is symmetric: for any non-null reference values x and y, x.equals(y) should return true if and only if y.equals(x) returns true.

Correct

It is transitive: for any non-null reference values x, y, and z, if x.equals(y) returns true and y.equals(z) returns true, then x.equals(z) should return true.

Correct

It is consistent: for any non-null reference values x and y, multiple invocations of x.equals(y) consistently return true or consistently return false, provided no information used in equals comparisons on the objects is modified.

Incorrect.

For any non-null reference value x, x.equals(null) should return false.

Incorrect.

Some time ago, I wrote:What would happen if you wrote the subexpressions in a different order?

I meant, what if you change this code which I showed you on Wednesday@Override public boolean equals(Object obj) {    return this == obj ||           obj == null &&           getClass() == obj.getClass() &&           ((Person) obj) == age &&           (name == null ? ((Person)obj).name == null                         : name.equals(((Person)obj).name))); }to@Override public boolean equals(Object obj) {    return this == obj ||           getClass() == obj.getClass() &&           ((Person) obj) == age &&           (name == null ? ((Person)obj).name == null                         : name.equals(((Person)obj).name))) &&           obj == null; }There was a serious error in the original and I have still not corrected it.

As per my understanding that matters in case of OR not AND.

Both AND and OR are associative and commutative, so that is incorrect.

[Monica Shiralkar]

Thanks.

No, it is the other way round. The hash code is calculated according to its formula and the Map decides where to locate the corresponding Entry.

But why is it wrong because I read that 2 keys will be stored in the same bucket if their hash codes are the same,.

Because I can remember how a String calculates its hash code.

Thanks. 2 strings with same content return same hashcode.

They aren't called braces; they are round brackets or parentheses. Only say “round brackets” in Britain. The extra () are not essential

If its not braces but then you said "round brackets" only in Britain.


Not sure why the below two will be wrong in that case:

It is consistent: for any non-null reference values x and y, multiple invocations of x.equals(y) consistently return true or consistently return false, provided no information used in equals comparisons on the objects is modified.

For any non-null reference value x, x.equals(null) should return false.

There was a serious error in the original and I have still not corrected it.

The outside brackets are missing.

Both AND and OR are associative and commutative, so that is incorrect.

But not sure why was it wrong in that case.

[Campbell Ritchie]

Monica Shiralkar wrote:Thanks. . . .

That's a pleasure

But why is it wrong because I read that 2 keys will be stored in the same bucket if their hash codes are the same,.

Remind yourself of what you wrote.

Hashcode has to return an integer which would be same for elements inserted in the same hash buckets.

The key's hash code is used to decide which “bucket” is used; two hash codes ending in the same bits (after any rehashing) will use the same “bucket”. They do not have to be the same hash codes. It is not a case of the “bucket” determining which hash code goes there. That is why I said it was the other way round.

. . . . 2 strings with same content return same hashcode. . . .

But I showed two Strings with different content producing the same hash codes, too.

It is consistent: for any non-null reference values x and y, multiple invocations of x.equals(y) consistently return true or consistently return false, provided no information used in equals comparisons on the objects is modified.

The code in question might never return a result at all. You should find it easy to find an example which fails to produce a result.

There was a serious error in the original and I have still not corrected it.

The outside brackets are missing.

No, that isn't the mistake I made. My mistake is much worse. Actually there are no necessary () missing.

Both AND and OR are associative and commutative, so that is incorrect.

But not sure why was it wrong in that case.

You said

that matters in case of OR not AND.

...which is incorrect.

Have you tried running any of the code I showed you, with or without mistakes? Have you worked out why I thought you were wrong about line 16? Have you worked out why it changed to 14 in one code block?