The problem is that the object.equals isn't sufficient when events are deserialized from a persistent store.
Being able to add events in a collection and know .contains will work - regardless of where the event came from - is definitely worth the hassle of maintaining the equals contract. -----Original Message----- From: Curt Arnold [mailto:[EMAIL PROTECTED] Sent: Tue 12/28/2004 12:49 PM To: Log4J Developers List Cc: Subject: Re: LoggingEvent.sequenceCount On Dec 28, 2004, at 2:06 PM, Ceki Gülcü wrote: >> > > The code currently says: > > /** > * The hashcode is computed as XOR of the lower 32 bits of > sequenceNumber and > * the higher 32 bits of timeStamp; > */ > public int hashCode() { > return (int)((timeStamp >> 32) ^ (sequenceNumber & 0xFFFFFFFF)); > } > > In what way does the comment not match the code? Sorry, I misread the comment. Thought it said lower 32 bits of the timestamp. > > The hashcode does not need to uniformly spread out the returned values > over the range of integer. It just has to make a minimal effort to > avoid that many values do not pile up on top of each other. Given that > all hash tables algorithms compute the hash value over modulo 'n' > where 'n' is a small prime number, for all practical purposes the > following hashcode would have been amply sufficient. > > public int hashCode() { > return (int)((sequenceNumber & 0xFFFFFFFF)); > } > > We are doing a little better by XORing with the higher 32 bits of the > timestamp. (2 to 32 milliseconds is about 50 days.) A slightly better > implementation would have been > > > public int hashCode() { > return (int)((timeStamp >> 20) ^ (sequenceNumber & 0xFFFFFFFF)); > } > > 2^20 millis = 1048576 millis or about 17 minutes. The point that I was trying to make and which I still think is valid despite my mistaken analysis of the hashCode function, is that it is better to have Chainsaw to make whatever comparison it thinks is appropriate for its filtering needs and avoid having to worry about maintaining the equals contract and having a hashCode function that results in good performance if LoggingEvents are added to a HashTable. > > >> p.s. LoggingEvent has commented out methods xgetMDCCopy and >> XXgetMDCKeySet. Are these going to be deleted or uncommented? > > They'll eventually be deleted. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
<<winmail.dat>>
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
