test user pass with special characters fixed to run on all platforms

[scottf]

No description provided.

[synadia-claude-reviewer]

Claude finished @scottf's task in 1m 53s —— View job

---

PR Review: test user pass with special characters fixed to run on all platforms

• Gather context and analyze PR
• Read changed file for context
• Review for correctness, security, and performance
• Post review findings

---

Summary

The fix is correct and well-reasoned. The root cause was that the old code always wrapped credentials in shell-quoting ("...") when passing them as --user/--pass args to the NATS server process. On Windows, ProcessBuilder flattens the arg list into a shell command line and the shell strips those quotes, so the server receives the bare credential. On Unix, ProcessBuilder passes the list directly to execv with no shell, so the quotes became literal characters in the credential string — making the test fail with the wrong credential. The fix adds quotes only on Windows.

---

One pre-existing issue worth noting

Duplicate test character (\t / (char)9)

src/test/java/io/nats/client/AuthTests.java, lines 105 and 107:

assertUserPassWithSpecialCharacters("\t");
assertUserPassWithSpecialCharacters("" + (char)9);

\t is ASCII 9 (horizontal tab), so these two lines test the identical character and one of the server-start/stop cycles is redundant. This was present in the original code too — not introduced by this PR — but since the test is being renamed and cleaned up anyway, this would be a good time to remove the duplicate.

---

Everything else looks good

• quoteCredentialForOs logic — correct. WINDOWS.isCurrentOs() from JUnit's org.junit.jupiter.api.condition.OS is the right way to branch. The method is private static and only used in the test helper, appropriate scope.
• Builder API switch — NatsServerRunner.builder().customArgs(customArgs) is the idiomatic newer API; the NatsTestServer(Builder b) constructor is already in place to accept it.
• Removing @EnabledOnOs — the whole point of the fix. The test is now valid on all platforms.
• Comments — the two block comments explaining the JSON-encoding rationale and the OS-quoting difference are clear and accurate; a future reader will understand the constraint without digging into ProcessBuilder docs.
• No security, thread-safety, or performance concerns — this is test infrastructure; correctness is the only axis that matters here.

[mtmk]

LGTM