CODEWITHSUNDEEP
javanew-operatorhashcode
samsamara
samsamara

Reputation: 4750

java new operator and the hashcode()

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?

Upvotes: 3

Views: 885

Answers (5)

user207421
user207421

Reputation: 311018

When we create a new object, 'new' operator returns the memory address of that object it creates

No. It returns a Java reference. Because of garbage collection and the implication that objects can be moved, the one thing you can bet on is that it isn't a memory address.

is this the same as the value returned by the hashCode()?

No. A hashCode is not a memory address, especially if hashCode() has been overridden.

What I BELIEVE is they are same.

Your belief is baseless.

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?

So obviously your belief is mistaken. Consider also 64-bit implementations. The only problem here is your assumptions.

Upvotes: 0

Cratylus
Cratylus

Reputation: 54094

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)

Upvotes: 2

Sergey Kalinichenko
Sergey Kalinichenko

Reputation: 726929

Since hash codes do not need to be unique, there would be no problem if converting addresses of two objects in 64-bit space resulted in hash code collision: there is no requirement for hash codes of different objects to be different - only a requirement of hash codes of equal objects to be the same.

In Real LifeTM the default hashCode values do look suspiciously similar to the object's address. However, this information is of no use to Java programmers: even if hash codes were equal to object's addresses, Java does not provide a mechanism to exploit this knowledge, rendering it a useless implementation detail.

Upvotes: 1

Mark Rotteveel
Mark Rotteveel

Reputation: 109146

new in Java does not return the memory address. And even more: Java can (and does) relocate objects in memory. So although the hashCode() implementation in Java could return a memory address, it probably doesn't as it wouldn't be stable over the lifetime of an object.

The hashCode does not have to be unique. In cases where the hashCode is used for identifying objects (eg in HashMap), it needs to be paired with an implementation of equals() to resolve collisions.

Upvotes: 0

Jon Skeet
Jon Skeet

Reputation: 1502806

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.

Upvotes: 5

Related Questions