This issue will be the main tracker of all the work related to Record Pattern. It aims to support the new record pattern syntax introduced in Java 21. It will involve updating existing checks to ensure they correctly handle this new syntax and analysis of possible static analysis coverage (new checks) for this new language feature.
AST view: https://github.com/checkstyle/checkstyle/wiki/Record-Pattern-Preview---AST-strucuture
New tokens: RECORD_PATTERN_DEF, RECORD_PATTERN_COMPONENTS
Similar/Related tokens and constructs: PATTERN_VARIABLE_DEF, PATTERN_DEF, LITERAL_INSTANCEOF, RECORD_COMPONENT_DEF, RECORD_COMPONENTS,...
Java Enhancement Proposals
reviewing JEP did not provide explicit guidance on possible checks that require updates to accommodate this new feature.
Similar and Related Tokens
mahfouz@dell-g15:~$ grep -rl "PATTERN_VARIABLE_DEF" $checks | cut -d/ -f14- >> checks.txt
mahfouz@dell-g15:~$ grep -rl "PATTERN_DEF" $checks | cut -d/ -f14- >> checks.txt
mahfouz@dell-g15:~$ grep -rl "LITERAL_INSTANCEOF" $checks | cut -d/ -f14- >> checks.txt
mahfouz@dell-g15:~$ grep -rl "RECORD_COMPONENT_DEF" $checks | cut -d/ -f14- >> checks.txt
mahfouz@dell-g15:~$ grep -rl "RECORD_COMPONENTS" $checks | cut -d/ -f14- >> checks.txt
mahfouz@dell-g15:~$ cat checks.txt | sort -u
Frequently Impacted Checks
Other Static Analysis tool
- Intellij Inspection:
- PMD: I don't see any updates in rules just grammer and parser updates
Good Source of Best Practices
the most encourged best practice stated for record pattern is to use it instead of the old destruction syntax. We can't make a check to enforce this because we are not type aware
Associated JEP's Recommendations (JEP 440)
If a record pattern names a generic record class but gives no type arguments (i.e., the record pattern uses a raw type) then the type arguments are always inferred. Inference works with nested record patterns. In fact it is possible to drop the type arguments in the outer record pattern as well, leading to the concise code
As of Java 21, type arguments for record patterns can be inferred by the compiler when not explicitly provided. JEP recommend to drop type arguments in record pattern as this leads to a more concise code. This guides us to consider implementing a new check named UnnecessaryTypeArgumentsWithRecordPattern
JEP Code Example:
static void test2(Box<Box<String>> bbs) {
if (bbs instanceof Box<Box<String>>(Box(var s))) {
System.out.println("String " + s);
}
if (bbs instanceof Box(Box(var s))) {
System.out.println("String " + s); // Here the compiler will infer that the entire instanceof pattern is Box<Box<String>>(Box<String>(var s)
}
}
---
Discover Similar Checks
We have a check that violate the parameter assignment. Paremeters assignment is often considered poor programming practice as it can lead to confusion and unexpected behavior. The same would apply to pattern variables.
We should consider implementing a new check similar to ParameterAssignment that violates the assignment of pattern variables
Potential New Checks
The previously mentioned approaches' analysis has led to the proposal of the following new checks.
This issue will be the main tracker of all the work related to Record Pattern. It aims to support the new record pattern syntax introduced in Java 21. It will involve updating existing checks to ensure they correctly handle this new syntax and analysis of possible static analysis coverage (new checks) for this new language feature.
AST view: https://github.com/checkstyle/checkstyle/wiki/Record-Pattern-Preview---AST-strucuture
New tokens:
RECORD_PATTERN_DEF,RECORD_PATTERN_COMPONENTSSimilar/Related tokens and constructs:
PATTERN_VARIABLE_DEF,PATTERN_DEF,LITERAL_INSTANCEOF,RECORD_COMPONENT_DEF,RECORD_COMPONENTS,...Java Enhancement Proposals
reviewing JEP did not provide explicit guidance on possible checks that require updates to accommodate this new feature.
Similar and Related Tokens
Frequently Impacted Checks
RECORD_DEFis supported in this check Add Check Support for Java 21 Record Pattern : MethodParamPad #14966RecordPattern (int x)same asLITERAL_SYNCHRONIZEDin this checkAdd Check Support for Java 21 Record Pattern Syntax: NoWhitespaceAfter #15009
Other Static Analysis tool
redundantNullCheckWithPatternMatchingGood Source of Best Practices
the most encourged best practice stated for record pattern is to use it instead of the old destruction syntax. We can't make a check to enforce this because we are not type aware
Associated JEP's Recommendations (JEP 440)
As of Java 21, type arguments for record patterns can be inferred by the compiler when not explicitly provided. JEP recommend to drop type arguments in record pattern as this leads to a more concise code. This guides us to consider implementing a new check named
UnnecessaryTypeArgumentsWithRecordPatternJEP Code Example:
Discover Similar Checks
We have a check that violate the parameter assignment. Paremeters assignment is often considered poor programming practice as it can lead to confusion and unexpected behavior. The same would apply to pattern variables.
We should consider implementing a new check similar to ParameterAssignment that violates the assignment of pattern variables
Potential New Checks
The previously mentioned approaches' analysis has led to the proposal of the following new checks.
RedundantNullCheckWithPatternMatching: Enforce removing redundant null checks when using instance of operator.Add Check Support for Java 21 Record Pattern : New Check UnnecessaryNullCheckWithInstanceof #14945
PatternVariableAssignment: Similar to the ParameterAssignment check, enforce best practices by disallowing assignments to pattern variables.Add Check Support for Java 21 Record Pattern : New Check PatternVariableAssignment #14949
UnnecessaryTypeArgumentsWithRecordPattern: Ensure type arguments are dropped in record patterns for conciseness. Given the fact that they are always inferred.New check UnnecessaryTypeArgumentsWithRecordPattern #15223