Community
Participate
Working Groups
To complete the plan item to deliver ICU4J support in the Eclipse (see bug 127876) code must be migrated to use the com.ibm.icu.* classes in place of the default java implementation. This component is affected. I will attach patches with the changes required (only import changes at this point). This needs to be done for RC1.
Created attachment 38119 [details] archive of patches for affected ui projects There is a patch file for each affected project, named accordingly.
Created attachment 38198 [details] archive of revised ui patches I had to revise some of the workbench and ide changes to work with the new Comparator and to resolve some of the unchanged imports that should have been changed. Boris double-checked these changes with me.
fixed for builds > 20060410
This patch introduces a dependency on ICU4J from JFace (org.eclipse.jface). I thought we were going to keep JFace independent of ICU4J in order to enable standalone SWT+JFace apps without requiring them to use ICU4J. I talked to Karice about this. The only dependencies appear to be for MessageFormat. We originally kept JFace using MessageFormat instead of NLS to allow standalone SWT+JFace apps to work without the Eclipse runtime. But now that the runtime has been refactored, it may make more sense to use NLS rather than MessageFormat. Jeff, NLS is in the OSGi supplement bundle isn't it?
For more background on standalone SWT+JFace scenarios, see bug 49497 comment 55.
In the JFace patch (this excludes JFace text and databindings plugins) we only are using MessageFormat.format(String, Object[]). Keeping this in mind, there are several options we can persue at this point: 1. Remove the ICU references and revert back to using java.text.MessageFormat. Doug tells me that if we are just passing an array of strings to MessageFormat.format(String, Object[]) then using ICU vs Java makes no difference. This would not require any new dependencies in the standalone SWT/JFace configuration. 2. Change MessageFormat.format calls to use NLS.bind. This would add a dependency on one of the osgi plugins when using JFace standalone with SWT. 3. Leave the code as it is now and communicate that if you are using JFace/SWT standalone that there is now a dependency on the ICU plugin - users could choose the ICU replacement plugin which is 100K in size or use the full ICU plugin. Nick, which would you prefer?
door #1 seems like more fun. Door #2 is potentially feasible as we *plan to* include the NLS code in the supplement bundle *but* we currently are not planning to have the supplement be part of 3.2. Door #3 is disappointing especially if the regular Java behaviour for our use is fine.
Nick, what would you like to do, based on this info? I think I know the answer.
I'll pick door #1 then. Cue the game show theme song...
Reverted use of ICU4J in org.eclipse.jface project only (text and databinding references were not changed back). released for build > 20060418
Verified in N20060425-0010
