Repository files navigation

A modern, lambda-friendly, 120 character Java formatter.

• Eclipse plugin
• IntelliJ plugin
• Gradle plugin
• Spotless

It is based on the excellentgoogle-java-format, and benefits from the work of all theoriginal authors. palantir-java-format is available under the sameApache 2.0 License.

• reduce '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 (we userefaster anderror-prone heavily)
• increased consistency across all repos, so contributing to other projects feels familiar
• reduce the number builds that trivially fail checkstyle
• easier to onboard new devs

• if you don't like how the formatter laid out your code, you may need to introduce new functions/variables
• the formatter is not as clever as humans are, so it can sometimes produce less readable code (we want to fix this where feasible)

Many other languages have already adopted formatters enthusiastically, including typescript (prettier), go (gofmt), rust (rustfmt).

(1) google-java-format output:

privatestaticvoidconfigureResolvedVersionsWithVersionMapping(Projectproject) {project.getPluginManager()            .withPlugin("maven-publish",plugin -> {project.getExtensions()                                .getByType(PublishingExtension.class)                                .getPublications()                                .withType(MavenPublication.class)                                .configureEach(publication ->publication.versionMapping(mapping -> {mapping.allVariants(VariantVersionMappingStrategy                                                                            ::fromResolutionResult);                                                        }));                    });}

(1) palantir-java-format output:

privatestaticvoidconfigureResolvedVersionsWithVersionMapping(Projectproject) {project.getPluginManager().withPlugin("maven-publish",plugin -> {project.getExtensions()                .getByType(PublishingExtension.class)                .getPublications()                .withType(MavenPublication.class)                .configureEach(publication ->publication.versionMapping(mapping -> {mapping.allVariants(VariantVersionMappingStrategy::fromResolutionResult);                }));    });}

(2) google-java-format output:

privatestaticGradleExceptionnotFound(Stringgroup,Stringname,Configurationconfiguration) {Stringactual =configuration.getIncoming().getResolutionResult().getAllComponents().stream()                    .map(ResolvedComponentResult::getModuleVersion)                    .map(mvi ->String.format("\t- %s:%s:%s",mvi.getGroup(),mvi.getName(),mvi.getVersion()))                    .collect(Collectors.joining("\n"));// ...}

(2) palantir-java-format output:

privatestaticGradleExceptionnotFound(Stringgroup,Stringname,Configurationconfiguration) {Stringactual =configuration.getIncoming().getResolutionResult().getAllComponents().stream()            .map(ResolvedComponentResult::getModuleVersion)            .map(mvi ->String.format("\t- %s:%s:%s",mvi.getGroup(),mvi.getName(),mvi.getVersion()))            .collect(Collectors.joining("\n"));// ...}

Even though PJF sometimes inlines code more than other formatters, reducing what we see as unnecessary breaks that don't help code comprehension, there are also cases where it will split code into more lines too, in order to improve clarity and code reviewability.

One such case is long method chains. Whereas other formatters are content to completely one-line a long method call chain if it fits, it doesn't usually produce a very readable result:

varfoo =SomeType.builder().thing1(thing1).thing2(thing2).thing3(thing3).build();

To avoid this edge case, we employ a limit of 80 chars for chained method calls, such thatthe last method call dot must come before that column, or else the chain is not inlined.

varfoo =SomeType.builder()        .thing1(thing1)        .thing2(thing2)        .thing3(thing3)        .build();

You should apply this plugin to all projects where you want your java code formatted, e.g.

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

Applying this automatically configures IntelliJ, whether you run./gradlew ideaor import the project directly from IntelliJ, to use the correct version of the formatterwhen formatting java code.

./gradlew format can be enabled by using thecom.palantir.baseline-format Gradle plugin.

• Seeintegration in Spotless Gradle plugin.
• Seeintegration in Spotless Maven plugin.

Apalantir-java-format IntelliJ pluginis available from the plugin repository. To install it, go to your IDE'ssettings and select thePlugins category. Click theMarketplace tab, searchfor thepalantir-java-format plugin, and click theInstall button.

The plugin will be disabled by default on new projects, but as mentionedabove,if using thecom.palantir.java-format gradle plugin, it will be recommendedin IntelliJ, and automatically configured.

To manually enable it in the current project, gotoFile→Settings...→palantir-java-format Settings (orIntelliJ IDEA→Preferences...→Other Settings→palantir-java-format Settings on macOS) andcheck theEnable palantir-java-format checkbox.

To enable it by default in new projects, useFile→Other Settings→Default Settings....

When enabled, it will replace the normalReformat Code action, which can betriggered from theCode menu or with the Ctrl-Alt-L (by default) keyboardshortcut.

1. Clone this repo
2. run./gradlew :idea-plugin:build
3. In IntelliJ, install a plugin from disk. Build artifacts are located in./idea-plugin/build/distributions/

In1211 we shipped Java 21 support. In order to use theJava 21 formatting capabilities, ensure that either:

• the Gradle daemon and the Intellij Project SDK are set to Java 21
• or that the gradle propertypalantir.native.formatter=true. This will run the formatter as a native image,
• independent of the Gradle daemon/Intellij project JDK version.

This comment explains why weswitched to a native image for the formatter. The startup time for the native image esp. in Intellij is >10x faster thanspinning up a new JVM process that does the formatting.However, the throughput of running the native image for a large set of files (eg. running./gradlew spotlessApply) isconsiderably slower (eg. 30s using the Java implementation vs 1m20s using the native image implementation). Therefore,when running the formatter fromspotlessApply we will default to using the Java implementation (if the Java version >= 21).

• preserveNON-NLS markers - these are comments that are used when implementing NLS internationalisation, and need to stay on the same line with the strings they come after.

(c) Copyright 2019 Palantir Technologies Inc. All rights reserved.Licensed under the Apache License, Version 2.0 (the "License"); you may notuse this file except in compliance with the License. You may obtain a copy ofthe License at    http://www.apache.org/licenses/LICENSE-2.0Unless required by applicable law or agreed to in writing, softwaredistributed under the License is distributed on an "AS IS" BASIS, WITHOUTWARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See theLicense for the specific language governing permissions and limitations underthe License.

This is a fork ofgoogle-java-format.Original work copyrighted by Google under the same license:

Copyright 2015 Google Inc.Licensed under the Apache License, Version 2.0 (the "License"); you may notuse this file except in compliance with the License. You may obtain a copy ofthe License at    http://www.apache.org/licenses/LICENSE-2.0Unless required by applicable law or agreed to in writing, softwaredistributed under the License is distributed on an "AS IS" BASIS, WITHOUTWARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See theLicense for the specific language governing permissions and limitations underthe License.