Warren is absolutely correct when he states:
Er, if your point is that k1 and k2 are essentially the 'same thing', then you'll be overriding equals(), won't you? Overriding the hashcode() method without overriding equals() won't change the behavior of your example at all.
When using class Tester as a key in a HashMap BOTH hashCode() and equals() need to be overriden. The following example works fine, but if I DO NOT override equals() null is returned when I "get" k2. get() is using equals() to see if the object I'm "getting" is in the HashMap. If Tester does not override equals(), Object's equals() is used abd returns false when k2 is specified in "get" since it is not the same object as k1, the object that we "put" in the HashMap.
Even though hashCode() returns the same value for the 2 objects (k1 & k2) equals() must be used during get() so equals() must be overriden in order for get() to operate correctly on different objects with the same values.
Stating that equals() and hashCode() should be overriden together is not just a guideline, but a requirement for using an object in a HashMap.