harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vladimir Strigun" <vstri...@gmail.com>
Subject Re: [classlib] [jira] Commented: (HARMONY-410) method decode(ByteBuffer, CharBuffer, boolean) should set correct position in ByteBuffer
Date Mon, 22 May 2006 10:42:40 GMT
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


Mime
View raw message