geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Matt Kurjanowicz" <>
Subject RE: Status: JavaMail API implementation now at Alpha quality
Date Tue, 16 Sep 2003 20:07:25 GMT
Well, after reviewing the code, I think that it's up to spec.  I've been
looking at it for a few days, and compared each class to the JavaDoc and
JavaMail API, and I think they all match well.  As far as the .equals()
method is concerned, I leave that up to the rest of the community.  I
don't have a personal preference, but I think blindly following the RI
is not always the way to go since we are implementing the *spec*, not
just a reimplementation of the Sun RI.  If the current implementation is
up to Spec, then I think that we're OK.

As far as packaging external classes, I think it very appropriate, as
long as we say *what* we are including.  It's our implementation of the
API, and as long as it's up to Spec, it doesn't matter what's going on
behind the scenes - that's just abstraction and is of no consequence to
the end-user.

One question I do have:
How would it be good to implement the requestPasswordAuthentication(...)
method in the javax.mail.Store class?  The javadoc says to prompt for a
username and password in a fairly standard way, but how does that fit in
to the Server?  Would it be a good idea to use a standard System.out and to read the username and password?

Just my 2cents.
mkurjano at

-----Original Message-----
From: Bill de hÓra [] 
Sent: Tuesday, September 16, 2003 2:55 PM
Subject: Re: Status: JavaMail API implementation now at Alpha quality

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

View raw message