[
https://issues.apache.org/jira/browse/CASSANDRA-18239?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17698623#comment-17698623
]
Maxim Muzafarov edited comment on CASSANDRA-18239 at 3/9/23 9:50 PM:
---------------------------------------------------------------------
My guess is that we can use an IDE-agnostic tool to perform static code
analysis, so Checkstyle + SpotBug + Sonar is a very good choice. I was
mentioning it here:
[https://lists.apache.org/thread/11j0hrv2bkx60xk7zvlgqgjwo982qv6h]
So we can remove the eclipse-warnings because they don't give us the expected
accuracy for source code checks, this will simplify the maintenance. I think it
will be better to have the shared Intellij code-style and inspections config as
I described it here CASSANDRA-18277 (we have almost everything for it).
Should we create an issue to configure Sonar's statistics updates on a commit
to the trunk (guess we can use GitHub Actions here)?
was (Author: mmuzaf):
My guess is that we can use an IDE-agnostic tool to perform static code
analysis, so Checkstyle + Sonar is a very good choice. I was mentioning it here:
[https://lists.apache.org/thread/11j0hrv2bkx60xk7zvlgqgjwo982qv6h]
So we can remove the eclipse-warnings because they don't give us the expected
accuracy for source code checks, this will simplify the maintenance. I think it
will be better to have the shared Intellij code-style and inspections config as
I described it here CASSANDRA-18277 (we have almost everything for it).
Should we create an issue to configure Sonar's statistics updates on a commit
to the trunk (guess we can use GitHub Actions here)?
> Replace eclipse warnings based static code analysis with something better
> (Sonar)
> ---------------------------------------------------------------------------------
>
> 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
