Google Java Format is an excellent formatter for 2-space, 100 line codebases. Its Rectangle Rule has a high degree of conceptual purity, and this works well in the context of 2-space, 100 line codebases where it was designed. If starting from scratch, or if radical changes to existing code style were on the table, this would be my ideal formatter.
For existing 4-space, 120 line codebases where radical changes to existing code style are not on the table, Google Java Format has some critical flaws. Its 4-space "AOSP" mode does not work well at all, and it was not the primary use case. In practice the combination of 4-space mode and the rectangle rule results in unreadable code for lambdas. I have complained about this on the Google Java Format issue tracker for years, but no fix appears to be on the horizon. This makes sense, because Google internally uses the 2-space non-AOSP mode. While various PRs have been submitted to fix this problem, the maintainers of Google Java Format have rejected or ignored them, likely because they all violate the conceptual purity of the Rectangle Rule.
For existing 4-space, 120 line codebases (and the Jenkins project consists largely of these) where radical changes to existing code style are not on the table, Palantir Java Format is a better choice than Google Java Format. It is a fork of Google Java Format designed for this use case with intentional violations of the Rectangle Rule. In practice it gives much better results than Google Java Format for this type of codebase.
The Maven project is reformatting its legacy codebase with Palantir Java Format and I have been impressed with how relatively uneventful it has been. Palantir Java Format works very well with this type of codebase, and Jenkins is an example of this type of codebase as well. I have successfully reformatted plugin-compat-tester this way in https://github.com/jenkinsci/plugin-compat-tester/pull/506 and the results are far better than Google Java Format.
Google Java Format is an excellent formatter for 2-space, 100 line codebases. Its Rectangle Rule has a high degree of conceptual purity, and this works well in the context of 2-space, 100 line codebases where it was designed. If starting from scratch, or if radical changes to existing code style were on the table, this would be my ideal formatter.
For existing 4-space, 120 line codebases where radical changes to existing code style are not on the table, Google Java Format has some critical flaws. Its 4-space "AOSP" mode does not work well at all, and it was not the primary use case. In practice the combination of 4-space mode and the rectangle rule results in unreadable code for lambdas. I have complained about this on the Google Java Format issue tracker for years, but no fix appears to be on the horizon. This makes sense, because Google internally uses the 2-space non-AOSP mode. While various PRs have been submitted to fix this problem, the maintainers of Google Java Format have rejected or ignored them, likely because they all violate the conceptual purity of the Rectangle Rule.
For existing 4-space, 120 line codebases (and the Jenkins project consists largely of these) where radical changes to existing code style are not on the table, Palantir Java Format is a better choice than Google Java Format. It is a fork of Google Java Format designed for this use case with intentional violations of the Rectangle Rule. In practice it gives much better results than Google Java Format for this type of codebase.
The Maven project is reformatting its legacy codebase with Palantir Java Format and I have been impressed with how relatively uneventful it has been. Palantir Java Format works very well with this type of codebase, and Jenkins is an example of this type of codebase as well. I have successfully reformatted
plugin-compat-testerthis way in https://github.com/jenkinsci/plugin-compat-tester/pull/506 and the results are far better than Google Java Format.As the Zen of Python states: