raja singh kumar wrote:Who and what decides if there are two objects with the same hashcode then they become a separate entry in the linked list or if the value gets overwritten for the same key?
SCJP 1.4 - SCJP 6 - SCWCD 5 - OCEEJBD 6 - OCEJPAD 6
How To Ask Questions How To Answer Questions
I also suggest you add an == check; this is one of the few places where the == operator is actually good design.
As you doubtless already know, you must also override hashCode.
But you are declaring obj as type Object.
Where on earth did you get that notion from? That looks completely incorrect. The == in the equals() method is simply a shortcut for the circumstance where the object it is called on and the argument are the same object. There is then no need to make the instanceof or equality tests, because you know they will be true already.raja singh kumar wrote:. . . The reason I did not use a == in the equals method was because I want the hashmap to have multiple entries which are stored as linked list.
That is quite contrary to how hash based collections work, but it you insist on all your instances going into the same bucket, all you have to do is implement the hash code method always to return the same result.If I use == I cannot have two employee objects where both of them go to the same bucket.
Have you tried it? What happens if you have two objects returning true from equals() and different results from hashCode?Now try some manipulations on the Map and its key set and see what goes wrong.. . . what implications are there if I override one method and do not override the other one?
Where on earth did you get that notion from? That looks completely incorrect. The == in the equals() method is simply a shortcut for the circumstance where the object it is called on and the argument are the same object. There is then no need to make the instanceof or equality tests, because you know they will be true already.
You appear to have misunderstood how an equals() method is written. What is going to happen if you have a large object with lots and lots of fields, maybe some of them being million‑element arrays or Lists? Maybe you can find that two instances are different very quickly, but you are going to have to compare every element in those arrays or Lists to confirm the two instances are equal. What is going to happen if you do this?Why do you need to go through all the checking when we can tell that you are comparing two references to the same object? You can tell that equals() call is going to return true without even having to investigate the fields of either object. Remember reflexivity: every object is equal to itself. So the == test is simply an optimisation, but a useful one. Unzip the src.zip file in your Java® installation folder and read java/lang/Object.java. Look how the equals method is implemented. What you are saying with == (if it returns true) is,raja singh kumar wrote:. . . If I take the employee class having String name as a parameter and if I use == in the equals method . . .
That is why I made sure to use the || operator (not |), so you can see I was short‑circuiting the second half of the method. The == operator is simply a way to implement the reflexivity part of the general contract for equals(). It has nothing to do with hash codes nor which bucket a KV pair goes into.My hypothetical equals() method wrote:It's the same instance. I don't need to check any more.
...What if you have a small Map with 16 buckets and there are 2³² different possible values of hash code? You are not going to be able to fit every potential hash code into its own bucket. You probably can't even create 2³² different buckets. The decision about which bucket to fit a particular pair into depends on (h % c) where h is the hash code (after any rehashing) and c is the capacity (=number of buckets). Many implementations use h & c − 1 which gives better performance and never returns a negative result, and works really well if c is an exact power of 2. The decision which bucket a pair goes into depends entirely on the hash code of the K. Implementation details of the equals method here constitute a red herring.Correct me if I am wrong. The decision if two entries go to the same bucket depends on the hashcode being equal.
Yes to both, assuming equals() and hashCode() are both correctly overridden.And the decision if the two entries will be considered as the same and will be one entry in the bucket if the equals method considers them equal. And two entries will be created in the same bucket if they have same hashcode and are different according to equals method.
Why do you need to go through all the checking when we can tell that you are comparing two references to the same object? You can tell that equals() call is going to return true without even having to investigate the fields of either object. Remember reflexivity: every object is equal to itself. So the == test is simply an optimisation, but a useful one. Unzip the src.zip file in your Java® installation folder and read java/lang/Object.java. Look how the equals method is implemented. What you are saying with == (if it returns true) is,
Please tell us the details of the compiler error. Also how did you import Objects?raja singh kumar wrote:. . . The above code does not compile and gives error on line 11.
Only if you are absolutely sure obj.name will never be null, otherwise you will suffer an exception. The Objects method can cope with null arguments both left and right.Should the line 11 be (((Employee)obj).name).equals(this.name);
Yes. But that is different from what you seemed to be asking earlier. If you only use == then don't override equals at all. Don't say class method; that would suggest it is static.. . . . My question is if for my Employee class if the equals method is written such that the only comparison done is == . . . then we might as well use the Object class equals method . . . Does that make sense?
Consider Paul's rocket mass heater. |