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]
