Hi there,
>> We've got to a bit careful lest we be compatible with Sun's bugs that
>> they later fix.
>>
>> I remember an early version of Mauve carefully testing that a
>> particular floating-point output bug in Sun was precisely reproduced!
>> By that reckoning Sun can never have any bugs, no matter how heinous
>> their effects!
>>
>> So: we should comply with the spec, and sometimes where in might be
>> important for applications we should comply with the JDK as well. But
>> unless there are very good reasons we should not be compatible with
>> bugs where the implementation diverges from the specification. That
>> way lies madness.
I agree. It doesn't fully answer my question really. I should have been
a bit more specific I guess. The problem here is that the spec says
@throws XYZException if input is invalid. Does that mean we are required
to check and throw that exception even if Sun doesn't? I think not,
especially since that spec is in an interface, and the classes that
don't check the input are only implementing classes and IMO free to not
throw the exception. At least one of the classes in question
(GapContent) can even deal with input out of bounds quite intelligently,
both on the RI and in Classpath (now) (that is the
GapContent.createPosition() method).
Also, if we are going the spec compliant way (should be ok here - I
haven't seen an app that explicitly makes use of that special GapContent
behaviour), then we should at least remove the tests that tests corner
cases that lie outside the spec.
/Roman
