> 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 <f...@florian-hockmann.de> 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 <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. > >> > > >
