en passant: is IndexingObjectStore safe?

[Ian Young]

While reviewing Rod's list of orphaned or near-orphaned classes in java-support, I took a look at the IndexingObjectStore class. The intention of this, looking at its Javadoc, is to compress the in-memory storage of large objects which are repeated by using the objects' hash as an index into a reference-counted storage system. I think the prototypical application is X.509 certs in metadata.

The Javadoc includes this documented assumption:

> Therefore this store should never be 
> used to store objects that produce identical hash codes but are not functionally identical objects.

In other words, if there are two objects which have different hashes, they had better have identical functionality or IndexedObjectStore will Do The Wrong Thing.

That seems to be a dangerous assumption for a class to be making (and it is an assumption, as far as I can tell the code doesn't validate it). I can't see how one can guarantee that the assumption will hold for X509-certs-as-strings, which seems to be the OpenSAML use case. Of course, for most real data sets, the assumption will not be violated, but I am more than a little concerned that things might go wrong in hard to understand ways here.

Maybe there's a reason we know that this is safe in the OpenSAML case. Even if that's the case, I think I'd argue that a class with this much of a potential for misuse doesn't belong in a common library but should be moved to a private helper class within OpenSAML. Alternatively, some other way of compressing this kind of use case involving generating indices as sequential integers and equals() rather than relying on the hash might be safer.

	-- 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/9fc2cac0/attachment-0001.bin