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
|