In general, I am +1 on adding a static analysis tool to our tool chain. I just wonder whether a Java compiler is the best choice for us right now or whether other static analysis tools would find most of the problems that such a compiler can find and also work with other languages than Java. SonarQube[1] for example looks pretty nice. It also supports Python, C#, and JavaScript and we can probably just integrate it via GitHub to generate reports for the release branches and all PRs where it would then add issues in the form of inline comments.
[1] https://www.sonarqube.org/ Am 20.03.2018 um 03:42 schrieb Robert Dale: > Some changes look good others look wrong evident by the failed builds. I > think any proposed changes would be separate PRs and reviewed on a > case-by-case basis. As for making it the default compiler, I think this > would be a profile, disabled by default, at best at least until a time it > can be massaged to where it works for this project. > > On Mon, Mar 19, 2018 at 14:59 Roman Leventov <leventov...@gmail.com> wrote: > >> See https://github.com/apache/tinkerpop/pull/819. >> >> 1) Are there any objections to using error-prone compiler instead of >> OpenJDK's javac compiler? >> 2) Stephen raised the question, that Tinkerpop project may better use >> another static analysis tool instead of error-prone. I have to answer that >> no static analysis tool covers 100% of the errors found by any other tool, >> so running more tools is always better. >> 3) Stephen raised the question, what checks should be enabled. I believe >> this is out of scope of the PR ( >> https://github.com/apache/tinkerpop/pull/819), >> because it doesn't (and doesn't intent to) enable any more checks beyond >> the default (= minimal) set of error patterns. More checks may or may not >> be enabled in later PRs and that could be discussed separately. >>
