harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Yang Paulex" <paulex.y...@gmail.com>
Subject Re: Problems with migration to new ICU, r592434 & r593469
Date Mon, 19 Nov 2007 10:10:23 GMT
2007/11/19, Alexey Petrenko <alexey.a.petrenko@gmail.com>:
>
> 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.
> 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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message