palantir-java-format fails on JDK 27 with NoSuchFieldError for JCCompilationUnit.endPositions

What happened?

Running palantir-java-format on JDK 27 (GA, 2026-09-15) fails on every file that reaches Trees.getEndPosition. Version 2.98.0 and every earlier release are affected, whether invoked through the CLI, Spotless or Gradle.

Hello.java:3:10: error: java.lang.NoSuchFieldError: Class com.sun.tools.javac.tree.JCTree$JCCompilationUnit does not have member field 'com.sun.tools.javac.tree.EndPosTable endPositions'
	at com.palantir.javaformat.java.Trees.getEndPosition(Trees.java:48)
	at com.palantir.javaformat.java.JavaInputAstVisitor.hasOnlyShortItems(JavaInputAstVisitor.java:573)
	at com.palantir.javaformat.java.JavaInputAstVisitor.argList(JavaInputAstVisitor.java:3234)
	...

Reproduce with any file containing a method call, for example:

public class Hello {
    public static void main(String[] args) {
        System.out.println("hi");
    }
}

java --add-exports jdk.compiler/com.sun.tools.javac.api=ALL-UNNAMED ... -cp <palantir-java-format-2.98.0 and deps> com.palantir.javaformat.java.Main Hello.java

Cause: JDK-8372948 ("Store end positions directly in JCTree", in JDK 27 from build 8 on) removed EndPosTable and the JCCompilationUnit.endPositions field. End positions are now JCTree.getEndPosition() with no argument. The same change dropped the keepEndPos parameter from ParserFactory.newParser, so the four-boolean overload that Formatter calls now means (input, keepDocComments, keepLineMap, parseModuleInfo). It still links, but the formatter is silently asking for module-info parsing.

Three call sites read the removed field: Trees.getEndPosition, StringWrapper.getEndPosition and RemoveUnusedImports.buildReplacements.

google-java-format hit the same failure in google/google-java-format#1396 and fixed it in google/google-java-format#1328.

What did you want to happen?

The formatter should run on JDK 27 while continuing to work on JDK 11 through 26. I have a change that routes all three call sites through one method handle that binds to whichever API the running JDK has, and passes the parser arguments in the right order per JDK generation. PR follows.

Start with Trees.java:48 and inspect the other two reported call sites in StringWrapper.getEndPosition and RemoveUnusedImports.buildReplacements. Review Formatter's ParserFactory.newParser invocation, then reproduce through the Main CLI command on JDK 27 and older JDKs. Done means formatting works on JDK 11 through 27 without the NoSuchFieldError or incorrect parser behavior.