harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mikhail Loenko" <mloe...@gmail.com>
Subject Re: bug-to-bug compatibility - another issue
Date Wed, 22 Feb 2006 10:21:47 GMT
Paulex

On 2/22/06, Paulex Yang <paulex.yang@gmail.com> wrote:
> Mikhail
>
>
> Mikhail Loenko wrote:
> > Paulex,
> >
> > look at the class description in the spec:
> >
> > "A decoder should always be used by making the following sequence of
> > method invocations, hereinafter referred to as a decoding operation:
> >
> > Reset the decoder via the reset method, unless it has not been used before;
> >
> > Invoke the decode method zero or more times, as long as additional
> > input may be available, passing false for the endOfInput argument and
> > filling the input buffer and flushing the output buffer between
> > invocations;
> >
> > Invoke the decode method one final time, passing true for the
> > endOfInput argument; and then
> >
> > Invoke the flush method so that the decoder can flush any internal
> > state to the output buffer. "
> >
> >
> As I said, what I paste at first is just ONE Example that RI's
> interesting internal status. I happened to have another simple JUnit
> test to show RI's contradiction on the paragraph above
>
>    public void testFlushAfterDecode() throws Exception {
>        ByteBuffer in = ByteBuffer.wrap(new byte[] { 98, 98 });
>        CharsetDecoder decoder = Charset.forName("utf-8").newDecoder();
>        CharBuffer out = decoder.decode(in);
>        try {
>            decoder.flush(out);
>            fail("should illegal");
>        } catch (IllegalStateException e) {
>        }
>    }
>
> RI(JDK 5.0/1.4.2) failed to pass this test because the flush(out) is
> permitted, but from the spec above, the decoder.decode(in) should invoke
> flush method at last, and the current status is FLUSHED, so that the
> flush(out) after that should throw IllegalStateException. Should Harmony
> be same with RI again?

It should be carefully thought of. In general case throwing an exception
when RI passes might break existing applications, not throwing exceptions
when RI does throw might create vulnerabilities.

> > So RI works according to class description. It might be a misprint in the
> > method description you have cited. I'd rather be compatible with RI
> >
> > Thanks,
> > Mikhail
> >
> I'm afraid I have different view on this,
> First, the method spec is not contradict with class's, the
> flush(CharBuffer) should be invoked in the decode(ByteBuffer), that's
> right, and it also can be invoked just after reset(), any logic problem?
> Second, how can we judge JavaDoc is misprinted? just by RI's behavior?

Definitely not only. But when one place in the spec contradicts to another
one (like in your first example) we should follow RI.

Thanks,
Mikhail


> >
> > On 2/22/06, Paulex Yang <paulex.yang@gmail.com> wrote:
> >
> >> Following the discussion before, I have another issue about RI's "bug",
> >>
> >> try this little test below:
> >>
> >> import java.nio.charset.*;
> >> public class DecoderTest{
> >>    public static void main(String[] args){
> >>            CharsetDecoder decoder = Charset.forName("utf-8").newDecoder();
> >>        decoder.reset();
> >>        decoder.flush(CharBuffer.allocate(10));
> >>    }
> >> }
> >>
> >> It quits quietly on Harmony, while on RI(JDK 5.0/1.4.2), it throws
> >> exception like below:
> >> java.lang.IllegalStateException: Current state = RESET, new state = FLUSHED
> >>    at
> >> java.nio.charset.CharsetDecoder.throwIllegalStateException(Unknown Source)
> >>    at java.nio.charset.CharsetDecoder.flush(Unknown Source)
> >>    ........
> >>
> >> But the spec of CharsetDecoder.flush() says:
> >>
> >> Throws:
> >>    IllegalStateException - If the previous step of the current decoding
> >> operation was an invocation neither of the reset method nor of the
> >> three-argument decode method with a value of true for the endOfInput
> >> parameter
> >>
> >> It's so interesting that the spec emphasizes it SHOULD NOT throw
> >> IllegalStateException when flush() just after reset().
> >>
> >> In fact, this is just one example of contradiction between spec and RI's
> >> CharsetDecoder/Encoder internal status implementation. These *bugs*  are
> >> serious so that the RI's Decoder/Encoder must be used by experiment.
> >> Should Harmony be compatible with RI?
> >>
> >>
> >>
> >> --
> >> Paulex Yang
> >> China Software Development Lab
> >> IBM
> >>
> >>
> >>
> >>
> >
> >
>
>
> --
> Paulex Yang
> China Software Development Lab
> IBM
>
>
>

Mime
View raw message