geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jeremy Boynes" <jer...@coredevelopers.net>
Subject RE: Status: JavaMail API implementation now at Alpha quality
Date Sat, 13 Sep 2003 16:13:21 GMT
> From: Alex.Blewitt@ioshq.com [mailto:Alex.Blewitt@ioshq.com]
> Sent: Saturday, September 13, 2003 5:12 AM
> > > 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.

Exactly, and when I changed it in the first place I explained to you then
why the change was necessary.

<snip/>
> 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.
>

Leave out the melodrama.

The rules are simple:
1) Implement what the spec says
2) If the spec is ambiguous, do what the RI does
3) If you think the RI is wrong, live with it

JavaMail is a poorly defined specification, which makes the role of the RI
more critical not less. It has also been around forever achieving de-facto
status and changing things runs the risk of making this implementation
unusable.

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

Trust is to be earned.

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

That you have not compared behaviour to the RI for a spec that is known to
be ambiguous illustrates my concerns about your approach. All the unit
testing in the world won't identify a problem in how you expect it to work.

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

Again Alex, approach - you dump a patch on us and then disappear leaving
others to clear up the mess. Show some thought for other members of the
community.

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

Number of bad patches: zero
Number of good patches: unbounded

If a 30 second skim of the patch raises concerns, if the patch needs to be
tweaked so that it compiles, if the patched code fails the unit tests, then
I'm going to classify it as bad.

--
Jeremy


Mime
View raw message