Re: bug-to-bug compatibility - another issue

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