geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex.Blew...@ioshq.com
Subject RE: Status: JavaMail API implementation now at Alpha quality
Date Sat, 13 Sep 2003 12:11:44 GMT
Don't you just love free internet access at airports :-)

> > From: Jeremy Boynes [mailto:jeremy@coredevelopers.net]
> > Sent: Friday, September 12, 2003 11:04 PM
> > To: geronimo-dev@incubator.apache.org
> > 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 *|
|*  Alex.Blewitt@ioshq.com  *                                  *|
|* Mobile: +44 7966 158 647 *    Spread a little happiness     *|
\***************************************************************/



Mime
View raw message