From: Mark Davis (mark.davis@jtcsv.com)
Date: Sun Jul 13 2003 - 23:34:48 EDT
...
> Of course
> Java already includes some parts of ICU, but other things are in
> ICU4J are difficult now to integrate in Java, simply because IBM
> forgot to modularize ICU so that it can be integrated slowly.
> Accepting ICU4J as part of the core is a big decision choice,
> because ICU4J is quite large, and there are certainly developers
> for Java that would not accept to have 1 aditional MB of data and
> classes loaded in each JVM (particularly because the integration
> of ICU would affect a lot of core classes for the Java2 platform
> now also used for small devices).
...
> For example, it is impossible to integrate the ICU's Normalizer
> class in Java without also importing the UChar class and all its
> related services for UString, such as transliterators, and
...
You are very misinformed about ICU4J.
Mark
__________________________________
http://www.macchiato.com
► “Eppur si muove” ◄
----- Original Message -----
From: "Philippe Verdy" <verdy_p@wanadoo.fr>
To: <unicode@unicode.org>
Sent: Saturday, July 12, 2003 14:45
Subject: Re: ISO 639 "duplicate" codes (was: Re: Ligatures in Turkish
and Azeri, was: Accented ij ligatures)
> On Saturday, July 12, 2003 4:17 PM, Jony Rosenne
<rosennej@qsm.co.il> wrote:
>
> > What has "iw" to with Hebrew?
> >
> > I wasn't involved with the change, but I'm glad it was done. Java
and
> > other systems probably still use it because they never bothered to
> > check the latest version of 639. I know for certain that this was
the
> > case with one of the major computer vendors.
>
> In the case of Java, I don't think so. Sun has certainly maintained
the
> language code simply to avoid breaking existing localizations to
> Hebrew of Java-written software, waiting probably for a better way
to
> locate locales than the fixed "locales path resolution algorithm"
which
> is part of its core Classes since the beginning.
>
> As long as Java core classes will not use a locale resolver that
allows
> tuning the resolution algorithm used to load resource bundles, while
> also maintaining the compatibility with the existing softwares that
> assume that Hebrew resources are loaded with the "iw" language code,
> Sun will not change this code.
>
> In IBM ICU4J, there is such an extended resolver, but Sun takes a
> long time to approve such proposals, and have it first accepted,
> documented, balloted and voted in its JCP program. Of course
> Java already includes some parts of ICU, but other things are in
> ICU4J are difficult now to integrate in Java, simply because IBM
> forgot to modularize ICU so that it can be integrated slowly.
> Accepting ICU4J as part of the core is a big decision choice,
> because ICU4J is quite large, and there are certainly developers
> for Java that would not accept to have 1 aditional MB of data and
> classes loaded in each JVM (particularly because the integration
> of ICU would affect a lot of core classes for the Java2 platform
> now also used for small devices).
>
> For example, it is impossible to integrate the ICU's Normalizer
> class in Java without also importing the UChar class and all its
> related services for UString, such as transliterators, and
> advanced features such as the UCA tailoring rules run-time
> compiler. Some ICU open-sourcers, as well as its users seem
> to think now that the modularization of ICU is an important but
> complex project.
>
> --
> Philippe.
> Spams non tolérés: tout message non sollicité sera
> rapporté à vos fournisseurs de services Internet.
>
>
>
This archive was generated by hypermail 2.1.5 : Mon Jul 14 2003 - 00:21:57 EDT