Bug 309477 - com.ibm.icu.base should be more generally applicable (providing Bidi, UCharacter, ULocale, UTF16)
Summary: com.ibm.icu.base should be more generally applicable (providing Bidi, UCharac...
Status: RESOLVED WONTFIX
Alias: None
Product: Orbit
Classification: Tools
Component: bundles (show other bugs)
Version: unspecified   Edit
Hardware: All All
: P3 enhancement (vote)
Target Milestone: ---   Edit
Assignee: DJ Houghton CLA
QA Contact:
URL:
Whiteboard:
Keywords: performance
Depends on:
Blocks: 290755 309468
  Show dependency tree
 
Reported: 2010-04-16 10:14 EDT by Martin Oberhuber CLA
Modified: 2015-11-19 15:33 EST (History)
8 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Martin Oberhuber CLA 2010-04-16 10:14:44 EDT
+++ 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.
Comment 1 Martin Oberhuber CLA 2010-04-16 11:01:31 EDT
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.
Comment 2 Martin Oberhuber CLA 2010-04-16 11:03:05 EDT
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?
Comment 3 Martin Oberhuber CLA 2010-04-19 11:02:49 EDT
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.
Comment 4 Martin Oberhuber CLA 2010-04-19 11:07:12 EDT
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.
Comment 5 Paul Webster CLA 2010-04-19 13:42:13 EDT
(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
Comment 6 David Williams CLA 2015-11-19 15:33:37 EST
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/