On Saturday, Sep 13, 2003, at 17:13 Europe/London, Jeremy Boynes wrote:
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Saturday, September 13, 2003 5:12 AMb) 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 list.
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 constraints.
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 stake.
Alex.
