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