Integrating Native Static Analyzers: detekt, SpotBugs, Rosly

Running a linter by hand is easy. Running five of them from a program, over code you did not write, on a machine you do not control, and getting back findings someone will act on — that is a different job.

This is what five integrations taught.

The split that decides everything is what the analyzer eats. Source (detekt, Bandit, ESLint) answers while the developer is typing. Compiled bytecode (SpotBugs) means the project must already be built and you have to find the output yourself. A full build (Roslyn) takes minutes and can fail for reasons unrelated to your scan — and still produce a valid report.

· Every general-purpose analyzer must be narrowed, and you only learn how by scanning somebody else's codebase. One default-on ESLint rule produced 31 of 33 findings on express; SpotBugs' non-security detectors produced 5 of 5 on spring-petclinic. · SARIF as the common format, and where each tool bends it — including the MSBuild escaped comma that silently downgrades Roslyn to SARIF v1 and makes every message parse as empty, with no error · Never build a .sln directly: every project writes to the same ErrorLog, only the last survives, and it is usually a test project · ESLint only lints under its working directory — point it elsewhere and you get zero findings and no error, the most confusing failure in this area · What an analyzer can see without type resolution, and why SpotBugs sees more but costs a build and dependency jars · Isolation: configuration on the command line, caches redirected, reports in temp, the user's project never modified

Per-analyzer reference with the exact invocation, narrowing flag, output format and traps for all five. Normalisation reference covering severity scales, rule ids, percent-encoded paths, and the CWE field that exists on some tools and hides inside the message on others.