What's your opnion?
Thanks.
On 5/15/06, Vladimir Strigun <[EMAIL PROTECTED]> wrote:
>
> On 5/5/06, Mikhail Loenko <[EMAIL PROTECTED]> wrote:
> > 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.
>
> Andrew,
>
> what do you think about it? I think we should mark it as compatibility
> bug and close it as wontfix. If we will switch to RI behaviour, we
> need to check all decoding operations in java.io package and possibly
> correct some methods.
>
> Thanks.
> Vladimir.
>
>
> > 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]
> >
> >
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
--
Andrew Zhang
China Software Development Lab, IBM
