[
https://issues.apache.org/jira/browse/CASSANDRA-18239?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17711613#comment-17711613
]
Ekaterina Dimitrova edited comment on CASSANDRA-18239 at 4/13/23 12:27 AM:
---------------------------------------------------------------------------
{quote}If you like, we can make a deal - we can try to verify SpotBugs,
ErrorProne, and Sonar by the end of the week on minimal code examples. If we
fail to do that due to the lack of time, go on with Eclipse-Warnings, WDYT?
(maybe [~mmuzaf] can help there as well). I have ErrorProne configured already
on some other project hence confirming it works or not should not be super hard.
{quote}
Sounds good to me. I need also ecj updated for Java UDFs but last time I
checked that wasn't an issue...while with eclipse-warnings and the standalone
compiler I am still suffering.
About ErrorProne - looking [here|https://errorprone.info/docs/installation], it
seems it supports newer jdk versions but....sigh...expects more add-exports to
be added for JDK internals access.
{quote}My biggest concern with SpotBugs is that it has limited support for the
jdk versions it runs on, which could cause us the same problems in the future
as we have now with the eclipse-warnings. These pros and cons should be
carefully investigated, so I just switched to the Sonar task as it has almost
no doubts (I used changes from CASSANDRA-18077 to do checks locally).
{quote}
Totally agree with this concern. I also shared it on CASSANDRA-18077 some time
ago. Trying to search again anything about newer JDKs, I found only these 4
issues to support JDK17 EA
[https://github.com/spotbugs/spotbugs/issues?q=is%3Aclosed+label%3AJava-17]
The changelog mentions them but I do not see anything mention explicitly about
- support Java 17. On the other hand the repo is active, there are commits from
yesterday. I can try to dig better tomorrow
was (Author: e.dimitrova):
{quote}If you like, we can make a deal - we can try to verify SpotBugs,
ErrorProne, and Sonar by the end of the week on minimal code examples. If we
fail to do that due to the lack of time, go on with Eclipse-Warnings, WDYT?
(maybe [~mmuzaf] can help there as well). I have ErrorProne configured already
on some other project hence confirming it works or not should not be super hard.
{quote}
Sounds good to me. I need also ecj updated for Java UDFs but last time I
checked that wasn't an issue...while with eclipse-warnings and the standalone
compiler I am still suffering.
About ErrorProne - looking [here|https://errorprone.info/docs/installation], it
seems it supports newer jdk versions but....sigh...expects more add-exports to
be added for JDK internals access.
{quote}My biggest concern with SpotBugs is that it has limited support for the
jdk versions it runs on, which could cause us the same problems in the future
as we have now with the eclipse-warnings. These pros and cons should be
carefully investigated, so I just switched to the Sonar task as it has almost
no doubts (I used changes from CASSANDRA-18077 to do checks locally).
{quote}
Totally agree with this concern. I also shared it on CASSANDRA-18077 some time
ago. Trying to search I found only these 4 issues to support JDK17 EA
[https://github.com/spotbugs/spotbugs/issues?q=is%3Aclosed+label%3AJava-17]
The changelog mentions them but I do not see anything mention explicitly about
- support Java 17. On the other hand the repo is active, there are commits from
yesterday.
> 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
