Palantir Java Format: a 120 column formatter that inlines method chains

A google-java-format fork with a different idea about breaking lines

palantir-java-format describes itself as a modern, lambda-friendly, 120 character Java formatter. It is based on google-java-format and credits the work of all the original authors, and it is available under the same Apache 2.0 licence.

So this is a fork, and the interesting question is what the fork changes. The answer is visible in the motivation examples, where the same method is shown formatted both ways.

google-java-format turns a nested plugin configuration call into a deeply indented staircase, where each lambda level adds another level of indentation and the argument to withPlugin is pushed onto its own line. Palantir's version keeps the lambda on the same line as its call and inlines the receiver chain, so the code reads across rather than down.

The second example shows the same effect on a stream pipeline, where the map and collect chain is flattened and the argument to the outer method stays on the declaration line.

The project states the principle behind this: even though it sometimes inlines code more than other formatters, reducing unnecessary breaks that do not help comprehension, there are also cases where it splits code into more lines in order to improve clarity and code reviewability.

That is the design position, and it is a considered trade rather than an accident of implementation. A formatter that keeps everything on one line until it must break produces deeply nested output when the code is genuinely nested, which is what the first example shows. Palantir's choice is that a lambda chain reads better left to right.

The 120 column width is the other half of the story. It is what makes the inlining affordable, because the same code that google-java-format at 100 columns would wrap, Palantir at 120 can often fit on one line.

The 80 character rule for method chains and why it exists

One deliberate rule is worth isolating, because it is the one that surprises people who arrive from another formatter.

Other formatters are content to completely one-line a long method call chain if it fits within the line width. The documentation gives the example:

var foo = SomeType.builder().thing1(thing1).thing2(thing2).thing3(thing3).build();

That is not a very readable result, however well it fits. To avoid that edge case, Palantir applies a limit of 80 chars for chained method calls, such that the last method call dot must come before that column, or else the chain is not inlined.

var foo = SomeType.builder()
        .thing1(thing1)
        .thing2(thing2)
        .thing3(thing3)
        .build();

The rule is narrower than the 120 column limit, which is the point. A chain gets inlined only if the whole thing fits in 120 columns and the final dot falls before column 80. That leaves room after the last call for arguments that might still need to wrap, which is what stops the awkward case where the closing bracket ends up far past the right margin.

For anyone migrating an existing codebase this produces a large diff, and it is worth saying so plainly. A repository formatted with google-java-format will be reformatted substantially by this one, because the two disagree about when to inline and where to break. The diff is noise in the sense the project's own docs mean it: it is whitespace, not logic.

The project addresses this indirectly through its tooling, since the formatter can be applied by a bot to incoming changes rather than by each developer.

The Gradle plugin wires the formatter into IntelliJ automatically

The Gradle plugin is the recommended entry point, and the documentation tells you to apply it to all projects where you want your Java code formatted.

buildscript {
    dependencies {
        classpath 'com.palantir.javaformat:gradle-palantir-java-format:<version>'
    }
}
allprojects {
    apply plugin: 'com.palantir.java-format'
}

The reason to prefer this over telling people to install a plugin by hand is in the next sentence. Applying the Gradle plugin automatically configures IntelliJ, whether you run ./gradlew idea or import the project directly from IntelliJ, to use the correct version of the formatter when formatting Java code.

That solves a specific and annoying problem. A formatter plugin installed globally in the IDE is the wrong version sooner or later, and then a developer's local formatting differs from what the build produces, and the diff appears in review. Pinning the version in the build and letting the plugin push it into the IDE removes that class of divergence.

For running the formatter from the command line, the documentation points at the com.palantir.baseline-format Gradle plugin, which enables ./gradlew format.

There is also a Spotless integration, documented through the Spotless Gradle plugin, for teams already using that tool for their other language formatting. The README lists four distribution channels at the top: an Eclipse plugin, an IntelliJ plugin, the Gradle plugin and Spotless.

The IntelliJ plugin is published on the JetBrains plugin marketplace, the Gradle plugin on the Gradle Plugin Portal, and the formatter itself on Maven Central under com.palantir.javaformat.

The stated trade: less bikeshedding, less control over layout

The project lists its upsides and downsides of automatic formatting with unusual candour, and the downsides section is the part to read before adopting it.

The upsides are organisational. Fewer nit comments in code reviews, allowing engineers to focus on the important logic rather than bikeshedding about whitespace. Bot-authored code changes can be auto-formatted to a highly readable style, with the project noting that they use refaster and error-prone heavily for that. Increased consistency across all repos, so contributing to other projects feels familiar. Fewer builds that trivially fail checkstyle. And easier onboarding for new developers.

