Is there a reason I should call Integer.hashCode()?

Question

Maybe there is a reason I don't know, but I see it's being used in my code to calculate hashcode of a complex object. Does it provide anything comparing to putting Integer itself there? (I hope not), or it's just for a better clarity?

class SomeClass() {
private Integer myIntegerField1;
private Integer myIntegerField2;
...
public int hashCode() {
 final int prime = 31;
 int result =1;
 result = prime * result + ((myIntegerField1 == null) ? 0 : myIntegerField1.hashCode());
 result = prime * result + ....
 ...
 return result;
}
}

• chrylis -cautiouslyoptimistic-: You'll really have to post the relevant code.

Answer 1

The javadoc of Integer.hashCode() says:

Returns: a hash code value for this object, equal to the primitive int value represented by this Integer object.

So using Integer.hashCode() or Integer.intValue(), or using auto-unboxing leads to exactly the same value.

• dhblah: Yes, that's why I asked the question, it really puzzled me why then hashCode() is used there. The only answer I have is for clarity.
• JB Nizet: The code is probably auto-generated by the IDE, and it uses the hashCode of the field, whatever the type of the field is.
• dhblah: Oh, yes, it's probably Eclipse's work. But thanks for clarifying.
• Peter Lawrey: @dhblah And consistency, there is little to be gained by knowing the internal implementation of each object 's hashCode just in case it doesn't need to be called.

Answer 2

Your posted code was auto-generated by an IDE. The code generator has no special cases to handle Integer or other primitive type wrappers, and there isn't a really good reason for it to have one: the way it is implemented now is 100% by the book and on a general level of consideration is the right thing to do.

If you replaced myIntegerField1.hashCode() with just myIntegerField1, the real effect would be a change from a hashCode() call to an intValue() call, and if you check out the source code, you'll find that these two methods are exactly the same.

Answer 3

Composite objects can use combined hashes of their internal state to calculate their own hash code. Example:

public class Person
{
 private Integer id;
 private String name;
 @Override
 public int hashCode()
 {
 int hash = getClass().getName().hashCode();
 if (id != null)
 {
 hash ^= id.hashCode();
 }
 if (name != null)
 {
 hash ^= name.hashCode();
 }
 return hash;
 }
}

Don't make hashes overly complicated, and base hashes only on some values which don't change, or are otherwise likely to be stable. Hash codes, by their very nature, are not required to be unique or collision-free.

The hash code is just a quick and dirty finger print that allows for a quick determination whether two instances are NOT equal (if they were equal, they would have to have the same hash code), so the actual equals() check has to be executed only for instances whose hash is equals (again, same hash does NOT imply that they are equal).

Answer 4

There is no reason to explicitly use the hashcode of an Integer. The source code just returns the value of the Integer:

public int hashCode(){
 return value;
}

So use the value of the Integer rather than the hash code.

What is the reason why this method is included in the source? What would happen if you had an Object that points to an Integer? Explicitly including the method in the source code ensures proper results.

Answer 5

Here you are trying to find the hashcode of SomeClass type objects.

public int hashCode() {
 final int prime = 31;
 int result =1;
 result = prime * result + ((myIntegerField1 == null) ? 0 : myIntegerField1.hashCode());
 result = prime * result + ....
 ...
 return result;
}

In

result = prime * result + ((myIntegerField1 == null) ? 0 : myIntegerField1.hashCode());

you are trying to check if myIntegerField1==null, return hashCode as 0 else hashCode of Integer myIntegerField1.

Remember : myIntegerField1.hashCode() and myIntegerField1.intValue() will return same value as myIntegerField1.