From harmony-dev-return-6268-apmail-incubator-harmony-dev-archive=incubator.apache.org@incubator.apache.org Thu Apr 06 16:41:25 2006 Return-Path: Delivered-To: apmail-incubator-harmony-dev-archive@www.apache.org Received: (qmail 24857 invoked from network); 6 Apr 2006 16:41:17 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 6 Apr 2006 16:41:17 -0000 Received: (qmail 60546 invoked by uid 500); 6 Apr 2006 16:41:08 -0000 Delivered-To: apmail-incubator-harmony-dev-archive@incubator.apache.org Received: (qmail 60340 invoked by uid 500); 6 Apr 2006 16:41:08 -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 60329 invoked by uid 99); 6 Apr 2006 16:41:08 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 06 Apr 2006 09:41:08 -0700 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests=HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (asf.osuosl.org: domain of dmitry.m.kononov@gmail.com designates 64.233.182.190 as permitted sender) Received: from [64.233.182.190] (HELO nproxy.gmail.com) (64.233.182.190) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 06 Apr 2006 09:41:07 -0700 Received: by nproxy.gmail.com with SMTP id h2so125540nfe for ; Thu, 06 Apr 2006 09:40:45 -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:references; b=J9QDtybeJyKbd31vgQFfcwDx/Exp9LJfx50wWnoCdAXo9Lu1q7ZNLBdyyBNID5RAW4IpUAIdypMh/PpxOFPsfSSUntLaLW7ENtszq+fSifJ2EkpbPiQJxSQ97kG7XFKU+4J9GDkI5Os3izAM1RA/H0Rhb7s7hzhpXYZrdG6ovhg= Received: by 10.49.69.20 with SMTP id w20mr725473nfk; Thu, 06 Apr 2006 09:40:45 -0700 (PDT) Received: by 10.49.9.10 with HTTP; Thu, 6 Apr 2006 09:40:45 -0700 (PDT) Message-ID: <98e7db8d0604060940s5486f8adx3e110663b8d1bbc7@mail.gmail.com> Date: Thu, 6 Apr 2006 20:40:45 +0400 From: "Dmitry M. Kononov" To: harmony-dev@incubator.apache.org Subject: Re: [jira] Updated: (HARMONY-308) java.nio.charset.Charset.encode(CharBuffer) returns bytes in a different order in Harmony and RI for the UTF-16 charset In-Reply-To: <443530FF.1070708@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_19693_30063747.1144341645756" References: <1260689736.1144232924322.JavaMail.jira@ajax> <44349AF9.7090509@gmail.com> <98e7db8d0604060545o61fc5fc2t5cbe69465e9eb012@mail.gmail.com> <443530FF.1070708@gmail.com> X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N ------=_Part_19693_30063747.1144341645756 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi Richard, On 4/6/06, Richard Liang wrote: > Dmitry M. Kononov wrote: > > As you exactly noticed the cause of this issue that Harmony uses the > > little-endian byte order, if an encoded UTF-16 sequence has no > byte-order > > mark. However, the spec reads such a case explicitly as follows: > > > > "When decoding, the UTF-16 charset interprets a byte-order mark to > indicate > > the byte order of the stream but defaults to big-endian if there is no > > byte-order mark; when encoding, it uses big-endian byte order and write= s > a > > big-endian byte-order mark." > > > > > Hello Dmitry, > > Yes, although Harmony and RI use different byte order, as both Harmony > and RI use byte-order mark (U+FEFF), I think both Harmony and RI are > compliant with the specification. So could we regard Harmony-308 as "not > a bug"? I think Harmony's behavior in this case is inconsistent with the java spec, since the spec defines the expected behavior explicitly: "when encoding, it uses big-endian byte order and writes a big-endian byte-order mark." But Harmony's encode() returns bytes in the little-endian order. It seems I do not understand why do you think Harmony follows the spec correctly in this case? :) I am really sorry for my misunderstanding. >From a test case attached to the HARMONY-308: 1) We have a char array that has no byte-order mark: private static final char chars[] =3D { 0x041b,0x0435,0x0442,0x043e,0x0020,0x0432,0x0020,0x0420,0x043e,0x0441, 0x0441,0x0438,0x0438}; 2) We have a byte array that encode() should return as we expect. private static final byte bytes[] =3D { (byte)254,(byte)255,(byte) 4,(byte) 27,(byte) 4,(byte) 53,(byte) 4, (byte) 66,(byte) 4,(byte) 62,(byte) 0,(byte) 32,(byte) 4,(byte) 50, (byte) 0,(byte) 32,(byte) 4,(byte) 32,(byte) 4,(byte) 62,(byte) 4, (byte) 65,(byte) 4,(byte) 65,(byte) 4,(byte) 56,(byte) 4,(byte) 56}; Please note, according to the spec we expect bytes returned by encode() in big-endian byte order. So, we expect the FEFF byte-order mark. Do you agree this expectation is correct and consistent with the spec? Thanks. -- Dmitry M. Kononov Intel Managed Runtime Division ------=_Part_19693_30063747.1144341645756--