What

Upstream palantir/palantir-java-format#1452 (open since 2025-10-24) reports that IntelliJ and Maven format the same file differently: the IDE wraps a long string, the build leaves it alone, so editing a file in the IDE pollutes the commit and then fails the build's check. The reason is that the two go through different entry points of the library.

We have the same split, in a different place. Checked here on 2.98.0.2 with the reporter's file:

class Test {
    public static void main(String[] args) {
        String example =
                "blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah";
    }
}

Running both library entry points over that file gives two different files: getFormatReplacements keeps the 119-column line, formatSourceAndFixImports breaks it into a concatenation. Formatter.formatSourceAndFixImports ends with StringWrapper.wrap; Formatter.getFormatReplacements has no such step.

Why it matters here

The manifesto says one style and nothing to tune, which only holds if the same file gives the same bytes wherever it is formatted. Today a file formatted by the Eclipse plugin can fail the check the GitHub Action runs, and neither output is wrong by itself. The Maven plugin in #26 would have to pick a side as well, and whichever it picks, half the users disagree with it.

To decide first

• Make the SPI reflow, so getFormatReplacements wraps the ranges it is asked to format, as the CLI does for --character-ranges. Every path then agrees. It changes what the SPI returns, so it is an output change for anything embedding the library — the same version question as Bring over upstream PRs #1707 (Java 25 syntax) and #1786 (JDK 27 end positions) #22 and Bring over upstream PR #1731: keep a map factory's key and value on one line #31.
• Or leave the library alone and fix the Eclipse plugin, then say in the SPI javadoc which method reflows and which does not.
• Whether reflowing is right for a range format at all: in the IDE, wrapping a string the user did not touch is exactly what upstream's reporter complains about.

Done when

• a test formats one file through every entry point — CLI, the Spotless step, the SPI, the native binary — and asserts the results are identical;
• the Eclipse plugin agrees with the CLI;
• the SPI javadoc states what each method does to long strings;
• whatever the Maven plugin (Add a Maven plugin with format and check goals #26) is built on inherits that answer.