Java Programming

Hi all,
I studied some docs reagarding hashCode() and have some questions.

From: java.lang.Object: hashCode():

1) "Whenever it is invoked on the same object more than once during an execution of a Java application, the hashCode method must consistently return the same integer, provided no information used in equals comparisons on the object is modified. This integer need not remain consistent from one execution of an application to another execution of the same application." Why?

2) From: Java Glossory: http://www.mindprod.com/jgloss/hashcode.html

Object.hashCode Implementation: The default hashCode() method uses the 32-bit internal JVM address of the Object as its hashCode. However, if the Object is moved in memory during garbage collection, the hashCode stays constant. This default hashCode is not very useful, since to look up an Object in a HashMap, you need the exact same key Object by which the key/value pair was originally filed. Normally, when you go to look up, you don't have the original key Object itself (Why?)
just some data for a key. So, unless your key is a String, nearly always you will need to implement a hashCode and equals method on your key class.

3) From the same text:
"As a rule of thumb, any time you use an Object as a key in a Map or Set (e.g. Hashtable, HashMap, HashSet, TreeMap etc.) you must redefine both equals and hashCode in such a way both incorporate all the fields of the logical key. Fields in the key Object irrelevant to lookup should not be included in either method."

Why do I need to implement the hashCode() method anyway? Why the 32-bit internal JVM address of the Object which is returned from hashCode() method wouldn't be enough to give me the key I need?

4) From Java theory and practice: Hashing it out: http://www-128.ibm.com/developerworks/java/library/j-jtp05273.html

"Why override equals() and hashCode()?
What would happen if Integer did not override equals() and hashCode()? Nothing, if we never used an Integer as a key in a HashMap or other hash-based collection. However, if we were to use such an Integer object for a key in a HashMap, we would not be able to reliably retrieve the associated value, unless we used the exact same Integer instance in the get() call as we did in the put() call. This would require ensuring that we only use a single instance of the Integer object corresponding to a particular integer value throughout our program. Needless to say, this approach would be inconvenient and error prone."

Why its error prone? Why can't we say that we are using the same instance of the Integer object?

5) Why do I need to override hashCode() for HashSet? We don't have the concept of key in HashSet?

6) Its also said that no matter what algorithm is used for calculating hashCode, its possible that two non-equal objects have the same hashCode, so if we are using those objects as keys in HashTable, how can we avoid having the same hashCode or the same key for two different values? On the other word, how can we avoid collisions, (if there is anyway) ?

I stopped going through more documents at this point, since it seems more questions will arise! If I know the answer to the above questions it will help to understand the rest of document. Any help is greatly appreciated.