Upstream: palantir#1781
Kind: bug | Priority: low

palantir-java-format#1781 (closed unmerged on 2026-10-17) describes a leftover of string wrapping: when a long concatenation of literals is re-wrapped and the pieces end up on the same line, the + between two adjacent literals stays, because the string-wrapping pass only acts on lines that exceed the column limit. The PR adds a pass that merges runs of adjacent literals which already share a line into one literal, guarded so that it never merges across a comment (NON-NLS markers), never touches text blocks, and refuses merges that would change an octal escape such as "\1" + "2".

Why it matters to us: our StringWrapper has no such joining pass, so we should leave the same "..." + "..." residue and the formatting stays dependent on how the author wrapped the string. It also interacts with our open work on NON-NLS markers (our #23). The idea also changes the semantics-adjacent text of string literals, so the escape guard is the part to get right.

Affected files: open-java-format/src/main/java/com/palantir/javaformat/java/StringWrapper.java (including the fast-path checks that decide whether wrapping is needed).

Before (upstream behaviour before the change; our StringWrapper has no joining pass, not run):

throw new SafeIllegalArgumentException(
        "Invalid recipient field - contains multiple " + "foreign key properties.",
        UnsafeArg.of("field", maybeField));

After (with the change):

throw new SafeIllegalArgumentException(
        "Invalid recipient field - contains multiple foreign key properties.",
        UnsafeArg.of("field", maybeField));

Suggested action: investigate; adopt the idea only with the escape and comment guards, low priority.

Filed from an upstream-watch ticket after manual review.