... > 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" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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. > > >
