Java Static Analysis Tools: Best Picks for 2026 (Free & Paid)

A bug found in production costs roughly 6× more to fix than one caught during code review — and a security vulnerability found after a breach costs orders of magnitude more than that. Java static analysis tools are the shift-left mechanism that makes the difference: they scan your source code or bytecode before a single test runs and surface real bugs, security flaws, and style violations in seconds. This guide covers every major static code analysis tool for Java in 2026 — free and commercial — ranked by what they actually catch, how they integrate into CI/CD, and whether they support Java 17 and 21. The static code analysis tools Java teams rely on today span free bytecode scanners, polyglot rule engines, and enterprise platforms, and picking the right combination depends on your risk profile and release cadence. For the broader landscape of static analyzers across all languages, see our companion article on static code analysis tools. For a security-first perspective, our SAST tools guide covers the full DevSecOps context.

What Is Java Static Analysis?

Java static analysis is the automated examination of Java source code or bytecode without executing the program. A static analyzer parses your .java files (or compiled .class files) into an internal representation — most commonly an Abstract Syntax Tree (AST) or a Control Flow Graph (CFG) — and then applies a library of rules to that representation. Findings are reported with file name, line number, severity, and a description of the issue, ready for developers to act on.

The term "java static source code analysis" is sometimes used interchangeably with linting, but it covers a broader spectrum:

• Style enforcement — naming conventions, brace placement, import order (Checkstyle)
• Bug detection — null-pointer dereferences, resource leaks, incorrect API use (SpotBugs)
• Code quality — dead code, copy-paste duplication, cyclomatic complexity (PMD, SonarQube)
• Security analysis — injection sinks, insecure crypto, hardcoded credentials (Semgrep, CodeQL, Snyk Code)
• Compile-time verification — plugging into javac itself to enforce contracts (Error Prone)

Because analysis happens without execution, it catches issues that unit tests miss: vulnerabilities in rarely-executed branches, resource leaks triggered only under specific heap pressure, or security sinks reachable only through an indirect call chain. That combination of broad coverage and zero runtime cost makes modern java code analysis tools the most cost-effective first line of quality defense — and explains why most mature engineering orgs run two or more of them in parallel rather than relying on a single scanner.

Why Java Needs Dedicated Static Analysis Tools

Java's long history — three decades of APIs, frameworks, and idioms — creates a uniquely large surface area for analysis. A generic multi-language linter cannot reason about Java-specific pitfalls. Dedicated java static analysis tools are built around the JVM's semantics and Java's most common failure modes.

The Java-specific bug taxonomy

Java has a well-documented set of recurring bug patterns. Null-pointer dereferences remain the most common production exception despite Java 8's Optional and Java 21's improved null-handling in pattern matching. Resource leaks from unclosed streams and connections are endemic in codebases that predate try-with-resources. Thread-safety issues — double-checked locking, mutable shared state, incorrect use of volatile — cause rare but catastrophic production failures that no test suite reliably reproduces.

Java's ecosystem depth

A Java-aware analyzer understands that String.equals() is not the same as == (a perennial source of bugs — see our deep dive on Java string comparison and String compareTo). It understands that HashMap iteration order is non-deterministic, that SimpleDateFormat is not thread-safe, and that ObjectInputStream.readObject() is a deserialization sink. A generic regex- based linter would miss all of these; a dedicated java source code review tool knows the API semantics.

Java 17 and 21: new patterns, new pitfalls

Modern Java introduces patterns that require updated analysis rules: sealed classes, records, text blocks, pattern matching for instanceof and switch, and virtual threads (Project Loom). A static analyzer that was not updated for Java 17+ will either fail to parse new syntax or produce false positives on correct modern code. This is why Java version support is a first-class evaluation criterion in 2026 — and why it appears as a column in the comparison matrix below.

The cost argument

