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 01:35:41 GMT
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


Mime
View raw message