You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jena.apache.org by "Damian Steer (Issue Comment Edited) (JIRA)" <ji...@apache.org> on 2012/01/02 21:26:30 UTC
[jira] [Issue Comment Edited] (JENA-177) If possible remove
dependency to ICU4J by using Java built-in functionality
[ https://issues.apache.org/jira/browse/JENA-177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13178531#comment-13178531 ]
Damian Steer edited comment on JENA-177 at 1/2/12 8:24 PM:
-----------------------------------------------------------
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, generated from and xml file somehow.
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 and 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, generated from and xml file somehow.
> If possible remove dependency to ICU4J by using Java built-in functionality
> ---------------------------------------------------------------------------
>
> Key: JENA-177
> URL: https://issues.apache.org/jira/browse/JENA-177
> Project: Jena
> Issue Type: Wish
> Components: IRI, Jena
> Reporter: Thorsten Möller
> 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 support. 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 in an alternative way, either by (i) using built-in (standard) Java classes, (ii) other libraries that are already dependencies, or (iii) in a completely alternative way. This is also supported by the fact that since relevant parts have been initially implemented, Unicode support has been considerably extended in Java, see http://java.sun.com/developer/technicalArticles/javase/i18n_enhance/.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira