2006/5/5, Vladimir Strigun <[EMAIL PROTECTED]>:
On 5/5/06, Mikhail Loenko <[EMAIL PROTECTED]> wrote:
> Vladimir, Andrew
>
> 2006/4/26, Andrew Zhang <[EMAIL PROTECTED]>:
> > Here I propose two solutions:
> >
> > 1. Set the ByteBuffer to the limit, and store the remaining ByteBuffer in
> > decoder. Invokers doesn't care the position of in. If the result is
> > UNDERFLOW and there're furthur input, just pass the new input to the
> > decoder. It's a typical streaming decoder. That's what Harmony does
> > currently.
> >
> > 2. Decoder doesn't store remaining ByteBuffer. Position of "in" is set to
> > indicate the remaining ByteBuffer. Invoker should take care to generate new
> > input ByteBuffer for next invocation. RI acts in this way.
> >
> > Both are acceptable.
>
>
> Did I get it right that both solutions do not contradict to the spec
> and that RI acts as the second one?
Mikhail,
you absolutely right. I think this issue could be closed, but possibly
it would be better to mark it as non-bug difference from RI.
Richard, what do you think?
In this case according to our compatibility guidelines we should switch
behavior to RI-like.
Thanks,
Mikhail
Thanks.
Vladimir.
> Thanks,
> Mikhail
>
>
> >
> > However, I think solution 1 is more reasonable.
> >
> > "Is it possible to store bytes in decoder, support streaming decoding, and,
> > at the same time sets correct position in input buffer after each operation?
> > "
> >
> > Yes. In fact, your patch will make Harmony act as the description above.
> >
> > However, I don't think it solve the problem. Maybe invoker is more
> > confusable and may think:
> >
> > "Is the remaining bytebuffer maintained in decoder or in ? Shall I get the
> > remaining buffer from in and pass it for next invocation?"
> >
> > Anyway, we need a decision on this compatibility issue.
> > By the way, Vladimir, does solution one cause any problem on other classlib
> > implementation?
> >
> > Any comment?
> >
> > Thanks !
> >
> >
> > Vladimir Strigun commented on HARMONY-410:
> > ------------------------------------------
> >
> > Hi Richard,
> >
> > Thanks for the clarification, I agree that streaming decode is good thing,
> > but I'd like to explain my understanding of specification :)
> > According to specification of CharsetDecoder decoding operation should
> > process by the following steps:
> > "
> > 2. 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;
> >
> > 3. Invoke the decode method one final time, passing true for the endOfInput
> > argument; and then
> > "
> > spec also says:
> > "The buffers' positions will be advanced to reflect the bytes read and the
> > characters written, but their marks and limits will not be modified"
> >
> > I understand these sentences in the next way:
> > invoke decode with endOfInput = false if you have additional input, then
> > fill the buffer (i.e. add to buffer some additional input), invoke decode
> > again and pass correct endOfInput parameter dependent of availability of
> > input.
> >
> > Example you provided is very useful and, of course, 1st option looks better,
> > but what I'm suggest here is to reflect actual processed bytes in input.
> > After first invocation of decode, not all bytes processed actually, i.e.
> > almost all bytes processed, but some stored in decoder to further operation.
> > Is it possible to store bytes in decoder, support streaming decoding, and,
> > at the same time sets correct position in input buffer after each operation?
> >
> > Thanks.
> > Vladimir.
> >
> > > method decode(ByteBuffer, CharBuffer, boolean) should set correct position
> > in ByteBuffer
> > >
> >
----------------------------------------------------------------------------------------
> > >
> > > Key: HARMONY-410
> > > URL: http://issues.apache.org/jira/browse/HARMONY-410
> > > Project: Harmony
> > > Type: Bug
> >
> > > Components: Classlib
> > > Reporter: Vladimir Strigun
> > > Assignee: Mikhail Loenko
> > > Priority: Minor
> > > Attachments: Harmony-410_patch.txt, harmony-410_test.txt
> > >
> > > When ByteBuffer contain incomplete sequence of bytes for successful
> > decoding, position in ByteBuffer should be set to latest successful byte. I
> > will attach testcase and patch soon.
> >
> > --
> > This message is automatically generated by JIRA.
> > -
> > If you think it was sent incorrectly contact one of the administrators:
> > http://issues.apache.org/jira/secure/Administrators.jspa
> > -
> > For more information on JIRA, see:
> > http://www.atlassian.com/software/jira
> >
> >
> >
> >
> >
> > --
> > Andrew Zhang
> > China Software Development Lab, IBM
> >
> >
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
