harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tony Wu" <wuyue...@gmail.com>
Subject Re: Problems with migration to new ICU, r592434 & r593469
Date Mon, 19 Nov 2007 09:52:31 GMT
On 11/19/07, Alexey Petrenko <alexey.a.petrenko@gmail.com> wrote:
> 2007/11/17, Tim Ellison <t.p.ellison@gmail.com>:
> > Alexey Petrenko wrote:
> > > To be clear all these issues are not from migrating from previous
> > > version of ICU to 3.8. But from removing Harmony code which duplicates
> > > ICU code.
> > Yes.  I'll admit that I misunderstood the original proposal.  Is it
> > possible to pick up the locale *data* from ICU rather than have our own
> > copy?  That would enable us to customize and update the locale
> > information using ICU tools.
> Yes, this could the best solution and we should investigate this possibility.
I've tried to leverage the data and leave their implementation alone
but I gived up when I found following two facts...

1.The format of data I got from ICU is totally different from our
implementation, that is we should rewrite almost all of our existing
code to handle the data.

2.Even worse that I can not find any document which defines the data
format. Imagine that I get an array of String and one of them is the
required data but I can not tell which one and no document explains
it. Or maybe just one character in a String is what I wanted but I can
not tell the position exactly.

I can do further study, but without deep knowledge on ICU's source
code / data structure, I'm not sure this proposal is feasible.

>
> May be Tony, as ICU guru, can tell something about this...
>
> SY, Alexey
>
> > > So we actually need to fix ICU not Harmony to get our performance and
> > > other behaviors back. And the problem here could be that we are not
> > > ICU and we do not have ICU committers, at least as far as I know. Thus
> > > we can not be sure that needed patches will be integrated ASAP even if
> > > we will create all needed patches our selves.
> > True.  The ICU project is set up to work in this area, if we can't reuse
> > their work successfully in Harmony I think would be a great shame for
> > both of us.
> >
> > > Moreover some patches can contradict with ICU vision. For example
> > > HARMONY-5085. The problem there that the Harmony method starts to
> > > return array of ICU classes instead of array of Harmony J2SE public
> > > API classes. Array scanning with ICU -> Harmony classes conversion
> > > will degrade performance. So the only way here to fix ICU to return
> > > public api classes instead of ICU classes. And I'm not sure that ICU
> > > project will be ready to integrate such a changes.
> >
> > I agree it is something we need to fix outside our mainline.
> >
> > > From the other hand I agree that we do not want to reinvent the wheel
> > > and keep and support all this internationalization stuff in Harmony if
> > > we can delegate it to another suitable project. But this project need
> > > to fit Harmony needs :)
> >
> > Yep, some of that text handling is complex, and if we can defer it to
> > ICU that would be best.
> >
> > > I suggest the following as a result...
> > > 1. Revert the patch which removes Harmony code which duplicates ICU.
> > > 2. File all the found issues to ICU database.
> > > 3. Create as much patches for ICU to fit Harmony needs as we can and
> > > provide them to ICU.
> > > 4. Wait until all these patches will be integrated and new ICU release come.
> > > 5. Remove ICU duplicating functionality again.
> > >
> > > Thoughts? Objections?
> >
> > I agree.  We should hear Tony's suggestion since he has been working in
> > this area.
> >
> > Regards,
> > Tim
> >
> >
>


-- 
Tony Wu
China Software Development Lab, IBM

Mime
View raw message