Description Dave Smith 2006-01-31 13:14:50 EST

GLA run-time needs to be changed to support ICU4J.  Here is a summary of ICU4J from the Architecture Group:

Quick Summary of ICU4J
----------------------
International Components for Unicode ("ICU") is open source 
ICU is recognized as the premier Unicode globalization library 
ICU4J supports and ships twice as many locales (over 230) as Java 
ICU4J uses Common Locale Data Repository ("CLDR") as a primary source so it is in full conformance for its globalization classes Common Locale Data Repository web site 
For sorting and searching Unicode data, ICU4J can be up to three times faster than Java and is Unicode-compliant 
There is a much faster turn-around on ICU4J bug-fixes and enhancements with releases every ~9 months 
With ICU4J, developers can choose to make use of premier globalization support for their own applications out-of-the-box 
There are additional functions provided by ICU4J not available in Java 5.0, including character normalization, enhanced date and currency formatting, and calendars used in different parts of the world 
ICU4J provides consistent globalization independent of the JRE level because it works with both Java 1.4 and Java 5.0 
More details on issues can be found in bugzilla 120002.
The top-level enhancement that is tracking this work for all of the projects is 123444.

Effort
------
Including support for ICU4J in Eclipse means replacing these classes with their compatible ICU4J equivalents: 
BreakIterator 
CollationKey 
Collator 
DateFormat 
DecimalFormat 
NumberFormat 
SimpleDateFormat 
StringCharacterIterator 
StringTokenizer 

Example of Required Changes
---------------------------
The following results from diff show the changes required to display the dates in Japanese format: 
import java.io.File;
-import java.text.DateFormat;
-import java.text.SimpleDateFormat;
+import com.ibm.icu.text.DateFormat;
+import com.ibm.icu.text.SimpleDateFormat;
 import java.util.Date;
 
 import org.eclipse.core.resources.IResource;


Code Snippet for returning ICU4J date format
--------------------------------------------
import com.ibm.icu.text.DateFormat;   // replaces import java.text.DateFormat
import com.ibm.icu.util.ULocale;      // replaces import java.util.Locale

    [...]

static final Date now = new Date();
static final String dateInLocale(ULocale ulocale) {
DateFormat fmt = DateFormat.getDateTimeInstance(DateFormat.LONG,
		DateFormat.LONG, ulocale);
return fmt.format(now);

- cannot break API, so must mark the old API deprecated and add a new API with the new ICU classes. It makes the code change nastier because now you have to qualify your classes. Only public API: extension points or public API then you have an issue. Otherwise you're okay.
- somehow later it calculates to another API and you have both old and new, you pretty much have to know if this is compatible with the old or not. Because the nature of it is that it's not so much that the types pass around change. Hidden risk is the Strings being serialized in models that will be parsed by older tool instances. 
- During test pass of iteration 1, please smoke test with German, Arabic, and Traditional Chinese (a European, BiDi, and DBCS language, respectively)