You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Honor a system/global JDK instead of downloading Temurin per analysis cache #237
Is your feature request related to a problem? Please describe.
PROBLEM
JCodeanalyzer's ensure_jdk downloads a Temurin JDK into each analysis cache dir — per project, potentially per service — so a machine analyzing ten projects fetches ten JDKs. This defeats pre-baking a JDK into a container image and costs a network fetch per analyzed project. Surfaced by COCOA's Docker packaging (codellm-devkit/cocoa#1).
SCOPE BOUNDARY
JDK discovery only. Not the analyzer distribution — sourcing codeanalyzer-java from PyPI was tried and reverted over GraalVM issues (#161, #162, closed won't-do), so the bundled jar stays and this must be solved on its own terms. Not JDK version policy, and not the pinned JDK_RELEASE itself.
GOALS
Probe for a usable JDK before downloading: JAVA_HOME, then a CLDK_JDK env or global cache path.
Verify the found JDK is version-compatible, not merely present.
Fall back to the current Adoptium download when no compatible JDK is found.
Log which JDK was selected and why, at DEBUG.
Document the precedence order.
CAVEATS AND KNOWN RISKS
Presence is not compatibility.JAVA_HOME on a dev machine is frequently stale or points at a different major. Accepting it unverified moves the failure from "slow download" to "analyzer crashes with an obscure JVM error" — strictly worse.
Silent fallback hides misconfiguration: a user who sets JAVA_HOME expecting it to be used, and is quietly ignored, has no signal. Hence the log line is part of the contract, not polish.
The per-project cache dir is also what makes analyses independent; a shared global JDK path is shared mutable state across concurrent runs.
DEFINITION OF DONE
With a compatible JAVA_HOME set, analysis completes and no download occurs — asserted in a test, not observed by eye.
With an incompatible JDK on JAVA_HOME, the run falls back to download and logs the reason.
A container image with a pre-baked JDK analyzes a project with no network access to Adoptium.
Context for whoever picks this up: the PyPI-distribution route (#161, #162) has been closed as won't-do — the Java backend was deliberately reverted to the bundled jar because of GraalVM issues. So the JDK question does not get solved as a side effect of moving Java to a native PyPI binary; it needs solving on its own terms here.
Confirmed still live: cldk/analysis/java/codeanalyzer/_jdk.py fetches and caches a pinned Temurin (JDK_RELEASE = "jdk-21.0.5+11") under the per-project cache dir, with no probe for a suitable system JDK.
Activity
rahlk commentedon Aug 3, 2026
Context for whoever picks this up: the PyPI-distribution route (#161, #162) has been closed as won't-do — the Java backend was deliberately reverted to the bundled jar because of GraalVM issues. So the JDK question does not get solved as a side effect of moving Java to a native PyPI binary; it needs solving on its own terms here.
Confirmed still live:
cldk/analysis/java/codeanalyzer/_jdk.pyfetches and caches a pinned Temurin (JDK_RELEASE = "jdk-21.0.5+11") under the per-project cache dir, with no probe for a suitable system JDK.