hashCode() method with long unsigned shift right
807589Oct 13 2008 — edited Oct 13 2008Hi, I'm reading Effective Java, Item #8, which discusses overriding the hashCode() method. When calculating a hashCode for a Object, it specifies that every significant field (which I interpret as member Object or primitive) contained in the Object needs it's own hashCode, and all of the hashCode's for the members of an Object are combined to make a hashCode for the Object itself.
My question is, the text says, "If the field is a long, compute (int)( f ^ ( f >>> 32 ))" as it's hashCode.
I understand that the hashCode that is ultimately returned needs to be an int, but I don't understand why the author is performing 32 unsigned shift right operations, and then using a bitwise exclusive-OR.
Why does this particular operation generate a suitable hashCode for longs? Why is this more appropriate, than say taking the long modulo 2 ^ 32 or something like that?