Re: How to check variables for uniqueness ?
John W. Kennedy wrote:
No, but toUpperCase translates "?" to "SS" because that is the only
uppercase that "?" has. It doesn't work the other way because "SS" can
be either "ss" or "?", depending on the word. This is documented behavior.
Just because a behavior is documented doesn't mean it isn't broken. Either:
*equalsIgnoreCase should consider all these spelling variants equal,
*toUpperCase should leave ? alone, e.g. Bei?en -> BEI?EN while a
toAllCapsTitle or similar makes it BEISSEN, or
*the behavior should be based on the system default locale, with
versions of all the methods that accept a Locale and use it in place of
the system default, consistency among equalsIgnoreCase, toUpperCase, and
toLowerCase for a given locale, and unsurprising behavior to people from
Independently of which, a bunch of these methods and others around the
system need renaming for case consistency in a very different way -- a
bunch of Java methods don't follow the usual camelCase convention. A
partial list seems to include
String.toUppercase (should be toUpperCase)
String.toLowercase (analogously; and equalsIgnoreCase is already as it
That's at least four where the start of a non-initial word isn't
capitalized (case, case, space, and copy, respectively).
These are an endless source of fun compile errors and debugging sessions
and really they shouldn't be. Even in eclipse, they manage to annoy
without being so extreme, and also hinder documentation search and
completion (put System.arrayc, try to autocomplete it, and it balks; try
to view the documentation to see if there's something you've missed and
it also balks; eclipse could definitely use case-insensitive completion
when there's no ambiguity as a result of case-insensitivity).
Another fun one:
Really, it should be HTTPURLConnection or HttpUrlConnection, probably
the former. HTTPConnection would be best, since it's certainly a network
(i.e. URL) connection. :P