On Sat, Aug 8, 2009 at 7:50 PM, Norman Maurer <[email protected]> wrote: > Well, I think we should alter it. I never understood why james support > case sensitive email addresses at all..
AIUI the local-part of a mailbox is case sensitive whereas the domain is not (see RFC 5321 section 2.4.). This is how Mime4j's class Mailbox implements hashCode and equals, anyway. In any case hashCode and equals have to be consistent with each other of course. Bye, Markus > > Bye, > Norma > > 2009/8/8 Robert Burrell Donkin <[email protected]>: >> On Thu, Aug 6, 2009 at 6:19 PM, A. Rothman<[email protected]> wrote: >>>> >>>>>>> 4. MailAddress.equals breaks the equals contract and the >>>>>>> equals/hashcode >>>>>>> relationship - I added a doc explicitly stating this to avoid future >>>>>>> bugs, >>>>>>> but it would be much better to fix it (without breaking james, of >>>>>>> course)... >>>>>>> >>>>>>> >>>>>> >>>>>> do you have an example of the breakage? >>>>>> >>>>>> >>>>> >>>>> From the javadoc I added: >>>>> >>>>> * Note that this implementation breaks the general contract of the >>>>> * equals method as well as its relationship with the hashcode method, >>>>> * since it can return true when compared to a String instance >>>>> * (braking the symmetry property, and allowing equal objects to have >>>>> * different hash codes). >>>>> >>>>> in other words, it can return true when compared to a String, but a >>>>> String >>>>> will always return false when compared to a non-String, and this breaks >>>>> the >>>>> contract in two different ways. >>>>> >>>> >>>> i agree about the symmetry but IIRC when i analysed the hash code it >>>> was ok(ish). given that the whole idea breaks a basic contract in >>>> java, this is probably just splitting hairs. i strongly dislike this >>>> design and would prefer a separate method to allow strings to be >>>> explicitly checked. >>>> >>>> in general, MailAddress has issues, and should have been modelled as >>>> an interface >>> >>> I still think hashCode is also broken - a MailAddress("m...@here") will be >>> equal to the String "m...@here" but they will have different hash codes. >> >> agreed >> >> i'm in favour of altering the equals behaviour on MailAddress but have >> no idea about the possible impact >> >> opinions? >> >> - robert >> >> --------------------------------------------------------------------- >> 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] > > -- Always remember you're unique. Just like everyone else. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
