codeanalyzer-java

One JAR turns an enterprise Java project into a symbol table and call graph — emitted as a single versioned JSON document, or projected losslessly into a Neo4j property graph your tools can query.

Quickstart Output schema GitHub

Point codeanalyzer-java at a Java project and get back analysis.json — a single document describing every class, method, field, and import in the codebase, plus an interprocedural call graph computed by WALA. The schema is the same shape the CLDK Python SDK deserializes into typed models, so whatever consumes it — an agent, a script, or the SDK — works against structured analysis instead of raw source.

The same symbol table and call graph can also be projected, losslessly, into a Neo4j property graph with --emit neo4j — a re-runnable graph.cypher snapshot, or a live, incremental push over Bolt. One database can hold many applications side by side, each anchored at its own :JApplication node, so cross-service questions become a Cypher traversal instead of a memory problem. The SDK can then read straight from the graph — no JDK, native binary, or project source on the consumer.

Start here

What is codeanalyzer-java? The mental model: project → JAR → analysis.json or Neo4j graph → typed consumers.

Quickstart Build the JAR and run your first analysis in a couple of minutes.

Installation Run as a fat JAR, or compile a native binary with GraalVM.

Architecture The pipeline: Javaparser symbol extraction + WALA call-graph construction.

Go deeper

CLI reference Every flag: input, analysis level, emit target, Neo4j connection, target files.

Output schema The full shape of analysis.json — symbol table and call graph.

Neo4j graph output Project the analysis into a shared Neo4j property graph with --emit neo4j, and read it back from the SDK.

Analysis levels Level 1 (symbol table) vs. level 2 (+ call graph), and what each costs.

Python SDK integration How CLDK consumes this JAR — shelling out to it, or reading the graph as JavaAnalysis.