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 Mon, 08 Oct 2007 09:28:09 GMT
Tony Wu wrote:
> Sorry for reply late, just recover from national holiday.
>   

No problem :)

> 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.  

Thanks Tony - it will be interesting to know how pure Java ICU performs 
within Harmony compared to the current setup. If it helps I can open a 
JIRA for moving to ICU4J 3.8 and attach a basic patch to eliminate the 
need for icu4jni/icu4c to get you started. Are there any particular 
benchmarks you had in mind for this?

> 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. 

Agreed - if we can use the ICU version of these resources then IMHO we 
should do it.

Regards,
Oliver

> 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 <oliver.deakin@googlemail.com> 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 <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
>>
>>
>>     
>
>
>   

-- 
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