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 Tue, 02 Oct 2007 09:51:45 GMT
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 <oliver.deakin@googlemail.com>:
>   
>> 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