Hi Andrew,
Yeah, I guess you have a better point. Going after every peculiar problem
of every RI(1.0, 1.1, 1.2, 1.3, 1.4, etc...) Sun produces would be insane.
Guess that's why "Write Once Run Everywhere" turned out to be a myth.
David
Fu.
> fchoong@xxxxxxxxxxx writes:
> >
> > > 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?
>
> > I also think that RI-compatibility should be given priority over
> > spec-compliance. So maybe only spec-compliance checks should be
> disabled.
> > Unfortunately, instead of reading what the spec says, most users will
> just
> > assume it is GNU Classpath's fault if the behavior is different from
> the
> > JDK :(
>
> 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.
>
> Andrew.
>
