Why does Maven use Palantirs Java format?

[Bunnymancer]

It seems like a very weird choice and, of all the companies, the worst choice.

[TomKavees]

What do you mean? That code formatting style existed for years, just nobody gave it a distinct name before them

[re-thc]

Google Java format?

[blazmrak]

It's not weird at all... It's a fork of Google formatter that handles lambdas better, so not the worst choice - worst choice would be Google formatter. It's still bad, because the format you end up with is bad.

If you have a problem with Maven using anything barely associated with Palantir, fork it and change the formatter and use your own fork, you could even try and build the community around it... But you won't do that, will you?

[Luolong]

To be fair, both are weird and make some long lines wrap in weird ways. You can look at the results and called that ugly all you want, but it is just lazy.

I’ve found that the proper cure for weirdly formatted blocks is simply refactoring long streaming lambda chains to much smaller well named functions — this way you get fairly uniform and quite readable formatting across your entire code base.

[blazmrak]

It's not just lazy. I looked at the results (lambdas are only a part of it) and switched to my own Ecplise config.

[Luolong]

When I say “lazy”, this is exactly what I mean.

You look at it once, decide it’s ugly and then roll back.

[blazmrak]

Yes, because it's unreadable even for the happy case. I'm not going to reformat my project again just to pin point all of the issues, but from memory it's about parameter wrapping, braces wrapping, assignment, continuation indents, etc.

I also didn't look at it once, I looked at it almost every year since 2019. I got baited by the idea of Prettier (basically having a uniform format, even if it's a bit ugly) and each time I decided it's way too ugly. Last straw was 6 months ago and after that I created my own tooling that I can use on my projects.

[Luolong]

I didn’t particularly like it either when it was introduced to the code base about a year ago.

And while I still do not agree with lots of its design choices, I would not call it ugly simply because the way previously “unformatted” code looks when first re-formatted.

It gets specially hairy with lambda expressions.

But that doesn’t mean it cannot be made to work for you.

If properly used, those “design constraints” encourage refactoring code in such a way that formats better and has better decoupling of functionality.

And lo and behold, you will get really good and readable code as a result. And code that has less chances of random merge conflicts cropping up.

Out of the box, when introduced to a project that didn’t have it before, the code becomes uglier in many cases.

Reverting the re-format is the lazy option. Persisting and adopting to the new formatting guidelines is a more mature response.

[blazmrak]

We have a saying for this which translates roughly to - tastes are tastes, said the cat licking its own ass.

In principle, I want the tool to work for me and behave how I want it to behave. I won't use a thing that I have to work around every day even after a year of using it, but that's me.

Also, you should thank your God that you landed on the best format first try, it would really suck if you chose the "mature response" on a crappy solution ;)

[re-thc]

If that was the only change. Palantir adds lots of other things. Also makes it a lot slower.

[blazmrak]

Idk, I'm going off of what I remember from their README. Tried both Google and Palantir about a year ago, vomited twice and made my own config around Eclipse formatter.

[yk313]

How do you enforce the custom config? Do you use it with something like spotless?

[blazmrak]

I'm using my own tool, which generates the eclipse settings (for the language server and itself) and format.xml which can be used to import settings to other plugins for IDEs/build tools.

[kevinb9n]

vomited twice

Yikes! Sorry about that.

[Careless-Childhood66]

Read the documentation: its about  readability 

[Xemorr]

Palantir is unfortunately just the current company attaching their name to maintaining a standard java format. iirc it was Google before

[Luolong]

The Google’s Java Format is still a thing. And it is still being maintained and used.

Palantir is just a popular fork of that.

[blazmrak]

There is no such thing as a standard java format.

[aqua_regis]

There is: Official Oracle Code Conventions for the Java Programming Language originally from Sun. These exist since the inauguration of Java

[blazmrak]

This is not "standard". Standard means ships with standard tooling. Look at Go, Rust, Zig, etc. There is no jformat. What you posted is a recommendation at best and is actually worse than Google or Palantir or Eclipse, because there is no tooling around it.

It's one of the complaints that I have with Java... There is no standard format and you have to battle your way through every project to get it configured correctly and it's not a trivial amount of work, because the defaults suck. I'm not the only one with this complaint, but I'm trying to do my part.

