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
