Community
Participate
Working Groups
+++ This bug was initially created as a clone of Bug #290755 +++ Build ID: Eclipse 3.6m6 The com.ibm.icu.base plug-in does not export the com.ibm.icu.lang package, nor the com.ibm.icu.util package. This is a defect in my opinion, since it defeats the icu.base purpose of being a replacement for the full ICU in those areas where ICU provides only marginal replacements compared to the plain JRE. As a result of this defect, the icu.base plug-in can not be used as replacement in the RSE.UI plugin (bug 290755). We need RSE in our commercial product, but we would like to use icu.base since our product will never be translated and ICU shows a 2 second performance hit on cold start which we are not willing to take. I can understand that icu.base does not contain any functionality that goes beyond the plain JRE. But I would expect that icu.base does include those ICU classes which are just a replacement of the original JRE classes. In the simplest case, ICU could just extend the original JRE classes to provide surrogates: com.ibm.icu.lang.UCharacter <-> java.lang.Character com.ibm.icu.lang.UCharacter.UnicodeBlock <-> java.lang.Character.UnicodeBlock com.ibm.icu.util.Calendar <-> java.util.Calendar com.ibm.icu.util.GregorianCalendar <-> java.util.GregorianCalendar com.ibm.icu.util.SimpleTimeZone <-> java.util.SimpleTimeZone com.ibm.icu.util.TimeZone <-> java.util.TimeZone com.ibm.icu.util.ULocale <-> java.util.Locale com.ibm.icu.util.UResourceBundle <-> java.util.ResourceBundle Client code which does not need functionality beyond these plain ICU enhancements can then "import-package" and thus live with icu.base; client code which needs functionality not in base can still "require-bundle" the full ICU. I would have filed this defect against icu-project.org but I did not find any information about com.ibm.icu.base on their pages, so I am unsure who really provides icu.base.
com.ibm.icu.text.Bidi <-> java.text.Bidi is another candidate, which is needed by JDT. java.text.Bidi was added in J2SE-1.4. Yet another candidate (used by org.eclipse.jem.util) is UTF16. I notice that this issue is more complex than I thought. Converting into an enhancement request for now.
Another related question is, would it be possible to have both icu.base and the full icu loaded (by different plugins). Assume an extendable system, where the base can run with icu.base -- but then a user comes and installs some add-on that needs the full ICU. Given that ICU4J is really a library, it's hard for me to see why the "Singleton" directive is set on it. Is there a reason? Would it be possible to have both loaded in parallel?
We (Wind River) would be interested in contributing code for an enhanced icu.base that - depends on J2SE-1.5, - provides Bidi, UCharacter, ULocale, UTF16 at least. such that the range of RCP's and Eclipse Applications that can live without the 6MB size / 2 second startup time burden of the full ICU can be extended. But at the moment I'm unsure where or how to contribute, since I cannot find any reference to icu.base on the http://www.icu-project.org pages. Any pointers are welcome. For now, I just understand that ICU is under a BSD-style license, so we're pretty free to do pretty much any thing to the code. But whatever we do, we're interested in contributing back.
Actually another option that might also work for us to alleviate startup performance issues, might be if the main ICU bundle were split into an "API" bundle and an "Impl" fragment which is only loaded on demand.
(In reply to comment #2) > Given that ICU4J is really a library, it's hard for me to see why the > "Singleton" directive is set on it. Is there a reason? Would it be possible to > have both loaded in parallel? The short answer is no. The ICU APIs reflect the JCL date/time/language APIs. Things like Locale (and hence ULocale) use statics and are global singletons. PW
Is this request still worth tracking? I am assuming not, since no comments or action in 5 years. But, if this change is still desired, please re-open. Or, perhaps better, open a bug [2] in the ICU4J project [1], since they are the ones who provide this special "base" bundle. [1] http://site.icu-project.org/ [2] http://bugs.icu-project.org/trac/