What

palantir/palantir-java-format#1731 by @ranpy13 keeps the key and the value of a Map.of-style call together when the call has to break. Today every argument goes on a line of its own. It closes upstream #1602, is 3 files and +101 −5, and has been open since 2026-08-01 with no review and an unsigned CLA — where palantir#1707 and palantir#1786 were.

Measured here, with a jar built from the PR on top of 2.98.0.2:

// today
static final Map<String, String> plain = ImmutableMap.of(
        "first key",
        "the first value",
        "second key",
        "the second value");

// with #1731
static final Map<String, String> plain = ImmutableMap.of(
        "first key", "the first value",
        "second key", "the second value");

It applies to a call named of with an even number of arguments whose receiver's simple name is one of Map, ImmutableMap, ImmutableSortedMap, ImmutableBiMap, SortedMap, NavigableMap, ConcurrentMap. A call that fits on one line is unaffected, and so is one the existing tabular heuristic already lays out in pairs.

Why not in 2.x

It changes the output, which the 2.x line promises to keep identical to palantir-java-format 2.98.0. A file that is formatted today would fail a format check after the upgrade, which the PR says itself.

How much: of the 15,747 files of the JDK 21 sources, 54 contain such a call and 6 come out differently. The formatter's error output over that corpus is unchanged.

To decide first

• Do we want this style at all? One line per pair is easier to read in a long map, and it is what upstream Make Map.of() and ImmutableMap.of() more readable palantir/palantir-java-format#1602 asked for. Under the manifesto it is decided once for everyone: no option, no flag.
• Which release, and what its number is — the same version-number question Bring over upstream PRs #1707 (Java 25 syntax) and #1786 (JDK 27 end positions) #22 raises for carried patches.
• Whether to wait for upstream. If palantir merges it, take theirs at the next sync.

What the PR still needs

Found while applying it here:

• Its test does not test it. MapOf.input formatted with 2.98.0.2 already gives exactly MapOf.output, so the golden passes without the change. It needs a case that fails today, such as the long call above, whose arguments the tabular heuristic does not recognise.
• Only of, and only with a receiver. Map.ofEntries, ImmutableMap.builder(), a statically imported of(…) and Maps.immutableEntry are untouched.
• SortedMap, NavigableMap and ConcurrentMap have no static of in the JDK, so those three entries can only ever match a type of your own with that simple name. Matching a receiver by simple name is all a formatter that does not resolve types can do, but that deserves a comment.
• The patch is not formatted by this formatter: MAP_FACTORY_TYPES =ImmutableSet.of(. --dry-run --set-exit-if-changed exits 1 on the file.

How

• Cherry-pick with the original author, as in Bring over upstream PRs #1707 (Java 25 syntax) and #1786 (JDK 27 end positions) #22: this fork shares history with upstream, so rename detection maps palantir-java-format/ to open-java-format/ on its own. Tried here — the visitor hunks apply cleanly, and only the two new testdata files arrive as "added in a renamed directory".
• The palantir-8 golden here contains such a call; check whether its expected output moves.
• The Style page describes the output, so it changes with this.

Done when

• a test fails without the change and passes with it;
• a corpus run shows only map factory calls moving, and the release notes say so;
• the Style page shows the new layout;
• it ships in a release that is allowed to change the output.