This post originated from an RSS feed registered with Java Buzz
by Joe Shelby.
Original Post: Debugging HashMap/HashSet
Feed Title: Joe's Java Jottings
Feed URL: http://www.blog-city.com/bc/
Feed Description: Notes, observations, and occasional other stuff on Java, with concentrations on Swing, XML, and the Semantic (Object) Web.
I ran into an interesting bug in code I was debugging (but didn't write; I certainly wouldn't have done it this way). The code was using an abstract object to store a Map that the derived classes would use to store their properties. Sometimes the concrete objects would be instantiated "JavaBean" style (through XML Serialization), sometimes through a DataAccessObject which would construct by passing in its Map implementation. Fetching a Long was done by casting the object in the Map to Number and doing the usual valueAsLong().
No problem, right?
Wrong. When the Maps are used in the implementation of equals and hashcode, the results will differ if the Maps have different implementation objects insde, even though at the JavaBean Property abstraction, the two objects are the same. In the case of getting the Object from XML Serialization, the Property type of long was preserved. However, the DataAccessObjects passed in the BigInteger that Oracle's JDBC decided to give us for that value. So the Objects are worked fine, and were equal() when they should have been, but had different hashcodes because of the implementation details of the objects inside the maps.
Go Fig.
Important safety tip (translation, reminder of what we should already all know) -- Be very clear about what is and isn't equal and the degree to which you depend on implementation details to construct your objects hashcode.
Previous Topic
