harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oliver Deakin <oliver.dea...@googlemail.com>
Subject Re: [classlib][icu] Bringing ICU level up to 3.8
Date Fri, 05 Oct 2007 14:31:48 GMT
Further on upgrading to ICU4J 3.8, when I run the text tests I see 
failures in BidiTest - namely: testCreateLineBidi; 
testCreateLineBidiInvalid; testGetRunLimit. For the Bidi scenarios in 
these tests ICU throws IllegalArgumentExceptions due to invalid 
parameters being passed through, whereas the RI ignores the fact that 
these parameters are illegal (one of the differences has been discussed 
previously in [1]). More precisely, the tests [2] and [3] throw 
exceptions on ICU 3.8 but complete successfully on the RI.

I have been in conversation with the Bidi developer and it seems that 
ICU is keeping in line with the spec while the RI is allowing illegal 
cases. The developer I have been talking to has asked if I feel these 
differences should be fixed in ICU, so I thought I would throw this 
question out to the Harmony community as it will be something that 
affects the behaviour of our Bidi class if we move to ICU4j 3.8. IMHO it 
is not a problem to follow the spec and differ from the RI, as ICU 
currently does, in these invalid cases. Does anyone object to this?

Regards,
Oliver


[1] https://issues.apache.org/jira/browse/HARMONY-649

[2] This test requests an illegal run limit value. Only values between 0 
(included) and run count (excluded) are valid. Since the run count in 
this case is 1, it is only valid to request the 0th run with 
getRunLimit. The RI ignores this invalid request while ICU throws 
IllegalArgumentException
public class Testa {
public static void main(String[] args) throws Throwable {
Bidi bidi = new Bidi("text", Bidi.DIRECTION_LEFT_TO_RIGHT);
bidi.getRunLimit(1);
}
}

[3] We try to create an invalid Line Bidi containing a \n character. The 
RI ignores the fact this Line Bidi is invalid while ICU throws 
IllegalArgumentException.
public class Testb {
public static void main(String[] args) throws Throwable {
Bidi bd = new Bidi("a\u05D0a\na\u05D0\"\u05D0a".toCharArray(), 0, new 
byte[] { 0, 0, 0, -3, -3, 2, 2, 0, 3 }, 0, 9, 
Bidi.DIRECTION_RIGHT_TO_LEFT);
Bidi line = bd.createLineBidi(2, 7);
}
}

Oliver Deakin wrote:
> Hi all,
>
> I have been looking recently at what it would take for us to step up 
> to icu4j 3.8 and thought I would give everyone a heads up on what I 
> have discovered.
>
> The first thing is that icu4jni is no longer supported from this 
> release onwards. The icu4jni api have been incorporated into icu4j and 
> are implemented in pure Java now.
> Secondly, the Bidi class has also been implemented fully in icu4j now, 
> so it is possible for us to also drop icu4c as a dependency and use 
> pure icu4j for this functionality.
>
> The major advantage I see of moving to pure icu4j 3.8 is that we no 
> longer need to maintain prebuilt binaries of the icu4c and icu4jni 
> libraries across all platforms in our repository. This simplifies the 
> process of upgrading to new versions of icu and also allows us to move 
> to new platforms with greater ease.
>
> I am currently testing a patch to switch over to icu 3.8 and 
> completely remove the need for icu4c/jni. I have discovered a couple 
> of bugs in the new Bidi functionality [1] which I have raised on the 
> icu dev list and are in the process of being fixed. I hope that once 
> they are all resolved we will be able to pick up a patched icu4j 3.8 
> jar for our use.
>
> Im interested to hear if anyone has any comments/objections to this?
>
> Regards,
> Oliver
>
> [1]
> http://bugs.icu-project.org/trac/ticket/5952
> http://bugs.icu-project.org/trac/ticket/5961
>

-- 
Oliver Deakin
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU


Mime
View raw message