en passant: is IndexingObjectStore safe?

[Ian Young]

On 15 Jan 2014, at 16:24, Tom Zeller <tzeller at dragonacea.biz> wrote:

> My logic-fu is weak this morning, but if two objects' hashCode()
> methods return different ints, then yes, the IndexingObjectStore will
> not optimize storage, but that is not really The Wrong Thing, AFAIK.

No, that's just less efficient than one would want. It isn't actually a problem.

It's the opposite I'm worried about... two DIFFERENT objects with the SAME hashCode() are seen as equivalent, when they may not be. The result would be that you may get back an object which is different than the one you stored.

For example, there are an infinite number of String values which have the same hashCode() value. We know this is true because there are an infinite number of possible String values but hashCode() returns an int (pigeonhole principle).

> Wondering if you are conflating hash with hashCode().

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's possible that there may be a flaw in my logic, though, that's what I am asking.

	-- Ian



-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5943 bytes
Desc: not available
Url : http://shibboleth.net/pipermail/dev/attachments/20140115/0a439d37/attachment-0001.bin