Re: bug-to-bug compatibility - another issue

Well the contradiction is:

according to class description there must be
a call of "the decode method one final time, passing true for the
endOfInput argument" and then 'flush', i.e.

reset -- [decode(false)]* -- decode(true) -- flush

according to method's description, 'flush' might follow 'reset', i.e.

reset -- flush

Thanks,
Mikhail


On 2/22/06, Paulex Yang <paulex.yang@xxxxxxxxx> wrote:
> Mikhail
>
> Mikhail Loenko :
> > Paulex
> >
> > On 2/22/06, Paulex Yang <paulex.yang@xxxxxxxxx> 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.
> >
> That's true, so I post it to mailing list for discussion:).
> >
> >>> 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.
> >
> Again, I don't think the spec is contradict, that's the RI which is
> contradict with Spec in several places. In this case, rather than
> suspecting spec is misprinted, I would like to say that RI is not logical.
>
> Regards,
>
> Paulex
> > Thanks,
> > Mikhail
> >
> >
> >
> >>> On 2/22/06, Paulex Yang <paulex.yang@xxxxxxxxx> 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
> >>
> >>
> >>
> >>
> >
> >
>
>
> --
> Paulex Yang
> China Software Development Lab
> IBM
>
>
>