• Post Reply Bookmark Topic Watch Topic
  • New Topic

HashMap not finding a key reference  RSS feed

 
Brian Carlisle
Greenhorn
Posts: 19
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Can someone please enlighten me as to why the code below does not find an occurrence of the Object. Seems like this is a popular topic. I am overriding the equals and hashcode methods. When I debug I notice that the equals method is not stopping at my breakpoint when I issue the get() method call. The call returns null even though separate calls to the equals method and hashcode return the same values.

It all seemed so logical on paper until I started coding lol. Perhaps I need another cup of coffee...

Much appreciated! Thanks.

 
Jeff Verdegan
Bartender
Posts: 6109
6
Android IntelliJ IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Well, for one thing, that code won't compile. Once you fix that small error though, it's something simple, but hard to spot.



If you use the @Override annotation whenever you're overriding a method, or implementing an abstract method, then if you get something wrong like the spelling or argument list, the compiler will complain.

Change your code like so to see what happens, and after that, correct your "hashcode" method.


Using @Override can turn some runtime errors (which are harder to find) into compile-time errors (which are much easier to find and fix).
 
Raghav Viswanathan
Greenhorn
Posts: 26
Chrome Eclipse IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello Brian,

Firstly, An interesting piece of code that I have come accross.

i found two things,

1. In the code, when you add


the "thing" that gets added as your key is:


2. When I remove toString() method from Frog class, the "thing" that gets added as a key is instance of the class or the object f2 itself.


[com.mycalc.Frog@19821f]

The following print statement helped me immensly.



Hope this helps

Also, If you add

you will get your desired result.

Hope this helps.

Regards,
Raghav. V

 
Jeff Verdegan
Bartender
Posts: 6109
6
Android IntelliJ IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Raghav Viswanathan wrote:
1. In the code, when you add


the "thing" that gets added as your key is:


No. The thing that gets added is a refrence to the object that f2 points to. The toString() method is not involved at all.

2. When I remove toString() method from Frog class, the "thing" that gets added as a key is instance of the class or the object f2 itself.


Just as above, what gets added as a key is a reference to the object pointed to by f2.

That's what happens tevery time you call map.put(key, value). It doesn't matter what kind of Map it is or what type key is or what methods it overrides.

Also, If you add

you will get your desired result.


But that's the wrong way to use a map, and it's not what the OP is trying to do, and it doesn't address his problem. (Read my first reply to see what his actual problem is. In the future, please read the other replies in a thread both before and after posting your own comments. Thanks!)

Hope this helps.


Actually, no. It just introduces misinformation and confusion.
 
Anayonkar Shivalkar
Bartender
Posts: 1558
5
Eclipse IDE Java Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Raghav Viswanathan wrote:
1. In the code, when you add


the "thing" that gets added as your key is:

Wrong.
When you add f2 as a key, then 'f2' is added to the Map. Period. Overriding (or not overriding) toString method has nothing to do with it.

However, when you print 'f2' (or values from m2.keySet()), then toString method of f2 is invoked, and hence it might appear that String was added as a key in Map.

Also, adding f2.hashcode() as a key is nothing to do with this issue. This works only because you have Map<Object, Object>. What if you have Map<Frog, String>? It will simply throw a compile time error.
Further, what if hashCodes of 2 objects are same, but equals method return false(which is absolutely legal scenario)? In that case, you'll end up overwriting one value with another.

The proper way to do it is - to override hashCode and equals methods properly. Currently, (as Jeff mentioned) hashCode method is not overridden.

I hope this helps.
 
Brian Carlisle
Greenhorn
Posts: 19
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Ugh...I cant believe I missed that. Thanks so much for the detailed explanations I appreciate it greatly. Coffee is hot so time to hit the books
 
Raghav Viswanathan
Greenhorn
Posts: 26
Chrome Eclipse IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello Anayonkar, Jeff,

I apologise if I have mislead. Please find the explanantion below

Now when I execute this piece of code with the toString() in Frog Class , The value that gets added as a key in the Map M2 is [my name is arthur]. (tried that by printing the keyset in the map)

When I remove the toString() method from the Frog Class and if I ran this piece of code again, the output I got was [com.mycalc.Frog@19821f]

Even I was under the same impression as both of you have pointed out that if I add f2 to the map, the key would actually be the reference to the object. I was stummped when I saw the result.

The reason why I tried to put the hashcode of the objects as key was to demonstrate that the hascode of the objects were the same. I apologise if I have mislead or given wrong information.

Regards,
raghav.V
 
Jeff Verdegan
Bartender
Posts: 6109
6
Android IntelliJ IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Raghav Viswanathan wrote:
Now when I execute this piece of code with the toString() in Frog Class , The value that gets added as a key in the Map M2 is [my name is arthur]. (tried that by printing the keyset in the map)

When I remove the toString() method from the Frog Class and if I ran this piece of code again, the output I got was [com.mycalc.Frog@19821f]


In both cases, the same reference to the same object is being added as the key. The only difference is in how that object gets rendered as a String. But that has nothing to do with what goes into the map.
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!