Re: [cross-project-issues-dev] com.ibm.icu requirement

[John Arthorne <John_Arthorne@xxxxxxxxxx>]

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 http://wiki.eclipse.org/ICU4J 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?

John

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>

To	Cross project issues <cross-project-issues-dev@xxxxxxxxxxx>
cc
Subject	Re: [cross-project-issues-dev] com.ibm.icu 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
> com.ibm.icu 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 com.ibm.icu
> 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 com.ibm.icu 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: 

http://icu-project.org/charts/comparison/
http://icu-project.org/icu4j_faq.html

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: http://java.sun.com/javase/6/docs/technotes/guides/intl/encoding.doc.html
and locales listed here: http://java.sun.com/javase/6/docs/technotes/guides/intl/locale.doc.html
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?

Regards,
Thomas Hallgren
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev