In release 2.2, there are 2 known non-reference platform compilers that fail compiling ICU4J source code, IBM JDK 1.3.1_02 and Jikes 1.16. Use ICU4J on unsupported JVMs and non-reference platform compilers at your own risk.</P>
In release 2.2, there is a limitation with pattern handling with DecimalFormat when a percent or permille sign is included.
</p>
<p>
<ul>
<li> Quoted percent or permille signs, which should be treated as literals, are instead treated as if they were unquoted.
<li> Patterns involving percent or permille signs will be generated with localized pattern characters for those signs, when a non-localized pattern is requested. If such a pattern is subsequently applied to a DecimalFormat as a non-localized pattern, the percent or permille signs will not be recognized if they differ from the non-localized signs in the locale being used.
</ul>
</p>
<p>These problems will be fixed in the next release.</p>
<p>ICU4J's collation has been upgraded and now differs significantly from the JDK's implementation (originally provided by us several years ago).</p>
<p>ICU's collation is, in general, much more efficient than the JDK's. (The time to generate sort keys is longer, because they are so much shorter and more efficient to process). For instance:
<ul>
<li>ICU4J can correctly process FCD format strings with normalization off. The JDK has no notion of FCD. Much user text is in FCD form (for more information about FCD, see <ahref="http://www.unicode.org/notes/tn5/">Unicode Technical Note #5</a>).</li>
<li>CollationKeys generated by ICU4J are compressed, and as compared with the JDK's, can be up to 70% smaller (e.g. in the case of Latin characters).</li>
<li>String comparison in ICU is faster than the JDK's. In our tests of Latin characters, it took just 35% of the JDK's time. </li>
</ul></p>
<p>Although ICU4J's collation API is very compatable with the JDK's, there are some differences. Here is a listing of the main ones:
<ul>
<li>ICU4J supports <b>quaternary</b> and <b>identical</b> strength, the JDK does not.</li>
<li> ICU4J supports extra collation options, the JDK does not:</li>
<ul>
<li>alternate handling</li>
<li>case level sort</li>
<li>upper case first or lower case first switch</li>
</ul>
<li>ICU4J supports Unicode 3.2, while the JDK (as of version 1.4) only supports Unicode 3.0.</li>
<li>ICU4J does not allow turning off Thai reordering, while the JDK does. This is because in Unicode 3.2 Thai reordering is always required. The JDK uses '!' in the rules to turn off Thai reordering; ICU4J ignores it.</li>
<li>ICU4J supports additional rule syntax for various options, for example, setting <b>variable-top</b>, code point collation element positioning, and others. For details, see the <ahref="http://oss.software.ibm.com/icu/userguide/Collate_Customization.html">user's guide</a>.
<li>ICU4J's version of CollationKey has a public constructor, so subclasses of RuleBasedCollator can create their own CollationKeys. This was overlooked in the JDK (mea culpa).</li>
<li>The FULL_DECOMPOSITION mode used in the JDK is unnecessary for the UCA (and actually incorrect in some cases). ICU4J does not define this mode; clients should use CANONICAL_DECOMPOSITION instead.
<li>ICU4J uses the standard UCA default ordering, plus fixes and additions for
different languages, so the sorting order will differ from the JDK's.
