Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 174991

Summary:	Contribute ICU4J 3.6.1 to Eclipse 3.3
Product:	[Eclipse Project] Platform	Reporter:	Yoshito Umaoka <yoshito_umaoka>
Component:	UI	Assignee:	Karice McIntyre <Karice_McIntyre>
Status:	RESOLVED FIXED	QA Contact:
Severity:	normal
Priority:	P3	CC:	alex.blewitt, bpasero, clin, Karice_McIntyre, Mike_Wilson, Tod_Creasey
Version:	3.3
Target Milestone:	3.3 M7
Hardware:	All
OS:	Windows XP
Whiteboard:
Bug Depends on:
Bug Blocks:	174248, 176341

Description Yoshito Umaoka

2007-02-21 12:00:42 EST

There were some bugs filed by eclipse users against ICU4J DateFormat performance problem. Some test cases indicate ICU4J 3.6 DateFormat instantiation is 80+ times slower than equivalent J2SE DateFormat. In ICU bug tracking system, following bug reports are related.

- Some methods in com.ibm.icu.text.DateFormat in ICU have bad performance. (http://bugs.icu-project.org/trac/ticket/5168)
- ICU4J Calendar factory methods are way slower than JDK (http://bugs.icu-project.org/trac/ticket/5187)
- ICU4J method SimpleDateFormat.format() appears to have memory leak (http://bugs.icu-project.org/trac/ticket/5281)
- ICU's DateFormat is slow compared the the JDK version (http://bugs.icu-project.org/trac/ticket/5402)

#5281 and #5402 were reported by an eclipse developer/consumer. We seriously look into the implementation issue after ICU4J 3.6 was released and resolved various performance problems. As the results, ICU4J DateFormat's performance (inistantiation/format/parse) is now equivalent to JDK. By sharing read-only locale data across DateFormat instances, memory usage is also largely improved. Below is the summary of changes -

1. Each instance of DateFormatSymbols initializes and owns locale data loaded from ICU bundle, although they are read-only. The symbol data for a single locale can be shared by multiple DateFormatSymbols instnace.
2. Constructing Calendar object takes good amount of time to determine a proper calendar type from given locale, although it always ends up "Gregorian".
3. When SimpleDateFormat is initialized, it always try to determine the default century start, which requires calendar calculation, although it might not be used at all.
4. DateFormat factory methods (DateFormat.getXXXInstance) access ICU data and create a pattern string. No cache is used here.

In addition to this performance fix, ICU development wants to provide fixes for multi-threading issues, which may also impact eclipse user in a certain use case scenario.

- ICU4J UResourceBundle thread lock (http://bugs.icu-project.org/trac/ticket/5536)
- Use ICU4J's DateFormat class in BIRT's Date/Time processing (eclipse: https://bugs.eclipse.org/bugs/show_bug.cgi?id=167618 / icu: http://bugs.icu-project.org/trac/ticket/5541)

Other than this, we want to refresh timezone data in ICU4J 3.6 to the latest Olson revision.

I'm merging these fixes/updates and planning to ship it as ICU4J 3.6.1. This will be a maintenance release of ICU4J 3.6, thus there are no public API changes. ICU team had dropped ICU4J 3.6 jar files to eclipse 3.3M4. We'd like to refresh the version to include these major fixes in eclipse 3.3 release.

Comment 1 Yoshito Umaoka

2007-02-21 13:52:42 EST

One correction

>- Use ICU4J's DateFormat class in BIRT's Date/Time processing (eclipse:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=167618 / icu:
http://bugs.icu-project.org/trac/ticket/5541)

This bug seemed to be fixed just before ICU4J 3.6 GA.  If it is the case, the icu4j 3.6 plug-in included in eclipse 3.3 M5 should not have this problem.  I'll check it again.

Comment 2 Karice McIntyre

2007-02-23 09:52:47 EST

Mike, PMC approval is required before the CQ can be submitted.

Comment 3 Mike Wilson

2007-02-23 10:55:08 EST

+1

Comment 4 Cheng-Yee Lin

2007-03-19 22:28:29 EDT

The BIRT team is still experiencing the problems described in bugs 176341 and 176265 with the 3.3 M5 build.  That blocks the testing of BIRT in the Japanese locale.

Can we ensure ICU 3.6.1 is incorporated into the 3.3 M6 build?

Thanks.

Comment 5 Karice McIntyre

2007-03-20 10:15:20 EDT

ICU4J 3.6.1 will not be in M6 due to: 
1) Eclipse foundation IP approval processing time.  The IPZilla bug is
https://dev.eclipse.org/ipzilla/show_bug.cgi?id=1367 
(note: you need to be a committer in order to view IPZilla bugs)
2) the platform is currently in stabilization mode for M6 - no new changes are going in until M6 is declared later this week.

In the meantime, Japanese testers can delete ICU4J 3.6 from their /plugins directory and use ICU4J 3.4.5.20061213 (which is present in the 3.2.2 builds) in its place.  Sorry, there isn't much else we can do.

Comment 6 Karice McIntyre

2007-04-26 12:58:43 EDT

ICU4J 3.6.1 released as of I-20070424-0930 build.  The source is missing but Kim is working on that - see Bug 183958