Return-Path: Delivered-To: apmail-incubator-harmony-dev-archive@www.apache.org Received: (qmail 6383 invoked from network); 23 May 2006 05:10:23 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 23 May 2006 05:10:23 -0000 Received: (qmail 44143 invoked by uid 500); 23 May 2006 05:10:20 -0000 Delivered-To: apmail-incubator-harmony-dev-archive@incubator.apache.org Received: (qmail 43974 invoked by uid 500); 23 May 2006 05:10:19 -0000 Mailing-List: contact harmony-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: harmony-dev@incubator.apache.org Delivered-To: mailing list harmony-dev@incubator.apache.org Received: (qmail 43963 invoked by uid 99); 23 May 2006 05:10:19 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 22 May 2006 22:10:19 -0700 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (asf.osuosl.org: domain of mloenko@gmail.com designates 66.249.92.171 as permitted sender) Received: from [66.249.92.171] (HELO ug-out-1314.google.com) (66.249.92.171) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 22 May 2006 22:10:18 -0700 Received: by ug-out-1314.google.com with SMTP id q2so1436314uge for ; Mon, 22 May 2006 22:09:56 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=ZSGfAoy540/ZjuIMPxc7PEIifNxcE0xXYraBXZvk/tA/qWUJXajoPhEXeXkoDGcQOjM40urrJWbc8cCMIeYfhBeePHzDlorIUIa3n3YYKW477OzeXQ9Ny7+KCiTFW4R+8d6TpOLA/OKfnhM3boGjljrR5VL6zkECK6zQN8HkoI8= Received: by 10.66.166.7 with SMTP id o7mr4251342uge; Mon, 22 May 2006 22:09:56 -0700 (PDT) Received: by 10.67.25.13 with HTTP; Mon, 22 May 2006 22:09:56 -0700 (PDT) Message-ID: <906dd82e0605222209p370857ffida7d0616a41eb51c@mail.gmail.com> Date: Tue, 23 May 2006 12:09:56 +0700 From: "Mikhail Loenko" To: harmony-dev@incubator.apache.org Subject: Re: [classlib] [jira] Commented: (HARMONY-410) method decode(ByteBuffer, CharBuffer, boolean) should set correct position in ByteBuffer In-Reply-To: <447266ED.3090604@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <444F365D.2040804@gmail.com> <4d0b24970604260220y5568920ar284eca95ff87423b@mail.gmail.com> <906dd82e0605042135i3ae640cep4b166c8769f98b4e@mail.gmail.com> <906dd82e0605050048w24855bfeiba6dad5ef7566b02@mail.gmail.com> <4d0b24970605220217m4b6c0de4r69d152054392b8db@mail.gmail.com> <447266ED.3090604@gmail.com> X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N 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 : > 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 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 poisti= on > >> 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 wrote: > >> > > >> > On 5/5/06, Mikhail Loenko wrote: > >> > > 2006/5/5, Vladimir Strigun : > >> > > > On 5/5/06, Mikhail Loenko wrote: > >> > > > > Vladimir, Andrew > >> > > > > > >> > > > > 2006/4/26, Andrew Zhang : > >> > > > > > 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 compatibili= ty > >> > 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 possibl= y > >> > 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 =3D false if you have addition= al > >> > 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 opti= on > >> > 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.htm= l > >> > > > > 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.o= rg > >> > > 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.o= rg > >> > > >> > > >> > >> > >> -- > >> 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