What is CLDK?

CLDK (CodeLLM-DevKit) is a Python library that loads a codebase. It gives you typed models of the classes, methods, fields, and call graph.

You send every query through one analysis object. The object answers questions about structure: which methods call a given method, or which methods that method calls. You do not parse files yourself. You do not join external tools together.

The programming model

Every CLDK program follows the same three steps: select a language, analyze a project, and query the resulting typed models.

1. Select the factory for your language, for example CLDK.java. This factory selects the backend.

2. Call the factory with a project path to build the analysis object: CLDK.java(project_path="commons-cli"). The backend runs at this step and builds the program model.

3. Query the typed models with get_classes(), get_method(...), get_call_graph(), and related methods. You can read these objects, walk them, serialize them, or send them to other tools.

Java

from cldk import CLDK
from cldk.analysis import AnalysisLevel

# 1. select the language  2. analyze the project  3. query
analysis = CLDK.java(
    project_path="commons-cli",
    analysis_level=AnalysisLevel.call_graph,
)

print(len(analysis.get_classes()), "classes")
print(analysis.get_call_graph())          # -> networkx.DiGraph
# 23 classes
# DiGraph with caller -> callee edges

Python

from cldk import CLDK
from cldk.analysis import AnalysisLevel

# Python requires a project_path (no single-file mode)
analysis = CLDK.python(
    project_path="my_pkg",
    analysis_level=AnalysisLevel.call_graph,
)

print(len(analysis.get_classes()), "classes")
print(analysis.get_call_graph())          # -> networkx.DiGraph

Analysis levels

analysis_level defaults to AnalysisLevel.symbol_table, which resolves classes, methods, and fields. Call graphs, callers, and callees need AnalysisLevel.call_graph. If you want call relationships, you must set this level.

CLDK 2.0 adds two deeper levels, program_dependency_graph and system_dependency_graph, which build dataflow. See Dataflow graphs.

A language-specific backend sits behind the same API:

flowchart LR
    A["CLDK.<lang>(project_path)"] --> B["analysis object"]
    B --> C["Typed program model"]
    C --> D["Symbol table"]
    C --> E["Call graph"]
    C --> F["Class structure"]

The language selects the backend. Java uses codeanalyzer-java over WALA. Python uses codeanalyzer-python over Jedi. TypeScript uses codeanalyzer-ts over the TypeScript compiler. Your query code stays the same for each language. Only the backend changes.

Language coverage

You query every language through the same analysis API. A different backend answers for each one. CLDK supports Java, Python, and TypeScript, and all three are production-ready. Java goes deepest, because it adds class-hierarchy analysis. TypeScript also analyzes JavaScript sources, and it detects framework entrypoints.

Language	Status	Symbol table	Call graph / callers / callees
Java	Supported	Yes	Yes
Python	Supported	Yes	Yes
TypeScript	Supported	Yes	Yes
JavaScript	Supported	Yes	Yes

Infrastructure-as-code (Helm) has a beta backend, codeanalyzer-iac. It has no CLDK.iac(...) factory yet, so you run caniac as a command. See The codeanalyzer backends for every backend and its maturity.

Next steps

Quickstart Install CLDK and run your first analysis in three steps.

Installation The JDK, Maven, and backend packages that each language needs.

Core concepts Symbol tables, call graphs, and analysis levels.

API reference Per-language analysis APIs and the typed data models.