harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tony Wu" <wuyue...@gmail.com>
Subject Re: [classlib][icu] Bringing ICU level up to 3.8
Date Tue, 09 Oct 2007 02:39:25 GMT
On 10/8/07, Oliver Deakin <oliver.deakin@googlemail.com> wrote:
> 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.
ok. we may need change the code in both DRLVM and j9 since the lib of
icu4c is directly refered by them.

> Are there any particular
> benchmarks you had in mind for this?
>
ya, there is a micro benchmark on HARMONY-3709

> > 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.
>
I've successfully changed the data in luni but got some problem in
text, since the organization in resource bundle for locale is
different from each other. And unfortunately there is no doc in
current harmony impl, I need some time to try and guess them.

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


-- 
Tony Wu
China Software Development Lab, IBM

Mime
View raw message