what really happens when passing objects in java?

Question

I know when we are passing objects we are passing its reference as a value. But this value you get is using the hashcode() method right (according to my tests it's the same)? Since hashcode() is not the memory address and not guaranteed to get unique values all the time, can there be strange things happen like collisions when passing objects?

(Assuming hashcode() hasn't be overridden, i.e., it returns the same value as System.identityHashCode() )

Three are many like this questions, but I can't find a relevant resource which discuses what is that value being passed and how do you get it?

EDIT: Here is my test. The default toSting() uses the hashCode() inside and converts it to a hex value. So when we are passing objects, is this the value being passed? Or what does java do to keep track of all the objects (being passed) so there won't be any reference collisions?

Object o = new Object();
System.out.println(o);
System.out.println(o.toString()); //both prints same thing - java.lang.Object@10385c1

Cristalcristate

Answer 1

hashcode() is not involved in any way with Java's internal memory storage. It's just a method that is supposed to return a unique value that can represent an object.

Now, it just so happens that a nice way to get a unique value to represent an object is to use its internal memory address. And that's what the default implementation of hashcode() does. But the fact that hashcode() uses a memory address does not mean that hashcode() defines the memory address.

Appendicectomy

As you say if the default implementation returns the memory address, then its no problem. But what I've seen is that it is (default function) not guaranteed to return the memory address. But again what then happens when there are more objects than 2^32 and hashcode() returns an integer which is 32 bits?? – Cristalcristate

@user601L hashcode() is by no means a foolproof method. There are occasionally collisions. But it will always find some value to return to you, regardless of whether or not it uses its memory address to get it. You really shouldn't worry about it much, just know that collisions are possible in the edge cases. – Appendicectomy

Answer 2

But this value you get is using the hashcode() method right (according to my tests it's the same)?

No.

From JSL:

The reference values (often just references) are pointers to these objects, and a special null reference, which refers to no object.

Read this page from Harnessing Java

Nevski

Answer 3

The default implementation of hashcode for Object in java is based on the memory address of the object, which is also what the reference is.

This does not mean hashCode() is called to get the reference. This is not what happens. The reference variable just holds the memory address after it gets it from an instantiation(new Whatever()). In fact, it's common for class implementations to override hashcode() to do something different.

Nanananak

The default implementation does not return the memory address. Java VMs routinely moves objects around during the compact phase of garbage collection, so using the memory address would make System.identityHashCode unstable. – Hoye

Answer 4

There is no requirement or expectation that that hashCode() be unique. It is not an identity method.

However, much of the JDK expects that if a.equals(b), then a.hashCode() == b.hashCode().

The reverse is never expected; i.e. if !a.equals(b) then it is not required that a.hashCode() != b.hashCode(). However, performance will suffer if this is not usually the case. In other words, hashCode() is expected to have few collisions.

The default implementation hashCode() in the Object class typically uses the memory address to generate the hashCode(), but it does not return the address, nor is there is no requirement in the language spec to do this.

Saint

Answer 5

In Java Objects are pass by reference means when ever you pass an Object actually you pass Original Object reference. An hashcode depends upon fields values associated to that Object. hashcode is nothing to do with real memory address. it is very rare that two objects with same values have different hashcode. Even if you create two different object but have same values their hashcode will be same always depends upon how much your hash function is efficient

Swingletree

I'm talking about the default hashcode() here, or the system.identityhashcode(). – Cristalcristate