harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vladimir Strigun" <vstri...@gmail.com>
Subject Re: [classlib] [jira] Commented: (HARMONY-410) method decode(ByteBuffer, CharBuffer, boolean) should set correct position in ByteBuffer
Date Mon, 15 May 2006 08:43:56 GMT
On 5/5/06, Mikhail Loenko <mloenko@gmail.com> wrote:
> 2006/5/5, Vladimir Strigun <vstrigun@gmail.com>:
> > On 5/5/06, Mikhail Loenko <mloenko@gmail.com> wrote:
> > > Vladimir, Andrew
> > >
> > > 2006/4/26, Andrew Zhang <zhanghuangzhu@gmail.com>:
> > > > 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: harmony-dev-unsubscribe@incubator.apache.org
> > > For additional commands, e-mail: harmony-dev-help@incubator.apache.org
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > Terms of use : http://incubator.apache.org/harmony/mailing.html
> > To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: harmony-dev-help@incubator.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>

---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org


Mime
View raw message