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?

[Monica Shiralkar]

I understood that if I do say  

get(new Emp("Joe", 18));

then I can retrieve the value of such object present in HashMap if hashcode and equals are overridden. But for what kind of use case would I be required to retrieve from HashMap using such a custom object. I know that often I would be required to retrieve from map using a String or and integer but for what kind of use case would I have to retrieve using an custom object like Employee object?

Thanks

[Junilu Lacar]

It doesn't matter what your use case is. Do you think the designers were thinking of specific use cases when they designed this? No, they were thinking of general rules and the general rule involved simply using hashCode() and equals().

[Monica Shiralkar]

I meant I know that I would be frequently doing things like

get("peter");

but have no idea that for what kind of things would I need to do something like

get(new Emp("Peter", 18));

[Junilu Lacar]

The same reason you'd do something like

put(new Emp("Peter", 18), someThingRelatedToPeter18);

[Monica Shiralkar]

Thanks.I understood.Suppose one has to store things for Peter ,Tom etc in hashmap we would just put these strings as keys.
But if we have to put somethings for Peter with emp id 18 and also for Peter with emp id 20 then we can create a type say Employee have properties name and emoloyeeId and then store such objects in map.Then we have to retrieve the value for Peter who had emp id 18, the we will create such employee object for this and retrieve.

[Paul Clapham]

Exactly. Or to put it another way: we're talking about Java here and so using objects to contain your data is a perfectly ordinary thing for a designer to do.

[Monica Shiralkar]

Yes the object oriented programming. If keys have to be combination of say var1 and var1 for HashMap, I have seen people do things like making var1_var2 as the key instead of creating a class say MyClass with var1 and var2 and then storing objects lile myClassObj1 and so on. For the second one ,one has to override equals and hashcode so some think insteading of doing all that let me simply do var1_var2.But then the second way(creating class ) is the proper way of doing it .

[Monica Shiralkar]

Campbell Ritchie wrote: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.

Thanks. Below is what I understood for hashcode.

It is used by HashSet, HashMap,HashTable to improve performance (quicker insertion/retrieval).

This is done by having buckets to store for example in case of HashMap. Had it been stored randomly, the retrieval would have been slower as it would have required to search everywhere. Now based on hashcode it will search only in that bucket. If multiple elements are there in bucket it will use equals method to find the exact one.
So, I thought this also meant that elements in same bucket will have same hashcode but as you said they dont have to have the same hashcode but should be having the same end bits(after rehashing). Let me check on rehashing and end bits.

[Campbell Ritchie]

Yes, elements in the same bucket may have different hash codes. It means you can traverse a single bucket looking for the same hash code, something much faster than testing all its contents with equals(). One you have found a has code match, then it is worth trying equals().

[Monica Shiralkar]

Campbell Ritchie wrote: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.

But this case (rehashing) is a specific case (only when number of elements in the map reaches the maximum threshold value). I am trying to also understand what happens in the generic case.If elements that are stored in same bucket do not need to have the same hashcode, then is there anything they need to have in common ? Thanks

[Paul Clapham]

Monica Shiralkar wrote:Yes the object oriented programming. If keys have to be combination of say var1 and var1 for HashMap, I have seen people do things like making var1_var2 as the key instead of creating a class say MyClass with var1 and var2 and then storing objects lile myClassObj1 and so on. For the second one ,one has to override equals and hashcode so some think insteading of doing all that let me simply do var1_var2.But then the second way(creating class ) is the proper way of doing it .

Yes. And once people are beyond the basic beginner stage, they should really not spend too much time writing hashCode() methods. Often all you have to do is to identify the fields which are being used in the equals() method, and have the hashCode() method simply return Objects.hash(those fields). For people doing actual work there is a great benefit from using utility methods like that, rather than writing tedious repetitive code which may contain errors. For your example: return Objects.hash(var1, var2);.

[Campbell Ritchie]

Paul Clapham wrote:. . . identify the fields . . . used in the equals() method . . .

The hard part is choosing the fields, so they are exactly the same as those used in equals(). I think there are some examples in Sierra and Bates' (or Sierra Bates and Robson's) Java8 cert book showing how you can be mistaken about choice of fields for hashCode().
The documentation for Objects#hash() says how it works; it says to use a different method if there is only one field.

[Campbell Ritchie]

Monica Shiralkar wrote:. . . making var1_var2 as the key . . .

Don't understand. How do you work that out? It looks like a combined key to me, which I have only seen in SQL.

[Monica Shiralkar]

Campbell Ritchie wrote:

Monica Shiralkar wrote:. . . making var1_var2 as the key . . .

Don't understand. How do you work that out?

Say Employee class has name and age , we insert objects of Employee  in a HashMap such as

 Employee emp1=new Employee("Peter",39)

and

Employee emp2=new Employee("Todd",40)

and Employee Class overrides equals method and the hashcode method. We can retrieve value from this map for Peter aged 39 by using get method and passing a

new Employee("Peter",39)

.

I have seen codes where some developers dont do this and instead just insert Peter_39 and Todd_40 as the keys and retrieve by building a string like Peter_39. I dont call this a good way because if tomorrow there are 10 members instead of just 2(age and name), they will have to do such tedious and error prone concatenation for 10. This is certainly bad code. Any other reason why this is bad?

[Monica Shiralkar]

Campbell Ritchie wrote: 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.

