harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mikhail Loenko" <mloe...@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:09:56 GMT
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


Mime
View raw message