Another option might be to use Coverity - https://scan.coverity.com/faq - and run it in Travis CI
Robert Dale On Wed, Mar 21, 2018 at 9:43 AM, Stephen Mallette <[email protected]> wrote: > > I think any proposed changes would be separate PRs and reviewed on a > case-by-case > basis. > > yeah - i think if we want something like this the goal should first be to > decide on a tool (i can't say that i agree with Roman that "running more > tools is always better" btw). note i'm still saying, "if we want something > like this" because while i'm not against it I'd like to be convinced that > we need to worry about this now at this stage of TinkerPop's development. > i'd have been more inclined to deal with this early on in TinkerPop's > development rather than now. And, yes, also agree that i would like to see > the tool in first and then each introduction of "rule" be a separate > discussion and PR. > > > 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. > > yeah....that might be a smart way to go > > > 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. > > very good thought. while the bulk of our code is java, we are far from a > single language code base. if there is one tool that can give us some nice > clean analysis across the entire code base, perhaps that's the best way to > go (again, "if we want something like this"). > > > > > On Tue, Mar 20, 2018 at 8:41 AM, Florian Hockmann <[email protected]> > wrote: > > > 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 <[email protected]> > > 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. > > >> > > > > > > >
