This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
Stephan Van Hulst wrote:The keys you are using are not "consistent with equals"
Hi Guys, @Stephan I agree with you...@Aashu I guess your implementation of the compareTo() method is the problem, the implementation makes the maps keys NOT consistent with the equals method. May I ask why you used that implementation?. Your map did NOT even recognise your keys in the first place...If you replace line 38 of your code with it returns null! ... ... This means the Map did NOT recognise your keys.
Lets try another implementation;
P.S. I modified line 38 of your code to give us the value of the removed key.
In Your Pursuit Towards Certification, NEVER Give Up.
In K.S book it has written that if you do not implement hashcode() and equals() then you will not be able to get the value.But when i tried this program at home and called get() i got the appropriate value.
Please Please Help me !!
sagar shroff wrote:In K.S book it has written that if you do not implement hashcode() and equals() then you will not be able to get the value.But when i tried this program at home and called get() i got the appropriate value.
You are talking about page 583 of the K&B book yes...Now this is a caption of what the book says: "Any classes that you use as a part of the keys for that map MUST override (I repeat override NOT implement) the hashCode() and equals() methods"...Okay you are correct, when you look at the program it is a little bit confusing (at first sight) because the HashIt class does NOT effectively override the hashCode() and equals() methods but the actual keys used are Strings and if you check the API you will see that Strings and Wrappers effectively override the hashCode() and equals() methods.
Here is a little program to demonstrate what I am trying to say;
The output may clarify your doubts and you can clearly see that it fulfils the fundamental aspect of the hashCode()/equals() contract which says if two objects return true according to the equals() method test, their hashCodes() MUST be equal.
I hope this helps
Phew what a long day...I am going to have dinner...I will be right back.