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 09:00:57 GMT
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...

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

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

> 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

View raw message