On 23/Sep/2010 01:10, Robert Muir (JIRA) wrote: > I thought about this too, > > one concern (not knowing if there are more cases involved) would be > if the input "should" be ascii, but "could" be something else. if > String.toLowerCase had the ascii special-case with a fallback to ICU, > it could fail less gracefully in such a situation if it encountered > non-ascii rather than simply not matching, especially since unit > tests tend to have more coverage for the ascii case... > > ...but this might be theoretical
Fail less gracefully than what? Today, by using String#toLowerCase(), invalid ascii gets past into ICU so will get converted as though it were a valid char encoding, so I don't think it would make anything worse than it is today. I the the debate is whether to find and fix places in the class library code where we know the input is ascii and change uses of String#toLowercase to use org.apache.harmony.luni.util.Util#toASCIILowerCase() [1] or put that detection into String so that ascii doesn't hit ICU. [1] http://svn.apache.org/viewvc/harmony/enhanced/java/trunk/classlib/modules/luni/src/main/java/org/apache/harmony/luni/util/Util.java?view=markup
