The codeanalyzer backends

The Python SDK you call is deliberately thin. The heavy lifting (parsing source, resolving symbols, building call graphs) happens in a family of standalone language analyzers, one per language, collectively the codeanalyzer-* backends. Each one emits the same shape of typed JSON, and the SDK facade deserializes it into the models you query.

flowchart LR
    SDK["CLDK Python SDK<br/>(analysis facade)"] -->|invokes| CAJ["codeanalyzer-java<br/>(JVM · WALA)"]
    SDK -->|invokes| CAP["codeanalyzer-python<br/>(Jedi · CodeQL)"]
    SDK -.->|coming soon| CAT["codeanalyzer-ts<br/>(TS compiler)"]
    CAJ -->|canonical JSON| SDK
    CAP -->|canonical JSON| SDK
    CAT -.->|canonical JSON| SDK

This separation is what lets one analysis API span languages: the facade never parses code itself, it shells out to the right backend, then maps the backend’s JSON onto typed models (JApplication, PyModule, …). Add a backend that speaks the canonical JSON and the SDK can analyze a new language with almost no new frontend logic: see Add a language backend.

You usually don't run these directly

The SDK manages the backend for you: auto-downloading the Java JAR, provisioning the Python analyzer in a virtualenv. These pages are for when you want to understand (or contribute to) what’s happening underneath.

The backends

codeanalyzer-java The most complete backend: WALA + Javaparser, producing symbol tables, call graphs, hierarchy, and CRUD analysis.

codeanalyzer-python Jedi-based semantic analysis with optional CodeQL call-graph augmentation; ships the canonical Py* schema.

codeanalyzer-ts The TypeScript analyzer: the backend exists today; Python SDK support is on the way.