Well, Patricia, even when Campbell seemed to suggest that the location of an object in memory could change over time (for instance due to the generational garbage collection placing old objects in another memory space), even so the contract for hashCode in javadoc says:
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.
Therefore, regardless of the implementation of garbage collection or any other mechanisms that might place the object in another memory space, this method ought to return the same integer during the execution of the JVM.
Now, that being said, you must consider that this behavior of returning the memory space of an object as a hash code is not a required implementation of the method. Other JVM might implement it differently without violating the contract. Therefore, I would suggest that you should not take this implementation-dependent details into account while dealing with hashCode implementations.
You should only consider the contract stated in javadoc.