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 10:13:30 GMT
2007/11/19, Yang Paulex <paulex.yang@gmail.com>:
>
>
>
> 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.
>

I'm a little too pessimistic, just have a closer look, at least
numberPatters[n] is a String array here:). But the arguments below sustain,
Harmony still need to understand which pattern is which, and what it
means...

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
>



-- 
Paulex Yang
China Software Development Lab
IBM

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