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

Reply via email to