jackson-databind: `ObjectMapperTest.testCopyWith()` failing on `2.16` branch on system with non-unix system linefeed

Search before asking

• I searched in the issues and found nothing similar.

Describe the bug

When I try to build on the 2.16 branch using mvn clean verify, I get:

[ERROR] Failures: 
[ERROR]   ObjectMapperTest.testCopyWith:206 expected:<{[
  "color" : "Black",
  "free" : "true",
  "pages" : "204.04"]
}> but was:<{[
  "color" : "Black",
  "free" : "true",
] "pages" : "204.04"
}>

Glancing at the source code, I see it’s comparing against a string with embedded \n (LF) literals.

String readResultAsString = "{\n  \"color\" : \"Black\",\n  \"free\" : \"true\",\n  \"pages\" : \"204.04\"\n}";
assertEquals(readResultAsString, mapper.writeValueAsString(readResult));

Just on the face of it (assuming normally the developers wouldn’t knowingly commit breaking code), I would bet you a cookie that Jackson is producing output using the system-configured line ending (which may in fact be appropriate), yet the person who wrote the test assumed that Jackson is producing LF line endings. The test passed for the developer because they are using a *nix machine. In my case, I’m on a Windows machine so perhaps it produced CRLF endings. (I’m just guessing by glancing at the code.)

If that is indeed the problem, you’ll want to either use System.lineSeparator() when constructing the expected output; or (perhaps a better approach) create a separate generalized output comparison method that normalizes line endings to be used across all the tests (except the few methods, if any, specifically checking for the line endings).

Version Information

No response

Reproduction

<-- Any of the following

1. Brief code sample/snippet: include here in preformatted/code section
2. Longer example stored somewhere else (diff repo, snippet), add a link
3. Textual explanation: include here –>

// Your code here

Expected behavior

No response

Additional context

No response