Thursday, November 16, 2006, 3:36:14 AM, you wrote:
JL> Hi Piyush, JL> I thought I had it right this time! The Factory.hashCode algorithm JL> multiplies by 31 for each loop, so I assumed it would be fully JL> discriminating. I've even added several unit test cases checking this (see JL> CookieTestCase class). JL> Now, looking closer, it appears that we indeed could run into some very very JL> rare cases where two unequals objects could return the same code. I guess we JL> can't affort them, even if there is one chance over a Integer.MAX_VALUE! So JL> I'll have to reverse the equals() implementations to manual comparison of JL> each property :( JL> Best regards, JL> Jerome >> -----Message d'origine----- >> De : Piyush Purang [mailto:[EMAIL PROTECTED] >> Envoyé : mercredi 15 novembre 2006 22:40 >> À : [email protected] >> Objet : equals and hashcode >> >> Hi Jerome, >> >> I saw the implementation of equals for cookie and have to admit I was >> almost shocked :) >> >> The code brings out to the fore the following phrases/sentences from >> the Object#equals and hashcode contracts >> >> Object#equals >> 1.1 equals method for class Object implements the most discriminating >> possible equivalence relation on objects >> >> 1.2 so as to maintain the general contract for the hashCode method, >> which states that equal objects must have equal hash codes. >> >> Object#hashCode >> >> 2.1 It is not required that if two objects are unequal according to >> the equals(java.lang.Object) method, then calling the hashCode method >> on each of the two objects must produce distinct integer results >> >> >> the essence of my objection to the present implementation is that >> "equal objects must have equal hash codes" but not "objects having >> equal hashCodes must be equal" >> >> In cookies case an example might be contrivied where for one cookie >> the version is say 1, name evaluates to 2 and all others evaluate to 1 >> and for another cookie the version is 2, name evaluates to 1 as do the >> other params .. in this case equals as implemented by Cookie will lead >> to a faulty conclusion of "true". The equals has to be even more >> discriminating than hashCode. and the instanceOf doesn't make it >> discriminating enough. >> >> I hope I was succint enough. >> >> Cheers >> Piyush Not sure if you knew but later version of Eclipse (probably 3.3) will create equals/hashCode for you. Here's what it suggest for Cookie: @Override public int hashCode() { final int prime = 31; int result = super.hashCode(); result = prime * result + ((domain == null) ? 0 : domain.hashCode()); result = prime * result + ((path == null) ? 0 : path.hashCode()); result = prime * result + version; return result; } @Override public boolean equals(Object obj) { if (this == obj) return true; if (!super.equals(obj)) return false; if (getClass() != obj.getClass()) return false; final Cookie other = (Cookie) obj; if (domain == null) { if (other.domain != null) return false; } else if (!domain.equals(other.domain)) return false; if (path == null) { if (other.path != null) return false; } else if (!path.equals(other.path)) return false; if (version != other.version) return false; return true; } -- Chris Grindstaff | http://gstaff.org
