The default system locale is selected by the JVM from operating-system preferences, environment variables such as LANG, or JVM system properties when code does not specify a locale. Locale-sensitive string and number operations can therefore change behavior across machines. section 6.2 section 6.11
A common mistake is using argument-free toUpperCase() or toLowerCase() for identifiers, tags, or keys. Turkish distinguishes dotted and dotless I, so a conversion that works under an English locale can produce a different result under Turkish. Case conversion can also change string length: Straße becomes STRASSE under German uppercase conversion. section 6.2
Locale-dependent number formatting
String.format("%.2f", 1.234) may produce a period in a US locale and a comma in a German locale. If that result is later passed to Double.parseDouble(), the program can reject valid displayed input. Grouping separators can create an even worse failure by silently reinterpreting the number. section 6.3
Avoid the mistake with explicit and consistent locale choices:
- Specify the intended locale for case conversion when processing language-independent identifiers or structured data. section 6.2
- Do not pair locale-aware formatting with locale-independent parsing; use the same NumberFormat instance for both formatting and parsing when supporting localized numbers. section 6.3
- Test behavior under different locales, including Turkish and German, and use static analysis to locate argument-free case conversions where supported. section 6.2
