geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bill de hÓra <b...@dehora.net>
Subject Re: Status: JavaMail API implementation now at Alpha quality
Date Tue, 16 Sep 2003 18:55:22 GMT
Alex Blewitt wrote:
> On Saturday, Sep 13, 2003, at 22:39 Europe/London, Danny Angus wrote:
> 
>> 4/ We know from discussions regarding Tomcat that the behaviour of a RI
>> itself forms "case law" and sets precedence about the expected  
>> behaviour of
>> other implementations.

In the absence of clarity in the spec, yes. Is the spec on this 
equals method unclear?


>> You are at liberty to "fix" it but this would then be a deviation 
>> from  the
>> API behavoiur which our user would have to be informed of, for the  
>> sake of
>> their sanity if nothing else.
> 
> 
> The 'bug' is in the definition of the 'equals' method, which is clearly  
> defined in the Java language in the java.lang.Object class:
> [...]
> The implementation in the Sun JavaMail breaks this by not being  
> transitive (that is, it is possible for the equals method to have  
> a.equals(c) and b.equals(c), but not a.equals(b). The implementation I  
> used had the advantage that (a) it was transitive, and that (b) the  
> implementation of the method is more efficient for large numbers of  
> subclasses.

Let's put aside the Object.equals contract and the RI code for a 
second. The important question it seems to me, is this: is what's in 
CVS now, compliant with the JavaMail *spec*?

If it is, leave it alone. If it's not, patch it.


> The only time a behavioural difference will be noted is if subclasses  
> of the offending object (URLName) are created.

Again, what matters is whether this means anything with regard to 
the *spec*.


The rest of this mail is technically offtopic.


> What I objected to was the implication "symptomatic of a coding  
> approach that may lead to other deviations" as if I was against working  
> towards a fully compliant code. Granted, I may make mistakes in the  
> implementation (and others have picked these out) but I am not working  
> on a coding approach that throws this all out of the window.

Seeing as RMH kicked off some honest speaking earlier, here's my 2c 
on all this malarky.

I'm not seeing peer review on this thread. not by a long shot. I 
think Alex is catching some negative feedback that doesn't strike me 
as clear, useful, or informative. I certainly wouldn't be sure what 
to do to get better after sucking it up. People here, especially 
those with commit and  membership liberties can perhaps do better 
than non-respond to (it seems to me) a fair question by citing the 
poster as melodramatic, or claim patches are being dumped on them again.

Bill de hÓra



Mime
View raw message