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 38109 [details] patch for org.eclipse.core.runtime.compatibility Are we allowed to reference ICU4J in this bundle?
There are concerns about adding such a large dependency to our core bundles. Particularly for the eRCP project. the ICU4J bundle is a whapping 3.2 meg bundle. Is there any way this can be made optional?
See http://wiki.eclipse.org/index.php/ICU4J#Replacement_Plug-in
Tom I don't see any problem with applying this patch as the dependency is added to the runtime compatibility layer.
Fine with me. I am more concerned about the core bundles adding this dependency. I understand that there is a 100K icu.base bundle which can be used instead, this is good, but 100K can still be viewed as "expensive" in an embedded space.
The ICU change was also made to org.eclipse.core.expressions which is part of eRCP. See defect 135774.
Note that this patch only adds ICU usage in one place: org.eclipse.core.internal.plugins.Policy#bind. I think this dependency could be avoided entirely by replacing the method's implementation with NLS#bind instead. I.e., as long as the reference to java.text.MessageFormat goes away, then runtime will not need ICU4J.
I think in general for core we should only be inserting ICU4J dependency if it is actually needed. After reviewing the patches for core resources and jobs I found there was no value in releasing it (see bug 135785). I think the core.expressions dependency was also not needed.
Why is the core.expressions patch not needed? It uses ICUs NumberFormat.
If all the MessageFormat usages can go away by using the NLS class that's great. Is that the case for all the usages of MessageFormat that you came across in the core resources and core runtime plugins?
Using NLS sounds good to me. Since the Policy class is internal we don't have to worry about breaking anyone using complicated MessageFormat formats. (we don't use them) Ok to change? Any objections? The core.expressions bundle is not owned by the runtime team.
The reference to NumberFormat was only in LRUCache.toString, which is specified as for debugging purposes only. I replaced: buffer.append(NumberFormat.getInstance().format(fillingRatio())); with: buffer.append(fillingRatio()); Where fillingRatio() returns a double.
Ok, I talked this over with team members and we replaced the call to MessageFormat with one to NLS. (in the Policy.bind method) So bug is fixed. (no dependancy on ICU4J) Patch not applied.
I will hunt down core.expressions and point to this bug.
My thanks to all you for helping keep 100K out of the eRCP runtime. It's a significant amount and your responsiveness is greatly appreciated.
