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 System.in to read the username and password? Just my 2cents. -Matt mkurjano at cc.gatech.edu -----Original Message----- From: Bill de h�ra [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 16, 2003 2:55 PM To: [EMAIL PROTECTED] 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 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
