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
