harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Yang Paulex" <paulex.y...@gmail.com>
Subject Re: Problems with migration to new ICU, r592434 & r593469
Date Mon, 19 Nov 2007 09:59:57 GMT
2007/11/19, Alexey Petrenko <alexey.a.petrenko@gmail.com>:
>
> 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'm not ICU guru, but had some experience with ICU. AFAIK, it's just not
easy to  use ICU data only, because the data is not  organized in some
simple way like resource bundle or so, instead it's in ICU specific binaries
forms, and is often accessed by undocumented contracts, take NumberFormat as
example, format pattern is read into a byte array like numberPatterns[n](no
matter how they are read from the binary files), and then the NumberFormat
uses numberPatterns[0], numberPatterns[1]... directly.

So IMO if we follow this way, at least we need
1. the ICU data
2. the DAO like data access logic from ICU (if there are some can be
separated)
3. Make Harmony "understand" the byte arrays like numberPatterns[i], which
I'm not sure if follows any spec or not.

I expect there are more trouble than our current way...

Though maybe it will be easier if there are some nice data process tool from
ICU, I guess there will be, because ICU team may need it to create the data
:).

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



-- 
Paulex Yang
China Software Development Lab
IBM

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message