en passant: is IndexingObjectStore safe?

Tom Zeller tzeller at dragonacea.biz
Wed Jan 15 12:16:04 EST 2014


>>> I should have said hashCode() explicitly, as that's what the class is
>>> using to detect "different" objects. My point is that this isn't
>>> sufficient to tell objects apart, unless you only define the class to be
>>> valid across objects where hashCode() comparison is the same as content
>>> equality, which is not in general the case.
>>
>> It seems like actual equality here is the only foolproof test criteria for
>> reusing an object,
>
> I think that's right. The premise of the class at present, though, is that you get back an index equal to the hashCode() that you can use to retrieve the object... and you can't have both of those things unless you never put in two objects which are not equal() but have the same hashCode(). That's *usually* going to be true, but is definitely not guaranteed.

Ah, I think I get it now, apologies for the noise.

I was going to say : two objects with the same hashCode() are equal(),
but that is not always true, and is the point you are making.

"If two objects are equal according to the {@code equals(Object)}
method, then calling the {@code hashCode} method on each of the two
objects must produce the same integer result."

"...the general contract for the {@code hashCode} method, [which]
states that equal objects must have equal hash codes."


More information about the dev mailing list