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 oliver.deakin@googlemail.com
 designates 66.249.92.169 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=googlemail.com; s=beta;
        h=received:message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding;
        b=g6U5sQexFIaVBinu7mJb+3tX76i57n0rC1Iezdfo6D1a6siAH+WKHeLoVgqik9Rc/WCFt4ZIYTp9hmiyue/OpjsES+n/JaKit7+NkkzuG/JMCdgM+RTsz54L7sRzz9cR68BjAX9xyQNQLz4v1PFNHF5e9LtmFr03KSAz4u5iswQ=
Message-ID: <4700D95B.6020002@googlemail.com>
Date: Mon, 01 Oct 2007 12:26:19 +0100
From: Oliver Deakin <oliver.deakin@googlemail.com>
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: dev@harmony.apache.org
Subject: Re: [classlib][icu] Bringing ICU level up to 3.8
References: <4700CBA0.1090304@googlemail.com>
 <e0f125db0710010352r251b0f1dt2080e8d41b849bcc@mail.gmail.com>
In-Reply-To: <e0f125db0710010352r251b0f1dt2080e8d41b849bcc@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Thanks Pavel, I didn't realise icu4c was also being used by DRLVM.

IMHO it would be good for classlib to move to pure icu4j for the reasons 
I've stated, plus it would mean that we could entirely remove the native 
code from the text module and also the BidiWrapper class, which I see as 
a bonus.

There are still a few bugs to be ironed out in icu4j 3.8 before we start 
using it (unless we are willing to put up with almost all the Bidi tests 
failing, which I don't think would be acceptable) so the transition to 
3.8 would not happen for a little while yet anyway. When the time came, 
I would think it would make sense to move these libraries to DRLVM as 
they would no longer be dependencies of classlib. Perhaps at that point 
it would also be worth stepping the icu4c libraries up to 3.8 so 
classlib and drlvm are at the same level?

Regards,
Oliver

Pavel Pervov wrote:
> Oliver,
>
> Please, note, that DRLVM uses prebuilt ICU4C from classlib for some internal
> tasks.
> Should we move ICU4C from classlib to DRLVM in repository?
>
> WBR,
>     Pavel.
> On 10/1/07, Oliver Deakin <oliver.deakin@googlemail.com> wrote:
>
>   
>> Hi all,
>>
>> I have been looking recently at what it would take for us to step up to
>> icu4j 3.8 and thought I would give everyone a heads up on what I have
>> discovered.
>>
>> The first thing is that icu4jni is no longer supported from this release
>> onwards. The icu4jni api have been incorporated into icu4j and are
>> implemented in pure Java now.
>> Secondly, the Bidi class has also been implemented fully in icu4j now,
>> so it is possible for us to also drop icu4c as a dependency and use pure
>> icu4j for this functionality.
>>
>> The major advantage I see of moving to pure icu4j 3.8 is that we no
>> longer need to maintain prebuilt binaries of the icu4c and icu4jni
>> libraries across all platforms in our repository. This simplifies the
>> process of upgrading to new versions of icu and also allows us to move
>> to new platforms with greater ease.
>>
>> I am currently testing a patch to switch over to icu 3.8 and completely
>> remove the need for icu4c/jni. I have discovered a couple of bugs in the
>> new Bidi functionality [1] which I have raised on the icu dev list and
>> are in the process of being fixed. I hope that once they are all
>> resolved we will be able to pick up a patched icu4j 3.8 jar for our use.
>>
>> Im interested to hear if anyone has any comments/objections to this?
>>
>> Regards,
>> Oliver
>>
>> [1]
>> http://bugs.icu-project.org/trac/ticket/5952
>> http://bugs.icu-project.org/trac/ticket/5961
>>
>> --
>> Oliver Deakin
>> Unless stated otherwise above:
>> IBM United Kingdom Limited - Registered in England and Wales with number
>> 741598.
>> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
>>
>>
>>     
>
>
>   

-- 
Oliver Deakin
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU