Skip to main content

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

I'm also curious what's the advantages to ICU4J 4.0, that is, over version 
3.8. I don't see it listed in this comparison table

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







From:
Thomas Hallgren <thomas@xxxxxxx>
To:
Cross project issues <cross-project-issues-dev@xxxxxxxxxxx>
Date:
01/19/2009 05:40 PM
Subject:
Re: [cross-project-issues-dev] com.ibm.icu requirement
Sent by:
cross-project-issues-dev-bounces@xxxxxxxxxxx



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





Back to the top