Rick Beton wrote:
2009/9/1 Ceki Gulcu <ceki@qos.ch <mailto:ceki@qos.ch>>
No, they do not have different behavior. Both methods act according to their respective contracts. Keep in mind that in a typical hashtable the actual size of the table is much smaller than the hash space. Thus, it is *perfectly* OK for hash values to collide from time to time.
I'm happy with that, but I was thinking about the particular case of several instances sharing a common enum value but differing in their parameters. They would all be in the same hashtable bucket so linear searching would be needed. If this is sufficiently unlikely, then there is no need to include the parameters in the hash value. However, a better hash value is produced by the more complex code I wrote 3 days ago.
Indeed, it would be possible to come up with MessageParamObj instances with common keys but differing in their args. In that case, your impl would be perform better. However, I don't think such cases are likely to occur and can be safely ignored.
Not only is the simpler hashCode implementation simpler, it will also be faster in computing its result. Since occasional hash collisions are OK, the overall results are likely to be better as well. As I said, having args contribute to the hashCode is a waste of the code reader/reviewer's time as well as CPU cycles. (If unconcinved, write a small test case comparing the performance of the two variants.)
The performance is not an issue - in the code I emailed, I had a lazy cache of the hashcode to avoid the cost of recomputing it (and likewise for toString()).
You still have to compute the hash code the first time. It is often the case that the hash code for an object is computed only once and repeatedly on different object instances having the same or different contents. In such a scenario, there would be many cache misses...
As far as complexity is concerned, your simpler approach is much much better.
Well, it's simpler. :-) I still don't see an obvious use-case where MessageParamObj instances would be inserted into a map, not to say that it could not happen.
I don't really have a strong view on this and I'll leave the choice to you.
OK. Thank you for being cool headed about this. I appreciate that.
Rick :-) -- Ceki Gülcü Logback: The reliable, generic, fast and flexible logging framework for Java. http://logback.qos.ch