james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "A. Rothman" <amich...@amichais.net>
Subject Re: Mailet API documentation
Date Thu, 06 Aug 2009 17:19:14 GMT
>
>>>> 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("me@here") will 
be equal to the String "ME@HERE" but they will have different hash codes.

Two more doc issues:

1. Can Matcher.match return null for no recipients? (more efficient... 
should be documented)


2. Are multi-valued init parameters always returned as a comma-separated 
string?


Robert - thanks for reviewing all the javadoc fixes :-)

Amichai


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message