File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

hashCode Contract Doubt

 
saloni jhanwar
Ranch Hand
Posts: 583
Firefox Browser Notepad Windows
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Book->K&B->Chapter7->page->554

I am not getting meaning of RED marked line
The hashCode() Contract
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.


how integer hashcode value would be changed if i execute application another time,i did so and found nothing so ??




C:\SCJP\Chapter7\HashCode>java Test
4072869
1671711

C:\SCJP\Chapter7\HashCode>java Test
4072869
1671711

C:\SCJP\Chapter7\HashCode>java Test
4072869
1671711
 
Seetharaman Venkatasamy
Ranch Hand
Posts: 5575
Eclipse IDE Java Windows XP
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
consider there are two user(say A, B) using a TestObject



A execute this calss as TestObject testAexecution = new TestObject(100);//hashcode for TestObject is 100.

B execute this calss as TestObject testBexecution = new TestObject(200);//hashcode for TestObject is 200.

I think above statement means this scenario .
 
saloni jhanwar
Ranch Hand
Posts: 583
Firefox Browser Notepad Windows
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Seetharaman Venkatasamy wrote:consider there are two user(say A, B) using a TestObject



A execute this calss as TestObject testAexecution = new TestObject(100);//hashcode for TestObject is 100.

B execute this calss as TestObject testBexecution = new TestObject(200);//hashcode for TestObject is 200.

I think above statement means this scenario .


It stated same application but you are changing code here for users.
 
Seetharaman Venkatasamy
Ranch Hand
Posts: 5575
Eclipse IDE Java Windows XP
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I am not sure, let see what others say
 
saloni jhanwar
Ranch Hand
Posts: 583
Firefox Browser Notepad Windows
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Seetharaman Venkatasamy wrote:I am not sure, let see what others say


 
Anayonkar Shivalkar
Bartender
Posts: 1557
5
Eclipse IDE Java Linux
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
What my interpretation is:

During a single execution, hashCode of an object must be same, no matter how many times the hashCode is invoked.
However, it is fine if hashCode is different for different execution. However, again, during any given execution, hashCode of an object must be constant throughout.

e.g. (its a very bad hashCode, but still valid) - I'm taking current directory (where class file resides), evaluating its absolute path and returning the String length of that path. Now, no matter how many times I invoke the hashCode method on that object, hashCode is not gonna change (I mean, as long as someone does not move that class file to some other location during the execution).
However, in my next execution, I put my class file (or jar file) in some different directory path and start running the code. In that case, the hashCode may be different from the first execution, but its fine as long as it remains same during that execution.

I hope this helps.
 
saloni jhanwar
Ranch Hand
Posts: 583
Firefox Browser Notepad Windows
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Anayonkar Shivalkar wrote:

However, it is fine if hashCode is different for different execution.




Yes, that's why i tested my code but there is always same hashcode, so when that case will occur(However, it is fine if hashCode is different for different execution).How i can believe that stated is correct.I just want a simple code example which demonstrate that case.thanks
 
Anayonkar Shivalkar
Bartender
Posts: 1557
5
Eclipse IDE Java Linux
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
saloni jhanwar wrote:I just want a simple code example which demonstrate that case.thanks

I've mentioned (though a bad) example of hashCode based on directory name.

I can suggest another thing:
Reboot your machine, delete the class file, recompile the code, and run it again. Chances are that you'll get different hashCode.

I hope this helps.
 
saloni jhanwar
Ranch Hand
Posts: 583
Firefox Browser Notepad Windows
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Anayonkar Shivalkar wrote:
saloni jhanwar wrote:I just want a simple code example which demonstrate that case.thanks

I've mentioned (though a bad) example of hashCode based on directory name.

I can suggest another thing:
Reboot your machine, delete the class file, recompile the code, and run it again. Chances are that you'll get different hashCode.

I hope this helps.


Each re-compilation generates new hashcode for object so that is fine but as stated one execution to another execution means interpretation isn't generating new hashcode .still confused.

 
Seetharaman Venkatasamy
Ranch Hand
Posts: 5575
Eclipse IDE Java Windows XP
 
