Add checks for Sun Style [4.2 - Wrapping Lines]

Parent issue: #20811

Description Add Checkstyle checks for all rules under 4.2 - Wrapping Lines of the Code Conventions for the Java Programming Language (cached page).

Rules covered From 4.2 - Wrapping Lines (CodeConventions.doc3.html#a248):

When an expression will not fit on a single-line, break it according to these general principles:

• Break after a comma.
• Break before an operator.
• Prefer higher-level breaks to lower-level breaks.
• Align the new line with the beginning of the expression at the same level on the previous line.
• If the above rules lead to confusing code or to code that's squished up against the right margin, just indent 8 spaces instead.

Here are some examples of breaking method calls:

someMethod(longExpression1, longExpression2, longExpression3,
        longExpression4, longExpression5);

var = someMethod1(longExpression1,
                someMethod2(longExpression2,
                        longExpression3));

Following are two examples of breaking an arithmetic expression. The first is preferred, since the break occurs outside the parenthesized expression, which is at a higher level.

longName1 = longName2 * (longName3 + longName4 - longName5)
           + 4 * longname6; // PREFER

longName1 = longName2 * (longName3 + longName4
                       - longName5) + 4 * longname6; // AVOID

Following are two examples of indenting method declarations. The first is the conventional case. The second would shift the second and third lines to the far right if it used conventional indentation, so instead it indents only 8 spaces.

//CONVENTIONAL INDENTATION
someMethod(int anArg, Object anotherArg, String yetAnotherArg,
           Object andStillAnother) {
    ...
}

//INDENT 8 SPACES TO AVOID VERY DEEP INDENTS
private static synchronized horkingLongMethodName(int anArg,
        Object anotherArg, String yetAnotherArg,
        Object andStillAnother) {
    ...
}

Line wrapping for if statements should generally use the 8-space rule, since conventional (4 space) indentation makes seeing the body difficult. For example:

//DON'T USE THIS INDENTATION
if ((condition1 && condition2)
    || (condition3 && condition4)
    ||!(condition5 && condition6)) { //BAD WRAPS
    doSomethingAboutIt();            //MAKE THIS LINE EASY TO MISS
}

//USE THIS INDENTATION INSTEAD
if ((condition1 && condition2)
        || (condition3 && condition4)
        ||!(condition5 && condition6)) {
    doSomethingAboutIt();
}

//OR USE THIS
if ((condition1 && condition2) || (condition3 && condition4)
        ||!(condition5 && condition6)) {
    doSomethingAboutIt();
}

Here are three acceptable ways to format ternary expressions:

alpha = (aLongBooleanExpression) ? beta : gamma;

alpha = (aLongBooleanExpression) ? beta
                                 : gamma;

alpha = (aLongBooleanExpression)
        ? beta
        : gamma;

Mapping: "Break after a comma" - SeparatorWrap (default eol). "Break before an operator" - OperatorWrap (default nl, already present). Alignment, 8-space avoidance indent and the method/if/ternary examples - Indentation (partial: enforces indentation mechanics; "prefer higher-level breaks" is judgment-based and not fully automatable). The PREFER/AVOID snippets are illustrations of the principles, not separate rules.

Checks to add to sun_checks.xml https://checkstyle.org/checks/whitespace/operatorwrap.html https://checkstyle.org/checks/whitespace/separatorwrap.html https://checkstyle.org/checks/misc/indentation.html

OperatorWrap - already present with defaults (nl = break before operator):

SeparatorWrap - to add (defaults: eol on COMMA = break after comma):

Indentation - to add (defaults match Sun's 4-space unit):

Progress tracker Check Rule PR OperatorWrap Break before an operator SeparatorWrap Break after a comma Indentation Align continuation lines, 8-space avoidance indent