2007/11/19, Yang Paulex <[EMAIL PROTECTED]>: > > > > 2007/11/19, Alexey Petrenko <[EMAIL PROTECTED]>: > > > > 2007/11/17, Tim Ellison <[EMAIL PROTECTED]>: > > > 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
