skip to content

Static Analysis Plugins

2 roadmaps6 questions

Binding Checkstyle, PMD, SpotBugs, Spotless, and Error Prone into the verify phase, and deciding when a violation should break the build. Interviewers want to hear how you introduce a linter to a legacy codebase without a thousand-issue first day.

on this pageshow

explore

questions

6

What are static analysis plugins in Maven, and how do you make one (e.g. Checkstyle) actually run during your build?

level: juniorimportance: must knowfreq 55%

answer

  1. plugin + execution + phase + goal
  2. check goal fails, report goal doesn't
  3. verify in CI
  4. configLocation / rules file
  5. SpotBugs needs bytecode

basics

~20 s

Static analysis plugins inspect source/bytecode for style and bug issues without running it. You add the plugin to your pom and bind its check goal to a build phase (often verify) inside an <execution> so mvn verify runs it automatically.

solid answer

~30 s

Static analysis tools (Checkstyle, PMD, SpotBugs, Spotless) examine code without executing it to catch style violations, bugs, and security smells. In Maven you add the plugin under <build><plugins>, then add an <execution> with an <id>, a <phase> (commonly verify), and the <goal> to run (e.g. checkstyle:check, pmd:check, spotbugs:check, spotless:check). The bare *:check goals fail the build on violations; the analyze/report goals only produce reports. Binding to a phase means a normal mvn verify enforces the rules in CI, so nobody has to remember to run the tool manually. You typically also point the plugin at a config/rules file and configure failOnViolation/failsOnError.

code

xml · 5 lines
xml
<execution>
  <id>checkstyle-validate</id>
  <phase>verify</phase>
  <goals><goal>check</goal></goals>
</execution>

go deeper

for a junior

Add the plugin, bind its check goal to a phase, run mvn verify.

for a middle

Knows check vs report goals, configLocation, failOnViolation, and that SpotBugs needs bytecode.

for a senior

Chooses phases for fast feedback vs completeness and wires the gate into CI deliberately.

for a principal

Standardizes the tool set and bindings across all repos via a parent/BOM so enforcement is consistent org-wide.

## What is static analysis? Static analysis means inspecting code *without running it* to find problems: formatting/style issues, likely bugs, anti-patterns, and security smells. It contrasts with dynamic analysis (unit tests, profilers) which run the program. In a Maven project these tools are delivered as **plugins**. ## The Maven plugins in this space - **maven-checkstyle-plugin** — enforces coding *style* (naming, imports, braces, Javadoc) from a Checkstyle ruleset XML. - **maven-pmd-plugin** — finds *code smells / likely bugs* from source (unused vars, empty catch, complexity) and also runs CPD (copy-paste detector). - **spotbugs-maven-plugin** — analyzes *bytecode* for bug patterns; plug in **find-sec-bugs** for security findings. - **spotless-maven-plugin** — a *formatter*; can auto-fix (spotless:apply) or just verify (spotless:check). - **error-prone** — not a standalone Maven plugin; it hooks into javac as a compiler plugin via maven-compiler-plugin, catching bugs at compile time. ## Report goal vs check goal Each tool usually has two kinds of goals: - a *report/analyze* goal (e.g. `checkstyle:checkstyle`, `pmd:pmd`, `spotbugs:spotbugs`) that produces an HTML/XML report and does **not** fail the build; - a *check* goal (e.g. `checkstyle:check`, `pmd:check`, `spotbugs:check`, `spotless:check`) that **fails** the build when violations exist. ## Binding to a phase Maven runs **goals** during lifecycle **phases**. To enforce a tool automatically you bind its check goal to a phase using an `<execution>`: ```xml <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-checkstyle-plugin</artifactId> <version>3.6.0</version> <configuration> <configLocation>config/checkstyle.xml</configLocation> <failOnViolation>true</failOnViolation> <consoleOutput>true</consoleOutput> <violationSeverity>warning</violationSeverity> </configuration> <executions> <execution> <id>checkstyle-validate</id> <phase>verify</phase> <goals><goal>check</goal></goals> </execution> </executions> </plugin> ``` Now `mvn verify` runs Checkstyle and fails on violations — perfect for CI gates. People debate `validate` (very early, fast feedback) vs `verify` (after tests). Style/format checks are cheap so `validate` gives fast failure; bytecode tools like SpotBugs need compiled classes so they bind around `compile`/`verify`.

  • Why bind to verify instead of just running checkstyle:check manually?
    Binding makes it run on every build/CI without anyone remembering, so violations gate merges automatically rather than relying on developer discipline.
  • Which of these tools needs compiled classes rather than source?
    SpotBugs analyzes bytecode, so it must run after compilation; Checkstyle and PMD work on source.

saying these in an interview costs you the question

  • Confusing the report goal (checkstyle:checkstyle) with the failing check goal (checkstyle:check)
  • Thinking adding the plugin alone enforces rules — without an <execution> bound to a phase it only runs when invoked by hand

context

resolving links…

open as a page

How do you make a static analysis plugin actually break the build on violations, and what knobs control that behavior?

level: middleimportance: must knowfreq 50%

basics

~10 s

Use the *:check goal (not the report goal) and keep its failure flag on: maven-checkstyle-plugin/maven-pmd-plugin use failOnViolation=true, spotbugs uses failOnError=true. Bind it to a phase like verify so mvn verify fails when violations exist.

open as a page

How do SpotBugs and find-sec-bugs differ from Checkstyle/PMD, and how do you wire them up in Maven?

level: middleimportance: should knowfreq 40%

basics

~20 s

Checkstyle and PMD read your source code; SpotBugs reads compiled bytecode, so it must run after compilation. find-sec-bugs is a SpotBugs plugin adding security bug patterns. You add it under the spotbugs plugin's <plugins> and run spotbugs:check.

open as a page

How do Spotless and Error Prone fit into a Maven build, and how do they differ from check-only linters?

level: seniorimportance: should knowfreq 30%

basics

~20 s

Spotless is a formatter: spotless:apply rewrites files to a standard format, spotless:check fails the build if they aren't formatted. Error Prone isn't a plugin — it plugs into javac via maven-compiler-plugin and fails compilation on bug-pattern findings.

open as a page

How do you handle false positives and legacy violations across these tools without disabling the gate, and how does baselining/suppression work per tool?

level: seniorimportance: should knowfreq 35%

basics

~20 s

Use each tool's targeted suppression instead of turning failures off: Checkstyle SuppressionFilter XML or @SuppressWarnings, PMD ruleset excludes or @SuppressWarnings("PMD.x"), SpotBugs excludeFilterFile or @SuppressFBWarnings. For legacy code, ratchet with a baseline or maxAllowedViolations so only new violations fail.

open as a page

How would you standardize and govern these static analysis gates across a large multi-module Maven project so rules stay consistent and enforceable?

level: principalimportance: nice to knowfreq 22%

basics

~20 s

Define plugin versions and configuration once in a parent POM (pluginManagement) so all modules inherit identical gates, share rule/suppression files (often packaged in a shared artifact), and bind check goals to verify so CI enforces them uniformly. Avoid per-module drift.

open as a page