The best Java code analysis tools fall into two groups. Static tools like SonarQube, PMD, SpotBugs, and Checkstyle check how your code is written before it ships. Runtime analysis like Azul Intelligence Cloud shows you which code actually runs in production. You’ll usually want one of each.
| # | Tool | Best For | Starting Price |
|---|---|---|---|
| 1 | Azul Intelligence Cloud | Finding dead code in production | Quote on request |
| 2 | SonarQube | One quality bar across every repo | Free; Cloud Team from $34/month |
| 3 | PMD | Rules you can tune or write yourself | Free |
| 4 | SpotBugs | Catching likely bugs in the build | Free |
| 5 | Checkstyle | Enforcing one coding standard | Free |
Why Java Teams Need More Than One Kind of Code Analysis
In our 2026 State of Java survey, 63% of the 2,039 respondents said dead and unused code affects their team’s productivity. Only 6% said it has no impact.
Static analysis tools catch bugs, style problems, and unused private methods before code ships. But they read code without running it. That means they can’t tell whether a public method, or a class your framework calls through reflection, has run in production this year. So which tool checks what, and which ones does your team need?
Analyze Your Java Code With Azul
We’re the only vendor 100% focused on Java, and we were founded in 2002. Today, we power mission-critical Java systems for 37% of the Fortune 100 and the world’s top 10 financial trading firms. InfoWorld named Intelligence Cloud, the runtime tool on this list, Technology of the Year for DevOps Analytics in 2024 and 2025.
After switching to Azul Prime, Workday reduced total pause time per JVM from 40,000 seconds per week to 14 seconds per week. We build JVMs for a living, so we’ll be upfront about where a static tool is the better pick.
What Is Java Code Analysis?
Java code analysis means checking your Java code for bugs, style problems, duplicated logic, or code that never runs. It comes in two kinds, each answering a different question.
Static analysis reads your source code or compiled bytecode without running the program. It tells you whether the code could break and whether it follows your rules. And since it doesn’t need a running app, it fits right into your IDE and CI build.
Runtime analysis, also called dynamic analysis, collects data from the JVM while your application runs. It tells you whether the code ran at all, which only production traffic can answer.
Think of static analysis as an inspector checking a building’s blueprints. Runtime analysis is the badge log that shows which rooms people actually use.
Why Is Java Code Analysis Important?
Bugs get caught before review. SpotBugs alone checks every build against more than 400 bug patterns.
Style stops being a debate once a shared config settles naming and formatting, so reviewers can focus on logic.
Every merge meets one bar. A quality gate can block a pull request whenever new code misses your team’s conditions.
Dead code stops costing you. Until you find it, an unused class still gets read, tested, and carried through every Java upgrade.
Modernization gets smaller, because you can plan a monolith split or migration around the code that runs.
How We Evaluated These Java Code Analysis Tools
No single tool answers every question about your code. So we judged each one by the question it’s built to answer. Does the code follow your rules, is it likely to break, or does it run at all? We then compared the tools on six criteria:
Analysis type: Does it read source code, compiled bytecode, or live JVM data? That decides what the tool can see and where it fits in your pipeline.
Dead-code coverage: Does it stop at unused private members and local variables, or can it confirm that public methods and framework-wired code never ran? This is where static and runtime tools differ most.
Accuracy and noise: How often does it flag code that’s actually in use? We checked what each tool’s own docs say about reflection, frameworks, and false positives.
Build and IDE fit: Does it plug into Maven, Gradle, CI, and the IDEs your team already uses? A check that runs on every build is harder to ignore than a report someone has to open.
Rule control: Can you start from a ready-made config, tune the rules, and write your own? Teams sharing one standard need room to adjust it.
Cost at scale: What does it cost once you cover every repo, line of code, or JVM? We used each vendor’s published pricing and noted where prices are quoted per customer.
5 Best Java Code Analysis Tools
We picked these five to cover every layer, from source style to compiled bytecode to live JVMs.
| # | Tool | Analysis type | What it checks | Best for | Starting price |
|---|---|---|---|---|---|
| 1 | Azul Intelligence Cloud | Runtime | Which classes and methods ran in production | Finding dead code in large codebases | Quote on request |
| 2 | SonarQube | Static (source plus bytecode) | Bugs, code smells, duplication, technical debt | One quality bar across every repo | Free; Cloud Team from $34/month |
| 3 | PMD | Static (source) | 400+ rules for common flaws, plus duplicate code | Rules you can tune or write yourself | Free |
| 4 | SpotBugs | Static (bytecode) | 400+ bug patterns | Catching likely bugs in the build | Free |
| 5 | Checkstyle | Static (source) | Naming, imports, formatting, Javadoc | Enforcing one coding standard | Free |
1. Azul Intelligence Cloud
Azul Intelligence Cloud is a SaaS service that uses runtime data from your JVMs to show you which Java code runs in production. It does a few jobs, but here we’re focusing on the one that matters for code analysis: Code Inventory.
Code Inventory records the first time each method runs inside the JVM, and collects that data with no performance penalty. Over weeks and months, that builds a record of what your applications use across every JVM you connect, without any code changes.
Static tools can only take you so far. SonarQube, PMD, and SpotBugs all flag an unused private method, but their own docs warn that reflection and frameworks can hide who’s calling it. In a peer-reviewed study by Haas et al., only 32% of the UCDetector plugin’s dead-code warnings pointed to code developers agreed was unnecessary.
In practice, you pick a time window and pull a Code Inventory report for it. Then you compare it against your repo. Anything in your source that’s missing from the report didn’t execute in that window, so it’s a candidate for removal. For code that only runs at year-end, stretch the window to a full cycle before you delete anything.
Key Features
Unused code reports: Filter to used or unused code, grouped by JAR, class, or method.
Method-level tracking: Switch on two agent flags when class-level data isn’t detailed enough.
Any-JVM agent: Connect Java 8+ JVMs from Oracle, Amazon, Microsoft, Red Hat, Temurin, or older Azul versions.
Forwarder: Route data from many JVMs through one proxy, so no JVM connects to the internet directly.
JVM Inventory: Catalog every connected JVM with its vendor, version, install path, and application.
AI Assistant: Ask plain-English questions like “What code hasn’t run in the past four quarters and is safe to remove?”
REST API and CLI: Pull Code Inventory data into your own dashboards and scripts.
Pricing
We don’t publish Intelligence Cloud pricing, since it’s quoted per customer. Book a demo to get a quote and see Code Inventory on your own JVMs.
Pros
Catches unused public and framework-wired code, which private-only dead-code rules can’t see.
One report covers your whole estate, whichever vendor built each JVM.
You’ll have production evidence before anyone deletes a line.
Cons
Doesn’t check style or flag bugs, so you’ll still want a static tool in your build.
On non-Azul or older Azul JVMs, you’ll run Azul’s agent, which can use up to 10% of your application’s memory.
Rarely run code, like a year-end job, won’t show up as used without a long observation window.
2. SonarQube
SonarQube is an automated code review and static analysis platform for 40+ languages, with 650+ rules for Java. Unlike PMD or Checkstyle, which report problems within a single build, SonarQube keeps results across every project, branch, and pull request. That’s useful when several teams share one standard.
For Java, it reads your source plus the compiled .class files, so analysis runs after your Maven or Gradle build.
Key Features
Quality gates: Block a pull request merge or fail the CI pipeline when new code misses your conditions.
Branch and pull request analysis: Scan every branch and pull request automatically as code is pushed.
SonarQube for IDE: Catch the same issues in VS Code, IntelliJ, or Eclipse as you type, for free.
Technical debt tracking: Follow maintainability and reliability trends across your whole codebase.
Pricing
Community Build: free and open source
SonarQube Cloud: free up to 50k lines of code; Team plan from $34/month for up to 100k lines
SonarQube Server: priced per instance per year by lines of code; contact sales
Pros
Quality gates turn your standards into a merge check, so nobody has to police it.
The free IDE extension flags issues before you commit.
One dashboard shows debt trends for every project.
Cons
Java analysis needs compiled classes, so it can’t run on raw source alone.
SonarQube Cloud’s free plan caps private projects at 50k lines of code, so larger codebases need a paid plan.
Its unused-method and unused-field rules only cover private members.
3. PMD
PMD is a free, open-source static code analyzer with 400+ built-in rules for flaws like unused variables and empty catch blocks. It’s a good fit when you want rules you can tune or write yourself.
Unlike SpotBugs, which reads bytecode, PMD parses your source into an abstract syntax tree and runs its rules against that. That means you can write a new rule as a short XPath query in your ruleset XML, without building a Java plugin.
Key Features
Copy/Paste Detector (CPD): Find duplicated code across a large project.
Java rule categories: Pick rules from Best Practices, Design, Error Prone, Multithreading, Performance, and more.
Build integration: Run PMD as a Maven goal, Gradle task, or Ant task, and fail the build on violations.
IDE and CI plugins: Check code in Eclipse, IntelliJ IDEA, or VS Code, or with PMD’s own GitHub Action.
Pricing
Free and open source under a BSD-style license.
Pros
CPD flags copy-pasted blocks before one bug turns into three.
XPath rules let you encode a team convention in your ruleset file.
Covers Java, Apex, and 16 other languages, which helps in a mixed-language repo.
Cons
Its unused-code rules cover private members and local variables, so an unused public method goes unflagged.
With 400+ rules, you’ll need to tune a ruleset or start from PMD’s quickstart set.
4. SpotBugs
SpotBugs is the free, open-source successor to FindBugs. It finds bugs in Java code by scanning compiled bytecode against more than 400 bug patterns.
SpotBugs runs after compilation and focuses on likely mistakes, like correctness and multithreading bugs.
Key Features
Bug pattern library: Check code against categories like Correctness, Bad practice, Performance, and Multithreaded correctness.
Plugins: Add extra detectors through plugins such as fb-contrib.
Build integrations: Run it from Maven, Gradle, Ant, or the command line.
IDE plugins: Review findings in Eclipse, IntelliJ IDEA, or VS Code.
Pricing
Free and open source under the LGPL.
Pros
Catches correctness and multithreading bugs a style checker can’t see.
Hooks into Gradle’s standard check task, so it runs whenever your other checks do.
Supports plugins for extra detectors.
Cons
Won’t run on source alone, since it needs compiled .class files.
Uncalled-method checks only cover private methods.
Doesn’t check naming or formatting, so you’ll need a style tool too.
5. Checkstyle
Checkstyle is a free, open-source tool that checks Java source against a coding standard, covering naming, imports, formatting, Javadoc, and class design.
Checkstyle processes one file at a time and doesn’t build a full inheritance hierarchy. So, as its docs say outright, you can’t write a check that finds unused public methods. That’s why teams run it alongside a whole-program tool like SpotBugs or SonarQube.
Key Features
Ready-made configs: Start from the bundled Google Java Style or Sun Conventions configuration.
Unused-code checks: Flag unused imports, local variables, and private fields.
IDE plugins: Get real-time feedback in Eclipse, IntelliJ IDEA, NetBeans, or VS Code.
Build and CI integration: Run checks in Maven, Gradle, or GitHub Actions.
Pricing
Free and open source under the LGPL v2.1.
Pros
One config file runs the same rules in your IDE, your build, and CI.
The Google config gives you a known standard without writing rules.
Parses all Java language features up to Java 25.
Cons
Checks one file at a time, so it can’t find unused public methods or redundant casts.
Won’t catch bugs the way SpotBugs does, since it sticks to style.
How to Choose the Best Java Code Analysis Tool for Your Business
Before you commit to a single tool, check how well it fits your code, team, and budget. These five factors matter most:
1. The question you need answered: Do you need consistent style, fewer bugs reaching production, or proof of which code still runs? Each is a different kind of analysis. If you need more than one answer, plan for more than one tool.
2. Your codebase’s size and age: A small, active repo may only need a checker in the build. A large or inherited codebase with framework-wired code needs evidence of what actually runs before anyone deletes it.
3. How it fits your workflow: Confirm it supports your build tool, CI pipeline, and the IDEs your team uses. Findings that show up in the pull request are harder to ignore than a report in a separate tool.
4. How much tuning your team can take on: A full rule set can flag thousands of old issues on day one. Look for ready-made configs, checks you can limit to new code, and support for custom rules.
5. Pricing and deployment model: Free tools still cost engineering time to set up and maintain. Paid tools may price by lines of code, instances, or usage. Also check where your code or runtime data goes, and whether that meets your security rules.
Cover Both Questions in Your Java Pipeline
Static tools tell you whether your Java code follows the rules and where it’s likely to break. Runtime analysis tells you whether it runs at all. So put a static checker in your build, then use production data before you delete anything.
Does your team maintain code nobody’s sure still runs? Then book a demo of Azul Intelligence Cloud and see Code Inventory on your own JVMs.
FAQs
1. What Are the Limitations of Static Code Analysis?
Static code analysis can’t observe a running program, so it has to approximate. As researcher Michael Ernst puts it, static analysis “reasons over all possible behaviors that might arise at runtime.” It also often can’t find configuration issues, since those aren’t in the code.
2. Can Code Analysis Tools Automatically Fix Code Issues?
Some can. SonarQube’s quick fixes repair certain Java issues with one click in your IDE. For bigger cleanups, you can load a Code Inventory report into an AI coding agent and have it remove unused code. Either way, review each change before it merges.
3. What Are Some Challenges Faced When Implementing Code Analysis in Large Java Projects?
Alert noise is a big one. When a tool flags thousands of old issues at once, people stop reading the results, and they switch off noisy rules. So start with a small ruleset, like PMD’s quickstart set. Then point your quality gate at new code first, so old issues don’t block every merge.
4. How Do You Find Dead Code in a Java Application?
Start with a static tool for unused imports, local variables, and private members. For public methods and framework-wired code, you need production data. Collect method usage across a full business cycle, then compare it against your repo. Azul Intelligence Cloud’s Code Inventory does this across every connected JVM.
