First, I'm speaking about the default hashCode() method here and not something overridden. When we create a new object, 'new' operator returns the memory address of that object it creates; which in java we say it returns reference more generally. What I want to know is, is this the same as the value returned by the hashCode()?
What I BELIEVE is they are same. But then again, when we have more than 2^32 objects and given hashCode() returns an integer (2^32 different numbers) there will be collisions all over and when we pass objects it would be a real mess. How does JVM deal with?
When we create a new object, 'new' operator returns the memory address of that object it creates; which in java we say it returns reference more generally.
Well, a reference certainly doesn't have to be an address. It's a way of referring to an object - the exact value of the bits depends on the JVM implementation.
What I want to know is, is this the same as the value returned by the hashCode()?
Not necessarily. You certainly shouldn't try to make any assumptions on that front. Again, it's an implementation detail.
It's worth remembering that while the garbage collector can move objects around in memory (updating references as it goes), the hash code must not change based on this, which is an argument against your suggestion.
But then again, when we have more than 2^32 objects and given hashCode() returns an integer (2^32 different numbers) there will be collisions all over and when we pass objects it would be a real mess.
There will be hash code collisions, yes. That's unavoidable - anything using hash codes needs to take the possibility of collisions into account. There can't be reference collisions though - a JVM which is able to support more than 232 values concurrently clearly can't just make the hash code and the reference have the same value.
which in java we say it returns reference more generally. What I want to know is, is this the same as the value returned by the hashCode()?
From the Object#HashCode (my highlight):
As much as is reasonably practical, the hashCode method defined by class Object does return distinct integers for distinct objects. (This is typically implemented by converting the internal address of the object into an integer, but this implementation technique is not required by the JavaTM programming language.)
So this is opaque to you the programmer.
All you need to know is that by new you get a handler for an object and that a hashCode is a "recipe" based on the conversion of the internal address to an integer representing the hashCode for an object, that is the same regardless of the memory area your object currently lies (e.g. due to GC movements)
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With