How do Scanner's delimiter and locale settings affect parsing, and what surprises can they cause?

## Two hidden knobs Scanner looks simple, but two settings silently change what it parses: the **delimiter** and the **locale**. Misunderstanding either produces bugs that only show up with certain input or on certain machines. ## 1. The delimiter ### What it is The **delimiter** is the pattern that separates one token from the next. It is a **regular expression** (a mini-language for matching text patterns). By default the delimiter matches **whitespace** (`\p{javaWhitespace}+`), so input is split on spaces, tabs, and newlines. ### Changing it ```java Scanner sc = new Scanner("alice,bob,carol"); sc.useDelimiter(","); while (sc.hasNext()) System.out.println(sc.next()); // alice / bob / carol ``` ### The surprises - **It is a regex, not a literal.** `useDelimiter(".")` does NOT split on a literal dot — `.` in regex means "any character," so it would split on every character. Use `useDelimiter("\\.")` or `Pattern.quote(".")` for a literal dot. - **Whitespace is no longer special.** Once you set a non-whitespace delimiter, leading/trailing spaces around values become part of the token. For `"a, b, c"` with delimiter `","`, you get tokens `"a"`, `" b"`, `" c"` (note the spaces). You often need `useDelimiter("\\s*,\\s*")` to also swallow surrounding whitespace. - **The change is global** to that Scanner: all subsequent reads use the new pattern until you change it again. ## 2. The locale ### What a locale is A **locale** is a set of regional conventions — language, and crucially for parsing, **number formatting rules**: which character is the decimal separator and which is the grouping (thousands) separator. In the US/UK, `1,234.56` means one thousand two hundred thirty-four point five six (comma groups, dot decimal). In Germany, the same value is written `1.234,56` (dot groups, comma decimal). ### How Scanner uses it Scanner's numeric methods (`nextInt`, `nextLong`, `nextDouble`, `nextBigDecimal`, ...) parse according to the **Scanner's locale**, which defaults to the **JVM default locale** (the machine's regional setting). This means: ```java // On a machine whose default locale uses ',' as the decimal separator: Scanner sc = new Scanner("3.14"); sc.nextDouble(); // throws InputMismatchException — '.' is a grouping char here, not a decimal ``` The *same code* works on a US-locale machine and fails on a German-locale machine. This is a classic "works on my machine" bug. ### Pinning the locale For input your own program formats (or any input you control), make parsing deterministic: ```java Scanner sc = new Scanner(System.in); sc.useLocale(Locale.ROOT); // or Locale.US — '.' decimal, no surprises double x = sc.nextDouble(); ``` `Locale.ROOT` is the neutral, culture-independent locale — a safe default for machine-readable numbers. If you are reading genuinely localized human input, set the matching locale instead. ## 3. They interact with reading code - A `nextDouble()` that throws `InputMismatchException` on perfectly valid-looking `"3.14"` is almost always a **locale** problem. - A loop that reads one giant token instead of several is almost always a **delimiter** problem (often a regex-literal mistake). ## Practical rule When parsing machine-generated or fixed-format input with Scanner, **pin both knobs**: `useLocale(Locale.ROOT)` for numbers and an explicit `useDelimiter(...)` (regex-escaped) for non-whitespace separators. When parsing localized human input, choose the locale deliberately. Leaving them at their defaults makes correctness depend on the host machine — exactly what you do not want.