Greetings, I remember another subtle issue which I would like to make people aware of.
3) Case-Insensitive String Comparison When developers need to compare strings without regard to case or want to realize a map with case-insensitive string keys, they often employ String.toLowerCase() or String.toUpperCase() to create a "normalized" string before doing a simple String.equals(). Now, the to*Case() methods are overloaded: One takes no arguments and one take a Locale object. The gotcha with the arg-less methods is that their output depends on the default locale of the JVM but the default locale is out of control of the developer (see also [0], [1]). That means the string expected by the developer (who runs/tests his code in a JVM using locale xy) does not necessarily match the string seen by another user (that runs a JVM with locale ab). For example, the comparison "info".equals(debugLevel.toLowerCase()) is likely to fail for systems with default locale Turkish. Since developers usually want to compare strings from the English language, they must use String.to*Case(Locale.ENGLISH) to get reliable results regardless of the end-user's default locale. Just to make the picture complete: String.to*Case() is locale-sensitive and context-aware. In contrast, Character.to*Case() and String.equalsIgnoreCase() (which relies on Character.to*Case()) are neither locale-sensitive nor context-aware [2]. For instance "ΣΣ".toLowerCase(Locale.ENGLISH).equals("σσ") is false while "ΣΣ".equalsIgnoreCase("σσ") is true (because the lower case form of "ΣΣ" is "σς"). Regards, Benjamin Bentmann [0] http://java.sun.com/javase/6/docs/api/java/lang/String.html#toLowerCase() [1] http://cafe.elharo.com/blogroll/turkish/ [2] http://java.sun.com/javase/6/docs/api/java/lang/Character.html#toLowerCase(char) --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]