I understood that my statement was wrong.
Hashcode is like address of an element stored in HashMap(or HashTable/HashSet).When we want to retrieve say the value of an element from HashMap, the hashcode will lead us to the bucket where it is residing but then there can be multiple with same hashcode and same bucket, in which case the equals method will help it find and retrieve the correct element. This will cause fast retrieval.

I undersood that there can be more than one element with the same hashcode value in a bucket.

I have a doubt.  Is one bucket entirely dedicated to elements of a particular hashcode or the bucket can have values with different hashcodes too?

[Paul Clapham]

Monica Shiralkar wrote:I have a doubt.  Is one bucket entirely dedicated to elements of a particular hashcode or the bucket can have values with different hashcodes too?

There are more than 4,000,000,000 possible hashcodes.

[Monica Shiralkar]

Paul Clapham wrote:

Monica Shiralkar wrote:I have a doubt.  Is one bucket entirely dedicated to elements of a particular hashcode or the bucket can have values with different hashcodes too?

There are more than 4,000,000,000 possible hashcodes.

Oh yes and very less buckets. So the obvious answer is No. Still it is the address of the element and that address of of other elements too. So I am trying to understand that based on what criteria is it a particular bucket the address of a particular element.

[Paul Clapham]

Monica Shiralkar wrote:So I am trying to understand that based on what criteria is it a particular bucket the address of a particular element.

Again the answer should be obvious. Since it's part of a Java class, it's done with programming. Somebody has written some code which maps all of the integers (because the hashCode method can return any int value at all) into a finite number of buckets.

[Monica Shiralkar]

Thanks.Yes. Does each bucket have hashcodes of a particular range ?

[Paul Clapham]

Monica Shiralkar wrote:Thanks.Yes. Does each bucket have hashcodes of a particular range ?

It could be that. It could be something else. It's not like there's only one Map that was ever written in Java over the last 25 years, different programmers could have chosen different strategies. Even if you're thinking of HashMap from the standard API, that could have changed from one version to the next.

[Campbell Ritchie]

Paul Clapham wrote:. . . HashMap from the standard API, that could have changed from one version to the next.

I am sure it now uses a different rehashing strategy from earlier versions. The structure of the buckets changed from a plain simple linked list to a tree (if  n > 8) in Java8.

[Junilu Lacar]

Monica Shiralkar wrote:Thanks.Yes. Does each bucket have hashcodes of a particular range ?

1. Why do you care? Are you trying to implement a hashmap yourself?

2. I suggest you research and understand How a HashMap works in Java

[Monica Shiralkar]

Thanks all.

Junilu Lacar wrote:Why do you care? Are you trying to implement a hashmap yourself?

No. So, for example with reference to this , while trying to understand what kind of things one should care for and what kind of things one should not care for?

I suggest you research and understand How a HashMap works in Java

Yes, thanks.

[Paul Clapham]

Campbell Ritchie wrote:... it says to use a different method if there is only one field.

It actually doesn't say that at all. It just warns that Objects.hashCode(x) may be different than x.hashCode(); that may or may not be significant. As far as I can see it would only be significant if you planned to put objects of the type which contains only x in the same hash map as x itself. Which would normally be ill-advised but I expect there might be places where it's suitable. And in those places, then yes, that warning would be important.

[Monica Shiralkar]

Hashing gives better retrieval performance. But this is limited to only some members of Collections framework:  HashMap, HashSet, HashTable use hashing. Why not arrayList been given this benifit?

[Carey Brown]

Monica Shiralkar wrote:Hashing gives better retrieval performance. But this is limited to only some members of Collections framework:  HashMap, HashSet, HashTable use hashing. Why not arrayList been given this benifit?

One could easily say: why was ArrayList given quick random indexed access and HashMaps weren't. You have to fit the collection type to the usage as best you can taking into account how you add, remove, and access elements.

[Monica Shiralkar]

Thanks.

[Jesse Silverman]

I have only one thing to add to the excellent discussion here.
A reasonable question was "how could an Oracle Certified Java Professional not be familiar with the sacredness of the .hashCode() .equals() contract?"

I recently commented on a throwaway thread where a certification seeker had made some undetermined mistake and falsely reported an error in Jeanne and Scott's lovely 816 prep book, that they report on the page following the non-error, that altho every version of the OCJP had the contract in scope, it is no longer in scope for the 816 exam.  They do say that every competent Java programmer still needs to understand how to properly overrride .toString(), .hashCode() and .equals() as appropriate for the use of the classes they define.

https://coderanch.com/t/737459/certification/Sybex-Chapter-page-Conceptual-error

I believe that if they are correct, and this situation persists (basically there is now so much material in potential scope for the 819 that this material has been permanently dropped from scope), we may find way more people in the future who are certified as Java Professionals but are fuzzy or worse about the contract.

It has been mentioned on nearly every Java interview I've ever been on, so maybe not, but more people will be learning about it from the "15 Java interview questions" type materials, rather than certification exam prep.  If there is one source that seems to have a worse reputation here than random third-party certification-related info scattered across the web, it would probably be random "Java interview question prep" material scattered across the web.

[Campbell Ritchie]

Jesse Silverman wrote:. . . one source that seems to have a worse reputation here than random third-party certification-related info scattered across the web, it would probably be random "Java interview question prep" material scattered across the web.

In my eyes, random beginners' tutorial material scattered across the web is jsut as bad. Not all of it. Some of it is good, but the beginners don't know how to distinguish the two yet.