Don't you just love free internet access at airports :-) > > From: Jeremy Boynes [mailto:[EMAIL PROTECTED] > > Sent: Friday, September 12, 2003 11:04 PM > > To: [EMAIL PROTECTED] > > Subject: RE: Status: JavaMail API implementation now at Alpha quality > > > > -1 for this patch because > > a) there is a dependency on geronimo-common that is inappropriate > > for a standalone spec module
The dependency is on the InvalidArgumentException and NullArgumentException. I originally put those in since when they become internationalised, changes made to those classes will have immediate benefit to the JavaMail API. They are fairly easily changed to throw IllegalArgumentException instead (which is what they were originally). I do not believe that the specs package cannot include classes outside of the javax. namespace; indeed, the Sun RI ships with a whole bunch of com.sun classes as is. There isn't any reason why JavaMail couldn't ship with an org.apache class or two instead. But this is a fairly trivial issue and could be resolved simply by moving them back to java.lang.IAE. > > b) a change was made to the impl of URLName.equals() that makes it > > behave differently to the RI and which I explicitly asked Alex > > not to make Actually, the change was /back/ to the original implementation, from which it was changed in the first place. The issue was in defining the equals method as: o instanceof URLName instead of the more correct o == null || o.getClass() != this.getClass() I wrote and demonstrated a unit test to show that the equals method was broken, (which may be why the unit test fails as above). Others may like to try and implement the equals method differently, but the only one that correctly passes the test case will be the getClass() variant. Unfortunately, Josh Bloch gave the entire Java industry the impression that using 'instanceof' is correct in his book 'Effective Java', which is otherwise a very good Java book -- but fails dismally on the implementation of equals method. All you have to do is look at the JavaDoc for java.lang.Object to find out what it should do, and the instanceof method fails two of the constraints required for a correct implementation of equals. The issue at stake is that the bug also exists in the Sun RI. I believe that it is right the community should decide which is appropriate to use, and we can use that one instead; it isn't for two people to disagree and come up with an implementation. The absolute question is: what are we trying to achieve in the JavaMail API reimplementation? Copy it byte-for-byte, including any bugs that are present in the JavaMail implementation? Or provide something that behaves correctly as per the JavaDoc? My take on this is that we should implement to the spec, and not try to represent every bug in the RI, since the latter will be a moving target. > > These may seem minor but they are symptomatic of a coding > > approach that may lead to other deviations and I think the > > entire patch should be reviewed in detail. If someone steps > > up to do that then it may be appropriate to commit this to a > > separate branch until done. Always nice not to be trusted :-) I've tried to code extensive unit tests for the code in the JavaMail API to ensure that I do closely stick to the spec, including feedback from others with JDiff about the implementation of the methods. I have always been very careful to implement the JavaMail APIs based on the JavaDoc, and I have not used the JavaMail binary at all during this process. Therefore, I believe the work I have been doing is very careful and considerate towards the specification, and I am upset by Jeremy's allegation above. Seriously, the reason I hand't put that in before was because I was submitting lots of small patches with detailed messages about them. This was then slated by the cathedral, so instead I submitted an entire patch with my work so far before going on holiday. I had wanted to bring the discussion about the 'warts-and-all approach vs correct implementation from JavaDoc' before submitting it later, but it got subsumed in this approach. I am of the opinion that the only number of patches people will be happy with me submitting is zero; it's not worked with detailed patches, and it's not worked with one-size-fits-all approach. See you all after I return, Alex. /***************************************************************\ |* Alex Blewitt * Hug, and the world hugs with you *| |* [EMAIL PROTECTED] * *| |* Mobile: +44 7966 158 647 * Spread a little happiness *| \***************************************************************/
