geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Blewitt <>
Subject Re: Status: JavaMail API implementation now at Alpha quality
Date Tue, 16 Sep 2003 18:04:29 GMT
On Saturday, Sep 13, 2003, at 17:13 Europe/London, Jeremy Boynes wrote:

>> From: []
>> 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.

We exchanged e-mails on the subject and were left in the knowledge that 
the Sun implementation does not correctly implement equals as per the 
JavaDoc. Thus, it was correct to fix the bug and implement it correctly.

>> The issue at stake is that the bug also exists in the Sun 
>> implementation.
> 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

The spec is not ambiguous; it is completely clear in java.lang.Object 
how the equals method behaves. The RI is demonstrably buggy; the 
implementation I provided is not. You re-introduced the bug breaking 
what the spec says.

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

Now who's being melodramatic? It is simply a bug, and bugs get fixed 
all the time. We are not chasing a movable set of bugs; we are 
achieving a reimplementation with its own set of bugs, and hopefully, 
its own set of fixes. The spec is the clear definition of what happens, 
and Suns implementation can be used where the spec is vague or missing 
on the subject. In this case, the spec is neither missing nor ambigous.

>>>> 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 have no issue with earning trust, and my code demonstrates what I am 
putting into the project. I also have no fear in disagreeing with 
people, and nor of code reviews by others -- several bugs I have 
inadvertently introduced have been found (and fixed) by others on this 

I never said that I would be a perfect coder, but I did say that I was 
conforming to the JavaMail spec. I took offence that you did not trust 
that this was my goal.

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

The spec is not ambiguous on this method, though, is it? Read the 
JavaDoc, and come back if you have questions.

FWIW I am following a license that does not allow checking against the 
RI; I am doing a full clean-room implementation according to the 
JavaMail license. You may be testing using a different license, such as 
the Sun Binary Code License, but I am not and therefore do not have the 
luxury of being ale to test the RI.

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

You complain when I submit lots of little patches. I ask for advice on 
the size of patches, both publicly and privately, to which I received 
no response. You complain when I submit a large patch.

I am coding faster than patches being applied can keep up with. I have 
raised this issue before, and am working within the current set of 

I also considered that other members of the community with which I have 
been conversing about the JavaMail and JAF packages would like to work 
with an alpha release of the JavaMail spec rather than me going on 
holiday and not providing them for others' use. So I do consider my 
work to be beneficial to the community at large, though perhaps not to 
yourself personally.

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

So, I can submit a large single patch as long as its good? Well, I've 
done that with the last one then :-)

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

Great! So it's a good patch then. It compiled, it ran, it passed the 
unit tests -- at least on my machine. The fact that you believe a bug 
should be emulated, whereas I believe it doesn't, is the only issue at 


View raw message