Bring over upstream PR #1789: start a switch expression on the line of the declaration it initializes

[abashev]

What

palantir/palantir-java-format#1789 by @pkoenig10 keeps a switch expression on the line of the declaration it initializes. Today a local variable or a field initialized with a switch expression breaks after the =, and the switch is indented by eight; a plain assignment already keeps the switch on its line. It closes upstream #1258, is 4 files and +19 −28, was merged on 2026-09-23, the day it was opened, and the release notes of palantir-java-format 2.99.0 (2026-09-23) list it as the release's one improvement.

Measured here with a jar of main (a079cbb, whose formatter code is unchanged since 86cdc74) on the PR's ExpressionSwitch.input: the fork's output is byte for byte the .output the PR replaces, and formatting it again changes nothing.

// today: a declaration
        int x =
                switch (y) {
                    case 1 -> 1;
                    case 2 -> throw new IllegalArgumentException();
                    default -> throw new IllegalStateException();
                };

// with #1789
        int x = switch (y) {
            case 1 -> 1;
            case 2 -> throw new IllegalArgumentException();
            default -> throw new IllegalStateException();
        };

// today and with #1789: a plain assignment
        label = switch (y) {
            case 1 -> "one";
            default -> "many";
        };

The change: declareOne in JavaInputAstVisitor loses its special case for an initializer that starts with switch (a plain level, marked TODO(fawind): Don't break switch expression assignment), so the initializer takes the same breakOnlyIfInnerLevelsThenFitOnOneLine level as any other; and visitCase in Java14InputAstVisitor drops the forcedBreak(minusTwo) after a rule case's ;. The PR's testdata moves two methods of ExpressionSwitch.

Why not in 2.x

It changes the output of files that format correctly today, which the 2.x line promises not to do: the README keeps the output of palantir-java-format 2.98.0 except for bug fixes, and other output changes wait for 3.0.

How much: in the 15,747 files of the JDK 21 sources, = switch ( occurs 108 times outside comments.

Shape	Occurrences	Files	Moves with palantir#1789
declaration, int x = switch (y) {	57	51	all of them
plain assignment, x = switch (y) {	51	46	none, already on one line

The counts are a grep; the corpus was not formatted.

To decide first

• Do we want it? A declaration and an assignment of the same switch come out differently today, and the difference says nothing to a reader. Under the manifesto it is decided once for everyone: no option, no flag.
• Which release. The same version-number 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: it goes with the other output changes waiting for 3.0.
• Whether to wait for the next upstream sync. It is merged and released upstream, so the next sync brings it anyway; carrying it alone only matters if 3.0 ships before that sync.

How

• Cherry-pick with the original author, as in 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: the fork shares history with upstream, so rename detection maps palantir-java-format/ to open-java-format/. Not tried here.
• The fork's ExpressionSwitch.output golden moves with it, in the same two methods as upstream's.

Found by the daily upstream check on 2026-09-24.