[dependabot]

Bumps dev.openjavaformat:open-java-format from 2.98.0.6 to 21.0.1.

Release notes

Sourced from dev.openjavaformat:open-java-format's releases.

21.0.1

This is the first release of open-java-format that stands on its own. Up to 2.98.0.6 the version was palantir-java-format's with a build number appended; once the bug fixes made the output differ from upstream, that numbering lost its meaning. The version now follows this project alone: <java>.<minor>.<build>. The first number is the Java version the formatter is built for, 21. The second moves with every change to the output, the third with fixes that leave the output alone. See Versions.

The output differs from 2.98.0.6, so take this release with one reformatting run, in a commit of its own.

From google-java-format

• A /* ... */ comment left on the line of an opening brace no longer lands one indent too deep, only for the next run to move it back (google/google-java-format#1464 by Tanvir Alam, for google/google-java-format#1260; #143).
• A comment on its own line right after an opening delimiter, such as for (, the ( of a try with several resources, assert with a detail message or the ; after enum constants, is indented as a continuation, and so is the code after it; both used to land at the indent of the statement. google-java-format fixed the same defect in its new layout builder (google/google-java-format#1501); its code does not apply here, its idea does (#175).
• Value classes (JEP 401): on a JDK that has them, the value modifier is recognized and put in order, while value, sealed and non stay identifiers where they are names. A lambda parameter named sealed or non no longer fails to parse (1959806 by Liam Miller-Cushon; #141).

Javadoc formatting, which only the formatJavadoc option of the API turns on; the command line and the plugins leave Javadoc as it is:

• /** ... **/ no longer comes out as /** ... * */ (google/google-java-format#1474 by Liam Miller-Cushon; #115).
• A word hyphenated at a line break is joined to its rest on the next line (google/google-java-format#1475 by Liam Miller-Cushon), and a comment that opens with a block tag such as <pre> gets no empty lines after /** (e4cef58 by Chris Povirk; #116).
• Lines of a <pre>{@code ...} block written without * keep their indentation: the defect of google/google-java-format#1476, fixed in this formatter's own lexer (#117).
• MOE strip markers are formatted like any other HTML comment (#155).

Fixed here

• A trailing // comment too long for its line stays where the first run wrapped it; the next run used to move the wrapped part to the indent of the code. google-java-format has had this open since 2017 (google/google-java-format#211; #169).
• //$NON-NLS-n$ markers stay valid for Eclipse: no space is inserted after //, and each marker stays on the line of its string when a statement is wrapped or reflowed (#23, #150).
• String literals that end up next to each other on one line are joined, "one " + "two" into "one two", so the output no longer depends on where the author broke a string (palantir/palantir-java-format#1781 by Zayan Khan, closed there unmerged, for palantir/palantir-java-format#68; #176).
• Removing unused imports keeps a used java.lang import that decides which class a simple name means (palantir/palantir-java-format#1778 by Zayan Khan, closed there unmerged, for palantir/palantir-java-format#1334; #174).
• A table of arguments or array elements laid out by hand keeps its rows when an operator such as -> or += comes before it on its line (#170).
• The pieces of a long string that the formatter wraps continue eight columns in, like any other continuation line, instead of four (#160).
• A // MOE: comment wraps like any other line comment (#150).

Thanks

To Liam Miller-Cushon and Chris Povirk of google-java-format, and to Tanvir Alam and Zayan Khan: their work is in this release, with their names on the commits.

Commits

• 7ab00d7 Merge pull request #179 from openjavaformat/fix/github-release-branch
• 2b233fe Name the release line's branch for the GitHub release
• 336a286 Merge pull request #178 from openjavaformat/fix/assert-case-joined-literals
• 957be3e Expect a joined detail message in commentAfterOpeningDelimiter-assert
• 0d2bc49 Merge pull request #176 from openjavaformat/fix/join-string-literals
• af36054 Merge pull request #175 from openjavaformat/fix/comment-after-opening-delimiter
• 05b43c8 Merge pull request #174 from openjavaformat/fix/keep-used-java-lang-import
• e66ee55 Move the tests of unused import removal into case files
• da784aa Join adjacent string literals that share a line
• 06edc5b Indent a comment after an opening delimiter like the code after it
• Additional commits viewable in compare view