Format google IT tests' input files to follow all the rules of google java style guide

[Zopsss]

All google tests are being migrated to whole config testing in this issue: #15214

We detected that Google java style simply reference to google-java-format as source of truth for specific chapter about line length (not whole) https://github.com/checkstyle/checkstyle/pull/14901/files#r1639771738 , same is location of { at https://github.com/checkstyle/checkstyle/pull/14901/files#r1621156853 . So we need to use this tool for Inputs and see cases where we are conflicting to make decision who is right. For other chapters we will still look at style guide first as source of truth.

As part of this issue, all the google tests' input files needs to be formatted to follow google java style guide rules. The input files should be formatted by google-java-format tool locally. This tool helps us to format the java file to follow google java style guide rules. Though this tool formats only some specific parts of the input file, it can fix incorrect spacing, indentation, brackets/curly braces placements, etc but it cannot fix incorrect variable names, missing javadoc comments, etc.

The input files will require to follow all the rules of the style guide, expect it will contain violations only corresponding to their section. In some cases, the input file will require some extra violations outside its corresponding section, which will be required to test the section properly, example: #15220 (comment)

---

Initially, we thought of adding google-java-format tool as a dependency to our project ( PR in which we tried to did this ) but after doing discussion on this topic, maintainers have come upon the idea of not adding this tool as a dependency for now. In future, we might add support for this tool, but for now we're not doing this, this tool should be used locally to format the input file but should not be added to CS as a dependency.

---

Input files of following sections needs to be formatted to follow all rules of google java style guide:

• 2.1 File name
• 2.3.1 Whitespace characters
• 2.3.2 Special escape sequences
• 2.3.3 Non-ASCII characters
• 3 Source file structure
• 3.2 Package statement
• 3.3.2 No line-wrapping
• 3.3.3 Ordering and spacing
• 3.4.1 Exactly one top-level class declaration
• 3.4.2.1 Overloads: never split
• 4.1.1 Use of optional braces
• 4.1.2 Nonempty blocks: K & R style
• 4.1.3 Empty blocks: may be concise
• 4.2 Block indentation: +2 spaces
• 4.3 One statement per line
• 4.4 Column limit: 100
• 4.5.1 Where to break
• 4.5.2 Indent continuation lines at least +4 spaces
• 4.6.1 Vertical Whitespace
• 4.6.2 Horizontal whitespace
• 4.8.2.1 One variable per declaration
• 4.8.2.2 Declared when needed
• 4.8.3.2 No C-style array declarations
• 4.8.4.1 Indentation
• 4.8.4.2 Fall-through: commented
• 4.8.4.3 Presence of the default label
• 4.8.5.3 Methods And Constructors Annotations
• 4.8.5.4 Field Annotations
• 4.8.6.1 Block comment style
• 4.8.7 Modifiers
• 4.8.8 Numeric Literals
• 5.2.1 Package names
• 5.2.2 Class names
• 5.2.3 Method names
• 5.2.5 Non-constant field names
• 5.2.6 Parameter names
• 5.2.7 Local variable names
• 5.2.8 Type variable names
• 5.3 Camel case: defined
• 6.2 Caught exceptions: not ignored
• 6.4 Finalizers: not used
• 7.1.1 General form
• 7.1.2 Paragraphs
• 7.1.3 Block tags
• 7.2 The summary fragment
• 7.3 Where Javadoc is used
• 7.3.1 Exception: self-explanatory methods
• 7.3.2 Exception: overrides
• 7.3.4 Non-required Javadoc

[nrmancuso]

After reading this issue description multiple times, I still cannot understand why we are doing this, how this is in scope for GSOC, and why we did not get maintainer consensus on the issue before approval.

[romani]

formatter come to radar as it is detected in diff of style and mentioned in style guide:

we have several issues where users complains on checkstyle that it is not aligned with google-java-format.

Java Style pages are updated by same Googler as maintainer of google-java-format.
there are hard to understand descriptions on expected formatting google/styleguide@4948841#r143131006 and all updates are linked to same update in google-java-format.

ITs Inputs are example of Good(fully compliant code) and code with Violations (not compliant by formatting or non-formatting issues).
We do format all by google-java-format for all Non spacing/curly/wrapping/... Inputs as confirmation that checkstyle is not conflicting with formatter, it is enhancing it it with extra validation.

If we find any conflict between formatter and Checkstyle we will reference to style guide wording to find out who has defect.

All pointing to fact that we have to be friends with formatter, and we make a good test foundation that are aligned with this tool for formatting issues of style guide.

google-java-format is versioned, so we need to use it make sure that during update of google-java-format dependency, it will might update Input sources but it will continue to be non conflicting with checkstyle. The only way to archive it is to do it on each commit.
There is options to use it as maven plugin and format all before compilation of chekcstyle, but it is more complicated configuration wise and as we are not absolutely sure what Inputs to format and what is not format, I accept fact that there might be complicated/weird cases and ..... so formattiing in certain test method is good migration option, very flexible.

[romani]

In future, we will move formatting of inputs to special CI job to do this (kind of requirements before jdk17) , outside of mvn install execution, but it is more complicated process, let's not go this direction now.
It is better to do this when all is set on what we format and how it works and how we handle edge cases.

[romani]

In future, we will move formatting of inputs to special CI job

Ok, I forgot to mention that in 2 days also mean "future" , here it is, CI job:
#15237

[Zopsss]

GitHub, generate site

[Zopsss]

all sections have been formatted, closing the issue