New Check: LargeConstantCollection

[yashvisharma1204]

I am proposing a new check within the coding category to detect large static collection initializers that exceed a specific element count. Currently, Checkstyle does not have a dedicated check to flag massive hard coded arrays, which can lead to significant bytecode bloat and poor separation of data and logic.

Rationale
In high-performance engineering, especially in AI and Data Engineering domains, developers sometimes embed lookup tables or model weights directly into Java source files.
This practice:

• Increases the size of the compiled .class file.
• Can lead to MethodTooLargeException if the static initializer grows too big.
• Makes the code difficult to maintain and read.

By implementing LargeConstantCollectionCheck, we can enforce a threshold (e.g., maxElements = 10) to encourage moving such data to external resource files like .json or .csv.

Proposed Configuration
The check will be configurable with a maxElements property.

<module name="LargeConstantCollection">
  <property name="maxElements" value="10"/>
</module>

Example of Violation

public class Config {
    // Violation: 12 elements exceed the default max of 10
    int[] lookup = {1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12}; 
}

Technical Implementation
The check will target TokenTypes.ARRAY_INIT and count the EXPR child tokens. If the count exceeds the threshold, it will log a violation using a message key for internationalization.

[saloni0903]

I'd like to take this up. I’ve been looking into TokenTypes.ARRAY_INIT and TokenTypes.LITERAL_NEW to ensure we capture both standard array initializers and collection-factory methods (like List.of).

I plan to:

1. Implement the visitToken logic to count child EXPR nodes.
2. Add a configurable maxElements property with a default of 10.
3. Write test cases covering nested arrays and different data types to ensure no false positives.