Rick Beton wrote:
Moreover, you could implement hashCode as follows, which correct and efficient at the same time. Having args contribute to the hashCode is a waste of time.
@Override public int hashCode() { return e.hashCode(); }
That's probably better (simpler often means better), but now hashCode() and equals() have different behaviour so there ought to be a remark in the JavaDoc to say so. It could, for example, mean that a hashtable of instances may be less efficient because more linear searching might happen.
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. 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.)
How about renaming ResourceMessage as MessageParameterObj. See also
http://www.refactoring.com/catalog/introduceParameterObject.html
I see from the Git patch email you've already done this. :-D
Indeed, but I am open to suggestions. -- Ceki Gülcü Logback: The reliable, generic, fast and flexible logging framework for Java. http://logback.qos.ch