On Thu, 2003-12-04 at 07:54, Ceki Gülcü wrote: > Yes. The general contact for the hashcode method says: > > 1 Two equal objects must have the same hashcode. > 2 Two unequal objects can have the same hashcode. > > Item 1 does *not* mean that unequal objects must have different hashcodes, > which is actually impossible to achieve.
Yes, sorry you are absolutely correct, that will work fine (you can see why I stuffed up my versions can't you... :) ).
Having said that, it might not be the most efficient, as any collection-style implementation which rely on 'buckets' will have those with the same hashcode in the same bucket, and will then require a linear search to locate them. If we can keep them more distinct, it might pay-off.
That is a good point but which is not necessarily correct. See below.
Now since the likelyhood of 2 events with exactly the same millisecond is small (but not impossible if aggregating events from lots of places, by say using a Receiver) maybe we should just tact on the hashCode of the Message?
The hashcode computation must be fast in itself, at least significantly faster than 'equals' method invocations which return false.
I think that String.hashcode computation is kinda slow depending on the JDK because it iterates on ALL the characters of the String.
On JDK 1.3.1 for example, the implementation is:
public int hashCode() {
int h = hash;
if (h == 0) {
int off = offset;
char val[] = value;
int len = count; for (int i = 0; i < len; i++)
h = 31*h + val[off++];
hash = h;
}
return h;
}It's the same implementation on 1.4.1.
cheers,
Paul
-- Ceki G�lc�
For log4j documentation consider "The complete log4j manual"
ISBN: 2970036908 http://www.qos.ch/shop/products/clm_t.jsp
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
