Skip to content
codeanalyzer-java

Contributing

codeanalyzer-java is open source under the Apache 2.0 license. Contributions — bug fixes, new framework finders, schema enrichments — are welcome.

Build and test locally

Section titled “Build and test locally”

  1. Install a JDK (11+) and clone:

    Terminal window
    sdk install java 17.0.10-sem
    git clone https://github.com/codellm-devkit/codeanalyzer-java
    cd codeanalyzer-java

  2. Build the fat JAR:

    build/libs/codeanalyzer-2.3.7.jar
    ./gradlew fatJar

  3. Run the test suite:

    Terminal window
    ./gradlew test

  4. Try it against a sample project:

    Terminal window
    java -jar build/libs/codeanalyzer-2.3.7.jar \
      -i src/test/resources/test-applications/<some-app> \
      -a 2 -v

Where things live

Section titled “Where things live”

The codebase is organized under com.ibm.cldk (see Architecture for the full map):

  • CodeAnalyzer.java — the CLI orchestrator; add or change flags here.
  • SymbolTable.java — Javaparser symbol extraction.
  • SystemDependencyGraph.java — WALA call-graph construction.
  • entities/ — the output data model. Changing these changes the JSON schema.
  • javaee/ — framework finders, dispatched by EntrypointsFinderFactory and CRUDFinderFactory.
  • utils/BuildProject.java — Maven/Gradle build and dependency download.

Adding a framework finder

Section titled “Adding a framework finder”

Entry-point and CRUD detection are pluggable per framework. To add support for a new framework:

  1. Pick the dimension — entry points, CRUD, or both — and find the matching factory (EntrypointsFinderFactory / CRUDFinderFactory).

  2. Add a finder under javaee/<framework>/ implementing the finder interface, with the annotations / superclasses / interfaces / method conventions that identify the construct (mirror an existing finder like the Spring or JAX-RS ones).

  3. Register it in the factory so it’s selected when that framework is present.

  4. Set the schema flags — entry-point finders mark is_entrypoint / is_entrypoint_class; CRUD finders populate crud_operations / crud_queries.

  5. Add a test application under src/test/resources/test-applications/ and assert the expected output.

See the existing entry-point and CRUD coverage for the patterns to follow. The Camel finder is a good example of a stub awaiting completion.

Evolving the schema

Section titled “Evolving the schema”

The output JSON is a versioned contract that the CLDK Python SDK and other consumers depend on.

  • Changing an entities/ class changes the wire format. Field names serialize as snake_case.
  • For incompatible changes, bump the version (in gradle.properties) and, where feasible, add a guard for the old shape — as was done for the legacy string-import format.
  • Update the schema docs alongside the code.

Keeping native-image config current

Section titled “Keeping native-image config current”

If you add reflection-dependent code, regenerate the native-image config so the native binary keeps working:

Terminal window
./gradlew fatJar
java -agentlib:native-image-agent=config-output-dir=src/main/resources/META-INF/native-image-config \
  -jar build/libs/codeanalyzer-2.3.7.jar -i <sample-project> -a 2 -v
./gradlew nativeCompile

Opening a PR

Section titled “Opening a PR”
  • Branch from main, keep changes focused, and include a test.
  • Run ./gradlew spotlessApply test before pushing.
  • Reference any related issue in the PR description.
Architecture The pipeline and package layout you'll be working in.
Output schema The contract your changes must respect.

Found a limitation? Open an issue with details.