Use Prettier Java for automatic code formatting

[koppor]

Background

I am so fed up that

• contributors are not able to configure IntelliJ properly (e.g., [WIP] This relativizes the PDF's filepaths after importing through "Find Unlinked Files" #10582). We tried OpenRewrite for auto fixing, but did not work.
• our reformatting broke a few months ago for exceptions (e.g., Display files from referenced crossref in entry table (Toro520 version) #10577 (review))
• Issues with Eclipse vs. IntelliJ

I checked multiple formats and tools (palantir-java-format (JabRef#663), spring-java-format, google-java-format, spotless, square java style) - and "Prettier Java" seems to be best

I focus in *.java. XML could come next.

• Diff palantir-java-format: See Switch to palantir-java-format jabref-koppor#663 (comment)
• Diff spring-java-format: Switch to palantir-java-format jabref-koppor#663 (comment)

Changed

• Reformatter WITH COMMIT in the CI
• Howto refined

Notes

When coming from a fork, this action will just fail.

See https://github.com/orgs/community/discussions/75867 for details.

I had to disable the OpenRewrite rule UnnecessaryParentheses - see openrewrite/rewrite-static-analysis#219 for details

Next steps

Better comments

The commenting action cannot comment on pull requests, but @reviewdog can. I removed the commenting things here. Follow-up is to convert the output in case of errors to a format consumable to reviewdog.

Negleted by the team

I would like to switch from spaces to tabs:

• tabs are objectively better than spaces (due to accessibility reasons): https://gomakethings.com/tabs-are-objectively-better-than-spaces/

  Another accessibility reason for tabs: when using a braille display, each space takes up one character cell, so indenting with four spaces eats up four cells. Indenting three times with four spaces each eats up 12 characters already. Tabs only take one character cell each, so three indents = three character cells used.

  Given many, if not most, braille displays are 40 cells long, and that 70-to 80-cell displays are considered a luxury, and you can see how cutting 12 space characters down to 3 tab characters could be really, really helpful.

• Another article arguing for accessibility: https://alexandersandberg.com/articles/default-to-tabs-instead-of-spaces-for-an-accessible-first-environment/

- tabWidth: 4
+ useTabs: true

Mandatory checks

• Change in CHANGELOG.md described in a way that is understandable for the average user (if applicable)
• Tests created for changes (if applicable)
• Manually tested changed features in running JabRef (always required)
• Screenshots added in PR description (for UI changes)
• Checked developer's documentation: Is the information available and up to date? If not, I outlined it in this pull request.
• Checked documentation: Is the information available and up to date? If not, I created an issue at https://github.com/JabRef/user-documentation/issues or, even better, I submitted a pull request to the documentation repository.

[Siedlerchr]

No, please keep spaces! Even though they might be better suited for some people this will mess up everything else

[calixtus]

+1 for keeping spaces. Modern braille displays should be able to deal with multiple whitespaces. If we change this, almost every line of code will be changed and the whole git history and blame will only show one name. Even though you can go back in history with some commands, it won't be shown directly and will destroy the very overlook on the blame.

[Siedlerchr]

It seems to still break at 80 chars width or at least introduces a lot of unnecessarily wrapping

[tobiasdiez]

+1 for keeping spaces. Modern braille displays should be able to deal with multiple whitespaces. If we change this, almost every line of code will be changed and the whole git history and blame will only show one name. Even though you can go back in history with some commands, it won't be shown directly and will destroy the very overlook on the blame.

That can be easily fixed with .git-blame-ignore-revs (which should be used anyway for large reformatting changes such as this PR)

[koppor]

It seems to still break at 80 chars width or at least introduces a lot of unnecessarily wrapping

OMG. - Because they rely on prettier, this is configurable. I switched from palantir, which has 120 characters, but a "review-friendly" wrapping - https://github.com/palantir/palantir-java-format#motivation--examples.

I changed to 100 chars.

But that is no "review-friendly" line wrapping. Code less readable IMHO. Thus, I am closing this one and go back to try out palantir.