gurpeet singh
Ranch Hand
Posts: 924
1
Fedora Java Netbeans IDE
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
how about this one





source http://stackoverflow.com/questions/9435925/different-enum-hashcode-generation
 
Matthew Brown
Bartender
Posts: 4549
8
Java Netbeans IDE Scala
  • 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The contract says the hash code doesn't have to be consistent between executions. It doesn't say that it won't be. That's down to a particular implementation in a particular class.
 
saloni jhanwar
Ranch Hand
Posts: 583
Firefox Browser Notepad Windows
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
gurpeet singh wrote:how about this one





source http://stackoverflow.com/questions/9435925/different-enum-hashcode-generation


i dont think, it will give different hashcode. if logic is correct as stated then it should behave same with any code.
 
Anayonkar Shivalkar
Bartender
Posts: 1557
5
Eclipse IDE Java Linux
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
saloni jhanwar wrote:Each re-compilation generates new hashcode for object so that is fine but as stated one execution to another execution means interpretation isn't generating new hashcode .still confused.

Well, in that case, you can try to run the class file with subsequent reboots(without recompiling). Does it still give you same hashCode? Also, how about running same class file on different machines?

Secondly, as Matthew Brown has said, hashCode may be different during subsequent executions. It doesn't mean that it has to be different.
 
gurpeet singh
Ranch Hand
Posts: 924
1
Fedora Java Netbeans IDE
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
saloni jhanwar wrote:
gurpeet singh wrote:how about this one





source http://stackoverflow.com/questions/9435925/different-enum-hashcode-generation


i dont think, it will give different hashcode. if logic is correct as stated then it should behave same with any code.



i ran it and it gave me different hashcode 2 times.
 
saloni jhanwar
Ranch Hand
Posts: 583
Firefox Browser Notepad Windows
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
gurpeet singh wrote:
saloni jhanwar wrote:
gurpeet singh wrote:how about this one





source http://stackoverflow.com/questions/9435925/different-enum-hashcode-generation


i dont think, it will give different hashcode. if logic is correct as stated then it should behave same with any code.



i ran it and it gave me different hashcode 2 times.


hmm as you said it's giving different hashcode i got surprised, i checked there is nothing new in this code.It is also creating an object so i decided to execute my code code again and 10th execution gave me diffrent hashcode.hence proved
 
saloni jhanwar
Ranch Hand
Posts: 583
Firefox Browser Notepad Windows
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
hashCodes Uncovered
 
Helen Ma
Ranch Hand
Posts: 451
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
So, if the hashcode of an object may be different for each execution, we should not write any code depending on hashcode?
For example, we should not use hashcode as a primary key of a database. Is it true?

I tried Integer i= new Integer(1). Every time, it gives me the hashcode = 1. Please verify this.
 
gurpeet singh
Ranch Hand
Posts: 924
1
Fedora Java Netbeans IDE
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Helen Ma wrote:So, if the hashcode of an object may be different for each execution, we should not write any code depending on hashcode?
For example, we should not use hashcode as a primary key of a database. Is it true?

I tried Integer i= new Integer(1). Every time, it gives me the hashcode = 1. Please verify this.


that's the wrapper object you are creating. wrappers have overridden hashcode method from the object class. so that is why you are getting the same hashcode. what saloni was referring about was regarding object of a class which has inherited hashcode implementation from object class.
 
Anayonkar Shivalkar
Bartender
Posts: 1557
5
Eclipse IDE Java Linux
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Helen Ma wrote:So, if the hashcode of an object may be different for each execution, we should not write any code depending on hashcode?
For example, we should not use hashcode as a primary key of a database. Is it true?

Using hashCode as a primary key is a strict no-no for me. But the main reason is not that it can be different for each execution. For me, the main problem is - hashCode contract itself:
It says that
It is not required that if two objects are unequal according to the equals(java.lang.Object) method, then calling the hashCode method on each of the two objects must produce distinct integer results.

Hence, it is absolutely valid for all objects to have same hashCode. So, now there is no way one should use hashCode as primary key. How about a database trigger?

