What does this line mean?

[chico9]

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

I don't really understand about haschodes, yet, so I can't seem to get my head around what exactly is generated by this hascode() method. All I know is, it's an integer :X

Right now, I am thinking the line in question (as is for temp1)..

((temp2== null) ? 0 : temp2.hashCode())

..means if temp2 is null then set to zero, if not set temp2 with the value of temp2.hashcode()? Am I on the right track?

Also, what does this overall hashcode() method do?

Thanks :?:

[~s.o.s~]

Simply put, a hash code is ideally a best effort numeric (integer) representation of a Java object. Each Java object which lives in the JVM has a default hashCode() which is mapped to the integer representation of the address of that object (which as you can see is a good enough representation, since objects have unique addresses. This breaks in cases where the underlying address space is more than the range of an integer but don't worry about that for now).

But why allow the hashCode() to be overridden? The short answer is: because it can be used in a clever way to implement hash tables in Java. The logic used in the hashCode() method can be thought of as a hash function used to generate hash codes for the given object.

As an example, let's suppose you decide to put the hashCode() method to good use for the String object. The objective here would be to make sure that we almost always get the same hashCode() for equal strings. The most logical way here would to consider the characters of the string to generate the hash code since if a string has same characters and same length, it has to be same. But, we have to make sure that the order of the characters are also taken into consideration when generating the hash code (we don't want 'sad' and 'das' to end up having the same hash code). But be warned, it is quite *possible* that the hash code of two different entities object can be the same and this is known as a 'hash collision'. Whenever writing a custom hash method, the aim should be to ensure that ideally there should be no collision (or practically very less collision %). The complicated code block you see in your example is just one of the mathematical tricks of ensuring that the hash collision is avoided if possible.

As far as Java is concerned, you *have* to override the hashCode() method if you are overriding the equals method. This restriction is in place to ensure that the hash code based associative array implementation of Java (i.e. HashMap), which relies on hashCode() and equals() method to keep track of elements doesn't break. As an example, let's take a hash map which stores 'strings' against 'strings' (first name against last name of individuals. Let's assume that the equals() implementation of the Object class is overridden by the String class to provide logical equality ('abc' == 'abc') but the hashCode() method isn't. Now lets play around with this map:

map.put(new String("ben"), "ten");
map.put(new String("ben"), "twenty");

How many entries do you think should be present in the map? Logically one, since we are dealing with the same person, ben, in both the cases. But in our case, we end up with two entries. Why is that? That's because when "storing" the first name, a hash based implementation tries to locate a "bucket" for a given entry based on its hash code. Let's suppose that the hashCode() for the first ben object is 0x12345678. This value is generally used to derive an offset for the underlying table (array) which stores the entries. Now, when we trying storing the second "ben" (which has a different hash code), the implementation looks at the hash code of the second ben object (let's say its 0x87654321) and places it in a "new" bucket. Now we have two buckets for the "same" ben object even though you made sure that calling "equals()" on these two ben objects would always yield true.

Hope that cleared up a couple of things. More detailed reading: http://www.ibm.com/developerworks/java/library/j-jtp05273/index.html

[chico9]

WOW, thanks alot man! Yes, I sort of get a general picture now of hash codes, thanks!! :)

..so, what about the first bit of my question?

((temp2== null) ? 0 : temp2.hashCode())

[~s.o.s~]

..so, what about the first bit of my question?

That check is a standard way of dealing with objects composed of others objects which can be NULL. Basically, you start off with a prime, keep adding the hash codes of the constituent objects and use 0 if a given field is NULL (since you can't invoke hashCode() on a NULL reference).

[chico9]

Awesome, thanks :)