Why Use ICU4J?

Summary

  • Fully implements current standards
    • Unicode collation, normalization, break iteration
    • Updated more frequently than Java
    • Full CLDR Locale data
  • Improved performance

Details

  • Normalization
    • Addresses lack of Unicode normalization support in Java 5
    • Addresses outdated Unicode normalization support in Java 6
  • Up-To-Date Unicode version
    • Java 5 & 6 are Unicode 4.0, while ICU 4.0 is Unicode 5.1
    • Characters added after Unicode 4.0 do not have character properties in Java
  • IDNA and StringPrep
    • Addresses lack of Internationalized Domain Name support in Java 5
    • Addresses generic stringprep (RFC3454) support. stringprep is required for supporting various internet protocols (NFS, LDAP…)
  • Collation
    • Provides Unicode standard compliant collation support
    • ICU Collator fully implements UTR#10, while the Java implementation is outdated and not compatible.
  • Provides ICU UnicodeSet for easy character range validation
    • much more flexible and convenient for validating identifiers/text tokens with a given syntax
    • full boolean operations (union, intersection, difference)
    • all Unicode properties supported
  • Locales
    • BCP47 (language tag) support in locale class (supporting “script”, 3-letter language codes, 3-digit region codes)
    • Locale data coverage - much better, many more locales, up-to-date
  • Broader charset converter coverage
    • In ICU4J 4.2, also output charset selection
    • Custom fallback in charset converter
  • Other features missing in the JDK
    • Dates:
      • Many more date formats: month+day, year+month,…
      • Date interval formats: “Dec 15-17, 2009”
      • APIs for returning time zone transitions
    • Other formatting
      • Plural formatting, including units: “1 hour” / “2 hours”
      • Rule based number format (“three thousand two hundred”)
      • Extensive Non-Gregorian calendar support
    • Transliterator (for flexible text/script transformations)
    • Collation-sensitive string search
    • Same data as ICU4C, allowing same behavior across programming languages
    • All Unicode character properties - over 80, Java provides access to only about 10
    • Thai wordbreak

Performance & Size

  • Instantiation times are comparable
    • Common instantiate and reuse model
    • ICU4J and Java both use caches to limit impact
  • Collation performance many times faster
    • sorting: 2 to 20 times faster
    • sort key generation: 1.5 to 4 times faster
    • sort key length: 2/3 to 1/4 the length of Java sort keys
  • Property access much faster (isLetter, isWhitespace,…)
  • Can easily produce scaled-down version (removing data)

API

  • Subclasses of JDK classes where possible
  • Drop-in (change of import) if not

Summary

  • ICU4J is not for you if

    • you have tight size constraints
    • you require the Java runtime behavior

  • ICU4J is for you if

    • you need full compliance with current standards
    • you need current or additional locale and property data
    • you need customizability
    • you need features missing from Java (normalization, collation,…)
    • you need better performance