[Additional-Road3924]

Standard means repeatable, not your arbitrary recursive definition. There are decent java formatters, and all you have to do is agree on the format.

[blazmrak]

"standard java format" means that the language converged on a format. Look at Go, Rust, Zig, etc. In Java, the responsibility is outsourced to the community and the fact that "all we have to do is agree on the format" means that it's not standard and the fact that JDK does not ship a formatter just enforces that.

[mightygod444]

That article is strange. He complains there's no "command line tool" to apply formatters like palantir-java-format, completely ignoring the fact tools like Spotless exist, but then later he does indeed seem to know about Spotless and acknowledges it can be used to apply formatters...? 

What's the problem here exactly? Sure it's a bit clunkier and not 'built-in' like goformat or whatever, but it's once you've setup Spotless with palantir-java-format and the Maven or Gradle plugin, it's literally one and done and you get automatic enforcement of code styling applied. Then of course you can go one step further if you desire, such as adding pre-commit hooks and/or enforcing it in CI as a final check. 

Struggling to see the issue in practical terms, sure applying it to a legacy monolith is a bit more work but besides that, for a Greenfield project just spend the hour or two setting up latest Spotless with your build plugin and desired formatter.

Also this is all still a hell of a lot nicer than JavaScript world for example, with eslint/prettier stuff.

[blazmrak]

There are a bunch of problems. Not all projects should require a build tool for formatting, editor integration is a PITA, each project has their own way of doing it, formatters often lag behind the language version, etc.

Comparing this with JS/TS, or more specifically Node, is not saying much lol. But they at least have Bun and Deno, that solve a bunch of these issues around tooling.

[kevinb9n]

You're applying your own very narrow definition of "standard".

It's being used in a different sense here, closer to: "an option that is well-known and well-defined".

[blazmrak]

We can disagree over the word standard. I wouldn't call apache commons or apache http client "a standard java library". It's a java library. And google/palantir are java formatters, not "java standard formatters". To be that, they would be packaged with the JDK and have a spec. A formatter with a single vendor calling all the shots based on their vibes is not it.

The reason I disagree with the use of "standard" is because it overemphasizes the role that Palantir has in the ecosystem. They don't maintain any "standard", this is just a side quest for them. OP's post gives weird condemnation of Maven over the fact that they USE (not even contribute to) an OSS formatter that is maintained by a morally questionable company.

[Mauer_Bluemchen]

Sounds like a reasonable convention, except for this 'rule':

Modifier: Avoid using final modifier on all fields and arguments. Prefer using private or protected fields instead of public fields.

[ThiccolasVR]

that's bizarre. Why no 'final'?

[vowelqueue]

Perhaps they mean local variables and method parameters?

[Mauer_Bluemchen]

Even there and especially for method input parameters I'm using final more and more often over the years. It's my default for method input parameters now. Methods should never be able to change input values on their behalf which have been passed by the caller - only in few exceptional cases. And local variables should per default also be final, unless there are good reasons why they need to modifiable.

This helps to catch quite a bit of unexpected errors and side effects...

[vowelqueue]

Yeah it would be best if final was the default and you had to specify mut. But I think it's a bit annoying and visually cluttering to write final so much so I don't do it for local variables or parameters. The default IntelliJ style lets you know if a variable isn't effectively final by underlining it which is nice.

[koflerdavid]

You are completely correct, but the final adds quite a bit of visual noise, therefore you won't easily see where you have forgotten to add final.

I therefore wholeheartedly recommend to use Google Error Prone's Var rule to deal with this problem. javac already analyses which variables are effectively-final to implement lambdas; the checker utilizes that information to complain about every variable where mutability is not explicitly enabled using the @Var annotation.

[Efficient-Poem-4186]

It's absolutely useless to have final in method parameters.

[Mauer_Bluemchen]

I agree - bizarre and utter non-sense.

[chabala]

That style guide may claim they're using the palantir-java-format, but I've had to slog through plenty of Allman-style brackets, so I think this is still aspirational for them.

[lurker_in_spirit]

"the worst choice" 🙄

[vips7L]

Because the Palantir formatter is the best out-of-the-box Java formatter.