Bring over upstream PRs #1707 (Java 25 syntax) and #1786 (JDK 27 end positions)

[abashev]

What

Two pull requests are open against palantir-java-format and not merged. Both stop the formatter from crashing on newer Java, and this fork has neither change.

Upstream PR	Author	What it fixes	Size	State upstream
palantir/palantir-java-format#1707	asm0dey	The formatter fails on import module …; (JEP 511), on compact source files with an instance main (JEP 512) and on unnamed patterns such as case Box(_, _) (JEP 456)	+981 −67, 40 files	Open since 2026-07-03. Reviewed in depth by a community member, several +1s, no maintainer response
palantir/palantir-java-format#1786	slachiewicz	NoSuchFieldError on JDK 27, where JDK-8372948 removed EndPosTable and JCCompilationUnit.endPositions, plus the re-ordered ParserFactory.newParser flags	+87 −6, 5 files	Open since 2026-09-15. Waiting on the CLA, whose signing page returns an error for the author

Checked here: open-java-format has no handling of JCModuleImport, IMPLICIT_CLASS or ANY_PATTERN, and Trees.getEndPosition still reads endPositions directly.

Why here

A fix that waits for months because nobody upstream picks it up is the case manifesto principle 6 describes. People on Java 25 cannot format these files today, and JDK 27 will break every user at once.

To decide first

• The compatibility promise. The 2.x line promises output identical to the upstream release with the same version number. By their descriptions neither PR changes the output of a file that formats today: Support JDK 27 end positions (JDK-8372948) palantir/palantir-java-format#1786 reports identical output on JDK 26 and 27, and Format module imports, compact source files, and unnamed patterns palantir/palantir-java-format#1707 turns errors into output. That has to be shown, not assumed, in particular for the ImportOrderer rewrite in Format module imports, compact source files, and unnamed patterns palantir/palantir-java-format#1707, which stops re-synthesising import declarations.
• The version number. So far the fourth number counts rebuilds of an upstream version. A release that carries patches upstream does not have needs a stated rule.
• The next upstream sync. If upstream merges either PR, the carried commits are dropped in favour of upstream's.

How

• Keep the authorship: cherry-pick with the original authors, or squash with Co-authored-by, and name the upstream PR in the commit message.
• Rewrite the paths while applying. Upstream's modules are palantir-java-format/… and palantir-java-format-native/…, here they are open-java-format/… and open-java-format-native/…. The Java packages are the same, so the code itself should apply cleanly.
• Leave out what only exists upstream: changelog/@unreleased/*.yml and the gradle/jdks/25/** files. The README changes of Format module imports, compact source files, and unnamed patterns palantir/palantir-java-format#1707 need rewording for this README.
• Format module imports, compact source files, and unnamed patterns palantir/palantir-java-format#1707 registers ImportTree#isModule in the native image's reachability-metadata.json. Carry that over to open-java-format-native.
• Format module imports, compact source files, and unnamed patterns palantir/palantir-java-format#1707 adds test data that only a JDK 25 parser accepts, and wires a JDK 25 test run into build.gradle. CI tests on JDK 21 today, so that needs a toolchain or a matrix entry.

Done when

• both changes are on main with their authors credited;
• a corpus formatted by the 2.98.0.1 jar and by the new build gives identical output, through the equivalence gate if it exists by then;
• the new test data passes on JDK 25, and the formatter runs on a JDK 27 early-access build;
• the native binary formats a file with import module.