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 10:06:03 GMT
On 11/19/07, Alexey Petrenko <alexey.a.petrenko@gmail.com> wrote:
> 2007/11/17, Tony Wu <wuyuehao@gmail.com>:
> > On 11/17/07, Alexey Petrenko <alexey.a.petrenko@gmail.com> 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...
Perhaps it breaks compatibility or degrades the performance currently,
I think some of them could be resolved or worked around by ourselves.
For example, the 5112 could be worked around by caching as suggestion
above. Frankly now I think people here is smart enough to handle these
problem :)

>
> > > 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? :)
Yes, but I should say that all the exposed issues. I believe there
must be something undiscovered.

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

see my pervious email.
>
> > 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...

I think we need a baseline here. In which condition that we should
accept the degradation or not. For example, current implementation is
not correct but has good performance, it is not fair to refuse the
correction.

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

we can try.

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

I'm expecting :)

>
> Thanks in advance.
>
> SY, Alexey
>


-- 
Tony Wu
China Software Development Lab, IBM

Mime
View raw message