The NIST report on the cost of software defects (repeatedly cited by IBM and others) estimates that a bug fixed in the coding phase costs $80; the same bug found in production costs $960. For security vulnerabilities, the ratio is worse: the OWASP Top 10 documents classes of vulnerabilities — injection, broken authentication, insecure deserialization — that appear repeatedly in breach post-mortems and that static code analysis for Java reliably catches before deployment.

Top Java Static Analysis Tools for 2026

The following eleven tools represent the current state of the art for java static analysis. They are ordered by community adoption, with free/open-source options first and commercial tools toward the end.

SonarQube

SonarQube is the most widely deployed java code analysis tool in enterprise teams. The Community Edition is free, open-source (LGPL), and self-hosted; it analyzes Java alongside 30+ other languages through a unified web dashboard with quality gates, issue tracking, and code coverage overlays. SonarQube's Java analyzer performs data flow analysis, detects OWASP Top 10 vulnerabilities, tracks technical debt, and measures cyclomatic complexity — all from a single scan.

SonarCloud is the managed SaaS counterpart, starting around $10/month for small teams (pricing tiers scale by lines of code — check SonarQube docs for current rates). Developer Edition and above add branch analysis, security reports, and portfolio views. Java 8 through 21 is fully supported, including records and sealed classes. For teams that want one tool to cover quality, security, and multi-language support, SonarQube is the default starting point.

SpotBugs

SpotBugs is the direct successor to the original FindBugs project (retired in 2016). It analyzes compiled Java bytecode rather than source, which gives it deep visibility into actual JVM behavior. SpotBugs is open-source (LGPL) and supports Java 8 through 21. Its rule set covers bug categories that are uniquely hard to catch in code review: incorrect null comparisons, resource leaks, malicious code vulnerability, performance anti-patterns, and concurrency bugs such as double-checked locking.

The Find Security Bugs plugin extends SpotBugs with 130+ security rules covering OWASP Top 10 and CWE categories — making it a capable lightweight SAST layer for Java without additional licensing cost. False positive rates are low compared to source-based tools because bytecode analysis removes ambiguity from parsed ASTs. SpotBugs integrates with Maven, Gradle, Ant, Eclipse, and IntelliJ IDEA.

PMD

PMD is an open-source (BSD license) java static analysis tool focused on source code quality rather than security. It is exceptionally fast — capable of scanning tens of thousands of lines per second — and ships with hundreds of built-in rules covering unused variables, overly complex methods, incorrect use of equals(), empty catch blocks, and naming convention violations.

PMD's most distinctive feature is CPD — Copy/Paste Detector, which identifies duplicate code blocks across the entire codebase using a token-based algorithm. Duplicate code is a leading indicator of maintenance debt: when the same logic exists in three places and a bug is found in one, the other two are still broken. PMD supports Java 8 through 21, is actively maintained, and integrates with Maven, Gradle, and all major CI systems.

Checkstyle

Checkstyle enforces Java coding standards and style conventions. It is open-source (LGPL) and ships with two preconfigured rule sets: the Google Java Style Guide and the Sun coding conventions. Teams can extend or replace these with custom rules. Checkstyle is not a bug finder — its focus is consistency: brace placement, Javadoc presence, import ordering, line length, and naming conventions.

In practice, Checkstyle is most valuable as a pre-commit gate that keeps style debates out of code review. It integrates with Maven, Gradle, IntelliJ IDEA (via CheckStyle-IDEA plugin), and VS Code (Checkstyle for Java extension). Java 17 and 21 syntax is supported. False positive rate is effectively zero — every violation is a genuine deviation from the configured standard.

Error Prone

Error Prone is Google's open-source (Apache 2.0) java static source code analysis tool that plugs directly into the javac compiler. It reports findings as compiler warnings or errors during the normal build — no separate analysis step required. Because it operates as a javac plugin, it has the same AST access as the compiler itself, enabling precise, low-false-positive detection of patterns like incorrect use of @Nullable, misuse of Java collections API, and improper exception handling.

