Switch to palantir-java-format

[koppor]

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" jabref#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) jabref#10577 (review))
• Issues with Eclipse vs. IntelliJ
  • Example: https://github.com/JabRef/jabref/pull/10707/files

Thus, I am looking for good autoformatting tools. I thought Google's Java Code Style would be great. However, 4 spaces need extra configuration (see #661). Moreover, the project seems to be unmaintained currently. Luckily, I found a maintained alternative: palantir-java-format

The diffs look good. Only three drawbacks:

• @FXML is placed before the declaration (because all annotations are placed the line before)
• this( reads strange with the 2x4 space indent next line
• XML and CSS is also reformatted

For me these are no real drawbacks or show stoppers.

REgarding migration: One needs to switch away from JabRef code style to "Default". However, I think, this is manageable as the active contributors can be informed - and the "drive-by" contributors are setting up their IDE before their contribution.

(GJF was tried out at #661)

---

Open issues:

• [IntelliJ] Add note on Imports palantir/palantir-java-format#954
• Setup .git blame ignore - as outlined at Use Prettier Java for automatic code formatting jabref#10646 (comment)
• Official Java 21 support: Java 21: Pattern Matching + StringTemplate JEP-430 + Unnamed JEP-445 palantir/palantir-java-format#935 (comment)

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.

[k3KAW8Pnf7mkmdSMPHz27]

My only problem with it thus far has been,

1. they update the style a bit faster than I'd like,
2. I mainly use Maven 😢
3. The marketplace plugin hasn't always been compatible with the most recent IntelliJ IDEA versions

I like the look it enforces, and it has some customizability with the Checkstyle rules. I'll try setting it up for IntelliJ in Windows based on this branch.

[github-actions]

Your code currently does not meet JabRef's code guidelines. We use Checkstyle to identify issues. The tool reviewdog already placed comments on GitHub to indicate the places. See the tab "Files" in you PR. Please carefully follow the setup guide for the codestyle. Afterwards, please run checkstyle locally and fix the issues.

More information on code quality in JabRef is available at https://devdocs.jabref.org/getting-into-the-code/development-strategy.html.

[github-actions]

Your code currently does not meet JabRef's code guidelines. We use OpenRewrite to ensure "modern" Java coding practices. The issues found can be automatically fixed. Please execute the gradle task rewriteRun, check the results, commit, and push.

You can check the detailed error output at the tab "Checks", section "Tests" (on the left), subsection "OpenRewrite".

[koppor]

As alternative, I checked spring-java-format, but it provides bad wrapping:

     /**
-     * Add X11 clipboard support to a text input control. It is necessary to call this method in every input where you
-     * want to use it: {@code ClipBoardManager.addX11Support(TextInputControl input);}.
-     *
-     * @param input the TextInputControl (e.g., TextField, TextArea, and children) where adding this functionality.
-     * @see <a href="https://www.uninformativ.de/blog/postings/2017-04-02/0/POSTING-en.html">Short summary for X11
-     * clipboards</a>
-     * @see <a href="https://unix.stackexchange.com/questions/139191/whats-the-difference-between-primary-selection-and-clipboard-buffer/139193#139193">Longer
+     * Add X11 clipboard support to a text input control. It is necessary to call this
+     * method in every input where you want to use it:
+     * {@code ClipBoardManager.addX11Support(TextInputControl input);}.
+     * @param input the TextInputControl (e.g., TextField, TextArea, and children) where
+     * adding this functionality.
+     * @see <a href=
+     * "https://www.uninformativ.de/blog/postings/2017-04-02/0/POSTING-en.html">Short
+     * summary for X11 clipboards</a>
+     * @see <a href=
+     * "https://unix.stackexchange.com/questions/139191/whats-the-difference-between-primary-selection-and-clipboard-buffer/139193#139193">Longer
      * text over

-    public ArgumentProcessor(String[] args,
-                             Mode startupMode,
-                             PreferencesService preferencesService,
-                             FileUpdateMonitor fileUpdateMonitor,
-                             BibEntryTypesManager entryTypesManager) throws org.apache.commons.cli.ParseException {
+    public ArgumentProcessor(String[] args, Mode startupMode, PreferencesService preferencesService,
+            FileUpdateMonitor fileUpdateMonitor, BibEntryTypesManager entryTypesManager)
+            throws org.apache.commons.cli.ParseException {

[koppor]

Note that spring java format uses tabs, because of good reasons:

• 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/

[koppor]

prettier-java does a great job in line wrapping.

palantir output:

        action.getKeyBinding().ifPresent(keyBinding -> keyBindingRepository
                .getKeyCombination(keyBinding)
                .ifPresent(combination -> setAccelerator(combination)));

prettier output:

        action
            .getKeyBinding()
            .ifPresent(keyBinding ->
                keyBindingRepository
                    .getKeyCombination(keyBinding)
                    .ifPresent(combination -> setAccelerator(combination))
            );

I like prettier more, because

• the subject is "always" in the first thing in the line.
• it also formats the imports

I'll file another PR. Let's see, how it works out ^^

[koppor]

The prettier-java output was "random", because line wrapping was at 80 chars... If set to 100 or 120 the wrapping is worse.

[koppor]

Blocked by palantir/palantir-java-format#935

[koppor]

Is it ehtically OK to use Palantir - even if it is "the best candidate"?

https://www.heise.de/news/Trotz-Bedenken-Bayern-testet-Palantir-Software-mit-echten-Personendaten-9545037.html

umstrittene[s] US-Unternehmen[...] Palantir