Mailing-List: contact jena-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: jena-dev@incubator.apache.org
Date: Mon, 2 Jan 2012 20:26:30 +0000 (UTC)
From: "Damian Steer (Issue Comment Edited) (JIRA)" <jira@apache.org>
To: jena-dev@incubator.apache.org
Message-ID: 
 <1589346998.58508.1325535990986.JavaMail.tomcat@hel.zones.apache.org>
In-Reply-To: 
 <1206237206.62803.1323627639942.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Issue Comment Edited] (JENA-177) If possible remove
 dependency to ICU4J by using Java built-in functionality
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


    [ https://issues.apache.org/jira/browse/JENA-177?page=3Dcom.atlassian.j=
ira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=3D131785=
31#comment-13178531 ]=20

Damian Steer edited comment on JENA-177 at 1/2/12 8:25 PM:
-----------------------------------------------------------

Thorsten: yep, it seems to be just plain wrong in this case. The USE...RULE=
S bit is a post-check to ensure the encoded name is a well behaved dns name=
. It seems that IDN is doing this check too early, before it's finished the=
 encoding (the answers without that check are correct) which is bizarre.

I've written a little wrapper that performs the check itself. 8 failures ->=
 2 failures!

Andy: ah, that is a good clue for the other failures. If you try decoding:

xn--a-bpad.example.org
xn--andr--ep.example.org

IDN and ICU4J 4.8.1.1 don't throw an exception but return this value (i.e. =
no decoding occurs). ICU4J 3.4.4 however does throw an error.

Tempted to simply disable those tests, although they are, ominously, genera=
ted from an xml file somehow.
               =20
      was (Author: shellac):
    Thorsten: yep, it seems to be just plain wrong in this case. The USE...=
RULES bit is a post-check to ensure the encoded name is a well behaved dns =
name. It seems that IDN is doing this check too early, before it's finished=
 the encoding (the answers without that check are correct) which is bizarre=
.

I've written a little wrapper that performs the check itself. 8 failures ->=
 2 failures!

Andy: ah, that is a good clue for the other failures. If you try decoding:

xn--a-bpad.example.org
xn--andr--ep.example.org

IDN and ICU4J 4.8.1.1 don't throw an exception but return this value (i.e. =
no decoding occurs). ICU4J 3.4.4 however does throw an error.

Tempted to simply disable those tests, although they are, ominously, genera=
ted from and xml file somehow.
                 =20
> If possible remove dependency to ICU4J by using Java built-in functionali=
ty
> -------------------------------------------------------------------------=
--
>
>                 Key: JENA-177
>                 URL: https://issues.apache.org/jira/browse/JENA-177
>             Project: Jena
>          Issue Type: Wish
>          Components: IRI, Jena
>            Reporter: Thorsten M=C3=B6ller
>            Priority: Minor
>         Attachments: IRI-icu4j.patch, IRI.patch, jena-icu4j.patch, jena2.=
patch
>
>   Original Estimate: 0h
>  Remaining Estimate: 0h
>
> Jena-core and IRI currently depend on ICU4J for implementing Unicode supp=
ort. Since ICU4J is rather heavyweight of which a rather small fraction is =
used, we should check if there is a way of implementing the functionality i=
n an alternative way, either by (i) using built-in (standard) Java classes,=
 (ii) other libraries that are already dependencies, or (iii) in a complete=
ly alternative way. This is also supported by the fact that since relevant =
parts have been initially implemented, Unicode support has been considerabl=
y extended in Java, see http://java.sun.com/developer/technicalArticles/jav=
ase/i18n_enhance/.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrato=
rs: https://issues.apache.org/jira/secure/ContactAdministrators!default.jsp=
a
For more information on JIRA, see: http://www.atlassian.com/software/jira