Can hashCode( ) return the same value for 2 different objects, given that I have not overridden this API in my objects?

The documentation for hashCode says "This is typically implemented by converting the internal address of the object into an integer". I wanted to know the actual implementation of this API in the sun JVM.

Also I wnated to know the outcome of the following:
1. Object A is in location X
2. A.hashCode( ) is invoked.
3. Garbage collector moves A from X to location Y
4. Object B is created in location x
5. B.hashCode( ) is invoked.

harihawking wrote:Can hashCode( ) return the same value for 2 different objects, given that I have not overridden this API in my objects?

Yes. In fact I've had that exact question some time ago and verified that two objects can easily return the same value here.

It's much more likely if one of those objects is no longer live (i.e. it has been or could have been GCed), but it can also happen while both objects are alive.

That's easily proven by the fact that current computer architectures allow for an amount of ram that easily allows more distinct objects than an int has different values.

The documentation for hashCode says "This is typically implemented by converting the internal address of the object into an integer".

I think this sentence is dangerous. Especially since I have a strong suspicion that it is no longer true in current JVMs. The memory occupied by the fields of some object can be moved during the lifetime of the object.

I wanted to know the actual implementation of this API in the sun JVM.

Check the source. It's the only way to know for sure.

>

Also I wnated to know the outcome of the following:
1. Object A is in location X
2. A.hashCode( ) is invoked.
3. Garbage collector moves A from X to location Y

Since this doesn't change the return value of A.hashCode() (otherwise it would be a violation of the contract) we know that the concrete location does not influence the return value of hashCode().

Also note that some GC implementations may not move objects.

4. Object B is created in location x
5. B.hashCode( ) is invoked.

Are the hash codes in the above case always same?

The value returned is usually distinct from the one returned by A.hashCode(). That's not a very strong guarantee, but it's the only one you can get.

So equating "As much as reasonably practical" with "Never" would be considered well-behaved? No offense meant, but I wouldn't want to work with a JVM that was designed according to that paradigm ;-)

I would define well-behaved as not violating the specification, which such an implementation would not. I did not take offense and mean to give no either, I just like things to be precise and correct. ;)

So equating "As much as reasonably practical" with "Never" would be considered well-behaved? No offense meant, but I wouldn't want to work with a JVM that was designed according to that paradigm ;-)

I would define well-behaved as not violating the specification, which such an implementation would not.

Oh, I see. That's where our definitions differ: my "well-behaved" extends quite a bit beyond "specification-conform" and also includes putting some effort into fulfilling optional requirements such as this one. Attempted fail-fast behavior of iterators is another point where I'd say that a well-behaved JVM would at least try to be conformant, while a specification-conforming JVM doesn't need to do anything.

I did not take offense and mean to give no either, I just like things to be precise and correct. ;)

JoachimSauer wrote:
That's where our definitions differ:
my "well-behaved" extends quite a bit beyond "specification-conform" and also includes putting some effort into fulfilling optional requirements such as this one. Attempted fail-fast behavior of iterators is another point where I'd say that a well-behaved JVM would at least try to be conformant, while a specification-conforming JVM doesn't need to do anything.

specification conformance - does that mean just JLS and JVM spec or does it include the Java API?
The JLS says refer to the Java API.

Well they would change each time the object is instantiated/initialized or if the state is changed unless the object is immutable.

Absolutely; I just wanted to insinuate that defining hashCode() and equals() for mutable objects is never safe.

With kind regards
Ben

well overriding hashcode and equals method is not unsafe since when the state of the object changes so would the hashcode, what is unsafe is using a such an object(mutable) as a key in one of the hash based collections. IMHO