Test for equality simply by checking identity in JAVA

[Hurkyl]

I'm writing a program that likes to test for equality simply by checking identity: IOW, a.equals(b) iff a == b.

Now, I think I would like to use HashMap's and stuff... so I would like to be able to use the appropriate accompanying hashCode method... that is, the default implementation of the hashCode method! It's the appropriate companion for my equality testing method, and it's quick as well... but I don't know how to access it if I'm handling an object that has overridden hashCode.

 

[so-crates]

Why would you want to use a hash method to test for equality ? Hash tables are for key indexing.

 

[Hurkyl]

Nonono...

Here's a more complete story:


In the code I'm writing, I only care about the identity of the objects I'm manipulating.

I would like to throw objects into a hash table, but where == is used for equality testing, not the "equals" method.

Now, equality testing is the easy part -- I'm already embedding the pointers to the objects of interest in another class, so I can just write the "equals" method of my class to test for equality via using == on the pointers.

Now, the question is how to write the "hashCode" method of my class. Since I'm using == for equality testing, it would be most appropriate (and most efficient) to use the default implementation of "hashCode". However, I don't know how to get that value if the object of interest has overridden the "hashCode" method.


As it turns out, I reorganized my data structures so that this is no longer an issue. However, I'm still interested if this question has an answer.

 

[so-crates]

I would like to throw objects into a hash table, but where == is used for equality testing, not the "equals" method.

Now, equality testing is the easy part -- I'm already embedding the pointers to the objects of interest in another class, so I can just write the "equals" method of my class to test for equality via using == on the pointers.

The == operator on two objects by default will test for reference equality, so there doesn't seem to be a need for pointers.

Now, the question is how to write the "hashCode" method of my class. Since I'm using == for equality testing, it would be most appropriate (and most efficient) to use the default implementation of "hashCode". However, I don't know how to get that value if the object of interest has overridden the "hashCode" method.

Can't you just extend the object and override isEquals() ? This can even be done without bloat anonymous/inner classes.

BTW I don't understand the utility of what you are suggesting. Hash tables are used to retrieve an object or value based on a key. The most common example is in databases where you retrieve a complete record based on on part of the data. I don't see how Java references are meaningful data items.

 

[Hurkyl]

I don't remember exactly how I was organizing things when I had this question, but the following, I think, was true:


My code was planning on receiving objects from the outside world. (Meaning some other piece of code)

My code cared only about the identity of the object.

I wanted to store these objects in HashSet's. (I don't think I ever actually used a HashMap)

Thus, the need for equals to be based on identity, and the desire to have the appropriate hashCode method.


I had wanted to attach something to the object, but I don't remember what. That's why I was wrapping the objects I received. At the time, I was worried about the possibility that I would wrap the same object multiple times, in which case I would want the wrappers to compare equal.

 

[TenaliRaman]

Hmm,
I was looking at your last line and was thinking, why can't you use the hashcode of your (presumably common) wrapper class for hashing, this way we don't have to bother whether the objects you receive has an overridden hashcode or not. Ofcourse this won't be of any use if you are using the hashcode of your wrapper class for some other purpose as well.

-- AI

 

[Hurkyl]

I remember worrying that I would wrap the same object on multiple occasions, and I had worked out that I would want the two different wrappers to compare equal in that case, meaning their hash codes would have to be equal.

 

[TenaliRaman]

Wasnt there anyway to avoid multiple wrapping? This seems to be the only problem to me here. Another way is to have a class with a static function which can generate hashcode out of any arbitrary object. But this hashcode has to be implemented manually (as is obvious). This would avoid worries abt objects getting multiply wrapped. But i am still in favour of avoiding multiple wrappings as that would allow a much more elegant and truly object oriented approach.

-- AI

 

[Hurkyl]

Well, the problem is that my code would be receiving objects from the outside world, and I might receive the same object multiple times.

The "elegant" way, I suppose, is to use .equals instead of ==, and if the user gives me two distinct objects that compare equal, then it's his own fault, but I didn't want to resort to that.