On Tuesday, Sep 16, 2003, at 19:55 Europe/London, Bill de h�ra wrote:
Alex Blewitt wrote:On Saturday, Sep 13, 2003, at 22:39 Europe/London, Danny Angus wrote:4/ We know from discussions regarding Tomcat that the behaviour of a RI
itself forms "case law" and sets precedence about the expected behaviour of
other implementations.
In the absence of clarity in the spec, yes. Is the spec on this equals method unclear?
It's vague, for certain -- the document is at
http://java.sun.com/products/javamail/javadocs/javax/mail/ URLName.html#equals(java.lang.Object)
However, it overrides the Object API which puts behavioural constraints on subclass' implementations, which they should honour.
You are at liberty to "fix" it but this would then be a deviation from theThe 'bug' is in the definition of the 'equals' method, which is clearly defined in the Java language in the java.lang.Object class:
API behavoiur which our user would have to be informed of, for the sake of
their sanity if nothing else.
[...]
The implementation in the Sun JavaMail breaks this by not being transitive (that is, it is possible for the equals method to have a.equals(c) and b.equals(c), but not a.equals(b). The implementation I used had the advantage that (a) it was transitive, and that (b) the implementation of the method is more efficient for large numbers of subclasses.
Let's put aside the Object.equals contract and the RI code for a second. The important question it seems to me, is this: is what's in CVS now, compliant with the JavaMail *spec*?
Both are compliant with the spec; one exhibits a bug. A test case already exists that demonstrates the bug and the associated patch fixes it.
If it is, leave it alone. If it's not, patch it.
I do not believe that it is right to emulate bugs in JavaMail -- otherwise, where would we stop? I believe that the bug should be fixed; but it's a bug introduced by another's opinion of how it should work.
The only time a behavioural difference will be noted is if subclasses of the offending object (URLName) are created.
Again, what matters is whether this means anything with regard to the *spec*.
What is the spec, though? The PDF document on the spec doesn't explicitly mention it, and the URLName's documentation describes how the behaviour of equals work, but does not explicitly re-state the conditions from the superclass. However, the superclass' documentation says that subclasses must implement the equals method in that fashion, so a class that overrides it and does not provide transitivity will be in violation of the contract.
It may well be a moot point since the JavaMail TCK is unlikely to test transitivity of equals (otherwise they would have picked up the bug :-) so either solution will pass spec compliance. But I still strongly dislike the idea of leaving a known bug in an implementation, especially when the test and fix is available.
Alex.
