harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paulex Yang <paulex.y...@gmail.com>
Subject Re: [classlib] [jira] Commented: (HARMONY-410) method decode(ByteBuffer, CharBuffer, boolean) should set correct position in ByteBuffer
Date Tue, 23 May 2006 05:27:36 GMT
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 <paulex.yang@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 <zhanghuangzhu@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 <vstrigun@gmail.com> wrote:
>> >> >
>> >> > 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
>> >> >
>> >> >
>> >>
>> >>
>> >> --
>> >> 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


Mime
View raw message