tags:

views:

199

answers:

8

Hi,

I am trying some code around object equality in java. As I have read somewhere

hashCode() is a number which is generated by applying the hash function. Hash Function can be different for each object but can also be same. At the object level, it returns the memory address of the object.

Now, I have sample program, which I run 10 times, consecutively. Every time i run the program I get the same value as hash code.

If hashCode() function returns the memory location for the object, how come the java(JVM) store the object at same memory address in the consecutive runs?

Can you please give me some insight and your view over this issue?

The Program I am running to test this behavior is below :

public class EqualityIndex {

    private int index;

    public EqualityIndex(int initialIndex) {
       this.index = initialIndex;
    }

    public static void main(String[] args) {
        EqualityIndex ei = new EqualityIndex(2);
        System.out.println(ei.hashCode());
    }

}

Every time I run this program the hash code value returned is 4072869.

+2  A: 

Which kinds of object you are created? Is it a specific kind of object like String (e.g). If it is a specific kind, the class can already override the hashCode() method and return it to you. In that case, what you receive is not memory address any more.

and also what values you receive, are you sure if it is memory address?

So, please post more code for more details

vodkhang
+3  A: 

Well, the objects may very well end up in the same location in the virtual memory. Nothing contradictory with that. Bottom line is that you shouldn't care anyway. If the hashCode is implemented to return something related to the internal storage address (there is no guarantee at all!) there is nothing useful you could do with that information anyway.

aioobe
+13  A: 

how come the java(JVM) store the object at same memory address in the consecutive runs?

Why wouldn't it? Non-kernel programs never work with absolute memory addresses, they use virtual memory where each process gets its own address space. So it's no surprise at all that a deterministic program would place stuff at the same location in each run.

Michael Borgwardt
A: 

hashCode can and may be overridden by the class you are using, the JavaDoc for Object.hashCode() states that it is '... typically implemented by converting the internal address of the object into an integer...' so the actual implementation may be system dependant. Note also the third point in the JavaDoc that two objects that are not equal are not required to return different hashCodes.

krock
A: 

If two objects are equal, they have to have the same hash codes. So, as long as you do not create plain Object instances, everytime you create object that has the same value, you'll get the same hash code.

el.pescado
it is not always true. It depends on the class you are talking about. It is a good convention to always override equals and hashCode but it is not always true
vodkhang
Of course, if objects are comparable.
el.pescado
When you say "have to have", you really mean "ought to have". There is nothing in the language or runtime system that *prevents* you from breaking contract for `hashcode()` and `equals()`. But if you do, anything that uses hashing on your object will behave incorrectly.
Stephen C
The point is that *all* objects *ought to* obey the hashcode / equals contract, not just those that are "comparable" ... whatever that means.
Stephen C
Yeah, I meant *ought to have*.
el.pescado
+1  A: 
for (int i=0; i < 10; i++) {
    System.out.println("i: " + i + ", hashCode: " + new Object().hashCode());
}

prints:


i: 0, hashCode: 1476323068
i: 1, hashCode: 535746438
i: 2, hashCode: 2038935242
i: 3, hashCode: 988057115
i: 4, hashCode: 1932373201
i: 5, hashCode: 1001195626
i: 6, hashCode: 1560511937
i: 7, hashCode: 306344348
i: 8, hashCode: 1211154977
i: 9, hashCode: 2031692173
Arjan Blokzijl
Interesting. What JVM are you using?
Stephen C
java -version:java version "1.6.0_20"Java(TM) SE Runtime Environment (build 1.6.0_20-b02)Java HotSpot(TM) 64-Bit Server VM (build 16.3-b01, mixed mode)
Arjan Blokzijl
+2  A: 

As I have read somewhere: " ... At the object level, it returns the memory address of the object."

That statement is incorrect, or at best an oversimplification.

The statement is referring to the default implementation of Object.hashCode() which returns the same value as System.identityHashcode(Object).

The Javadoc for Object.hashCode() says this:

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.)

and this:

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.

In fact, the identity hashcode value is typically based on the Object's machine address when the method is first called for the object. The value is stored in a hidden field in the Object header. This allows the same hashcode to be returned on subsequent calls ... even if the GC has relocated the Object in the meantime.

Note that if the identity hashcode value did change over the lifetime of an Object, it would violate the contract for hashcode(), and would be useless as a hashcode.

Stephen C
+2  A: 

The hashCode() function should return the same value for the same object in the same execution. It is not necessary to return same value for different execution. See the following comments which was extracted from Object class.

The general contract of hashCode is:

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. This integer need not remain consistent from one execution of an application to another execution of the same application.

I have executed your code few times. Here is my result

1935465023

1425840452

1935465023

1935465023

1935465023

1925529038

1935465023

1935465023

The same number is repeated multiple times. But that doesn't mean they are same always. Lets assume, a particular implementation of JVM is looking for first free slot in the memory. then if you don't run any other applications, the chances for allocating the object in the same slot is high.

Sujee