Mailing-List: contact dev-help@harmony.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@harmony.apache.org
Received-SPF: pass (athena.apache.org: domain of alexey.a.petrenko@gmail.com
 designates 209.85.132.246 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=MUwD56M2RSjPv/rxXwoEkwPYuSyOWkuvZGZdLItKUSkBnkHveQrVtEHWBgH9Nx8ueQBo9c9d66Ndscfcu71L0DtQ2G/wgLfpslyRUcvfvQu43iq/MyUvkZnET6E5EeTt/K7vczycdGylvGUVRie+LtDdtizMBpelBcEO9vsETp4=
Message-ID: <c3755b3a0711190042v224c8d66k5bfec2b41fb1a6e9@mail.gmail.com>
Date: Mon, 19 Nov 2007 11:42:22 +0300
From: "Alexey Petrenko" <alexey.a.petrenko@gmail.com>
To: dev@harmony.apache.org
Subject: Re: Problems with migration to new ICU, r592434 & r593469
In-Reply-To: <473E15F0.8000104@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <253b20230711160740h71b90e5fv1b16614b56ebd2@mail.gmail.com>
	 <c3755b3a0711160829t221ccc77yc08b9d20b354b30f@mail.gmail.com>
	 <473E15F0.8000104@gmail.com>

2007/11/17, Tim Ellison <t.p.ellison@gmail.com>:
> Alexey Petrenko 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.
> Yes.  I'll admit that I misunderstood the original proposal.  Is it
> possible to pick up the locale *data* from ICU rather than have our own
> copy?  That would enable us to customize and update the locale
> information using ICU tools.
Yes, this could the best solution and we should investigate this possibility.

May be Tony, as ICU guru, can tell something about this...

SY, Alexey

> > 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.
> True.  The ICU project is set up to work in this area, if we can't reuse
> their work successfully in Harmony I think would be a great shame for
> both of us.
>
> > 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.
>
> I agree it is something we need to fix outside our mainline.
>
> > 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 :)
>
> Yep, some of that text handling is complex, and if we can defer it to
> ICU that would be best.
>
> > 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 agree.  We should hear Tony's suggestion since he has been working in
> this area.
>
> Regards,
> Tim
>
>