Re: bug-to-bug compatibility - another issue

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?

> 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?
> 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