2007/11/19, Alexey Petrenko <[EMAIL PROTECTED]>: > > 2007/11/17, Tony Wu <[EMAIL PROTECTED]>: > > On 11/17/07, Alexey Petrenko <[EMAIL PROTECTED]> 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. > > > 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. > > yes. > > > > > > 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. > > It is not easy for both them and us. > > > > > > 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 :) > > To my knowledge, we have no alternative project except ICU :) > I do not know the alternative either. But I think that everyone here > would agree that we can not integrate the project to Harmony if it > breaks compatibility and degrades the performance... > > > > 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've thought about the reverting. Basically I agree to reverting this > > patch for the coming milestone. I will record what I have modified and > > revert it soon. > Thanks. > > > Still I have some concern and want to discuss with you here. We have > > to face some problem which can not be deracinated even if I recommit > > the patch at the beginning of next iteration. > Next iteration will not be right after the next milestone but after > all the issues are fixed, right? :) > > > One of them is about implementation detail which may contradict to > > ICU's vision as you mentioned on Harmony-5085. > Speaking of this particular issue we can suggest ICU to change the > super class of com.ibm.icu.text.DateFormat$Field from > java.text.Format.Field to java.text.DateFormat.Field. This will fit > our needs and, I believe, will not break anything in ICU... > > And we really need to think about lower level integration of ICU as > suggested by Tim.
As mentioned, I'm not sure a whole solution based on low level integration is feasible or not, but we can take it as a way for performance tweak in the places where it becomes significant concerns. Say, the DateFormat$Field case, maybe it's possible to access the low level data directly, if ICU team are not happy with the idea to change their class hierarchy. > Another is the performance degradations. I'm afraid that we will > > suffer from the delegation even if ICU has no performance issue > > itself. > Yes, this is possible... Need to decide case by case... > > > As I talked in another thread, the perfect solution is that ICU could > > contribute their implementation against java SE API to harmony > > directly. But I think we have a long way to go to achieve it. > Yes, this would be nice. > > > > Meanwhile I suggest setting up some infrastructure on performance. > > First, we can have a baseline and try to improve step by step based on > > it. Then we could notice the degradation immediately when it happens. > > Furthermore, we can get the detail whenever we want to analyze it. > > (Sorry if there is one existing and I did not notice.) > As far as I know we have one. Probably not fully automatic... Sergey, > Aleksey, could you please comment? > > Thanks in advance. > > SY, Alexey > -- Paulex Yang China Software Development Lab IBM
