[ https://issues.apache.org/jira/browse/CASSANDRA-18239?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17686550#comment-17686550 ]
Josh McKenzie commented on CASSANDRA-18239: ------------------------------------------- {quote}I've found it is on the whole pretty useful? There aren't many errant suppressions. If we are to remove it, we should ensure we replace it with an equivalent suite of checks that are maintained. {quote} I want to second this sentiment. In my experience on other projects, static analysis once tuned is an incredibly valuable tool to both avoid specific classes of common defects and also helping keep code style consistent. Getting to that point, especially with an older codebase, can be _quite_ laborious, but operating in environments with "all warnings are treated as compiler errors unless otherwise suppressed" has proven to be a huge benefit in my experience. My personal .02: I don't think eclipse warnings is the best tool for this job for us today, but I also don't want to see us regress and rip it out without having the bones of something else in place to all collaborate on replacing it with. > Remove eclipse warnings task > ---------------------------- > > Key: CASSANDRA-18239 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18239 > Project: Cassandra > Issue Type: Task > Components: Build > Reporter: Jacek Lewandowski > Priority: Normal > > Eclipse warnings is used for static code analysis. However, it does not fit > well into Cassandra code and practically we end up explicitly adding > suppressions in many places just to satisfy that tool rather than fix the > real issues. > This is an incomplete list of reasons to remove it: > - not closed resources are detected incorrectly > - does not recognize custom utility methods used to close the resources, > which use use heavily in the code, like {{Throwables.close}}, > {{FileUtils.close}}, {{closeQuietly}}... > - because of the above, we cannot make important things like {{Ref}} to > implement {{Closeable}} as it would make the tool to explode with tons of > warnings > - it complains about correct generics - something like "method X is not > applicable for ..." when the code compiles successfully is not acceptable > - it is old and not maintained > There are better tools like IntelliJ inspections for example, which can also > be run in headless mode -- This message was sent by Atlassian Jira (v8.20.10#820010) --------------------------------------------------------------------- To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org