Mailing-List: contact commits-help@harmony.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@harmony.apache.org
Message-ID: <10357655.187011284493173000.JavaMail.jira@thor>
Date: Tue, 14 Sep 2010 15:39:32 -0400 (EDT)
From: "Robert Muir (JIRA)" <jira@apache.org>
To: commits@harmony.apache.org
Subject: [jira] Commented: (HARMONY-6640) UTF8 decoder doesn't properly
 decode supplementary characters
In-Reply-To: <3577427.138991283434073787.JavaMail.jira@thor>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/HARMONY-6640?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12909406#action_12909406 ] 

Robert Muir commented on HARMONY-6640:
--------------------------------------

Thanks Mark!

By the way: its looking much better since i switched from M14 to http://people.apache.org/~hindessm/milestones/5.0M15/


> UTF8 decoder doesn't properly decode supplementary characters
> -------------------------------------------------------------
>
>                 Key: HARMONY-6640
>                 URL: https://issues.apache.org/jira/browse/HARMONY-6640
>             Project: Harmony
>          Issue Type: Bug
>          Components: Classlib
>    Affects Versions: 5.0M14
>         Environment: Windows Vista
>            Reporter: Robert Muir
>            Assignee: Tim Ellison
>             Fix For: 5.0M16
>
>         Attachments: HARMONY-6640.patch, HARMONY-6640.patch, nio_char.jar
>
>
> When attempting to build Lucene, I discovered a problem with UTF8 decoding.
> (this actually prevents our tests from even compiling without a workaround)
> For any codepoint > 0xffff (4-byte utf-8 sequence), the decoder doesn't properly
> split the decoded codepoint into surrogate pairs.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.