[glaforge]

Summary

Restores JavaFormatterOptions.Style.PALANTIR as a @Deprecated alias for Style.OJF (indentationMultiplier = 2, maxLineLength = 120) in open-java-format-spi and treats Style.PALANTIR identically to Style.OJF in ImportOrderer.

Motivation: Ecosystem & Spotless Backward Compatibility

As noted in the README ("Identical Java packages. com.palantir.javaformat.* stays, so your code and the SPI keep working. One-line migration. Change the coordinates below. Nothing else."), keeping binary and reflective compatibility in com.palantir.javaformat.java.JavaFormatterOptions.Style allows existing integrations to swap coordinates without breaking:

1. Spotless's built-in palantirJavaFormat() step (com.diffplug.spotless.java.PalantirJavaFormatStep):
   Spotless's built-in step defaults to DEFAULT_STYLE = "PALANTIR" and invokes com.palantir.javaformat.java.JavaFormatterOptions$Style.valueOf(style) via reflection. When a Gradle or Maven project overrides the dependency of Spotless's palantirJavaFormat() step to dev.openjavaformat:open-java-format without explicitly passing .style("OJF"), Style.valueOf("PALANTIR") previously threw:

   java.lang.IllegalArgumentException: No enum constant com.palantir.javaformat.java.JavaFormatterOptions.Style.PALANTIR
   

   With @Deprecated PALANTIR(2, 120) present on Style, existing Spotless palantirJavaFormat() configurations and direct Java API/SPI callers using Style.PALANTIR work out of the box as a true one-line coordinate swap.
2. Direct Java API / SPI callers:
   Codebases calling JavaFormatterOptions.builder().style(Style.PALANTIR).build() or ImportOrderer.reorderImports(input, Style.PALANTIR) continue to compile and format identically to Style.OJF, while receiving a standard Java deprecation warning guiding them toward Style.OJF.

(Note: CLI style flag handling from e8c0ee19 is intentionally left untouched so --palantir on the CLI continues to fail fast with exit code 2 as tested in MainTest.unknownFlagIsAnError.)

Suggested Follow-up Contribution to diffplug/spotless

In addition to keeping Style.PALANTIR as a deprecated alias here for immediate backward compatibility, a natural follow-up contribution to diffplug/spotless would give open-java-format first-class support in Spotless for both Gradle and Maven users:

1. spotless-lib (com.diffplug.spotless.java.OpenJavaFormatStep):
   • Maven coordinate: dev.openjavaformat:open-java-format (default version "21.0.1" or latest 21.x)
   • Default style: "OJF" (supporting "OJF", "PALANTIR", "GOOGLE", "AOSP") and formatJavadoc(boolean)
   • Reuses the same isolated classloader / FormatterService + JavaFormatterOptions reflective invocation mechanism as PalantirJavaFormatStep (since the com.palantir.javaformat.java.* package names are preserved).
2. spotless-plugin-gradle (com.diffplug.gradle.spotless.JavaExtension):
   • Expose openJavaFormat() and openJavaFormat(String version) DSL methods on spotless { java { ... } } with .style(String) and .formatJavadoc(boolean) configuration methods.
3. spotless-plugin-maven (com.diffplug.spotless.maven.java.OpenJavaFormat):
   • Expose <openJavaFormat> in <configuration><java>...</java></configuration> with optional <version>, <style>, and <formatJavadoc> parameters.

Verification

• Added FormatterTest.palantirStyleAliasMatchesOjfStyle verifying Style.valueOf("PALANTIR"), indentationMultiplier(), maxLineLength(), Formatter.formatSource, Formatter.formatSourceAndFixImports, and ImportOrderer.reorderImports.
• Ran ./gradlew formatDiff :open-java-format-spi:check :open-java-format:check :open-java-format:test.

[glaforge]

Thank you!
Once there's a new release out, we can see if we contribute to Spotless as suggested?

[glaforge]

I've filed: diffplug/spotless#3179
What do you think?

[abashev]

@glaforge thank you so much! I didn't know about your challenge, but my evening mood for making PRs came at the right time 😁 One amendment to your comparison table: we have only two options, OJF or PALANTIR, because we are not able to support the Google style at the same time.

If you have a similar usage profile, there are some interesting things in addition to JBang (my favourite, and it brought a lot of energy into this fork):

The Palantir Gradle plugin is nice, but it doesn't support the configuration cache or the build cache. In my understanding, that is a must-have for Java development right now. open-java-format has both, and it also fixes an issue with multi-module projects and a single shared repository for the formatter.

MAX_ROUNDS comes from this regression: palantir#1632, so a more detailed comparison will show a difference in our numbers 😉

And under 'recent Java features' you forgot about JDK 28 and value classes: they are part of our CI process, and we fully support them.

For the Spotless fix I'll add as many reactions as I can, but you need somebody on the other side. There is also one important thing: Spotless uses this call from Formatter: https://github.com/openjavaformat/open-java-format/blob/21.X.X/open-java-format/src/main/java/com/palantir/javaformat/java/Formatter.java#L293
Maybe that is a leftover from migrating the code from the Google formatter. But Palantir extended it here: https://github.com/openjavaformat/open-java-format/blob/21.X.X/open-java-format/src/main/java/com/palantir/javaformat/java/Formatter.java#L308, and all the plugins, native binaries and formatters use that call. So adding a group doesn't make much sense without a proper method that keeps all results consistent across all possible calls.