geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Blewitt <Alex.Blew...@ioshq.com>
Subject Re: Status: JavaMail API implementation now at Alpha quality
Date Tue, 16 Sep 2003 20:19:33 GMT
On Tuesday, Sep 16, 2003, at 19:55 Europe/London, Bill de hÓra wrote:

> 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?

It's vague, for certain -- the document is at
   
http://java.sun.com/products/javamail/javadocs/javax/mail/ 
URLName.html#equals(java.lang.Object)

However, it overrides the Object API which puts behavioural constraints  
on subclass' implementations, which they should honour.

>>> 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*?

Both are compliant with the spec; one exhibits a bug. A test case  
already exists that demonstrates the bug and the associated patch fixes  
it.

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

I do not believe that it is right to emulate bugs in JavaMail --  
otherwise, where would we stop? I believe that the bug should be fixed;  
but it's a bug introduced by another's opinion of how it should work.

>> 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*.

What is the spec, though? The PDF document on the spec doesn't  
explicitly mention it, and the URLName's documentation describes how  
the behaviour of equals work, but does not explicitly re-state the  
conditions from the superclass. However, the superclass' documentation  
says that subclasses must implement the equals method in that fashion,  
so a class that overrides it and does not provide transitivity will be  
in violation of the contract.

It may well be a moot point since the JavaMail TCK is unlikely to test  
transitivity of equals (otherwise they would have picked up the bug :-)  
so either solution will pass spec compliance. But I still strongly  
dislike the idea of leaving a known bug in an implementation,  
especially when the test and fix is available.

Alex.

Mime
View raw message