Add checkstyle rules for List.of() / Set.of() / Map.of()
See original GitHub issueWe decided to not use List.of(), Set.of() and Map.of(), preferring Collections.emptyList(), etc. We should have a checkstyle rule to prevent creeping them accidentally in the codebase. Note that we only want to prohibit the non-argument versions, using List.of(a) etc. is fine.
Issue Analytics
- State:
- Created a year ago
- Comments:8 (8 by maintainers)
Top Results From Across the Web
checkstyle – Configuration - SourceForge
A Checkstyle configuration specifies which modules to plug in and apply to Java source files. Modules are structured in a tree whose root...
Read more >Imports - checkstyle
Checks that the groups of import declarations appear in the order specified by the user. If there is an import but its group...
Read more >Coding - checkstyle
Covariant equals() - method that is similar to equals(Object) , but with a covariant parameter type (any subtype of Object).
Read more >Naming Conventions - checkstyle
public class MyTest { public void myTest() { try { // . ... Checks identifiers with a pattern for a set of illegal...
Read more >Whitespace - checkstyle
Checks for empty line separators before package, all import ... public class Test { public Test() { // OK super(); // OK }...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found

@dreis2211 We’re only disallowing the use of the zero-argument
of()methods.List.of(a),Set.of(a, b), and so on will be permitted and we’re already making some use of those methods.@dreis2211 We discussed this on the team call today and decided that
Collections.emptyList()was more explicit thanList.of()for creating empty lists. However, we might decide to change this in the future because there is the consistency argument in favor ofList.of(). For #28174, #28175 and #28178, we’ve decided to put those on hold for now. We won’t be doing a blanket replacement across the entire codebase but will approach it piecemeal for new usages.List.of()/Set.of()/Map.of()throw an NPE oncontains(null)and will require closer examination than just replacing all occurrences of theCollectionsmethods.