The downsides are stated in the first person plural, which suggests the authors have the experience behind them. If you do not like how the formatter laid out your code, you may need to introduce new functions or variables. And the formatter is not as clever as humans are, so it can sometimes produce less readable code, with the note that they want to fix this where feasible.

That second bullet is the honest cost. Once formatting is automated, your lever for improving readability is not adjusting whitespace, it is restructuring the code so that the layout the formatter produces is readable anyway. A deeply nested lambda that the formatter renders as a staircase stays a staircase, and the fix is to extract it.

The project places this in a lineage, noting that many other languages have adopted formatters enthusiastically, including typescript with prettier, go with gofmt and rust with rustfmt. The topic tags on the repository include gofmt, which makes the analogy explicit.

For a team evaluating a formatter, the practical reading is that this decision is about review culture first and tool choice second. Adopting any formatter means giving up layout control; choosing this one means giving it up in exchange for a style that suits lambda-heavy modern Java.

The repository is several build targets, not one jar

The top level layout shows how much more this project is than a formatting library, and each directory corresponds to a distribution channel.

There is palantir-java-format/ for the core, and separate directories for the Eclipse plugin, the Gradle plugin, the IntelliJ plugin, and the native and JDK bootstrap builds: palantir-java-format-native/ and palantir-java-format-jdk-bootstrap/. There is also palantir-java-format-spi/, which suggests the formatter logic is factored behind an interface so that different front ends can drive it, and palantir-java-format-benchmarks/ for performance measurement of the formatter itself.

The docs/ and debugger/ directories are there for the documentation site and for an attached debugger, and the .baseline/ directory reflects the use of Palantir's own Baseline build tooling.

The build tooling at the root is worth noting too. build.gradle and settings.gradle drive the whole thing, with versions.lock and versions.props pinning dependency versions, and gradlew plus gradlew.bat for the wrapper. There is an .excavator.yml, which is Palantir's dependency update automation, and a .bulldozer.yml, which is their merge automation. The circleci/ directory holds the CI configuration, and .palantir/ holds project-level settings.

That build shape has a consequence for contributors. A change to the core formatter has to be tested against the native build, the JDK bootstrap build, and the plugin front ends, so the build is heavier than a single-module library. It also explains why the project ships a benchmark module: a formatter runs on every save and every commit in a large repository, so its speed is a real property rather than a nicety.

The default branch is develop, and the release history shows a rapid cadence with versions 2.100.0 on 2026-09-28, 2.101.0 on 2026-10-01 and 2.102.0 on 2026-10-05, with the last push on 2026-10-20. Releases are automated through Palantir's autorelease service, with the badge pointing at their internal Autorelease instance, and the changelog is configured through .changelog.yml.

Licence, provenance and the ecosystem it plugs into

The licence field on the repository says Apache-2.0, and the README states that palantir-java-format is available under the same Apache 2.0 licence as google-java-format. Since the project is a fork of google-java-format, that shared licence is what makes the fork possible without renegotiating terms with the original authors, and it also means the derivative work inherits the obligations of the original: the notice travels with the source, and the patent grant applies.

This is not legal advice, but it is a straightforward arrangement for a formatter, and the provenance is stated plainly in the README rather than buried. Anyone with a licensing question about using it in a commercial product can point at the LICENSE file in the repository root and at the google-java-format project it derives from.

The interesting legal-adjacent question is the other one: a formatter does not own your code, but it does own the layout decisions it makes, and those decisions are not configurable in any documented way. There is no style options file, no toggle for the chain limit, no configuration block in the visible documentation. The 120 column width and the 80 character chain rule are fixed properties of the tool.

That constraint is worth weighing against the alternatives. google-java-format at 100 columns has its own fixed decisions. Spotless lets you configure which formatter runs and with which options, but the options it exposes are the formatter's own. A hand-rolled formatter is configurable but then you own the maintenance.

The project also links out to the wider Palantir Java ecosystem in practice: refaster and error-prone for the bot-authored code changes the README mentions, and the baseline-format Gradle plugin for running the formatter as a build step. Those are optional, but they show the intended context, which is a large Java organisation with a lot of code and a lot of review.

Editorial conclusion

Palantir Java Format suits a Java organisation that has already decided to adopt automatic formatting and wants a style that does not shred lambda chains into unreadable nesting, particularly teams moving from google-java-format and already invested in Spotless or Gradle formatting. It does not suit a team that has not yet agreed on a formatter, because adopting one is a decision about review culture rather than about whitespace, and the project is candid that its output can be less readable than what a human would write. Before adopting it, check the 80 character chain limit, since it produces deliberately broken chains that look like a misconfiguration to anyone used to a different formatter, and confirm the IntelliJ plugin version matches the formatter version you pin in the build.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. palantir/palantir-java-format on GitHub
4. README
5. Releases