I hope this helps.
 
saloni jhanwar
Ranch Hand
Posts: 583
Firefox Browser Notepad Windows
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
gurpeet singh wrote:
Helen Ma wrote:So, if the hashcode of an object may be different for each execution, we should not write any code depending on hashcode?
For example, we should not use hashcode as a primary key of a database. Is it true?

I tried Integer i= new Integer(1). Every time, it gives me the hashcode = 1. Please verify this.


that's the wrapper object you are creating. wrappers have overridden hashcode method from the object class. so that is why you are getting the same hashcode. what saloni was referring about was regarding object of a class which has inherited hashcode implementation from object class.


There is no such a condition that if you override hashcode() then it will give same hashcode all time ,you can check original hashcode using System.identityHashCode(obj);
 
gurpeet singh
Ranch Hand
Posts: 924
1
Fedora Java Netbeans IDE
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
saloni jhanwar wrote:
gurpeet singh wrote:
Helen Ma wrote:So, if the hashcode of an object may be different for each execution, we should not write any code depending on hashcode?
For example, we should not use hashcode as a primary key of a database. Is it true?

I tried Integer i= new Integer(1). Every time, it gives me the hashcode = 1. Please verify this.


that's the wrapper object you are creating. wrappers have overridden hashcode method from the object class. so that is why you are getting the same hashcode. what saloni was referring about was regarding object of a class which has inherited hashcode implementation from object class.


There is no such a condition that if you override hashcode() then it will give same hashcode all time ,you can check original hashcode using System.identityHashCode(obj);



do you mean that if i override hashcode like this public int hashcode() { return 5; }, the subsequent execution of the hashcode method will return something different ?
 
saloni jhanwar
Ranch Hand
Posts: 583
Firefox Browser Notepad Windows
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
gurpeet singh wrote:
saloni jhanwar wrote:
gurpeet singh wrote:
Helen Ma wrote:So, if the hashcode of an object may be different for each execution, we should not write any code depending on hashcode?
For example, we should not use hashcode as a primary key of a database. Is it true?

I tried Integer i= new Integer(1). Every time, it gives me the hashcode = 1. Please verify this.


that's the wrapper object you are creating. wrappers have overridden hashcode method from the object class. so that is why you are getting the same hashcode. what saloni was referring about was regarding object of a class which has inherited hashcode implementation from object class.


There is no such a condition that if you override hashcode() then it will give same hashcode all time ,you can check original hashcode using System.identityHashCode(obj);



do you mean that if i override hashcode like this public int hashcode() { return 5; }, the subsequent execution of the hashcode method will return something different ?


It'll always give you 5 but internal original hashcode wont be same all time .When in this method you will use System.identityHashCode(obj) you will find that original hashcode is changing while your overridden hashcode isn't.
 
gurpeet singh
Ranch Hand
Posts: 924
1
Fedora Java Netbeans IDE
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
saloni jhanwar wrote:
gurpeet singh wrote:
saloni jhanwar wrote:
gurpeet singh wrote:
Helen Ma wrote:So, if the hashcode of an object may be different for each execution, we should not write any code depending on hashcode?
For example, we should not use hashcode as a primary key of a database. Is it true?

I tried Integer i= new Integer(1). Every time, it gives me the hashcode = 1. Please verify this.


that's the wrapper object you are creating. wrappers have overridden hashcode method from the object class. so that is why you are getting the same hashcode. what saloni was referring about was regarding object of a class which has inherited hashcode implementation from object class.


There is no such a condition that if you override hashcode() then it will give same hashcode all time ,you can check original hashcode using System.identityHashCode(obj);



do you mean that if i override hashcode like this public int hashcode() { return 5; }, the subsequent execution of the hashcode method will return something different ?


It'll always give you 5 but internal original hashcode wont be same all time .


ya exactly. wrappers classes have overridden hashcode method , so in their case the hashcode will be always consistent for subsequent executions and even after multiple compilation and execution scenarios. because in that case the internal original hashcode method of the Object class won't run.
 
I agree. Here's the link: http://aspose.com/file-tools
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic