Yes, I think I did, but that was before I found the symmetry bug in HashTree.
I'll try again - but I'm sure some clone tests will fail as they check for cloned items being equal. I suppose if equality testing was required for purposes other than Collections we could implement a sameAs() or similar() method that would not get used by Collections. S. >-----Original Message----- >From: Jordi Salvat i Alabart [mailto:[EMAIL PROTECTED] >Sent: 20 February 2004 14:27 >To: JMeter Developers List >Subject: Re: [HEADS UP] Possible problems with equals() and hashCode() > > >Yes, let's clean up! Have you tried removing those equals() methods? > >BAZLEY, Sebastian wrote: >> I've been looking at equals/hashcode following some warnings >from FindBugs, >> but not resolved the problems fully. Thought it would be >useful to summarise >> what I've found so far: >> >> If a class over-rides equals(), it should also override hashCode(), >> otherwise it cannot be used reliably in Collections which >use hashing. >> Furthermore, if a non-abstract class overrides equals(), it is then >> impossible to write a compliant equals() method for any >class that extends >> and adds an aspect to the base class. >> >> Now AbstractTestElement (ATE) overrides equals(), but does >not provide a >> compliant hashCode(). >> The equals() method compares instances using the propMap >field only, but >> when I tried using propMap.hashCode(), all sorts of problems >occurred in the >> test tree, with elements being lost. >> >> Furthermore, the classes that extend AbstractTestElement >(ATE) don't provide >> their own equals() and hashCode() methods, even if they add >an aspect to the >> class. Two such classes can compare equal even if there are >significant >> differences in their data areas. >> >> I tried adding what I thought were suitable equals() and >hashCode() methods >> to the sub-classes of ATE, but started to get JUnit errors. >Likewise if the >> equals method is removed from ATE. I've not yet worked out >if these are >> real, or if the tests need changing. >> >> Actually, I'm not clear on is the purpose of providing an >equals() method >> for test elements - can anyone provide enlightenment? >> >> There may be a similar problem with Properties. >> I can see that these might be suitable candidates for using >equals(), but I >> think the hashCode() contract is currently not always >honoured. I need to >> write some tests for this ... >> >> S. >> >> >> >_______________________________________________________________ >____________ >> >> This e-mail and the documents attached are confidential and >intended solely >> for the addressee; it may also be privileged. If you receive >this e-mail in >> error, please notify the sender immediately and destroy it. >As its integrity >> cannot be secured on the Internet, the Atos Origin group >liability cannot be >> triggered for the message content. Although the sender >endeavours to maintain >> a computer virus-free network, the sender does not warrant that this >> transmission is virus-free and will not be liable for any >damages resulting >> from any virus transmitted. >> >_______________________________________________________________ >____________ >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > >--------------------------------------------------------------------- >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
