You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Mikhail Loenko <ml...@gmail.com> on 2006/05/05 06:35:41 UTC
Re: [classlib] [jira] Commented: (HARMONY-410) method decode(ByteBuffer, CharBuffer, boolean) should set correct position in ByteBuffer
Vladimir, Andrew
2006/4/26, Andrew Zhang <zh...@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?
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
Re: [classlib] [jira] Commented: (HARMONY-410) method decode(ByteBuffer,
CharBuffer, boolean) should set correct position in ByteBuffer
Posted by Paulex Yang <pa...@gmail.com>.
Ah, I only checked the bug type just now, I just noticed that the
"non-bug differences from RI" is not type but component. Sorry and thanks:).
Mikhail Loenko wrote:
> Hi Paulex
>
> I've changed JIRA category to "non-bug differences from RI" just before
> I closed the bug
>
> Thanks,
> Mikhail
>
> 2006/5/23, Paulex Yang <pa...@gmail.com>:
>> Currently Mikhail marked this issue as "won't fix" with comments of "
>> non-bug difference from RI". I remember there is a similar category in
>> JIRA(I just cannot recall the exact name, but it should be obvious), is
>> there any chance in JIRA system to change this issue's category to that
>> one? I think it will be easier to search later. If not, how about raise
>> another one in that "non-bug difference from RI" category and add a link
>> to 410?
>>
>> Vladimir Strigun wrote:
>> > Hi Andrew,
>> >
>> > Thanks for your answer, please see my comments inside.
>> >
>> > On 5/22/06, Andrew Zhang <zh...@gmail.com> wrote:
>> >> Hi, Mikhail and Vladimir,
>> >>
>> >> I'd rather consider it as compatibility bug and close it as wontfix.
>> >
>> > Yes, we can close the issue as wontfix with compatibility comments,
>> > but I think we should put some description to Wiki. Or possible you
>> > can suggest more appropriate place for this.
>> >
>> >> "Did I get it right that both solutions do not contradict to the spec
>> >> and
>> >> that RI acts as the second one?"
>> >>
>> >> Partly right. Vladimir, maybe as you know, deep studying on decode
>> >> will show
>> >> many RI's unreasonable behaviours.
>> >>
>> >> Since RI's behaviour is not logical and the spec description is very
>> >> vague
>> >> in some situations (e.g. decode state defination, in/out buffer
>> poistion
>> >> defination),
>> >
>> > I can't say that RI's behaviour is not logical, but I can agree that
>> > decoding process implemented in Harmony is more convenient for
>> > developers (you don't need to get undecoded part from buffer and put
>> > it to the next decoding operation).
>> >
>> >> we finally decided not to follow RI's behaviour.
>> >>
>> >> IMO, current Harmony implementation complies with spec strictly,
>> acts in
>> >> logical way and also doesn't affect end-users.
>> >> So I'd rather consider it as compatibility bug and close it as
>> wontfix.
>> >
>> > Corresponding to my previous comment, I can't agree that Harmony
>> > strictly comply with the spec, it's just our understanding of the
>> > spec. That's why I'd like to document this behaviour.
>> >
>> >
>> > Thanks.
>> > Vladimir.
>> >
>> >> What's your opnion?
>> >>
>> >> Thanks.
>> >>
>> >>
>> >> On 5/15/06, Vladimir Strigun <vs...@gmail.com> wrote:
>> >> >
>> >> > On 5/5/06, Mikhail Loenko <ml...@gmail.com> wrote:
>> >> > > 2006/5/5, Vladimir Strigun <vs...@gmail.com>:
>> >> > > > On 5/5/06, Mikhail Loenko <ml...@gmail.com> wrote:
>> >> > > > > Vladimir, Andrew
>> >> > > > >
>> >> > > > > 2006/4/26, Andrew Zhang <zh...@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
>> >> >
>> >> >
>> >>
>> >>
>> >> --
>> >> 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
>> >
>> >
>>
>>
>> --
>> Paulex Yang
>> 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
>
>
--
Paulex Yang
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
Re: [classlib] [jira] Commented: (HARMONY-410) method decode(ByteBuffer, CharBuffer, boolean) should set correct position in ByteBuffer
Posted by Mikhail Loenko <ml...@gmail.com>.
Hi Paulex
I've changed JIRA category to "non-bug differences from RI" just before
I closed the bug
Thanks,
Mikhail
2006/5/23, Paulex Yang <pa...@gmail.com>:
> Currently Mikhail marked this issue as "won't fix" with comments of "
> non-bug difference from RI". I remember there is a similar category in
> JIRA(I just cannot recall the exact name, but it should be obvious), is
> there any chance in JIRA system to change this issue's category to that
> one? I think it will be easier to search later. If not, how about raise
> another one in that "non-bug difference from RI" category and add a link
> to 410?
>
> Vladimir Strigun wrote:
> > Hi Andrew,
> >
> > Thanks for your answer, please see my comments inside.
> >
> > On 5/22/06, Andrew Zhang <zh...@gmail.com> wrote:
> >> Hi, Mikhail and Vladimir,
> >>
> >> I'd rather consider it as compatibility bug and close it as wontfix.
> >
> > Yes, we can close the issue as wontfix with compatibility comments,
> > but I think we should put some description to Wiki. Or possible you
> > can suggest more appropriate place for this.
> >
> >> "Did I get it right that both solutions do not contradict to the spec
> >> and
> >> that RI acts as the second one?"
> >>
> >> Partly right. Vladimir, maybe as you know, deep studying on decode
> >> will show
> >> many RI's unreasonable behaviours.
> >>
> >> Since RI's behaviour is not logical and the spec description is very
> >> vague
> >> in some situations (e.g. decode state defination, in/out buffer poistion
> >> defination),
> >
> > I can't say that RI's behaviour is not logical, but I can agree that
> > decoding process implemented in Harmony is more convenient for
> > developers (you don't need to get undecoded part from buffer and put
> > it to the next decoding operation).
> >
> >> we finally decided not to follow RI's behaviour.
> >>
> >> IMO, current Harmony implementation complies with spec strictly, acts in
> >> logical way and also doesn't affect end-users.
> >> So I'd rather consider it as compatibility bug and close it as wontfix.
> >
> > Corresponding to my previous comment, I can't agree that Harmony
> > strictly comply with the spec, it's just our understanding of the
> > spec. That's why I'd like to document this behaviour.
> >
> >
> > Thanks.
> > Vladimir.
> >
> >> What's your opnion?
> >>
> >> Thanks.
> >>
> >>
> >> On 5/15/06, Vladimir Strigun <vs...@gmail.com> wrote:
> >> >
> >> > On 5/5/06, Mikhail Loenko <ml...@gmail.com> wrote:
> >> > > 2006/5/5, Vladimir Strigun <vs...@gmail.com>:
> >> > > > On 5/5/06, Mikhail Loenko <ml...@gmail.com> wrote:
> >> > > > > Vladimir, Andrew
> >> > > > >
> >> > > > > 2006/4/26, Andrew Zhang <zh...@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
> >> >
> >> >
> >>
> >>
> >> --
> >> 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
> >
> >
>
>
> --
> Paulex Yang
> 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
Re: [classlib] [jira] Commented: (HARMONY-410) method decode(ByteBuffer,
CharBuffer, boolean) should set correct position in ByteBuffer
Posted by Paulex Yang <pa...@gmail.com>.
Currently Mikhail marked this issue as "won't fix" with comments of "
non-bug difference from RI". I remember there is a similar category in
JIRA(I just cannot recall the exact name, but it should be obvious), is
there any chance in JIRA system to change this issue's category to that
one? I think it will be easier to search later. If not, how about raise
another one in that "non-bug difference from RI" category and add a link
to 410?
Vladimir Strigun wrote:
> Hi Andrew,
>
> Thanks for your answer, please see my comments inside.
>
> On 5/22/06, Andrew Zhang <zh...@gmail.com> wrote:
>> Hi, Mikhail and Vladimir,
>>
>> I'd rather consider it as compatibility bug and close it as wontfix.
>
> Yes, we can close the issue as wontfix with compatibility comments,
> but I think we should put some description to Wiki. Or possible you
> can suggest more appropriate place for this.
>
>> "Did I get it right that both solutions do not contradict to the spec
>> and
>> that RI acts as the second one?"
>>
>> Partly right. Vladimir, maybe as you know, deep studying on decode
>> will show
>> many RI's unreasonable behaviours.
>>
>> Since RI's behaviour is not logical and the spec description is very
>> vague
>> in some situations (e.g. decode state defination, in/out buffer poistion
>> defination),
>
> I can't say that RI's behaviour is not logical, but I can agree that
> decoding process implemented in Harmony is more convenient for
> developers (you don't need to get undecoded part from buffer and put
> it to the next decoding operation).
>
>> we finally decided not to follow RI's behaviour.
>>
>> IMO, current Harmony implementation complies with spec strictly, acts in
>> logical way and also doesn't affect end-users.
>> So I'd rather consider it as compatibility bug and close it as wontfix.
>
> Corresponding to my previous comment, I can't agree that Harmony
> strictly comply with the spec, it's just our understanding of the
> spec. That's why I'd like to document this behaviour.
>
>
> Thanks.
> Vladimir.
>
>> What's your opnion?
>>
>> Thanks.
>>
>>
>> On 5/15/06, Vladimir Strigun <vs...@gmail.com> wrote:
>> >
>> > On 5/5/06, Mikhail Loenko <ml...@gmail.com> wrote:
>> > > 2006/5/5, Vladimir Strigun <vs...@gmail.com>:
>> > > > On 5/5/06, Mikhail Loenko <ml...@gmail.com> wrote:
>> > > > > Vladimir, Andrew
>> > > > >
>> > > > > 2006/4/26, Andrew Zhang <zh...@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
>> >
>> >
>>
>>
>> --
>> 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
>
>
--
Paulex Yang
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
Re: [classlib] [jira] Commented: (HARMONY-410) method decode(ByteBuffer, CharBuffer, boolean) should set correct position in ByteBuffer
Posted by Vladimir Strigun <vs...@gmail.com>.
Hi Andrew,
Thanks for your answer, please see my comments inside.
On 5/22/06, Andrew Zhang <zh...@gmail.com> wrote:
> Hi, Mikhail and Vladimir,
>
> I'd rather consider it as compatibility bug and close it as wontfix.
Yes, we can close the issue as wontfix with compatibility comments,
but I think we should put some description to Wiki. Or possible you
can suggest more appropriate place for this.
> "Did I get it right that both solutions do not contradict to the spec and
> that RI acts as the second one?"
>
> Partly right. Vladimir, maybe as you know, deep studying on decode will show
> many RI's unreasonable behaviours.
>
> Since RI's behaviour is not logical and the spec description is very vague
> in some situations (e.g. decode state defination, in/out buffer poistion
> defination),
I can't say that RI's behaviour is not logical, but I can agree that
decoding process implemented in Harmony is more convenient for
developers (you don't need to get undecoded part from buffer and put
it to the next decoding operation).
> we finally decided not to follow RI's behaviour.
>
> IMO, current Harmony implementation complies with spec strictly, acts in
> logical way and also doesn't affect end-users.
> So I'd rather consider it as compatibility bug and close it as wontfix.
Corresponding to my previous comment, I can't agree that Harmony
strictly comply with the spec, it's just our understanding of the
spec. That's why I'd like to document this behaviour.
Thanks.
Vladimir.
> What's your opnion?
>
> Thanks.
>
>
> On 5/15/06, Vladimir Strigun <vs...@gmail.com> wrote:
> >
> > On 5/5/06, Mikhail Loenko <ml...@gmail.com> wrote:
> > > 2006/5/5, Vladimir Strigun <vs...@gmail.com>:
> > > > On 5/5/06, Mikhail Loenko <ml...@gmail.com> wrote:
> > > > > Vladimir, Andrew
> > > > >
> > > > > 2006/4/26, Andrew Zhang <zh...@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
> >
> >
>
>
> --
> 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
Re: [classlib] [jira] Commented: (HARMONY-410) method decode(ByteBuffer, CharBuffer, boolean) should set correct position in ByteBuffer
Posted by Andrew Zhang <zh...@gmail.com>.
Hi, Mikhail and Vladimir,
I'd rather consider it as compatibility bug and close it as wontfix.
"Did I get it right that both solutions do not contradict to the spec and
that RI acts as the second one?"
Partly right. Vladimir, maybe as you know, deep studying on decode will show
many RI's unreasonable behaviours.
Since RI's behaviour is not logical and the spec description is very vague
in some situations (e.g. decode state defination, in/out buffer poistion
defination),
we finally decided not to follow RI's behaviour.
IMO, current Harmony implementation complies with spec strictly, acts in
logical way and also doesn't affect end-users.
So I'd rather consider it as compatibility bug and close it as wontfix.
What's your opnion?
Thanks.
On 5/15/06, Vladimir Strigun <vs...@gmail.com> wrote:
>
> On 5/5/06, Mikhail Loenko <ml...@gmail.com> wrote:
> > 2006/5/5, Vladimir Strigun <vs...@gmail.com>:
> > > On 5/5/06, Mikhail Loenko <ml...@gmail.com> wrote:
> > > > Vladimir, Andrew
> > > >
> > > > 2006/4/26, Andrew Zhang <zh...@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
>
>
--
Andrew Zhang
China Software Development Lab, IBM
Re: [classlib] [jira] Commented: (HARMONY-410) method decode(ByteBuffer, CharBuffer, boolean) should set correct position in ByteBuffer
Posted by Vladimir Strigun <vs...@gmail.com>.
On 5/5/06, Mikhail Loenko <ml...@gmail.com> wrote:
> 2006/5/5, Vladimir Strigun <vs...@gmail.com>:
> > On 5/5/06, Mikhail Loenko <ml...@gmail.com> wrote:
> > > Vladimir, Andrew
> > >
> > > 2006/4/26, Andrew Zhang <zh...@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
Re: [classlib] [jira] Commented: (HARMONY-410) method decode(ByteBuffer, CharBuffer, boolean) should set correct position in ByteBuffer
Posted by Mikhail Loenko <ml...@gmail.com>.
2006/5/5, Vladimir Strigun <vs...@gmail.com>:
> On 5/5/06, Mikhail Loenko <ml...@gmail.com> wrote:
> > Vladimir, Andrew
> >
> > 2006/4/26, Andrew Zhang <zh...@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.
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
Re: [classlib] [jira] Commented: (HARMONY-410) method decode(ByteBuffer, CharBuffer, boolean) should set correct position in ByteBuffer
Posted by Vladimir Strigun <vs...@gmail.com>.
On 5/5/06, Mikhail Loenko <ml...@gmail.com> wrote:
> Vladimir, Andrew
>
> 2006/4/26, Andrew Zhang <zh...@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?
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