Sorry for reply late, just recover from national holiday. About the performance issue, native code is faster but jni call is heavy. So, icu4j 3.4 is good at encoding/decoding several bytes whereas icu4jni3.4 is good at handling thousands bytes. Bidi is another story, I'll try to compare the native impl and java impl later in 3.8. Anyway, it is worth to do some work to remove the 10m dependency(icu4c).
BTW, We keep some resource bundle classes in luni, such as Locale and Currency, which used by luni and text module. These data are aslo included in icu, I suggest to remove this overlap, just keep one of them. A good news is that icu3.8 providers a data customization tool[1], I've tried it and reported a failure when customizing icu4j. [1]http://apps.icu-project.org/datacustom/ On 10/2/07, Oliver Deakin <[EMAIL PROTECTED]> wrote: > Hi Alexei, > > Yes, performance is an issue here. I would envisage that for > small/medium icu jobs we will see a performance increase due to calls > into icu C code via jni adding an overhead. For larger conversion jobs > we may find that icu4c/icu4jni provide better results. Clearly this is > something that needs to be weighed up against the pros of moving to > using a purely Java implementation. Are there any tests you might > suggest to make a performance comparison? > > I see Tony has spoken to the icu developers before about this issue [1]. > Do you have any input Tony? > > Regards, > Oliver > > [1] http://www.nabble.com/From-icu4jni-to-icu4j-t3543140.html > > Alexei Zakharov wrote: > > Hi Oliver and all, > > > > > >> 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. > >> > > > > I have no objections. Only like to be sure we won't get significant > > performance degradation by moving from native implementation to pure > > Java. > > > > Thanks, > > Alexei > > > > 2007/10/1, Oliver Deakin <[EMAIL PROTECTED]>: > > > >> 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 > > -- Tony Wu China Software Development Lab, IBM
