hashCode() Method

[Patricia Samuel]

Hi,

I was asked a problem - There are some values in database. And we need to add these values for some class. At some point these values get some hashcode that got repeated for different values for example i m having MCFJ and RTYZ and they are having say 10 for this hashcode and we will add values to the class based on this hashcode. What implementation should we give to stop repetiotion of hashcode at some time.

I think answer could be no implementation of the hashcode or we may implement it like giving some value to M, C and blah blah and use xor operator.

Would anyone like to give input on this?

Regard,
Patricia.

[Edwin Dalorzo]

Not sure if with your questions you are referring the the implementation of the hashCode() method of java.lang.Object and which, by inheritance, is present in all Java objects.

If you do not override it, then the hashCode will return a value generated out of converting the internal address of the object into an integer. Therefore we could expect that all objects have a different hash code (Not sure what would happen, though, if the number of active Objects surpass Integer.MAX_VALUE).

Now, if you decide to override the method yourself, then you will need to make sure that for a given class, the hashCode you generate is as unique as possible. Typically you do this using an algorithm that has as fewer collisions as possible, if any. At any rate, the Java contract for hashCode() does not require that two give objects have different hashCodes all the time. It does require that if two objects are considered equal by the equals() method that they should have the same hash code value.

[Campbell Ritchie]

It actually says in the Object class documentation that location is a typical way to calculate a hash code. But the location of an object in memory may change, eg after garbage collection when its hash code will usually be unchanged.

[Patricia Samuel]

That means we can limit the duplication to some extent by not implementing the hashCode method but we can't gurantee how JVM will behave at a particular moment.

[Edwin Dalorzo]

Well, Patricia, even when Campbell seemed to suggest that the location of an object in memory could change over time (for instance due to the generational garbage collection placing old objects in another memory space), even so the contract for hashCode in javadoc says:

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.

Therefore, regardless of the implementation of garbage collection or any other mechanisms that might place the object in another memory space, this method ought to return the same integer during the execution of the JVM.

Now, that being said, you must consider that this behavior of returning the memory space of an object as a hash code is not a required implementation of the method. Other JVM might implement it differently without violating the contract. Therefore, I would suggest that you should not take this implementation-dependent details into account while dealing with hashCode implementations.

You should only consider the contract stated in javadoc.

[Campbell Ritchie]

Yes, Edwin, that is what I meant.

[Patricia Samuel]

I realize that i had made a mistake in writing the post. This is really an interview question and not a requirement.

The question is - We want to use hashcode() to add element for a class. There is no equals() method. But at some instance hashcode() has same value for different pattern string. Say UFWX has hashcode() - 10 and FWXV - 10. So Interviewer wanted to ask me what could be the best implementation in that case for hashcode. He wanted to use hashcode to decide the duplication of records. UFWX and FWXV are two different values but they have same hashcode. I could tell only this - we could use XOR to manage the things.

Please suggest or let me know if I am not clear all again


Thanks & Regards,
Patricia Samuel.

[Patricia Samuel]

Waiting for experts' comments.

[Paul Clapham]

If there is no equals() method, then you don't need a hashCode() method either. The rule is: if two objects are equal according to the equals() method, then they must have the same value of their hashCode() methods. And since the only way for two objects of this class to be equal is when they are the same object, there is no requirement for two objects of this class to have the same hashCode() value.

So when you say about the interviewer:

He wanted to use hashcode to decide the duplication of records.

The answer to that is: No. The equals() method is the method you use for that.

[Cecilia Burman]

As long as your object inherits from Object, there must be an equals() method unless I'm much mistaken.