harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexey Petrenko" <alexey.a.petre...@gmail.com>
Subject Re: Problems with migration to new ICU, r592434 & r593469
Date Mon, 19 Nov 2007 10:58:04 GMT
2007/11/19, Tony Wu <wuyuehao@gmail.com>:
> 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 :)
It depends on how much efforts will be needed to compensate the
breaks... Some times it's easier to rewrite from scratch :)

> > > 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.
I have no doubts that there are undiscovered issues... :)

> > > 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.
It depends on what degradation will bring ICU. Probably it will be
better to fix our implementation.

Anyway all these talks are out of the scope and we should decide case by case.

SY, Alexey

Mime
View raw message