String#equals / String#compareTo are semantically different from
Collator#equals / Collator#compare.
I think your main question is how to adopt ICU4J APIs in existing code
usig JDK APIs. In this context, if the original implementation is
appropriate, you should not make such replacements.
String methods simply checks the equality or binary representation of
Strings (UTF-16), while Collator considers:
1. Unicode forms (composed/decomposed/normalization form differences)
2. Level of comparison strength (ignore case, accents, etc..)
3. Linguistic differences (language specific matching/ordering)
In general, you should not simply replace String methods with Collator
methods.
However, it's pretty common that a Java application code lacking
internationalization considerations uses String methods where Collator
should be used instead.
-Yoshito
Ewan Chalmers <ewan.chalmers@...> wrote on 03/03/2010 05:28:57 PM:
>
> I am migrating a large codebase to use ICU4J
>
> A refactoring tool I am using suggests that String.equals(String) and
> String.compareTo(String) should be refactored to use Collator and
> StringComparator respectively.
>
> Is there any reason not to implement this refactoring consistently
across
> the code?
>
> For example, is it sensible to replace all s1.equals(s2) statements, for
> example in SomeType.equals(Object) implementations to use
> Collator.getInstance().equals(s1, s2)?
>
> Or should such refactoring be done selectively?
>
>
>
------------------------------------------------------------------------------
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> icu-support mailing list - icu-support@...
> To Un/Subscribe:
https://lists.sourceforge.net/lists/listinfo/icu-support
|