Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cross-project-issues-dev] requirement

I agree you should be able to avoid using ICU4J in headless applications, if you don't need to build locale-specific representations of dates, times, etc. We don't use ICU4J at all in non-UI bundles in Equinox, and the Platform core bundles also don't use it for the most part. Maybe the answer for you is to avoid the problematic classes mentioned on altogether, which would remove any need for ICU4J in Buckminster. Is the problem for you that you have dependencies that in turn pull in the dependency on ICU4J?


Thomas Hallgren <thomas@xxxxxxx>
Sent by: cross-project-issues-dev-bounces@xxxxxxxxxxx

01/19/2009 05:38 PM

Please respond to
Cross project issues <cross-project-issues-dev@xxxxxxxxxxx>

Cross project issues <cross-project-issues-dev@xxxxxxxxxxx>
Re: [cross-project-issues-dev] requirement

Hi John,

John Arthorne wrote:

Thomas Hallgren wrote on 01/17/2009 07:48:47 PM:

> The Galileo release has a hard requirement that projects use the
> bundle. This is understandable when NLS is of great
> importance and it is expected that the bundle will run in older JVM's.
> The more recent the JVM is however, the less important the
> bundle gets since most of its content is merged into the runtime of  the
> latest Java releases.

I'm wondering what led you to this conclusion that the content gets merged into Java releases? According to documentation at the ICU site, the latest Java release (Java SE 6) doesn't have nearly the same functionality as even ICU4J 3.8:

I read this quote on the front page under "Why ICU4J":

"Java provides a very strong foundation for global programs, and IBM and the ICU team played a key role in providing globalization technology into Sun's Java. But because of its long release schedule, Java cannot always keep up-to-date with evolving standards."

Looking at the comparison I also see comments like "Since Java 5" or "Since Java 6" on some of the more prominent features of ICU4J that are now supported by the JRE.

Although I'm sure some of the fixes and additional locales do eventually find their way into the JDK, my impression is that there is a significant lag, and that there is no JDK version available today with nearly the same level of NLS functionality and Unicode compliance as ICU4J.
I'm not in total agreement regarding the "nearly the same level of ...". I'd consider the differences fairly esoteric. For UI based applications, they might matter but I doubt they have any significance for a headless build tool. We are quite happy supporting the encodings listed here: and locales listed here: and when it comes to dates and times stipulate a strict ISO-8601 format anyway. If we didn't, we would also have to provide locale information and formatters with all meta-data.

On a related subject:
I think IBM should consider submitting parts of ICU4J to the Open JDK project. The international calendars could be rewritten to make the calendars seamlessly available through the standard java.util.Calendar API and the optimizations on the RuleBasedCollator would certainly be a very appreciated addition as well. Chances are that the lag times mentioned could be shortened radically. Do you know if anyone in the ICU4J project has looked into this?

Thomas Hallgren
cross-project-issues-dev mailing list

Back to the top