Error Prone is used extensively within Google's codebase and is battle-tested across billions of lines of Java. It supports custom checks via the BugChecker API, making it extensible for project-specific patterns. The trade-off: it requires integrating into the Maven or Gradle build configuration, and findings must be suppressed with @SuppressWarnings annotations — a discipline overhead that smaller teams may find friction-heavy.

Infer (Meta)

Infer is Meta's open-source (MIT license) static analyzer, originally developed for Facebook's mobile apps and now widely used for Java and Android analysis. Infer's distinctive approach is bi-abduction: a form of abstract interpretation that automatically infers pre- and post-conditions of methods, allowing it to track null-pointer dereferences and resource leaks across interprocedural call chains that other tools would miss.

Infer shines on large codebases with deep call graphs — it has found critical bugs in codebases of tens of millions of lines. It supports Java, Kotlin, C, C++, and Objective-C. The limitation: Infer is heavyweight to run (it instruments the build), produces a higher false positive rate than SpotBugs on typical enterprise codebases, and has steeper CI integration complexity. Java 17 support is available; Java 21 compatibility should be verified against the current release.

Coverity (Black Duck)

Coverity is a commercial static analysis platform owned by Clearlake Capital Group and Francisco Partners (formerly part of Synopsys), used by defense, financial services, and automotive organizations with strict compliance requirements. Its Java analysis engine performs interprocedural data flow analysis with a proprietary approach that minimizes false positives — Coverity's low false positive rate is one of its primary selling points in enterprise procurement conversations.

Coverity supports Java 8 through 21 and produces findings mapped to CWE, CERT-J, and OWASP categories. It includes an Audit IDE plugin for developer-facing review and integrates with Jira, Jenkins, and Azure DevOps. Pricing is enterprise (contact sales); it is not cost-effective for teams that can achieve adequate coverage with open-source alternatives.

Qodana (JetBrains)

Qodana is JetBrains' static analysis platform built on the IntelliJ IDEA analysis engine — the same engine powering the inspections developers see while coding. This means findings in CI exactly match IDE warnings, eliminating the "works on my machine" disconnect between local and pipeline analysis. The Community tier is free; Qodana Ultimate adds security-focused inspections and license compliance checking.

For teams already using IntelliJ IDEA, Qodana is a natural fit because zero reconfiguration is needed: the same inspection profile used locally runs in CI. Qodana supports Java 8 through 21 via its Docker image (jetbrains/qodana-jvm), integrates natively with GitHub Actions and TeamCity, and produces results in SARIF format. It is an excellent java source code review tool for IntelliJ shops.

Semgrep

Semgrep is a polyglot, open-source (OSS tier) pattern-based static analyzer that has become popular for its balance of speed and customizability. Rules are written in YAML that mirrors the code pattern you want to match — no AST traversal code required. The Semgrep Registry contains hundreds of Java rules covering OWASP Top 10, Spring Security pitfalls, and common Java antipatterns.

Semgrep OSS is free; Semgrep Pro adds cross-file and cross-function taint analysis that closes the gap with commercial tools for security findings. For teams writing custom security rules — for example, enforcing internal API usage patterns or detecting calls to deprecated encryption methods — Semgrep's syntax is the most accessible of any major java static analysis tool. Java 17 and 21 are supported.

Snyk Code

