On 10/9/07, Oliver Deakin <[EMAIL PROTECTED]> wrote: > Tony Wu wrote: > > On 10/8/07, Oliver Deakin <[EMAIL PROTECTED]> 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. > > > > Yes - In [1] Pavel mentioned that DRLVM uses ICU4C for some tasks. I > think, as Pavel later suggests [2], we could move the ICU4C libraries to > the DRLVM repository when they are no longer required by classlib and > raise a JIRA for further discussion as to whether we want to remove this > dependency for DRLVM also or keep ICU4C and upgrade to 3.8. > agree.
> J9's dependency on the ICUInterface dll is purely a dllload() call so > that the library is initialised before use by the class library. I > believe this can be easily worked around with the current J9 VME by > simply having a dummy dll in jre/bin for it to load. > would you pls help to build a new J9 VME for this purpose :) > > > >> Are there any particular > >> benchmarks you had in mind for this? > >> > >> > > ya, there is a micro benchmark on HARMONY-3709 > > > > Thanks Tony - Ill take a look. > > > > >>> 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. > > > > Which data in luni have you moved to the ICU versions? There is some > conversation in another branch of this thread [3] about keeping Harmony > versions of charsets - is that relevant to what you're looking at? > Sorry I should have clarified that it's not about charsets. I delegated all the classes which depends on their internal resoure bundle data in luni to ICU's impl, so that we can remove all the classes in removed the package org/apache/harmony/luni/internal/locale later. That will get 2 mega bytes decrease form harmony source code. > Regards, > Oliver > > [1] > http://mail-archives.apache.org/mod_mbox/harmony-dev/200710.mbox/[EMAIL > PROTECTED] > [2] > http://mail-archives.apache.org/mod_mbox/harmony-dev/200710.mbox/[EMAIL > PROTECTED] > [3] > http://mail-archives.apache.org/mod_mbox/harmony-dev/200710.mbox/[EMAIL > PROTECTED] > > > > >> 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 <[EMAIL PROTECTED]> 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 <[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 > >>>> > >>>> > >>>> > >>>> > >>> > >>> > >> -- > >> 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
