Jar Analyzer: a local bytecode database for auditing large Java applications

Why build a database instead of asking a chat window

The argument the README makes for a dedicated tool rather than a large language model is quantitative, and it is the most interesting thing in the repository. A large application can run to hundreds of thousands of classes and millions of methods, which does not fit in any context window. Jar Analyzer parses the artifact once, stores methods, references and strings in a local database, and then answers arbitrary queries against it in seconds. Every answer is a real class and a real method in the artifact you loaded, not a plausible-sounding guess.

The input side is generous. It takes JAR, WAR and loose classes, accepts multiple files at once, and handles nested fat JARs. It also has the two filters you would want before an analysis run: black and white lists that apply both to database construction and to search, with exact class name and package name matching. Doing that filtering at build time is what keeps a database small enough to stay responsive on a third-party artifact full of bundled libraries you do not care about.

The trade is honest to state. This is a desktop Swing application with ten visual themes and light, dark and orange variants, not a service. It stores state on your machine and expects you to drive it. For the confidential-target case it is built for, that is the point rather than a limitation.

Forward and reverse DFS call chains checked by a simulated JVM

Once the database exists, the core question becomes reachability. The tool builds a method call graph and will search both method definitions and method references, exactly or fuzzily. From any method you can launch a depth-first search of the call chain in either direction, so you can ask both what this dangerous method can reach and what might reach it.

Direction alone is a weak claim in a graph that large, which is why the DFS result is paired with a second mechanism: a simplified simulation of JVM taint analysis, used to check whether a candidate call chain is actually feasible. A path existing in the graph and a path that can be driven with a tainted value are different questions, and the tool gives you an answer to the second one. That pairing is the difference between a graph browser and an analysis tool.

The sinks are not hardcoded into a black box. `dfs-sink.json` sits at the root of the tree next to `vulnerability.yaml`, so the sink definition is a file you can read, and arguably edit before a run. The README describes many common Java vulnerability sinks as built in, and the file layout suggests the rule set is data rather than compiled logic.

Control flow graphs, stack frames and SpEL search as a query language

Two lower-level views sit under the graph work. The CFG view draws intra-method control flow, partitions basic blocks, and shows exception handler paths, which is how you check whether a validation branch actually guards the sink you care about. The JVM stack frame view tracks the local variable table and operand stack through the method, which is static analysis of runtime data flow rather than a printed disassembly.

The feature with the widest reach is the custom expression search built on SpEL. Instead of only asking for a hardcoded string, you compose expressions to search for gadget chains and other patterns, and the results link into the calling context. String search complements it by locating LDC instructions, both fuzzily and exactly, and pinning the hit to the enclosing method.

Entry point analysis is the piece that saves you the most setup. The tool locates and exports Java Servlet and Filter components, plus Spring controllers, so a web application audit does not begin with guessing where the routes are. Against that you get simple SCA, sensitive information leak scanning across static resources and class constants, and a possible gadget finder. The README frames this as covering most situations with far less setup than CodeQL or Tabby, which is a fair comparison to make about onboarding time and not about depth.

JAR diff as the main workflow for patch analysis

JAR DIFF arrived in version 5.21 and gained full record export in 5.22, which turns the tool into a change-driven auditor rather than a one-shot reader. You can compare two builds or compare two directories, and since 5.22 the complete record can be exported for downstream AI analysis. For anyone tracking whether a known vulnerability has actually been patched in a shipped artifact, this is the highest value feature in the list.

Decompilation supports the workflow underneath it. A modified Fernflower is built in, so a double-click decompiles, and JavaParser is used to locate the method position precisely, which matters because the usual failure mode of decompiler-driven audits is losing track of which decompiled method corresponds to which analyzed method.

The README claims five years of continuous updates and 67 released versions across both v1 and v2. The repository is GPL-3.0 with 202 forks and 21 open issues, and the last push was on 2026-09-06.

The MCP server is the AI story, not the analysis story

Version 6.0, published 2026-06-23, added an AI assistant, workflow content and an MCP panel inside the GUI. The panel starts the server in place, supports SSE and Streamable HTTP, and lets you inspect the tool list from the UI. The documented path is to point an agent such as Claude Code, Codex, Qwen Code or ZCode at it and then ask it to use `jar-analyzer-mcp` to look for a vulnerability.

It is worth being clear about the division of labour the project itself draws. The assistant is a front end over deterministic results, not a source of those results, and the README is unusually honest about why. Language models hallucinate class names and call relationships, and an audit that reports a nonexistent method is worse than no audit. So the database answers what exists, the taint simulation answers what is reachable, and the model helps you phrase and drive the questions.

Two related repositories extend that split: `jar-analyzer-engine` holds the core engine, and `jar-analyzer-claude` is a Claude Code plugin. The engine split means a UI is not strictly required, though the GUI is what most people will use.

Four download flavors and what the release notes fix

Distribution is unusual enough to read carefully. Everything is built by GitHub Actions and offered as `windows-full`, which bundles a JRE 8 with G1GC enabled and is the primary build; `windows-25`, bundling a JRE 25 with ZGC that the release notes flag as not fully tested; `windows-system`, which uses a launcher against your own JRE and recommends JRE or JDK 8; and a plain `zip` containing only the jar, started with `java -jar`. macOS users therefore need their own Java, and 6.2 raises that floor to Java 11.

That Java 11 requirement came from a real problem. The 6.2 notes record that macOS combined with Java 8 produced garbled characters and fuzzy rendering, and that investigation concluded the fault lay in Java itself rather than in the tool. The same release fixes a NullPointerException when decompiling `module-info` and an incompatibility between the bundled Fernflower and JDK 25, which explains the JRE 25 build being marked untested rather than being the recommended path.

Version 6.1 is the more interesting release for anyone running this in CI. It closes three advisories by GHSA id: `fgw4-24hw-cjm6` for ZIP SLIP, `77fr-7cxc-mxqr` for denial of service and `xxj8-5qwp-rrmh` for XSS. An analysis tool that unzips hostile archives is itself an attack surface, and a project publishing those fixes by identifier is telling you something useful. Version 6.1 also replaced the GUI designer with native Swing, updated all dependencies, moved the bundled JRE to 8u502 and 25.0.4, and stopped publishing the Go implementation of the MCP code in favour of the embedded Java one.

Editorial conclusion

Jar Analyzer is at its best on the kind of target it was built for: a large proprietary JAR that nobody can hand to a hosted service, reviewed by someone who already knows how Java sinks work. The build-a-database-then-query design is the right call for artifacts with hundreds of thousands of classes, the DFS chain plus simulated taint pairing is more useful than either half alone, and the SpEL expression search is the feature that makes gadget hunting a search problem instead of a reading exercise. What it does not settle is anything about your build: the license is GPL-3.0, so shipping it into a commercial product is a decision the project leaves entirely to you. Start with a black and white list pass and a JAR DIFF against a patched build, because the diff mode is where the tool is clearly more productive than a chat window.

Frequently asked questions

Official sources

1. jar-analyzer/jar-analyzer on GitHub
2. License: GPL-3.0
3. Project website
4. README
5. Releases