Roman Kennke wrote:
Hi lists, hi David (you wrote most of the tests I'm gonna talk about..)
While trying to clean up some Mauve failures I came upon a couple of
tests that fail on JDK because they test strictly against the spec
where the JDK isn't as strict. This is mostly bounds checking, where
the spec says throws BadLocationException if invalid or similar. I
think the JDK simply doesn't perform explicit checks in the Content
implementations. See for example the tests for GapContent and
StringContent.
Now I am not sure how to handle this. I've commented these tests out
locally, simply to avoid clutter in the Mauve output. The question is
how to interpret the spec. Adding the throws BadLocationException does
mean (to me) that the impl may or may not throw a
BadLocationException, but the application should be prepared to deal
with it anyways. Moreover, the throws BadLocationException is
specified in the interface. The implementations are not required to
throw the BadLocationException if they decide to deal with wrong input
themselves. For instance, the GapContent implementation (ours as well
as JDK) can very well handle Position outside the range, because it
only calculates offsets.
The situation gets worse. There are a number of tests both in Mauve
and in the Intel testsuite that actually test the JDK behaviour of
_not_ throwing the BLE, sometimes indirectly (via a Document impl or
so). So we can't get to fully PASS with Mauve.
We should decide if we want to test strict spec compliance or
reference impl compatibility. So far the decisions in GNU Classpath
have been made in favour of (bug-) compatibility over strict spec
compliance, so I think we should do the same for Mauve.
Anyway, I think we should either disable the spec-compliance checks or
the RI-compatibility checks or both in Mauve so that we have at least
a chance to reach 100%.
Any opinions on that?
/Roman
Hi Roman,
The theory is easy: Mauve should test AN implementation against THE
spec. The reality is...well, you know already what the reality is.
Send me the names of the tests that are causing problems, and I'll try
to recode them to pass on Sun's JRE 1.5.0, otherwise I'll file a bug
report with Sun. I may recode some tests with two paths, so I can set a
system property (say) and check for strict spec compliance if I want or
need to.
I never heard back from Sun about the GapContent bug I filed in
January. I filed a few other bug reports since then, with little to
show for it:
http://www.object-refinery.com/jre/bugs/
...but with 100,000 bug reports in the first half of 2006, I guess
they're busy!
Regards,
Dave