Snyk Code is the SAST component of the Snyk developer security platform. It uses a proprietary semantic analysis engine trained on millions of vulnerability fixes to produce results with lower noise than traditional rule-based scanners. Snyk Code analyzes Java (plus JavaScript, TypeScript, Python, Go, C#, and others) and surfaces findings inline in VS Code and JetBrains IDEs with suggested fix snippets.

Snyk Code offers a free tier for small teams and open-source projects. Its strength is developer experience: findings come with natural-language explanations, code examples of the fix, and links to relevant CVEs or CWEs. For Java-heavy teams that also want software composition analysis (SCA) for dependency vulnerabilities, the Snyk platform covers both in a single tool. Java 17 and 21 are fully supported.

CodeQL (GitHub Advanced Security)

CodeQL is GitHub's semantic static analysis engine, originally developed by Semmle. It models your Java codebase as a relational database and lets you express vulnerability queries in its own query language (QL), enabling highly precise interprocedural analysis that traces tainted data from source to sink across multiple files and class boundaries. CodeQL is free for public GitHub repositories; it is included in GitHub Advanced Security for private repositories (contact GitHub for pricing).

Enabling CodeQL for a Java project requires adding a single GitHub Actions workflow file. Results appear as code scanning alerts on pull requests, integrating tightly into the review workflow. CodeQL supports Java 8 through 21 and is regularly updated with new query packs covering the latest OWASP and CVE patterns. Security researchers use CodeQL to discover zero-days in major open-source Java projects — it is the highest-precision open-source java code analysis tool available.

Java Static Analysis Tools Comparison Matrix

Use this matrix to compare the top static code analysis tools for Java across the dimensions most relevant to your decision: license, pricing tier, primary focus, CI/CD integration, Java 17/21 support, and relative false-positive rate. Modern analyzers have converged on SARIF output and IDE-first UX, so switching between them is cheaper than it was five years ago — another reason to benchmark your options rather than locking in on a single vendor.

Pricing is approximate as of 2026 and subject to change — verify current tiers with vendors before purchasing. False-positive rates are relative and depend heavily on rule configuration and codebase characteristics.

Open-Source vs Commercial: Decision Framework

The most common question teams ask when evaluating java static analysis tools is whether the free options are good enough. The honest answer: for the majority of Java projects, they are — but with important caveats. Work through these five decision points to find your answer.

1. Team size and scanning volume

Open-source tools (SonarQube Community, SpotBugs, PMD, Checkstyle, Semgrep OSS, CodeQL for public repos) impose no per-seat or per-scan cost. If you are a team of 1–20 developers with a self-hosted CI environment, the operational cost of running these tools is a few hours of initial setup. Commercial tools (Coverity, Snyk Code Pro, Semgrep Pro, SonarCloud paid tiers) become cost-competitive when the engineering time saved on false-positive triage, compliance report generation, and integration maintenance exceeds the licensing cost.

2. Compliance and audit requirements

Organizations subject to PCI-DSS, HIPAA, FedRAMP, or ISO 27001 often need static analysis findings mapped to specific control frameworks, with audit trails, historical trending, and suppression workflows documented for auditors. Commercial tools — particularly Coverity and the paid tiers of SonarQube — are purpose-built for this. Open-source tools can meet compliance requirements, but you will need additional tooling to generate the required reports and evidence packages.

3. False-positive tolerance

False positives are the primary driver of developer resistance to static analysis. A tool that produces 500 findings of which 80% are noise will quickly be ignored. Bytecode analyzers like SpotBugs have lower false-positive rates than source-based tools because bytecode is unambiguous. Commercial tools with proprietary tuning (Coverity, CodeQL) also achieve very low rates. If your team has a low tolerance for triage overhead, start with SpotBugs + CodeQL (for public repos) before layering in higher-volume tools.

4. Language and framework specificity

If your Java codebase is a standard Spring Boot or Jakarta EE application, every tool on this list will serve you well — the Java ecosystem is comprehensively covered. If you use unusual frameworks (microprofile, Quarkus extensions, custom bytecode manipulation), verify that your chosen tool's rule set understands the framework before committing.

5. IDE integration and developer experience

The fastest feedback loop is in the IDE — findings surfaced as you type, before a commit is made. SonarLint (SonarQube's IDE extension), Snyk Code's IDE plugins, Qodana's IntelliJ integration, and Error Prone's javac plugin all provide this. If your team uses IntelliJ IDEA, Qodana is the most seamless transition from local analysis to CI analysis with zero configuration drift. For VS Code users, Snyk Code or SonarLint are the leading options.

What Each Tool Actually Catches (Real Java Examples)

Abstract descriptions of rule categories matter less than understanding what a tool will flag in your actual code. Here are three concrete Java code patterns and which tools catch them. Note that in Astro templates, curly braces in code blocks are escaped as { and } to prevent Astro from interpreting them as expressions.

Example 1: Null-pointer dereference (SpotBugs, Infer, SonarQube)

public String getUserDisplayName(Long userId) {
    User user = userRepository.findById(userId).orElse(null);
    // SpotBugs: NP_NULL_ON_SOME_PATH — user may be null here
    return user.getFirstName() + " " + user.getLastName();
}

SpotBugs detects this via its NP (Null Pointer) bug category — it traces the assignment of null from orElse(null) and flags the subsequent field access. Infer catches it through its bi-abduction interprocedural analysis. SonarQube flags it under rule java:S2259 (NullPointerException). The fix — using orElseThrow() or checking for null before use — is exactly the kind of change you want to verify with a diff tool after applying it.

Example 2: SQL injection via string concatenation (CodeQL, Semgrep, Snyk Code)

public List<User> searchUsers(String nameFilter) throws SQLException {
    // CodeQL: sql-injection — user input flows to SQL query without sanitization
    String query = "SELECT * FROM users WHERE name = '" + nameFilter + "'";
    return jdbcTemplate.query(query, new UserRowMapper());
}

CodeQL traces the tainted data flow from the nameFilter parameter (a source) through string concatenation to the jdbcTemplate.query() call (a SQL execution sink), flagging it as CWE-89. Semgrep catches it with a Java JDBC injection rule. Snyk Code detects it via its ML-trained vulnerability model. The correct fix is parameterized queries — a change that is trivially verifiable with a side-by-side diff of the before and after.

Example 3: Unclosed resource / stream leak (SpotBugs, SonarQube, Error Prone)

public byte[] readFileContents(String path) throws IOException {
    // SpotBugs: OBL_UNSATISFIED_OBLIGATION — FileInputStream not closed
    FileInputStream fis = new FileInputStream(path);
    return fis.readAllBytes();
    // fis.close() never called — leaks file descriptor under exceptions
}

SpotBugs flags this as OBL_UNSATISFIED_OBLIGATION — an obligation to close the stream that is never satisfied. SonarQube reports rule java:S2095 (resources should be closed). The fix is a try-with-resources block: try (FileInputStream fis = new FileInputStream(path)) { return fis.readAllBytes(); }. PMD's CloseResource rule also catches this variant. For a cross-language comparison of equality and type comparison patterns, see our guide on equal sign in JavaScript — the contrast between Java's explicit resource management and JavaScript's garbage collection illustrates why Java-specific analysis rules are necessary.

Integrating Java Static Analysis into CI/CD

The effectiveness of java static analysis depends entirely on when and how it runs in your pipeline. A scan that runs but whose results no one acts on is not static analysis — it is security theater. The following four-stage architecture gives every finding an appropriate response loop.

Stage 1: Pre-commit (developer's machine)

Install SonarLint, Snyk Code, or the Qodana IntelliJ plugin in developers' IDEs. These surface findings in real time as code is written, before any commit is made. For style enforcement, add Checkstyle to the project's Gradle or Maven build so it runs on gradle check locally. Error Prone runs automatically as part of mvn compile once configured. This stage has zero CI cost and closes the feedback loop in seconds.

Stage 2: PR gate (fast, blocking)

On every pull request, run a fast subset of tools as a required status check. SpotBugs and PMD complete in under two minutes on most codebases and can be added as Maven Enforcer or Gradle verification tasks. The key discipline: configure tools to fail only on new issues introduced by the PR, not on pre-existing baseline findings. SonarQube's "new code" period mode does this automatically. For a GitHub Actions example with Semgrep:

name: Java Static Analysis
on:
  pull_request: {}
jobs:
  semgrep:
    runs-on: ubuntu-latest
    container:
      image: semgrep/semgrep
    steps:
      - uses: actions/checkout@v4
      - run: semgrep ci --config "p/java" --sarif --output semgrep.sarif
      - uses: github/codeql-action/upload-sarif@v3
        with:
          sarif_file: semgrep.sarif

Stage 3: Deep nightly scan

Schedule a full-codebase CodeQL analysis or SonarQube scan nightly against the main branch. Deep interprocedural analysis takes longer — CodeQL can take 20–60 minutes on a large Java monorepo — so it should not block PR pipelines. Nightly scans also catch vulnerabilities introduced by rule updates: a new CodeQL query pack may surface issues in unchanged code that was not in scope for any recent PR.

Stage 4: Maven and Gradle integration patterns

For Maven projects, add SpotBugs and PMD to the <reporting> section of your POM to generate HTML reports on mvn site, or add them to the <build><plugins> section with <failsOnError>true</failsOnError> to block the build. For Gradle, apply the com.github.spotbugs and PMD plugins in build.gradle and wire them to the check lifecycle task. Checkstyle has first-class support in both build tools through official plugins.

Reviewing Analysis Results with Code Diff Tools

Running a java static analysis tool produces a list of findings. The next step is remediation — and that is where code diff tools earn their place in the workflow. When you apply a fix suggested by SpotBugs or SonarQube, verifying the exact change boundary is critical: you want to confirm that the fix addresses the flagged issue, does not introduce a regression, and does not accidentally change surrounding logic.

This is the exact workflow that finding the difference between two versions of a file is designed for. A side-by-side diff of the pre-fix and post-fix versions of a Java class makes it immediately clear whether the null-check was added in the right place, whether the SQL query was properly parameterized, or whether the try-with-resources block actually wraps all the relevant resource allocations.

This matters especially in code review: reviewers triaging static analysis findings often need to see the original code and the fix side by side, not just the final state. A browser-based diff tool lets reviewers paste both versions and instantly see the delta without checking out the branch locally.

Best Practices for Java Static Analysis in 2026

The teams that get the most value from java static analysis tools follow a consistent set of operational practices. Whether you run lightweight java static source code analysis on every commit or full interprocedural scans nightly, the same discipline separates noise from signal. Here are the eight that matter most.

1. Start with a baseline, not a clean slate

When you introduce static analysis to an existing Java codebase, you will likely find hundreds or thousands of existing findings. Do not try to fix them all before enabling the gate — you never will. Instead, establish a baseline snapshot and configure tools to fail only on findings introduced after a specific date or commit. SonarQube's "new code" period, Semgrep's --baseline-commit flag, and SpotBugs' XML output with diff-based comparison all support this pattern.

2. Layer tools by purpose, not by redundancy

Running three bug-finding tools with overlapping rule sets produces duplicate findings and inflates noise. A well-layered Java analysis stack looks like: Checkstyle (style) + SpotBugs (bugs) + PMD (quality + CPD) + SonarQube or Semgrep (security + quality overview). Add CodeQL for deep security analysis on critical services. Each tool has a lane; they do not compete.

3. Tune aggressively before rollout

Every major java code analysis tool ships with more rules than any team needs. Start with the minimum rule set — SpotBugs' CORRECTNESS category, PMD's errorprone and bestpractices rule sets, Checkstyle's Google profile. Add rules incrementally as you develop familiarity with the tool. A team that ships with 20 high-signal rules enforced consistently is more effective than one that ships with 200 rules, 160 of which are suppressed.

4. Integrate findings into the developer workflow, not a separate portal

Static analysis that requires developers to log into a separate dashboard to check findings will be ignored. Wire findings to pull request comments (GitHub, GitLab), IDE inspections (SonarLint, Snyk Code), or build failure messages with file-and-line context. The faster and closer to the developer the feedback loop, the higher the remediation rate.

5. Track metrics over time

A single scan is a snapshot. The signal is trend: Is the count of Critical SpotBugs findings decreasing sprint over sprint? Is the mean time between introduction and remediation of a High SonarQube issue under one week? SonarQube's quality gate history, Semgrep's finding trends, and exported SARIF data parsed into a dashboard all serve this purpose. Metrics make the business case for continued investment in static code analysis for Java.

6. Suppress findings with documented rationale

Every tool supports suppression of false positives. Do it properly: file-level suppression with a comment explaining why the finding is not applicable (@SuppressWarnings("SpotBugs") // reason: ...) is far better than global rule disabling. Track suppressions in code review so they are visible to the team and periodically reviewed for continued validity.

7. Keep tools updated

Static analysis rule sets are updated frequently as new CVE patterns, Java API misuse patterns, and CWE categories are identified. SpotBugs 4.x, PMD 7.x, and SonarQube's Java analyzer each receive regular rule updates. Running a two-year-old version of SpotBugs against Java 21 code will miss modern patterns. Pin tool versions in your build configuration, review changelogs quarterly, and update intentionally.

8. Combine static analysis with complementary techniques

Java static analysis tools catch code-level issues but do not detect third-party dependency vulnerabilities (use OWASP Dependency-Check or Snyk SCA), runtime configuration errors (use DAST), or infrastructure misconfigurations (use IaC scanners). A layered security posture — SAST + SCA + DAST — provides coverage at each layer of the stack. Our companion guide on SAST tools covers how these layers fit together in a DevSecOps pipeline.

Frequently Asked Questions

What is Java static analysis?

Java static analysis is the automated examination of Java source code or bytecode without executing the program. Tools parse your code into an AST or CFG and apply rule sets to detect bugs (null-pointer dereferences, resource leaks), security vulnerabilities (SQL injection, insecure crypto), style violations, and dead code. Because no execution is required, java static source code analysis runs cheaply in CI and catches issues that unit tests miss — particularly in code paths that are rarely exercised.

What is the best free Java static analysis tool?

For most teams, SpotBugs is the best free java static analysis tool for finding real runtime bugs — it catches null-pointer dereferences, resource leaks, and concurrency issues in compiled bytecode with a low false-positive rate. SonarQube Community Edition is the best free option for a full quality dashboard with multi-language support. CodeQL (free for public GitHub repositories) provides the deepest security analysis. For style enforcement, Checkstyle and PMD are the standards.

Does SonarQube support Java 17 and Java 21?

Yes. SonarQube's Java analyzer supports Java 8 through Java 21, including sealed classes, records, pattern matching for switch, and virtual threads introduced in Java 21 (Project Loom). The SonarQube scanner uses its own parser rather than the JDK compiler, so it can analyze Java 21 code without requiring JDK 21 on the CI agent.

Is static analysis enough for Java security?

No. Java static analysis tools catch code-level vulnerabilities but cannot detect runtime configuration issues, authentication flaws requiring a live environment, or vulnerabilities in third-party dependencies. A comprehensive Java security posture requires static code analysis for Java (SAST), dependency scanning (SCA), dynamic testing (DAST), and, for high-assurance systems, runtime application self-protection (RASP). SAST is the most cost-effective first layer because it runs early and cheaply — before a single container is deployed.

How do I integrate Java static analysis into CI/CD?

Add a fast tool (SpotBugs, PMD, or Checkstyle) as a Maven or Gradle build step that fails on rule violations — this runs on every commit in under two minutes. Add SonarQube or Semgrep as a separate CI stage on pull requests, scoped to new code only, publishing results as PR comments. Schedule a full CodeQL or deep SonarQube scan nightly against main. Keep the PR gate fast by analyzing only changed files; use the nightly scan for whole-codebase interprocedural analysis.

What is the difference between SpotBugs and PMD for Java?

SpotBugs analyzes compiled bytecode and specializes in genuine runtime bugs: null-pointer dereferences, resource leaks, incorrect synchronization, and API misuse. Its findings are high-signal and low-noise. PMD analyzes Java source code and focuses on code quality: unused variables, overly complex methods, naming convention violations, and — via its CPD engine — copy-paste duplicate code. They are complementary: most Java projects benefit from running both. SpotBugs is your bug net; PMD is your code quality auditor.